Eight to Late

Sensemaking and Analytics for Organizations

Planned failure – a project management paradox

with 6 comments

The other day a friend and I were talking about a failed process improvement initiative in his organisation.  The project had blown its budget and exceeded the allocated time by over 50%, which in itself was a problem. However, what I found more interesting was that the failure was in a sense planned – that is, given the way the initiative was structured, failure was almost inevitable. Consider the following:

  • Process owners had little or no input into the project plan. The “plan” was created by management and handed down to those at the coalface of processes. This made sense from management’s point of view – they had an audit deadline to meet. However, it alienated those involved from the outset.
  • The focus was on time, cost and scope; history was ignored. Legacy matters – as Paul Culmsee mentions in a recent post, “To me, considering time, cost and scope without legacy is delusional and plain dumb. Legacy informs time, cost and scope and challenges us to look beyond the visible symptoms of what we perceive as the problem to what’s really going on.This is an insightful observation – indeed, ignoring legacy is guaranteed to cause problems down the line.

The conversation with my friend got me thinking about planned failures in general. A feature that is common to many failed projects is that planning decisions are based on dubious assumptions.  Consider, for example, the following (rather common) assumptions made in project work:

  • Stakeholders have a shared understanding of project goals. That is, all those who matter are on the same page regarding the expected outcome of the project.
  • Key personnel will be available when needed and – more importantly – will be able to dedicate 100% of their committed time to the project.

The first assumption may be moot because stakeholders view a project in terms of their priorities and these may not coincide with those of other stakeholder groups. Hence the mismatch of expectations between, say, development and marketing groups in product development companies. The second assumption is problematic because key project personnel are often assigned more work than they can actually do.  Interestingly, this happens because of flawed organisational procedures rather than poor project planning or scheduling  – see my  post on the resource allocation syndrome for a detailed discussion of this issue.

Another factor that contributes to failure is that these and other such assumptions often come in to play during the early stages of a project. Decisions that are based on these assumptions thus affect all subsequent stages of the project. To make matters worse, their effects can be amplified as the project progresses.    I have discussed these and other problems  in my post on front-end decision making in projects.

What is relevant from the point of view of failure is that assumptions such as the ones above are rarely queried, which begs the question as to why they remain unchallenged.  There are many reasons for this, some of the more common ones are:

  1. Groupthink:  This   is the tendency of members of a group to think alike because of peer pressure and insulation from external opinions. Project groups are prone to falling into this trap, particularly when they are under pressure. See this post for more on groupthink in project environments and ways to address it.
  2. Cognitive bias: This term refers to a wide variety of errors in perception or judgement that humans often make (see this Wikipedia article for a comprehensive list of cognitive biases).  In contrast to groupthink, cognitive bias operates at the level of an individual.  A common example of cognitive bias at work in projects is when people underestimate the effort involved in a project task through a combination of anchoring and/or over-optimism  (see this post for a detailed discussion of these biases at work in a project situation). Further examples can be found in in my post on the role of cognitive biases in project failure,  which discusses how many high profile project failures can be attributed to systematic errors in perception and judgement.
  3. Fear of challenging authority:  Those who manage and work on projects are often reluctant to challenge assumptions made by those in positions of authority. As a result, they play along until the inevitable train wreck occurs.

So there is no paradox:  planned failures occur for reasons that we know and understand. However, knowledge is one thing,  acting on it quite another.  The paradox will live on because in real life it is not so easy to bell the cat.

Written by K

June 16, 2011 at 10:17 pm

6 Responses

Subscribe to comments with RSS.

  1. Two days ago, finished reading the “CRITICAL CHAIN” (by Eliyahu M. Goldratt). It seemed to me interesting and useful. May be it would be useful and your friend?



    June 17, 2011 at 5:24 pm

    • Vladimir,

      Thanks for your comment. The critical chain method is essentially a scheduling technique. As such it does not address organisational-level issues associated with the resource allocation syndrome. Further, as I have discussed above, planned failure can occur for reasons that have nothing to do with scheduling.





      June 18, 2011 at 5:47 am

  2. K,

    In some procurement processes (NAVAIR for example), past performance in the Basis of Estimate cannot come from “best engineering judgement.” It must be validated by actual “past performance” means tangible evidence that the cost, schedule, and technical performance can be confirmed in one of several ways. “Similar to,” “Like,” “Parametrically scaled,” or “verified model,” or something like. Engineering opinion is simply not allowed.


    Glen Alleman

    June 18, 2011 at 6:53 am

  3. Glen,

    That’s a good point, and one that I should have made. I agree that estimates ought to be based on hard data. However, one has to be certain that the data used is actually relevant to the current project (the so-called reference class problem). That said, “planned failures” can occur for other reasons as well – unvalidated assumptions regarding resourcing being one; unreconciled diversity of views regarding the project being another. Although theory tells us that these kinds of issues ought to be sorted out up front, in practice they sometimes (dare I say, often) aren’t.





    June 18, 2011 at 4:12 pm

  4. I actually winced when I read that. Brilliant article, and quite spot on… poor organisational structures doesn’t just mean people get more work assigned to them that they can actually do, it also (in my experience) results in people being allocated work that they aren’t neccessarily qualified to do, and even worse, the paralyzing conflicts that ensue when differing people up and down the chain try to take responsibility for the same critical functions out of sheer necessity. Yep, I’m still wincing.


    Dries Smit

    July 19, 2011 at 6:17 pm

  5. Indeed!
    In past January I gave coaching in Quito, and asked the teams to assess failed projects for the factors of their failure. In ALL cases the factors were previous to the very beginning of the projects, not those execution risks we put, like heavy rain, earthquakes, lack of money, etc.

    In another case I reviewed a 200-project history in some software factory, and MOST projects had 150-200% shift in cost and schedule. However, with the facts at hand, management refused to adjust the Function Point modulus.

    This -and I confess is a late recognition, much at odds with my preferences- suggests to me that companies should really try to mature in PM, and at the same time have an eye put on “Management”. For it seems that Management (à la HBS or Taylor) is requesting too much optimization and thus making initiatives be too fragile and without “fat” to do tactical adaptations.

    I made abuse of the fact that I am no physician and invented the Cypher Syndrome: when people chooses to live in the Matrix instead of dealing with reality, because reality sucks. Just imagine! Companies invest zillions in brilliant plans that everybody buy but that nobody pay.

    An example: after a conference I gave in Rio, a guy told me that he worked at the largest Oil&Gas company in Brazil, Petrobras. The CEO, a fierce woman, told the managers at a $3000B program internal kickoff: “if someone doubts we’ll be successful bay Q3 2012, he or she can leave the room now”. The guy and everyone else knew that the initiative would never succeed, but no one complained. That for an Ethics code! Survival was first.

    Great Work, Kailash!


    Ricardo Guido-Lavalle

    November 13, 2015 at 11:45 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: