The Reasons Projects and Programmes Fail

In this post I’ll be describing the five categories that I’ve identified of reasons that Projects and Programmes Fail, this categorisation has been built up from doing a large number of system, project and programme reviews and audits over the years, and this article follows on from the project review and programme audit framework which I wrote about recently.

Whatever problems are found in a project or programme in my experience they can be broken down into these five categories:

  1. Strategic / Alignment
  2. Contractual / Financial
  3. People / Politics
  4. Process / Procedural
  5. Technical / Architectural

For a number of years my categorization of reasons why projects and programmes fail did not include “Strategic / Alignment” as an area, and was a model made up of just the other four categories, but then I kept coming across a couple of definitive reasons why it should be added; more on this below.

So lets look at these five categories individually in more detail:

    1. Strategic / AlignmentA fundamental lack of strategic alignment to the Business has been made.

      Basically the project should never have been commissioned in the first place. It is either not required whatsoever (and yes, shockingly, I have come across this happening), or is no longer required (either because of a change of business circumstance, or functionality overlap with another system, i.e. something else does this just fine thank you very much).

      A lack of an Executive Sponsor is a good indication that this could be an issue, and even if the project or programme is some form of ‘Skunk Works’ you would expect the overall ‘Skunk Works’ innovation concept and framework to be supported by an Executive Sponsor, such as the Head of R&D;, and for a watching brief kept over costs versus potential revenues and benefits.

      Projects and programmes which are purely or highly non-functional, and provide limited, or unperceived business benefit, may also be an indication of this issue.

    1. People / PoliticsGetting people to work together can be complex and difficult, especially when their goals are not co-ordinated. Long term political enemies, people competing for resources, promotions and remuneration, are all potential issues.

      This magnifies up at a macro level into business units being in competition for talent, resources and even access to customers and partners. Programmes where multiple business units have to work together and integrate systems and functionality are almost always problematic, even when there are serious penalties if it not done.

      In general Governance compliance issues and management failings also fall into this category, as do business conduct issues, moral, etc.

    1. Process / ProceduralThe process is ‘broken’. Procedures are not in place or are not being complied with. It is either the wrong process to have been used in the first place, is not being adhered to correctly, or is not even being used at all.

      A process is in place but it is over subscribed and can not ‘scale’, alternately a process does not have enough people to service it, perhaps because of downsizing or such.

      The status of a capable Project Management Office (PMO), or of stable, authoritative, Document Repository are also indicators that there is a problem in this area, as is a lack of due diligence when managing and implementing change control.

      Governance in terms of appropriate operating model and related procedural items are here too.

    1. Contractual / FinancialFor some reason the financial arrangements of the project are having a negative impact on the ability to deliver that project. The contract is counter intuitive perhaps, or is weighted in such a way that means that the ends are not easily achieved, or does a poor job of defining the requirements.

      If you hear something like the “spirit of the contract” versus the “word of the contract” then this is a good indicator that there is an issue with the contract and that it doesn’t cover what is wanted or expected.

      Be aware that this is likely to be a problem shared by the client and their vendors as mutual understanding of what can be delivered versus what is wanted and needed by the business. This a re-iterative learning process as the business learns more about what can be delivered by technology and the system defined, whilst those involved in delivery learn the semantics, language and nature of the business and experience more of the challenges that the business has.

  1. Technical / ArchitecturalThis is last for a very good reason, and that is this is often the least contributing factor in terms of projects failing to deliver.

    When there are issues in this area in my experience it is often one of not having the appropriate people and skills at the right time, or not even identifying the key individuals you require accurately, rather than hard technology issues.

    Other issues are architectural and compositional problems (more on architectural issues in an upcoming article), access to resources at the right time, and the typical technology compatibility issues (i.e. “what works with what”) and access to vendor technology and knowledge bases.

    As a reviewer of projects and programmes which could be failing it’s likely that you will have come from a technology implementation background and that this area is well within your ‘comfort zone’, but I assure you that in the majority of cases technology may well be a minor contributing factor to the failure of an overall project, nor is the hardest problem area to improve upon (with good recommendations, of course), but it may be an area that you could potentially over focus upon and lose sight of more significant issues at hand.

Again, hope you enjoyed the article, will try and look at some other pieces, such as the top architectural mistakes made, how to identify possibly failing projects and suggestions for rescuing them.