Failed Projects – and the lessons learned

One of the hardest aspects of project management is determining the success of a project. How do we decide the difference between success and failure, when no two projects are exactly the same for comparison? You will see from this article there is no clear-cut answer to what failure looks like. What we can do is use the decision-making processes from differing methodologies to understand performance. Projects are a journey and take many detours to get to the end goal. Here we look at some high-profile failed projects and the lessons learned leading to continuous improvement.

What is project failure?

Project failure takes many definitions. A quick Google search will reveal cost overruns, failure to deliver a return on investment, time overruns, and scope creep as many examples of a failed project. But is it really a failed project, or perhaps more a failure of governance of the project? If a project is no longer aligned with the business objectives, and therefore delivers no value to the business, has the project failed even though it delivers on time, to cost, quality and scope? The governance of the project should have stopped the project from moving forward, as we will see from the methodologies in practice. Read on!

Project failure #1 – Airbus A380

In 2004, Airbus set about piecing together parts of what they hoped would become the largest passenger plane in the skies. Pieces were shipped from Toulouse to the assembly site in Hamburg. As the pieces were moved closer together, it soon became clear that they didn’t fit.

Designers working on the parts of the plane were using different CAD software which meant that the measurements were all different.

Of course, that was not the only problem for this highly complex project. The project cost nearly double the original cost and was several years behind schedule.

Key lesson from Airbus A380

Everyone on the same page is an important part of project management, especially with geographically dispersed teams. Set out at the start of the project are the tools and techniques for development.

In PRINCE2, the Senior Supplier role would be responsible for specifying the standards and tools to use. This role has significant input into the project approach, and the resources needed for the project. An incorrect project approach will seriously derail any project, potentially needing complete rework!

This lesson may lead to a reconciliation of software projects, ensuring there is a single ‘source of truth’ going forward.

Project failure #2 – Challenger Space Shuttle

The most tragic failures are those that result in a loss of life. On January 28, 1986, the Challenger Space Shuttle exploded just 73 seconds after take-off. It was later determined that a faulty seal on one of the solid rocket boosters combined with the cold weather conditions allowed the tragedy to unfold.

Lift-off is not part of the project and despite the incident, does not make the project a failure.  It does indicate that the quality control (i.e. inspection) might not have been up to standard, and a procedural improvement is needed.

Digging a little deeper revealed that quality control had highlighted the issue of the seal under cold conditions was not up to standard and the risk of consequential failure was identified and reported. The decision to continue with the launch in the prevailing weather lead ultimately to the disaster.

Ensuring the timely identification of risk and understanding the consequences is key to effective governance and mitigation of potential project failures. This is an important lesson leading to continual improvement. In the incident’s aftermath and project post-mortem, persistent failures in governance and unnecessary bureaucracy within the organisation were found to be a considerable leading factor to the disaster.

Decisions being made with poor information is the issue.  It is easy to point fingers when things do not go according to plan.  What we learn, the improvements we make as a result, gives participants the confidence to try again, without the fear of retribution. Lessons learned inform decision-making which in turn improve projects.

Key lesson from Challenger Space Shuttle

Manage by Exception is a core concept across all project management methodologies. It highlights the need for clearly defined, and understood, roles and responsibilities, including who has what authority in making decisions and the demarcation point for escalation. Trust in the teams and ownership are paramount to success. This is probably the hardest part of project management, especially in high-value and highly complex project where even the smallest of flaws can lead to lengthy delays costing hundreds of millions of dollars.

Project failure #3 – World Athletics Championships 2019

In 2019, the best athletes in the world flocked to Doha for the World Athletics Championships. Competing in eerily silent stadiums as the host nation had failed to sell even a fraction of the tickets and punishing heat despite huge fans, air conditioning and events being held in the middle of the night, many athletes withdrew from the competition.

There was much criticism of the International Association of Athletics Federations (IAAF) in what has been a very damaging blow to their public image. Not least claims of putting money before the needs of the sport as well as the Human Rights aspects associated with the host country.

Key lesson from the World Athletics Championships

How the decisions were made pre-project by the IAAF was the first aspect of project failure. An initial risk assessment would have highlighted heat as a potential threat to the success of the event. China incorporated lessons and improvements from previous events into their preparations for the 2020 Olympics with top-notch risk management a key to success. For example, television coverage was enhanced to compensate the drastically reduced audiences due to COVID-19. Additionally, artificial snow was made to mitigate unusually warm weather for the snow events.

For Qatar, with extreme heat most of the year it would have been advisable to hold events during cooler months, or have stadium covers to shield from heat.

In any case, these events are programmes, not projects. It is important to distinguish between the highly complex and complicated environment of interdependent projects which make up a program. A framework such as Cynefin® is useful for determining complexity.

Using a program methodology such as Agile Programme Management (AgilePM®) or Managing Successful Programmes (MSP®) helps to manage the often-conflicting priorities between interdependent projects and the risk associated with complexity. Programmes are inherently agile by nature. AgilePM® does have some advantages over MSP® due to its ability to be less linear.

Project failure #4 – Berlin Brandenburg Airport

Germany had hoped this airport would put Berlin on the map as a center of commerce. After 15 years of planning, construction started on the airport in 2006.

