The December 2022 issue of IEEE Spectrum is here!

Close bar

Last July, the United Kingdom National Audit Office's (NAO) report on the UK FiReControl Project, which was intended to integrate 46 stand-alone fire department control rooms into nine regional centers, labeled it a "comprehensive failure."

Yesterday, the UK Parliament's Public Accounts Committee (PAC) published the final governmental postmortem on the project, which was finally canceled late last year and has resulted in a minimum of £469 million being spent with nothing to show for it. It also leaves a legacy of potentially another £180 million in future costs. The report, while not breaking any real new ground, does fill in some of the background detail on how project decisions were made that the NAO report did not cover.

In the summary of its FiReControl report, the PAC calls the FiReControl Project "...one of the worst cases of project failure that the Committee has seen in many years." It goes on to state:

"The project was flawed from the outset, as the Department for Communities and Local Government (the Department) attempted, without sufficient mandatory powers, to impose a single, national approach on locally accountable Fire and Rescue Services who were reluctant to change the way they operated. Yet rather than engaging with the Services to persuade them of the project's merits, the Department excluded them from decisions about the design of the regional control centres and the proposed IT solution, even though these decisions would leave local services with potential long-term costs and residual liabilities to which they had not agreed."

Ah, the old "how to make enemies and exclude friends" approach to IT development. I know it well.

The summary then goes on to state that the Department for Communities and Local Government  "... acted without applying basic project approval checks and balances—taking decisions before a business case, project plan, or procurement strategy had been developed and tested amongst Fire Services."

Heck, why bother doing a business case or making a project plan when you know you're right and project failure is not an option?

You can probably guess what comes next:

"The result was hugely unrealistic forecast costs and savings, naïve over-optimism on the deliverability of the IT solution, and under-appreciation or mitigation of the risks. The Department demonstrated poor judgement in approving the project and failed to provide appropriate checks and challenge."

How poor was that judgment? Here is an example.

"The Department awarded the IT contract to a company with no direct experience of supplying the emergency services and who mostly relied on sub-contractors over which the Department had no visibility or control. The contract was poorly designed, lacking early milestones which would have enabled the Department to hold the contractor accountable for project delays."

Yet, given the "extraordinary failure of leadership"—I have another, less printable phrase for it—the PAC report says that:

"... no individuals have been held accountable for the failure and waste associated with this project."

No doubt the Department looks at the whole exercise as a "learning experience," and one doesn't punish learning experiences, right?

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}