Project failure is relative; most projects fail in part, 40% of projects fail overall in terms of net value delivered. This is avoidable if you use a value perspective.



Compromise as Failure

If the project is building your house, every compromise made from your desired specification is a degree of failure.

So ‘failure’ is just not the wholesale cancellation or collapse of a project; but every deviation from what was required.

Each compromise that moves the final outcome away from the planned outcomes increases the degree of failure. Each compromise—intentional or not—reduces the resultant value of the result.

Compromised but OK

Now some compromised outcomes are still highly beneficial. They still deliver significant benefits despite the degrees of compromise embedded in the solution. The patio doors in each bedroom may have been replaced by smaller windows in order to save costs, but the bedroom is fine albeit the patio is now not accessible. The house is eminently livable in but ‘breakfast on the patio’ is no longer an easily available benefit.

Compromised to death

But there comes a tipping point when individual decisions or the accumulation of compromises tip the solution from beneficial to negative. A reduction in your house's ceiling height from, say, 12 feet to 8 feet will totally destroy a planned ambience of space and lightness. The house will still ‘work’ but will totally miss the livability criteria defined.

Compromises v realism

Now we all know that life is full of compromises—but the opposite of compromises in this context is not perfection but realism. What you should be aiming to deliver should not be utopia but a realistically achievable set of outcomes (established at the business case stage).

Importantly, this realistic goal should be seen as the ‘minimum’ to be delivered rather than the maximum.

In one methodology I read some years ago the project teams were told to identify the business’ minimum criteria and then set that as their target (ie their maximum goal).

The impacts of compromises

The impact of compromises is obviously different dependent on their nature. Some will eliminate nice-to-haves (eg breakfast on the patio) whereas others can destroy the whole point of the project.

A steering committee seeking to avoid a cost overrun eliminated one aspect of the proposed solution’s design. This cost-saving-driven decision eliminated one of the two major benefits the project was to deliver—it’s ease-of-use. As a result, the staff still had to take 10 minutes each time they used the system rather than the planned 3 minutes. This additional operational cost was not considered when the cost-cutting compromise decision was made.

So failure is not absolute. There are degrees of failure. But at some stage the accumulation of compromises, mistakes and failings can render the whole project a ‘total failure’, NB Around 40% of projects leave their organizations worse off than before they were started.

Delivered project failure is all too common and too commonly accepted.

 

Compromise v value

Every compromise you make on your project reduces its potential value. Compromise should therefore be resisted rather than accepted.

In Conclusion

The key is to tackle the root cause of compromise. Each suggested compromise (eg scope change) or actual compromise (e.g. delivery shortfall) should be assessed in terms of its impact on the project’s desired business outcomes, benefits and value. As soon as the net value or the strategic intent of the project is nullified by one or cumulative compromises, the project should be stopped and the remaining funds allocated to more worthwhile projects.

NB Around 40% of projects are compromised to death. They deliver no net value. Yet this can be avoided if you use a value assessment perspective on every proposed or delivered compromise.

When you eliminate compromise, you eliminate waste and failure.

It really is that simple.

 To discover how simple it can be view "Delivering successful projects can be simple"

Topics: Project Success

Further Reading

 




Footnotes

[1] ...





Revision History

First published: Simms, J. (Mar 2016) as "When Does A Project 'Fail'?"

Updated: Chapman, A. (March 2020), Revisions and Corrections