Although literally translated as “harm-joy”, the German word Schadenfreude has come to mean for us taking delight in the misfortune of others. For Project Management Professionals (PMPs®), disasters on other projects bring no delight and we are more likely to reflect that there but for the grace of God go I.
However, there are many valuable lessons to be learned by studying failed projects, no matter how much project management certification you have. Although PMP® training will make you aware of the different facets of the project manager’s role, there are always risks to projects that have not been identified up front – what Donald Rumsfeld called the “unknown unknowns”. Let us consider a few projects here and see what could have been done to prevent disaster.
The Airbus A380 is an amazing sight. It is capable of carrying up to 850 passengers on its two decks and I understand that the air recirculation system is a step beyond what we are used to in older airliners. However, the gestation of the A380 was problematic: it was two years behind schedule and millions over budget. The main reason for this related to wiring.
The A380 is a complicated machine. It has 100,000 wires (totalling 530kms in length) and 40,300 connectors that allow 1,150 functions to be performed. The wiring harnesses were built by one company, while the airframe was built elsewhere. Both companies were using the same CAD (Computer Aided Design) package. However, on delivery, the wires were often several centimetres too short. Root cause analysis discovered that the two companies were using different versions of the CAD software and one of the differneces related to how the radii of curves were calculated.
This problem is inherent in using Work Breakdown Structures, a technique favoured in PMP® courses. Splitting work into logical sections makes sense from a management perspective, but it adds an integration activity to bring them all back together again. Traditionally, the development of subsystems proceeds independently and the integration activity happens at the end. If there are problems, like the wiring one described above, extensive rework is required.
The project management practice of continuous integration identifies these problems earlier. Teams should strive to get some preliminary functionality working quickly and integrate with other teams as soon as possible. In this way, interface problems are highlighted earlier – when there is still time to do something about them. The use of multi-disciplinary teams helps as well – something for PMPs® to consider when acquiring the project team. While specialists will develop their work packages as before, they are working closely with the people on the other sides of the interfaces and can integrate their work much more conveniently.
Back in the 1920’s, Martin Heidigger developed what he called the “Hermeneutic Circle”, where your understanding of the whole is established by reference to the individual parts and your understanding of each individual part is by reference to the whole. So when you build your Work Breakdown Structures, do not forget the big picture.
No discussion of project failures these days can avoid considering the banks. The Northern Rock collapse in Britain highlights poor business strategy – getting caught up in the sub-prime mortgage debacle. But a further blow was received when it was discovered that there was an administrative error. The bank did not print the original amount of money loaned on the statements given to customers. This is illegal, meaning that customers were not required to pay interest payments on their loans.
This shows extremely poor stakeholder management. Clearly, the bank did not identify the Banking Regulators as important stakeholders and did not include legal requirements in the design of its standard forms. Also the bank did not Validate Scope at the end of developing new forms. It should have obtained official government approval before going live with these.
Big information technology projects are often good examples of failed projects. We have had our own PPARS disaster here, but it might be less painful for project managers to consider the State of California’s efforts to merge thirteen separate payroll systems into one. California reasoned that a single system would save a fortune in systems administration and reduce duplication. In 2004, $70 million was spent in an initial attempt to integrate these payroll functions. The contractor responsible for that initial attempt was terminated in 2009 due to a lack of progress.
So they tried again. This time an SAP (Systems, Applications, Products in data processing, or Solves All Problems as some wits have named it) implementation was attempted. In 2012, the integrated solution was deployed in a single organizational unit with just 1,300 staff and the system immediately ran into problems. Employees were incorrectly paid, simple mathematical functions did not work and the wrong allowances were being handed out. Not surprisingly, the contract was terminated in 2013.
IT systems tend to evolve over time, being shaped by the needs of the host organization. Functionality is added to cater for exceptional cases and the original requirements have long been superseded by the realities of the environment. In other words, an established IT system is difficult to understand and needs careful business process analysis to determine exactly what it does do.
For a project manager, it is very important to understand what it is the project is trying to achieve – its vision as it were. The goals of the Californian IT rationalization were to reduce admin costs and avoid duplication. It actually was not to replace existing IT systems. This is a very common situation in the IT industry – the problem definition gets wrapped up in the solution space. It reminds me of the Hitchhikers’ Guide to the Galaxy dilemma: the answer to Life, the Universe and Everything is 42. This makes no sense, because we really do not understand the question.
It is interesting that the State of California never conducted a post-mortem after its first attempt at replacing its systems. A better requirements gathering process (as you will recall from your PMP® training) would have saved a lot of grief. So the lesson to take away from this is to have a clear goal for your project. If the goal is not clear, then maybe another project is required to define what that goal is?
At the end of the day, the better your understanding of project management principles, the less likely you are to be involved in disastrous projects. For more information about project management certification, please visit our training page. For your convenience, we run our project management courses in Dublin, Cork, Limerick and Galway. To get more details, please contact us directly.