The original opening date was supposed to be in 2011. The airport eventually opened on 31st October 2020, in the middle of the global COVID-19 pandemic!

Many of the issues with the Berlin airport stem from having too many stakeholders with conflicting visions. By allowing the common goal to become diluted, it made it impossible to progress at a normal rate. Ambition and scope creep contributed to the delays.

However, it’s worth noting that the 2007 economic downturn didn’t help. Successful projects require risk management of internal and external environments.

Key lesson from Berlin Brandenburg Airport

Similar to the World Athletics Championships 2019, building an airport is a program. One of the key success factors of a program is a single vision of the end goal. There will be multiple visions contributing to the overarching vision. These represent step-changes along the way. A compelling vision unites stakeholders, bringing them on the journey. It also withstands the test of time.

Planning in detail, to the nth degree, is always detrimental to the world of projects. The more complex a project (or program) the more fatal to success in-depth planning up front will be. Plans change! Projects and programs are susceptible to external factors. It was failed projects that caused more detailed planning up-front to provide more confidence to stakeholders, via the perception that more planning gives greater control. Wrong! The phrase “best laid plans go to waste” is on-point.

High-level planning to a foreseeable horizon enables changes in direction without huge waste of resource or money. This applies to project and program. 15 years of planning is simply wasteful and burns a great big hole in the budget. Programs will define the projects needed to deliver the work. Projects will deliver the outputs needed to achieve the outcomes and therefore the benefits. Stage gates within projects, reporting and tolerances give the additional confidence needed to stakeholders. Effective stakeholder engagement ensures continued buy-in. Afterall, stakeholders are part of the project team, not just external spectators.

Failed Project #5 – Waterworld

When shooting started for the film Waterworld, the director didn’t yet hold a finalised script. But this wasn’t the only problem to plague the shoot. The project was scheduled for 96 days of shooting, but multiple rewrites led to multiple re-shoots and this time frame was stretched out to 150 days. Making movies isn’t cheap, so this pushed production costs to $135 million over budget.

Controlling the scope of a project is essential to reduce the risk of overruns.

The assumption that a project is over budget makes it a failure is common, and incorrect.  Projects typically operate within tolerances.  It’s what we do with those decisions when tolerances are breached which determines whether a project has failed (or not).

Key lesson from Waterworld

First of all, what is Business As Usual (BAU) and how does it differ from a project? A project has 5 key characteristics (PRINCE2®).

• Unique
• Cross-functional
• Temporary
• Change
• Uncertainty

That is to say:

while the film-industry makes films, which is the business as usual, the film itself is a project. Each film is different (unique), has different actors/producers/crew (cross-functional), has a defined start and end date (temporary), can invoke perceptions and meaning (change in behaviours), and have a degree of risk (uncertainty).

AgilePM® was made for the film industry – no, not really. But it is ideally situated for this type of project. Agile is not just for IT and software! A structure like AgilePM can be used to limit risk inherent to the nature of making a film. Numerous retakes is very much iterative development, and some parts need to be axed entirely to meet deadlines and budgets. Even the script is developed iteratively.

AgilePM® allows for change in the detail, without impacting the overarching scope. Flexible, yet provides confidence through predictable delivery. Need something most structured? PRINCE2® can be flexible too.

Failed Project #6 – Denver International Airport

Denver International Airport set out to create the most sophisticated luggage handling systems in the world. The project was soon deemed to be far more complex than anyone was anticipating and delayed for 16 months at a cost of $560 m. Large portions of the project had to be “redone” and the project was then scrapped in 2005.

Key lesson from Denver International Airport

The hardest part of a project is understanding whether a project is viable, desirable and achievable. These are all aspects set out in a business case. We answer the question of desirability when the concept is first put before a sponsor. The project needs to remain desirable throughout. If no longer desirable, then it needs to be closed down.

Is the project achievable? This means can we achieve the benefits stated in the business case. Caution is needed, because benefits are often overstated in the business case and often there is no focus on achievement once the project has finished. Managing Benefits® and Better Business Cases® can help an organisation improve the return on investment for projects and programs.

Is the project viable? Can we actually build it? If the answer is “no”, then that’s the end of the project. This question needs to be answered early on in the project and has a lot of input from the supplier stakeholders. Hand-in-hand with viability is scoping out the project.

Both PRINCE2® and AgilePM® look at a project in terms of key deliverables (products in the case of PRINCE2® and high-level User Stories in the case of AgilePM®). In both cases, we are looking at the end goal of the project, and breaking that goal down into major items. These will then be decomposed further to determine the scope. Working in this way limits the amount of exposure to risk of not having the full requirements, and help determine whether the project is viable at all.

 There are a number of cited documents regarding this project. In essence, lack of governance was an overriding aspect of project failure.  The project was part of a larger program of works. Other airports have learnt from the experience, and improved the governance between multiple parties ensuring a smooth command of the project.

Conclusion

Although the perception of project failure comes from many different sources, the reality is projects fail because of poor governance. Make sure you know what good governance for a project and program is and what your role and responsibility does to contribute to good governance by attending a course. Contact us today to discuss your requirements and what project management training might be best to achieve your goals.