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?





Comments

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.

Cheers,

Peter

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…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

Five Simple Questions To Determine If You Have the Agile Mindset

My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …