Why Projects Fail ? (Project Best Practices 1 of 2)

We have all seen the studies – all pointing more or less to the same fact that around half of all IT projects started fail, or fail to reach their objectives, and/or are plagued by massive delays and budget overruns. I have seen my share of those at many clients in my 23 years at Accenture.

In this article series, I want to share some of the most common reasons for project failure that I have seen. Hope these help you to avoid or at least lower the risk for failure on your projects!

This first part focuses on the project definition phase, from the initial project idea through project design until formal project kickoff.

The second part then covers project mobilization and project execution, until project closure.

OK, lets get started!

Project Definition Phase

This is where all evil starts. In my view, most project failures can be traced back to decisions made or not made during project definition. Unfortunately, many organizations approach this phase with not enough rigor and discipline, or lack expertise to do a proper project and solution planning.

Let’s look at what needs to be done here:

  • Be clear on the project’s ‘big idea’ and what goal it is supposed to achieve: specific, tangible, measurable (a SMART goal). Is this a new business or technical capability? A new product? Is its goal to reduce cost (how much off the baseline?) or increase revenue (by how much?). Or does it address client or people satisfaction (increase by how much?). Have a clear problem statement.
  • Define Scope: My Accenture pre-sales colleges remember: we rejected all proposals that were not able to define a one-page scope document, with a red rectangle delineating the project boundaries. This can be a system schematic, function map, process map, or organization chart. In any case it must be we clear what the project covers and what not.
  • Define Solution: how, exactly, are you planning to solve the problem and achieve the project goals? Is it a tool, s new software, a widget, process, training, etc. or a combination thereof?
  • Estimate Effort: This is essential, and should be based on your in-house estimating models, or an industry or reputable vendor estimating model. And do not only estimate the implementation cost, but also the ongoing cost of maintaining the solution. If you have neither, get an expert in. In any case the estimate needs to be validated by an expert in the subject area of the project. Create a high-level timeline. This is essential input into:
  • Create Business Case and Risk Log (commercial validation): You have a fairly good and quantitative view of what the project goals are.  Now you have an estimate for implementation and ongoing efforts, you can check whether it is actually worth doing the project! Now is a great time to kill this idea if it is not worth it! In addition,  have a look at the risks that can potentially jeopardize project success. Weigh them by likelihood and impact, design mitigation actions.
  • Stakeholder Approval: if the project survived the commercial validation, it is time to get everyone aboard and signed-up. For this, you should also be clear on what you expect from the stakeholders in terms of contribution: is it just rubberstamping, or money, or people for this project (which ones, how long, % of dedication), etc.
  • Create sourcing model and detailed project plan: staff the key roles first – project manager, functional architect, technical architect, business analysts. Then look at filling up the team to cover the effort and meet the expected timeline. Look at internal and external resources. Look at the cost profile of the planned team to stay within the approved cost budget. Keep at least 10-15% contingency
  • Get suppliers on board: if your project relies on products and services of vendors, get them aboard and negotiate contracts.

Now, what are the top reasons for project failure rooted in the project definition phase? Clearly, if you miss any of the activities outlined above, you increase the risk of failure.  In my experience, here are the ones that hurt the most:

  1. Fuzziness around project intent and goal: if you can’t articulate those well, how can you expect to motivate an A-team and get enthusiastic stakeholder support?
  2. Wrong solution for the problem: In the old days, the answer to all problems IT was IBM, then for a long time SAP, today it seems the answer often is agile and cloud. My point here is to make sure the solution addresses the problem, effectively, cost and otherwise, and not just provides a new sandbox for your IT architects or a sale for your favorite IT vendor.
  3. Failing to get the right team: no matter how well you do everything else, a weak team will most likely cause the project to miss its value target, and/or blow budget and timeline. But more on this in the next article.
  4. Fuzzy scope: deadly. If you don’t  know the scope, how can you design, estimate, cost a solution? Agile may be a way out of this, but only if you are clear on project intent and goals, and have full stakeholder support for an incremental approach.
  5. No business case: you will be found out, and your project killed. Certainly when one of your benevolent stakeholders changes.
  6. Underestimated effort: very common and ‘de rigueur’ in large, public projects such as Stuttgart 21 or the BER airport. I’ve seen clients that deliberately do this to get projects approved in the first place. They are so used to change request procedure that everybody expects an underestimation in the beginning. For me, as an engineer, this is unacceptable.

This list should give you a good start. If you feel that you or your team lack experience in any of these steps, get an expert in. In this phase, this is money very well spent. Imagine you have to fix a project months later after it went off the rail – that is going to require much more effort and headache!

Leave a Reply