It’s not unusual to read in the newspapers about government-run projects failing. It’s not just public sector projects though which can go disastrously wrong.
Private sector projects also fail, but we don’t often read about these because unlike government projects, there’s no external auditing and democratic accountability as is the case with taxpayers’ money.
One such example of a private sector project which failed is the automated fulfilment system project set up by Sainsbury’s supermarket. Intended to increase efficiencies, and streamline operations, it was installed in 2003 only to be scrapped 4 years later because of “horrendous” barcode-reading errors. The project cost Sainsbury’s £150 million. 
Over recent years in the UK, some of the highest profile projects which have been deemed failures include the following (start years shown):
- 1997 - The Government's communications headquarters (GCHQ) new accommodation programme originally estimated to cost about £40m but ended up costing more than £300m. 
- 1998 - The Libra courts system – described by Edward Leigh, chairman of the Public Accounts Committee, as "one of the worst IT projects I have ever seen. It may also be the shoddiest PFI project ever." This project was originally forecast to cost £194m over 10 years but actually ended up costing £390m over 8 years, although £60m of this was due to an increase in the scope.
- 2004 - FiRe Control – this IT-led reform of Fire and Rescue Services cost taxpayers £494m only to be cancelled in 2010 without delivering any of the promised reforms.
- 2004 - The C-NOMIS prison case management I.T. system which ended up costing £444m, far more than the original £234m budget and which was described by the same Edward Leigh in the following terms: "Clearly this project was handled badly, it achieved poor value for money, many of the causes of delays and cost overruns could have been avoided.”
This article is going to try to get to the bottom of why the C-NOMIS project failed, and will look at recommendations from the government’s own project management standard method (PRINCE2®) to see what can be done on future projects to help avoid such massive failures again.
The C-NOMIS case study
The C-NOMIS project was initiated by the National Offender Management Service (NOMS) in 2004 as part of a programme to improve the way in which offenders are managed by prisons and probation services across the UK.
The key benefit expected of the overall programme was a reduction in the rate of re-offending. The desired outcome of the C-NOMIS project was a single, integrated case management I.T. system to support end-to-end offender management, information sharing, continuity, and follow up. Originally it was specified that the single system was to be rolled out across public and private prisons and probation services in the UK and Wales.
The target finish date for C-NOMIS was January 2008, but was cancelled in 2009. The remnants of the C-NOMIS system (renamed Prison-NOMIS) were later integrated into the NOMIS Programme which completed in March 2012 but with major parts of the original requirements not implemented. Prison-NOMIS was only rolled out across the prison service, and not the probation service as originally intended .
In 2009, the National Audit Office (NAO) published a damning report that exposed the C-NOMIS project as subject to not one, but seven of the eight causes of project failure identified by the Office of Government Commerce (OGC) (now the Cabinet Office) in 2002 . The report’s conclusions for each of the eight points were as follows (whether or not the project showed one of the eight causes is shown in brackets):
|Cause of failure||A cause on this project|
|No clear link between the project and the organisation’s key strategic priorities||Partially|
|Lack of clear senior management, ownership and leadership||Yes|
|No effective stakeholder engagement||Partially|
|Poor approach to project and risk management||Yes|
|Too little attention paid to breaking down the project into manageable stages||No|
|Evaluation of the Business Case is driven by initial price rather than by value for money||Partially|
|Failure to understand or collaborate with suppliers at senior management levels||Yes|
|Non-integration of customer, supplier, user and project management team||Yes|
The rest of this article will examine each of these causes in turn and how they impacted on the C-NOMIS project.
Failure of strategic alignment
OGC’s causes of project failure - 1: ‘the absence of any clear link between the project and the key strategic priorities of the parent organisation’
The NAO report declared the failure of the original C-NOMIS. It described how the project had demonstrated seven out of the eight primary causes of project failure. Although the de-scoped NOMIS Programme has now delivered the case management I.T. system to all UK prisons, important questions remain - Why was the project managed so badly? Why was mismanagement of the project tolerated for so long? What value-for-money that can be expected from vast government programmes of this kind?
The “key strategic priority” of NOMS was to reduce the rate of re-offending in the UK, through the implementation of end-to-end offender case management. This would entail matching a single case manager for every offender, and making offender information available to the appropriate individuals within both the prison and probation services.
The C-NOMIS project was set up to create a single, integrated database for all offender information. By integrating the information management systems across over 140 prisons, as well as the 42 administrative areas of the National Probation Service, NOMS hoped to redefine how information about offenders is managed, in order to improve the continuity, consistency and efficiency of offender case management.
To this extent, C-NOMIS was clearly aligned to the strategic objectives of the organisation. However, the absence of any project-programme plan and failure to define the link between the project and the programme led to C-NOMIS being regarded as an independent IT project, rather than as a part of an IT-enabled business change programme.
As the government-standard PRINCE2 and MSP® (Managing Successful Programmes) guidance makes clear, any project that is treated as independent of its programme or business context is in danger of being implemented for its own sake, regardless of whether it actually benefits the organisation’s strategy.
Furthermore, independence can also lead to insufficient external support to maximise the value of the project’s outputs. In the case of C-NOMIS, this was seen in the absence of any attempt to integrate the various information management systems currently in use. Even if C-NOMIS had delivered the expected IT solution, its benefits were automatically compromised by the difficulties imposed by the existing systems. As a result, these various systems complicated the design of the C-NOMIS database, encouraging the scope-creep that eventually led to the demise of the project.
Effectively aligning the project to strategic priorities is clearly crucial to project success. But how do managers ensure that their projects are strategically worthwhile and supported as such? PRINCE2 recommends the following:
- There must be continued business justification via a detailed and thorough Business Case, which must include a full appreciation of the expected benefits and costs involved
- The Business Case must be monitored at regular intervals throughout the lifecycle of the project
- Effective business assurance to check whether the project remains aligned to corporate or programme strategies
In addition, an effective project management office should be established to ensure centralised support to projects, and to provide a reliable source of information about an organisation’s project management activity. Portfolio management tools such as the Prioritisation Model can also be used to evaluate the relative worth of individual projects and programmes.
Lack of effective senior management
According to the NAO report, the C-NOMIS project has been overseen by three different SROs (Senior Responsible Officers), the first of whom had very little prior experience working with large-scale IT systems projects. A further element of confusion was added by the fact that NOMS – the organisation running the project – was a recent amalgamation of HM Prisons, the National Probation Service and various other government offices and organisations, all of which came with their own management structures and their own ways of doing things.
The consequences of this confusion were as follows:
- Poor monitoring by senior management - Neither the project board nor the SRO requested or received any information about the project beyond standard summaries and briefings until mid-2007. There is no evidence during this period that senior management monitored the delivery of the product.
- No clear financial accountability - Although the project board met once every two months, the records show that there was no discussion of project finances until May 2007 – by which point the estimated cost of the project had almost tripled to £690 million.
- Weak change control - One key reason for the increasing costs and delays was the “scope creep” allowed on the integrated database. This was partly caused by having various requirements from the different departments and no central figure of authority to ensure that the requirements were compatible, achievable and necessary to the project objectives. Scope creep is often fatal for a project if the Business Case is not regularly reviewed, as it changes the cost/benefit balance - often for the worse.
Regular highlight reports should have been sent to senior management from the project manager. These should have been reviewed by business assurance to ensure the Business Case was still acceptable and that the solution was continuing to provide value for money. Assurance from external to the project should have occurred via gate reviews and these are mandated for all government high risk projects. External gate reviews could have examined the likelihood of project delivery and checked the robustness of plans. It is not clear from information provided whether these were in fact conducted on C-NOMIS.
Insufficient stakeholder engagement
OGC’s causes of project failure - 3: ‘insufficient or ineffective engagement with project stakeholders’
Identifying and effectively communicating with influential project stakeholders is crucial, to ensure a full understanding of the need for the project, the benefits that the project is expected to bring and the project’s business justification. Regular and transparent communication fosters stakeholder confidence in the project management team, and enables stakeholders to raise immediately any concerns that may develop.
According to the NAO report the engagement of the C-NOMIS project management team with its key stakeholders was erratic, to say the least.
At the start of the project, user groups were identified and encouraged to participate in workshops that would determine the specification, goals and even the overall direction of the project. The requirements of the product (the C-NOMIS database intended to capture and share information about offenders required by the prison and probation services) were therefore extremely comprehensive – so comprehensive, in fact, that they encouraged ‘scope creep’ (the extension of product requirements beyond the scope defined in the project’s Business Case).
Having started off with good intentions, the C-NOMIS project management team did not continue quite as one might have been hoped. Not only was little information passed from project to stakeholder regarding the spiralling costs and the increasingly delayed deadline for project completion, but a number of stakeholders informed the NAO that they had felt unsure how to notify the C-NOMIS project management team of their own concerns. It is not surprising that C-NOMIS gradually lost the support of its stakeholders.
The Cabinet Office’s MSP best practice guidance recommends a 6-step process for stakeholder engagement:
1. Identify who the stakeholders are, so that communication strategies can be appropriately focused.
2. Evaluate the interest, attitude and influence of the stakeholder
3. Write a stakeholder engagement strategy, including the content, format and frequency of communication, as well as the designated sender(s) and recipient(s)
4. Plan when and how the stakeholder engagement strategy will take place
5. Implement the stakeholder engagement strategy (communicate the required information)
6. Monitor the effectiveness of the strategy, but ensuring that all the key stakeholders have the information that they require and are satisfied with their position in relation to the project
As the C-NOMIS report demonstrates, insufficient or ineffective channels of communication can reduce confidence in the project, and can impact on project success. The failure of senior and project management staff to effectively engage with the project stakeholders was one of the reasons that C-NOMIS turned into such a costly disaster.
Poor approach to project management
OGC’s causes of project failure - 4: ‘poor approach to project and risk management’
In consultation with hundreds of experienced management professionals and business experts, the OGC has developed best practice guidelines and frameworks for project management (PRINCE2) and risk management (M_o_R®).
Considering the bedrock of project and risk management support that the C-NOMIS project could fall back on, how did the absence of a solid approach to project/risk management become one of the key factors that the NAO identified in the failure of the project?
The NAO report highlighted several specific flaws in the approach to project and risk management used on the project:
- Over-reliance on contract staff - Due to a shortage in skilled personnel, the project relied too much on contract staff, which led to higher costs, more time spent inducting staff into the project and less staff ‘buy-in’ on the project.
- Inexperienced SRO (Senior Responsible Owner) - The SRO took personal responsibility for the delivery of the project and any proposed business changes. The first SRO on the project had little experience of managing large-scale IT projects, and therefore was perhaps ill-equipped to deal with the scope creep that allowed the budget to soar and the estimated duration of the project more than double.
- Risks identified but not properly managed - Although it was recognised early on that the project was high-risk, there was no contingency budget for implementing risk responses.
- Scope creep - Poor change management procedures led to the incorporation of many adjustments and additions into the original product specification. These changes eventually proved too much for the time and budget allocated to the project, and C-NOMIS overran its tolerance levels.
- ‘Good news’ culture (green-lighting) - The project manager was the key person reporting to the programme director, which led to a ‘good news’ culture and an absence of external assurance on the project. This, combined with the infrequency of project-programme communications, meant that senior management were unaware of the scale of the project’s problems.
Ideally, a project management team should remain consistent for the duration of the project. More important however is to have people with the right skills and experience for the roles expected of them. Appointing someone as SRO with little previous experience now sounds utterly bizarre decision and should have been identified as a major risk early in the project.
The C-NOMIS project was heavily reliant on the delivery of a complex I.T. system. The project failed, to a substantial extent, because it underestimated the cost and complexity of the system. An experienced IT project manager, or an experienced project manager equipped with lessons learned on previous major IT projects, might have been better positioned to judge and enforce the scope tolerance on the project and deal with IT suppliers.
Every project should have external assurance, particularly a project with such a high profile (and budget) as the C-NOMIS project. Without project assurance it is impossible for senior management to be assured that the project is making adequate progress.
It’s not uncommon for senior managers to lack experience in project management methods, and in these cases they need to gain the appropriate training courses and be given the support necessary. Developing the skill-sets of the internal staff through training and mentoring would have given a better return on investment in the short term and would have had the additional benefit of having highly suitable internal staff to call upon on later projects.
Whilst the SRO took on the role of the project Executive and this is permitted under PRINCE2 best practices, this role also needs to be able to involve both users and suppliers in the decision-making of the Project Board as a whole. By taking on the responsibility for the proposed business changes, the risks were increased that the requirements would not satisfy the diverse needs of the different users. A better approach would have been to involve users more widely in decisions about the proposed changes.
Changing requirements are commonplace on projects, but at the heart of any change control process must be an appreciation of the impact on the project’s Business Case. Simply adding more requirements without adequate prioritization or robust impact analysis is a guaranteed way to exceed the project’s budget.
Project managers should never report to programme management, but instead should report to the Project Board. Without assurance independent of the project manager, it’s all too easy to ‘green-light’ progress i.e. to report the project is proceeding smoothly on green, yet is really on red alert.
Management by stages
OGC’s causes of project failure - 5: ‘too little attention paid to breaking down the project into manageable stages’
Strikingly, this was the only possible cause of failure identified by the NAO report as not being a factor in the failure of the C-NOMIS project.
Management by stages as recommended by PRINCE2 is a less risky approach to investment decisions because key decisions are taken before work commences. The revised Business Case must be reviewed at the end of each stage, and assurances need to be given that the project is still worthwhile, that plans are still achievable the project is still viable.
The C-NOMIS project included a pilot/trial stage, which proved to be a valuable learning experience for the project management team. The division of the project into management stages also allowed the organisation (NOMS) to re-evaluate the project when it exceeded its tolerance levels, and to prevent further resources being committed to the project, until it had been re-scoped and shown to provide continued business justification.
More active senior management involvement and crucially, independent assurance in the project might have prevented C-NOMIS failing in the first place. However, the use of PRINCE2 management stages meant that the project could be halted in 2007 and a decision taken to re-scope the project.
The number and length of management stages on a project depends on the length and complexity of the project. More frequent and shorter stages enable a higher degree of senior management control; less frequent and longer stages save management overheads and place more responsibility in the hands of the project manager. When deciding how to distribute management stages, project and programme managers should take the following factors into account:
- Risk appetite of the organisation and risk profile of the project;
- Length and complexity of the project;
- Experience of the project manager;
- Timing of technical stages
Robust business case
OGC’s causes of project failure - 6: ‘evaluation of the Business Case is driven by initial price rather than by value for money’
The NAO report pronounced this factor to be only partially the case on the project. According to the original Business Case, the project should have created a positive net present value. However, the serious underestimation of costs, combined with alarming scope creep meant that the project’s value for money swiftly became dubious. Meanwhile, inadequate communication between the different levels of project and programme management prevented regular review of the Business Case. This meant that the project was allowed to continue long after it ceased to have business justification.
Real projects are never as simple as methodological models, as NOMS’s decision regarding the re-scoping of the project amply illustrates. Best practice guidance and project management methods provide clear and simplified frameworks for carrying out projects successfully; however, these frameworks cannot cover every possible situation or combination of situations.
It is crucial that project management frameworks should be applied thoughtfully, with due consideration of what will happen if the guidance is/is not followed.
Understanding the supplier
OGC’s causes of project failure - 7: ‘failure to understand or collaborate with suppliers at senior management levels’.
Before the start of the C-NOMIS project, NOMS had an existing contract with IT suppliers EDS and Syscon. These contracts were renewed for the delivery of the C-NOMIS information management system. Although the project needs and supplier assumptions were documented prior to project implementation, no formal assessment was made to decide whether the suppliers could fulfil the customer requirements.
Furthermore, by failing to review the supplier contracts, NOMS did not retain sufficient rights over the product that it had commissioned. According to the NAO report, Syscon is able to market the software customised as part of the C-NOMIS project, without any financial return on NOMS’s investment.
In hindsight this might have been ill-advised. C-NOMIS is one of several high-profile public sector I.T. projects that have suffered when the supplier was EDS . A more thorough evaluation of the competence of the supplier to deliver the product might at least have mitigated – or even prevented – project failure.
Although the C-NOMIS project was part of a larger programme and organisation, it was not necessary (or, as it turned out, advisable) to continue to use the same I.T. supplier. Individual projects may have specific needs or conditions that affect which supplier would provide value for money. The supplier proposals should be carefully analysed during the initiation stage of the project, to ensure that aspects such as cost, time, quality and scope are not overlooked when the supplier is chosen.
PRINCE2 recommends lessons are learned from previous projects which are able to be passed on each project when it is starting up. Evidence of poor previous delivery by EDS should have been identified at this point, and alternative suppliers sought.
Integration of the project management team
OGC’s causes of project failure - 8: ‘non-integration of customer, supplier, user and project management team’
We have already discussed the failure of the NOMS corporate/programme managers to effectively collaborate with the supplier organisations, EDS and Syscon. According to the NAO report, the break-down in project/supplier communication also impacted at project and team management levels.
Because of the insufficient assessment of the competence and contractual obligations of suppliers, NOMS allowed the delivery of products required for the project to overrun cost and time tolerances to an unacceptable degree. In 2007, for example, EDS estimated that their costs would increase from £95 million to £200 million – almost the total lifetime costs originally estimated for the project. This led to a breakdown in communication between the project management team and the supplier organisations, and contributed in significant ways to the failure of the project.
PRINCE2 recommends that the project board be comprised of business, user and supplier representatives. This is to unite the different interests in the common aims of the project at the highest level of decision-making so as to enable effective project governance and decision-making. The interests of all three must be satisfied if the project is to be successful.
I have examined the 8 causes of project failure identified by the OGC, and how they relate to the colossal failure of the C-NOMIS project.
C-NOMIS was supposed to deliver an information management system through which the National Offender Management Service could manage the casework of offenders in as smooth and effective a manner as possible. The key benefit envisioned was the reduction in the rate of re-offending, through closer interaction between probation officers, prison officers and case workers.
In the end, the C-NOMIS project did not deliver. The database requirements mushroomed far beyond those needed to realise the key benefit, and combined with poor supplier management, this led to an uncontrolled increase in costs and an apparently interminable project. The moratorium declared in 2007 allowed NOMS senior management time to take stock of the situation, and the project was later morphed into the NOMIS Programme, with a much reduced scope and tighter controls over the project schedule and budget.
The mistakes that hindered C-NOMIS are not uncommon – the causes analysed in this article have, after all, been identified by the OGC as the most common causes of project failure. However, given the emphasis placed on good project and programme management practice within the public sector, it is at the very least disappointing (if not quite surprising) to think that the most fundamental concepts of effective project management were so thoroughly neglected by the C-NOMIS team.
One question that arises is whether the project management team actually understood the project and programme management concepts and frameworks that were relevant to C-NOMIS. As this project failure showed, best-practice frameworks such as PRINCE2 and MSP are all too often not implemented in the way they should be.
PRINCE2 is clear about where ultimate accountability for project success lies: with the Project Board. After all, the Project Board takes all the big decisions regarding investment and whether the project will deliver value for money. To assist them in this crucial role, Project Assurance must advise the Project Board and check the project remains viable, monitor business risks and monitor that the project is on track to realize the expected benefits. As the C-NOMIS project shows, if green-lighting occurs and this obscures a true insight into project progress, then assurance is surely lacking. This is a sure recipe for a project which will spiral out of control.
C-NOMIS is not the first large-scale government project failure and it certainly won’t be the last. Perhaps the most important result that could come out of such a failure is to learn the lessons of this project, and ensure future projects are managed much more effectively.
PRINCE2® is a registered trade mark of the Cabinet Office. MSP® is a registered trade mark of the Cabinet Office. M_o_R® is a registered trade mark of the Cabinet Office.
 Widman, J. (2008, October 9). IT's biggest project failures - and what we can learn from them. http://www.computerworld.com/s/article/9116470/IT_s_biggest_project_failures_and_what_we_can_learn_from_them?taxonomyId=73&pageNumber=1
 National Audit Office, (2009, March 12). The National Offender Management Information System. http://www.nao.org.uk/publications/0809/national_offender_management.aspx
 National Audit Office, (2011, July 1). The failure of the FiReControl project. http://www.nao.org.uk/publications/1012/failure_of_firecontrol.aspx
 National Audit Office, (2003, January). New IT Systems for Magistrates' Courts: the Libra Project. http://www.nao.org.uk/publications/0203/new_it_systems_for_magistrates.aspx
 National Audit Office, (2003, July 16). Government Communications Headquarters (GCHQ): New Accommodation Programme. http://www.nao.org.uk/publications/0203/gchq_new_accommodation_program.aspx
 Ministry of Justice, (2012, June). Freedom of Information Request FOI 76280. http://www.justice.gov.uk/downloads/information-access-rights/foi-disclosure-log/prison-probation/foi-76280.doc
 Office of Government Commerce, (2002). Common Causes of Project Failure. http://www.dfpni.gov.uk/cpd-coe-ogcnaolessons-common-causes-of-project-failure.pdf
 Office of Government Commerce, (2009). Managing Successful Projects using PRINCE2TM. ISBN: 9780113310593
 Cabinet Office, (2009). Managing Successful Programmes. ISBN-10: 0113313276
 Krigsman, M. (2008, May 13). EDS’s troubled legacy of failed IT projects. http://www.zdnet.com/blog/projectfailures/eds-troubled-legacy-of-failed-it-projects/761