in Uncategorized

Why Projects Fail

Did you know that  68% of IT projects fail – 44% of these projects were late, over budget, and/or had fewer than the required features and functions, and 24% were cancelled prior to completion, or delivered and were never used (Source: Standish Group’s 2009 CHAOS report). With statistics like these, it’s just a matter of time before you’re dealing with a project that is spiralling out of control. How do you get things back on track?

Or take a look at the latest high profile projects failure and the consequences for senior executives – “Confusion” led to BBC digital project failure.

bbc failure

Why do projects get in the red?
Firstly, let take a look at the top reasons that projects get into trouble – then we can look at what we can do about it.
The top three reasons that projects fail to deliver are:
1. Poorly defined requirements
2. Poor or inadequate project leadership
3. Poor or inadequate controls

What can we do about it?
The devil is in the detail, and you need to lift the hood and get down into the detail. The good news is that the solution is always found within your current team and all that is needed is to bring clarity of purpose to the team and put the focus on performance. How you ask.

Treat this as a new beginning and remember, project don’t fail at the end, they fail at the beginning.


Firstly you need to seek clarity on the exact requirements and the remaining scope of work. Clarity with respect to the purpose and what is essential – is it time critical, is it essential that all the scope is delivered on day one or can you live with an interim solution on the way to a final solution (one note of caution, there needs to be a master plan that delivers both as part of your recovery plan), what level of quality is essential with respect to delivery. Get the team in a room and explore this in detail – make sure that the customer and key decision makers are part of this process. Document your finding and agree upon them as a team. If there is any conflict, now is the time to resolve it.
Establish some core working principles during this stage that can guide people as they seek to rapidly execute your project to a recovery path. Make sure that your break the work down into interim deliverable that can be more easily managed.


Once you have clarity of purpose, you need to pass it through the “Is it essential?” filter. This exercise needs the key solution architects and all the key stakeholders. Take time to discuss the consequences of including or eliminating certain elements – full and frank discussion is mandatory. Execute this phase as quickly as possible as there is a team looking for direction.
Don’t leave the room until you have full agreement – the leadership team need to commit to one plan. Update your plans – this is what you are now going to deliver.


Now that decisions are made, you need to communicate them clearly to the team and how you are going to manage and monitor them. From the phase above, you should have:

  1. A renewed project brief outlining the remaining scope of work and all key attributes – everyone working on the project must read this.
  2. A work breakdown structure (WBS) with details of each package, who delivers what and interdependencies.
  3. A milestone schedule built from the WBS
  4. A schedule
  5. A list of deliverables

You need to have a clear, visible scoreboard that indicates whether you are winning or losing and this needs to be updated daily (or at least weekly).

Get the team together and walk them through the new plan in detail.

Sweat the details.

This is the very topic which I am writing a book on – sign up and receive a chapter from the book. Plus, you will be too first to be informed on its launch.

Leave a Reply