Why Projects Really Fail
This is a subject that has been endlessly written about, probably since the Stonehenge or the first pyramids were planned (or not!). As professionals we know that almost every project goes through difficult phases, as they evolve from concept to conclusion. Given the level of intellectual investment made, why do projects still go wrong, need to be recovered and why do they continue to be delivered late and over budget? Are we really missing something?
This written piece seeks to provoke yet further discussion and proposes three root causes (and one imperative) to explain the root causes of project failure. They are definitions, people and sponsorship and the imperative of deadline. Applicable to almost every project, they are relevant and go to the heart of what causes projects to go wrong.
All projects must operate to a set of common definitions, whether in terms of language, lifecycle approach and methodology. Without these, project team communication can become difficult with resultant misunderstandings. Teams assembling to deliver projects bring their own knowledge, skills and experience and in addition their own habits, good and bad, and preferred ways of working.
Small project team may feel less impact from a lack of definition but may still see a tendency to work at cross purposes. On major projects this lack of clarity can represent a much more significant issue. Project professionals recognise and respond to structure. In all cases a well written and fully communicated set of core project documents and the definition they provide will create alignment, increase understanding and mobilise the project team around a shared and common way of working.
People prefer certainty, well defined boundaries and clarity of role and responsibilities when working within teams. They operate more effectively when good performance is rewarded and poor performance is challenged and not ignored. As projects evolve over time, the skill needs change from a development focus to delivery and then bringing into operation. The role of project leadership is to signal the change from stage to stage and support the transition. With moves from stage to stage responsibilities change and with this tenure in role. Maintaining certainty by providing clarity remains key even during role development, demobilisation or transition to a new project.
Good definition and project execution planning enabled by structured organisation and operating models will support the recruitment of the right people in to the right roles at the right time and with the right sense of purpose; not just warm bodies to occupy a desk! With structure, alignment and clear accountabilities comes better communication and collaboration and less reasons to disrupt by straying across boundaries or dipping down.
My third and final root cause is sponsorship. Without a senior sponsor holding the organisation accountable for delivery of the outcomes and benefits that the project team has committed to deliver, projects are destined to follow a slow and painful path through delay, time and cost overruns and interventions.
A strong executive sponsor will demand progress updates, recognise the importance of consequences being a driver for success and create organisational “pull” for the project and what it is designed to deliver.
Projects without this risk being driven by committee leading to decisions being made at the lowest common denominator, subject to disruption by politics and exposed to endless change and instability. Projects are not democracies, they need leadership with authority, though not at the cost of appropriate checks and balances.
On my sole imperative of deadline, all projects need defined interim and end points (milestones and gateways), to enable progress tracking and to maintain focus; without these, project teams will find any number of reasons why agreed activity cannot be done, more work needs doing and key dates needs to be rescheduled, reducing certainty and impacting scope, time and cost.
These are my three root causes: definitions, people and sponsorship and the imperative of deadline - all of which are essential to creating an environment for project success.
Over the coming months I plan to discuss each area in more detail, but for the time being, this is represents my hypothesis about why project fail.
Good read, Iain. However, in reading the beginning of the article, I was expecting to know what is your definition of "failure". Generally, I agree with the causes you mentioned, however, I believe these root causes could only be eliminated in an ideal world. Take, as an example, the quality of a product at the end of the project is found to be low. After research, it turns out that people made mistake, the contractor faced financial difficulty, and the government imposed requirements which affected the quality, and the weather condition also had some impacts on the product. Lets face it; sometimes, things get out of hand, and we could only mitigate the negative consequences. So, should we call this a failure?
Good Article Iain, I agree with everything you've wrote
Iain, perfect synopsis of where our profession sits. Your ‘Definition’ and ‘People’ of your three telling factors are interesting for the latter group do indeed come to us with their own ideas on HOW the lifecycle will be delivered and managed oftentimes not giving anything but a cursory glimpse towards the former: much less following the needs of the processes generated by that definition item. And that so neatly ties to your sponsorship from which the governance need is derived - or not! I constantly see the fallout from failures against your simple assessment as a result of performing Integrated Baseline Reviews and the like. Great read Iain, thank you. gs