Why Projects Fail and What To Do About It

Back in 2002 the UK Office of Government Commerce (OGC) and National Audit Office (NAO) agreed eight common causes of project failure which were disseminated to Government Departments in February 2003. These are listed below for ease, but should be read in conjunction with the NAO Report.

  1. Lack of clear link between the project and the organization’s key strategic priorities, including agreed measures of success.
  2. Lack of clear senior management and Ministerial (for ‘Ministerial’ read ‘Board Level’) ownership and leadership.
  3. Lack of effective engagement with stakeholders.
  4. Lack of skills and proven approach to project management and risk management.
  5. Too little attention to breaking development and implementation into manageable steps.
  6. Evaluation of proposals driven by initial price rather than long-term value for money (especially securing delivery of business benefits)
  7. Lack of understanding of and contact with the supply industry at senior levels of the organization.
  8. Lack of effective project team integration between clients, the supplier team and the supply chain.

In May 2005, one particularly high profile IT project was certified by the Home Office’s Programme and Project Management Support Unit as failing, and was subject to ministerial review and redefinition. The project to produce a national case management system to provide end-to-end offender management for the Prison and Probation services was called C-NOMIS, and after review was projected to be massively over budget. Interestingly, in it’s report, the National Audit Office found that C-NOMIS suffered from four of the eight common causes of project failure in full, and three in part; that must be some kind of record!

The project was laced with odd practices, which probably seemed like a good idea at the time, but in the light of day seem to be at best, short sighted. For example, the authority (the National Offender Management Service or NOMS) did not seek to revise its contractual arrangements with Syscon, the software developers, immediately the extent of the customization of an off the shelf product became clear. This is like a major corporation paying Microsoft to rewrite a substantial part of the Office suit, and then allowing Bill Gates to sell the product without a share in the profits made from the improvements. The supplier Syscon is now able to market the improved software, but taxpayers will not benefit from their investment in the product. This is not a criticism of Syscon, far from it, as they have clearly exercised their duty to their shareholders. However it does beg the question “What where NOMS thinking?”

As TechCo have decades of project management experience it is appropriate to list the guidelines we use:

  • Identify the aims of the project (including the strategic priorities) and define success in those terms. Often when you list them, there are mutual conflicts, which must be resolved before the project starts. For example deadlines around financial accounting periods (actually a constraint) and the need for a dynamic system which must respond to any change of circumstance or eventuality. If those conflicts can not be resolved, then the project should not start.
  • As the success of a project is 20% technology (the systems, processes and tools used) and 80% psychology, make sure that your key project staff are trained in people skills and team dynamics.
  • Then ensure that the board or senior management are fully engaged with the project.
  • For more information see the following links:

    Friday, August 20th, 2010 General