Skip to main content

FAMOZ: Let's treat project failures like airplane crashes

Whenever an airliner crashes, two questions demand answers:
  • Who is responsible? -- so we can punish them, sue them or put them in jail (or gain advantage for ourselves)
  • How did this happen? -- so we can prevent accidents like this in the future. 
Oddly enough, if the investigation seeks to answer the first question, it becomes very difficult to achieve the goal of the second question. If people are afraid of punishment, they are reluctant to provide information which can and will be used against them. The investigation of airline incidents always focus on the second question and aviation has enjoyed an excellent and improving safety record because of it.

The city of Zurich has "pulled the plug" on "ELUSA" (or FAMOZ, as it was originally known). This system to integrate the operations of four departments of the city's social services office was originally budgeted at 11 million CHF, but after several rounds of additional financing was now expected to cost 29 million. Stopping the project will limit the costs to 26 Million. The politician are speaking of a disaster, citizens are expressing disgust, and the suppliers are saying 'we're being made into scapegoats.'

Is this case exceptional? According to the Tages-Anzeiger, 75% of the functionality is completed and operational, the costs are 235% of the original budget, and the project was restarted at least once. According to criteria of the Standish group's CHAOS report, this large project would be considered challenged: "completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.

According to the CHAOS report, 61.5% of all large projects are challenged, only 9% are successful and the rest fail. 94% of all challenged or failed projects restart at least once. The average cost overrun is about 180% of the original budget. So this project is in many ways typical and based on the numbers comes into the "top 25%" of project failures.

Why did this project have to end in a disaster? 75% of the functionality is available. According to other work of the Standish Group, 64% of the functionality developed in such projects is seldom or never used. So if the project had implemented the 'right' 36% first, i.e. the functionality that is needed frequently or every day, the project could have been stopped long ago and as a success and at a figure close to the original budget.

Why did this crash have to happen? The first Chaos report was published in 1995. This is not the first or even the biggest 'plane crash' of a Swiss government IT project. If this had been an airplane crash, the safety authorities would be crawling over the scene of the accident; politicians and the flying public would demand that the causes be identified and the

Why can't an IT failure be treated like a plane crash? Why are failures used for political gain rather than as a basis for learning? Why can't we have an IT Project Safety Board, which investigates "accidents" and makes recommendations to prevent similar incidents in the future?


srinivas C said…
Because no one is killed. A typical s/w project is just something that brings about some benefit, sometimes hard to discern. A crash and this cannot be treating with the same or even similar seriousness. However I take your point, we indeed need to be more serious about project failures.
Peter said…
So true, no one is killed! Although you might get a different impression when you listen to the politicians attacking each other, the civil servants involved, the IT supplier and the whole IT sector!

Of course this kind of bickering can be more about the politicians than the project itself. In this case, insiders report that the project was a success and the software has been in service for years. Appartently there were issues around price negotiations for the next release which were the primary source of heat. A small detail: Again, according my source, 75% of the "project costs" are internal costs of the city administration, not funds paid to the supplier. "Figures don't lie, but liars can figure" -- Mark Twain.

If I understand the history correctly, Norm Kerth created the prime directive after a fatal accident at a regatta where he was a race official. The concept of creating an environment of safety is now a core concept of the retrospective community.

So for me plane crashes are an extreme case - we look at the principles that work in the extreme case and see how they apply in the more day to day cases.



Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…