« The Four Breakthroughs for Creative Solutions | Main | Project Fault Lines in Implementation Designs »

October 17, 2005

Why Projects Fail

It seems obvious that if any project is going to be rated a success, there are three high-level issues to successfully manage: Quality, Timing, and Expectations. Mismanagement in any of the three areas pulls the project towards what would be considered "failure."

But in looking at the project as an action, failure should be understood in two ways: in terms of "technique" and in terms of "outcome".

Every project is designed with the presumption that its technique will cause the intended outcome, but the execution of the design may involve an actual experience to the contrary. One point to make clear here is that it is possible for execution to be very good without the intended outcome being generated. This is because a project deliverable is not in itself an impact -- instead it is just a resource that has an impact when utilized.

In every complex structure, the potential value of its capability is designed in, and the actual value of the capability is the result of its reaction to stress. Projects, which are complex structures, are just an example of this.

All projects have the same basic function -- to *produce* something that, according to the specifications, wasn't already there. From the viewpoint of the designated recipient, "production" takes place in a variety of ways that might include buying, borrowing, and/or building the specified "product"... Depending on the recipient, it may not matter how the production was conducted. But from the management standpoint, what these three things have in common is that in their execution each one will depend on (deep breath) a "process" that is used to account for progress in the terms of a "project." It's noteworthy that the form of the process might need to adapt to the project's needs, either in appearance or in actual conduct.

This particular accounting is why, within every project, there is a group of what we should call "progress requirements".

The role of a manager is to ensure that actual technical progress is aligned with actual outcome progress.

A progress requirement becomes a criterion against which the processes that are used within projects should be selected and controlled. Therefore, one source of project failure can be *execution* -- namely, inadequate process management, including inadequate process integration.

*Impact* failure is an evaluation taken as a fact. This is interesting because of the law of unintended consequences, and because not all unintended consequences are undesirable or without great value. But to the point, since projects do not evaluate themselves, the perspective and terms of the evaluators are the place where anything that happens can make the ultimate difference. Inadequate precision and stringency in the terms of evaluation are therefore sources of project failure. Notably, this inadequacy can include unresolved conflicts and omissions amongst multiple stakeholders. Producers are stakeholders, too, along with owners, operators and users.

Since processes and stakeholders don't sit still over time, alignment of technical progress and outcome progress in the project must be defended dynamically, not statically. If managers do not continuously create effective relationships between processes and stakeholders in a project, then misalignment will pull the "project" towards failure even though "production" may have never halted.

Posted by Malcolm Ryder at October 17, 2005 9:14 AM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/144

Comments

Post a comment