In thinking of good examples of project failure (unfortunately, I’ve seen more than one in my time), I thought we’d discuss a failed company integration program, as it illustrated typical failure points.
A mid-market manufacturer purchased two companies – one smaller and one larger than itself. There was a vast opportunity in terms of product synergies; however, it failed to yield even meager results. What went wrong? 1) Too many chiefs and no Indians. 2) Lost critical knowledge base. 3) Forgot to ask questions.
1. Too many chiefs and no Indians – As well-intentioned as the leadership was in terms of hiring experts with knowledge in the acquired companies and with large-company experience (since, clearly, the company was going to grow dramatically in size through the process), there were not nearly enough Indians to implement the millions of project tasks requested by the chiefs. No program can be successful without considering the scope and complexity of implementation.
Projects do not fail in formulation; they fail in implementation. The same is true of strategy. Therefore, if there are too many chiefs coupled with no Indians, you can easily have the best strategy in the world. While this strategy which should yield significant synergies with huge profit potential, it can still fail miserably. Not only did the companies not integrate successfully but customers were lost and cash ran short.
2. Lost critical knowledge base – Another tempting and normal reaction to planning for the integration is to move people among jobs and change responsibilities. If handled with expertise, this is fine; however, it rarely occurs. Even if handled ok, people tend to become disheartened if they perceive the new job as a demotion and/or they have a hard time adjusting to the new situation. It’s likely their new boss has transitioned as well, and so it can be a tough situation. Sometimes, they leave. Sometimes, they end up fired. And, sometimes they just become unproductive. All are undesirable results.
For example, in the integration project, the management team hired new leaders, moved employees to different roles and sometimes even to different departments and/or locations, changed responsibilities etc. They did this in order to reorganize so that the “right people were in the right positions” to support the new organizations. All done with the best intentions in maon. However, in the end, they lost a critical knowledge base of how the processes and systems worked to support customers. As a result, although everyone worked hard, customer service levels dropped by 25-50%.
In order to make this transition successful, it is vital to think carefully about who has what knowledge, skills, and history. Think about your leaders – both formal and informal. The trick is to utilize the informal and formal leaders effectively to leverage the collective talents of the organization to achieve a successful integration. Don’t forget about the critical employees who keep things going – shipping, receiving, calling customers etc. Each person plays a valuable role. Have you defined how each person fits into the integration plan? Have you communicated this to them?
3. Forgot to ask questions – Last but not least, don’t forget to ask questions. There is no way to know everything required to integrate successfully without continually asking effective questions. Questions need to be asked of each company, department, and person as the integration proceeds.
In the integration project, there were so many tasks and issues to address that the executives and project leaders didn’t have the time to ask enough questions. Thus, they didn’t know we were shipping 50% of our typical volume. They didn’t realize customers weren’t receiving the same level of service. They didn’t realize that production was inefficient. And they didn’t know what the suppliers expected. Without this critical information, it was easy for the systems to fall apart – and the integration program to fail.
Instead, ask questions. It’s important not to just ask random, meaningless questions, as that not only wastes time but it will also not help to achieve your goal. Take the time to learn about the culture, people, processes, and systems, and then ask questions. Make sure project team members know that you care about their responses.
It is always easy to identify issues with others’ projects (and tempting to tell them all about it); however, it’s not nearly as easy to see or implement on your own projects. Spend the time upfront to think through examples of program, project and task successes and failures – both yours and others. What were the root causes of failure? Ask the project leader. Ask team members. Incorporate the lessons learned into your project, and you’ll succeed when it counts the most!
Don't forget to leave your comments below.
Read the full case study – Denver International Airport Baggage Handling System case study – or read the abstract below.
Originally billed as the most advanced system in the world, the baggage handling system at the new Denver International Airport was to become one of the most notorious examples of project failure. Originally planned to automate the handling of baggage through the entire airport, the system proved to be far more complex than some had original believed. The problems building the system resulted in the newly complete airport sitting idle for 16 months while engineers worked on getting the baggage system to work.
Denver Baggage Handling System
The delay added approximately $560M USD to the cost of the airport and became a feature article in Scientific American titled the Software’s Chronic Crisis. At the end of the day, the system that was finally implemented was a shadow of what was originally planned. Rather than integrating all three concourses into a single system, the system supported outbound flights on a single concourse only. All other baggage was handled by a manual tug and trolley system that was hurriedly built when it became clear the automated system would never meet its goals.
Even the portion of the system that was implemented never functioned properly and in Aug 2005 the system was scrapped altogether. The $1M monthly cost to maintain the system was outweighing the value the remaining parts of the system offered and using a manual system actually cut costs.
Contributing factors as reported in the press :
Underestimation of complexity. Complex architecture. Changes in requirements. Underestimation of schedule and budget. Dismissal of advice from experts. Failure to build in backup or recovery process to handle situations in which part of the system failed. The tendency of the system to enjoy eating people’s baggage.
Full case study :
For more information read the following in-depth analysis –
Denver International Airport Baggage Handling System case study
Related story :
In Apr 2008 British Airways & British Airports Authority encountered serious problems when Heathrow’s Terminal 5 opened. Again Baggage system glitches were a major contributor to the problem.
Reference links :
- Denver Airport to mangle last bag
- The baggage system at Denver : prospects and lessons
- MSNBC on Denver’s Automated Baggage System
Other case studies :
- US Census Bureau – Field Data Collection Automation project