The Project Management Institute (PMI) has a case study library here. Unfortunately, it is as much a marketing tool for the PMI as an objective case study library. However, several of the case studies provide good level of detail on project execution and best practice techniques. Some of the better ones are the case studies on AT&T, Marriott and Saudi Aramco.
The US Government Accountability Office recently published a 13 page report on how the Federal Aviation Administration (FAA) is doing on upgrading elements of the US air traffic control systems to move to satellite based aircraft tracking, use better coordinated data exchange rather than voice for routine information sharing during flight and ultimately create better alignment between US and European processes, it’s early in the project but here are the highlights:
- Clear customer oriented success metrics in place for the project (e.g. reducing delays 27% from 2009 levels)
- Currently ahead of schedule in certain areas (e.g. innovation in fuel saving routes for aircraft)
- Currently forecast to be 7% over-budget across all projects. As if often the case of 5 key projects, 4 are on track, but one is materially delayed and may impact the others due to dependencies.
- Stakeholder credibility – even though the work is broadly on track, most stakeholders (the airlines) are skeptical that the work will be done on time, and aren’t willing to make necessary aircraft investments until they see more evidence that of project success.
It’s too early to have a firm view on the success or failure of this project. Most interesting is the stakeholder dynamic – the airlines not believing that the FAA will complete their work on time could be self-fulfilling because the FAA requires the airlines to complete aircraft upgrades to allow technology investments the FAA are making to succeed.
Currently, there is a proposal for a venture capital scheme where the airlines get loans to make the necessary upgrades with payback contingent on whether the FAA meets its schedule commitments, this is an interesting solution to the problem, though of course it would be preferable if the FAA had credibility in the first place.
One of the criticisms of calling the Sydney Opera House a failed project given it’s time and budget overruns, is that is an architectural masterpiece. The thinking is that budget and schedule overruns are necessary evil if you are creating a work of art.
This idea is persuasive, but wrong. The Guggenheim Bilbao demonstrates that award-winning architecture does not have to be the result of lax project management. There is a detailed case study from the Havard design school here and Bent Flyvbjerg addresses the topic on page 53 of this paper.
The Guggenheim Bilbao was completed on time and budget and though it has not won the Pritzker Prize, it does place well in architectural surveys. It is a good counter example to the idea that architecturally innovative designs are likely to come in late and over budget.
Taurus is one of the larger IT project failures in terms of the scale of the time and cost overruns. The clear message is the importance of stakeholder management, otherwise requirements inevitably become far larger than can be accomplished with time and budget constraints. With the Taurus system the approach to requirements management appeared to be to attempt all requirements – of course, all this did was to balloon duration and costs until the project was ultimately killed by warring factions of management consultants.
Taurus stands for Transfer and Automatic Registration of UncertificatedStock. Basically a way to automate the back end processing of London Stock Exchange transactions, since the prior Talisman system was stretched.
Taurus was first estimated to take 6-18 months and ultimately took 10 years, without success. Budget overruns were similarly impressive, with initial estimates in the range of 6-18 million pounds and the final figure being somewhere between 400 and 800 million. I believe the reason for the range of estimates is because the project having multiple phases and directions to it, with two initial proposals (Taurus1 and a committee recommendation) being scraped until a final and very ambitious proposal was attempted.
The core problem was 280 financial institutions in putting requirements and the economist John Kay describes on his blog.
“It would take a full page of the Financial Times to list interests that needed to be placated and demanded to be represented. The registrars feared that a centralised computerized system would put them out of business. Listed companies wanted to make sure they could find out easily if arbitrageurs were on their share register. Private client brokers wanted to protect their customers’ rights to hang share certificates on their walls and make cheap crossings on the English Channel with their concessionary shares. The government insisted that communications should be as secure as the Government Communications Headquarters and investors’ funds as well protected as the gold in the Bank of England.
And so it went on. And on, and on, through interminable committees and working groups.”
Ultimately Taurus was scrapped and CREST was implemented, Daniel Davies argues CREST succeeded due to regulatory stability, but I think that is overlooks the stakeholder chaos that Taurus experienced independent of regulatory change. Rory Linwood argues that requirements management was the crux of it here. CREST didn’t give everyone everything, but it made the tough decisions early and was successfully implemented within 3 years.
Similar issues with the challenge of design by committee and unclear reporting chains can be seen in the project failure of the Typhoon Eurofighter weak requirements management as also evident in the FBI’s virtual case file project.
Posted in Finance, IT
Tagged cost overrun, CREST, delay, IT project, London Stock Exchange, LSE, project management, requirements management, Talisman, Taurus