Stages of Blame for a Failed Project Funny

Project Management is a very interesting topic. I am inspired by Vikas Singhai while writing this blog on discussion of various case studies of Project Management.

There is no silver bullet for project success since we are all humans prone to make mistakes often based on assumptions, beliefs, and unhealthy ambition. Even the best method is only as good as the degree to which it is applied and enforced. Every project failure carries with it at least one practical lesson for helping project managers improve their project management skills. And the best part of learning from a bad experience is that it is very hard to forget the lesson.

This blog is based on lessons learned from various famous failed projects.

A) Communication Failure - Space Shuttle Challenger disaster

The Challenger shuttle crew, of seven astronauts died tragically in the explosion of their spacecraft during the launch from the Kennedy Space Center on January 28, 1986. The explosion occurred 73 seconds into the flight as a result of a leak in one of two Solid Rocket Boosters that ignited the main liquid fuel tank.

The NASA investigational Rogers commission's report on the incident cited the cause of the disaster as a failure of an "O-ring" seal in the solid-fuel rocket on the Space Shuttle Challenger's right side. The faulty design of the seal coupled with the unusually cold weather of the launch date, let hot gases leak through the joint and allow fuels from the tank and booster mixed and ignited, causing the Space Shuttle Challenger to tear apart.

The commission not only found fault with a failed sealant ring but also with the officials at the National Aeronautics and Space Administration (NASA) who allowed the shuttle launch to take place despite concerns voiced by NASA engineers regarding the safety of the launch.

Lessons Learned - The engineers had told NASA the O-ring had unidentified and unsafe factors, it may cause dangerous and Challenger launch had risk. But NASA insisted to launch as blindness. The main gap between Engineers and managers is that they are in different level. Absolutely managers are higher than engineers. They could not communicate at an equality level. It caused managers make an arbitrary decision. There was a big communication gap and Risk was not managed properly which could have been avoided this disaster.

Challenger Disaster - Case Study

B) Death March Project - Baggage System Failure at Denver International Airport

What is a Death March Project ?

According to software industry veteran Edward Yourdon, a Death March project is any project "where the schedule, budget, staff, or resources are 50–100 percent less than what they should be." Thus, a death march isn't merely a project which experiences failure, but one whose failure could have been anticipated from the outset, given proper planning. In this sense, it is a "march" toward almost certain failure.

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. It was contracted to BAE Automated Systems Inc. The project was expected with the integrated automated baggage system to increase ground time efficiency and reduces the time wasting manual baggage handling and sorting. 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 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.

Lessons Learned -

a) Scope Creep - The automatic baggage system was not included to the original design of the project plan, the geometry of the airport which was already in construction was too tight for the automatic system to fit in, the automatic system had to be forced to fit in the boundaries of the airport passenger buildings, the underground tunnel that connects the concourses and the terminal.

b) Chaotic Communications - Communications between the Denver officials, the project management team, BAE and the airlines were never clearly defined.Each party had their own task tracking systems and there was a lot of redundancy.

c) No Proper Testing - The schedule of the system (within 21 months) was too tight.The tight schedule did not allow the system to be tested for at least six months to enable corrections.

d) No Stakeholder involvement - The project faced major issue when Walter Slinger who was the system's de facto sponsor died in October 1992; his death left the project without critically needed leadership. A new leader was appointed but the leader lacked the profound engineering knowledge required to understand the system.

Denver Airport Baggage Issue - Case Study

C) A True Story Of Scope Creep - The Wasa (Vasa)

Wasa (Vasa) is a Swedish warship built between 1626 and 1628. The ship sank after sailing about 1,300 m (1,400 yd) into her maiden voyage on 10 August 1628.

The ship was built on the orders of the King of Sweden Gustavus Adolphus as part of the military expansion he initiated in a war with Poland-Lithuania (1621–1629). Sweden was leading power in Europe during that time. It was time for a new era of large battleships, which demand the enemy's respect, serving as firing platforms for mighty cannons to fight from a distance. The king himself was principal stakeholder and sole sponsor of the projects to construct the Vasa. So what went wrong !

Lets check from Project Management eye - It is important for a project manager to have strong sponsorship commitment and ability to control the project scope. Controlling scope does not mean that no changes are possible after the project starts – this would be unrealistic. As a rule, changes late in the project increase cost dramatically, so avoiding 'scope creep', i.e. uncontrolled changes late in the game, is a crucial. King kept on adding scope to ship e.g. increase size of ship, include heavy artilary etc. without knowing the Risks of end product.

Lessons Learned -

a) Stakeholder Disengagement - Poor communication between sponsor/stakeholders and the project manager. The King gave orders from afar without visiting the construction to connect with key players and make more informed decisions (a Show & Tell could have avoided this issue)

b) Scope Creep - King does not know every task that goes into each change and the risks it induces. It demonstrates even more the importance of a controlled change management process that reflects the impact of each change transparent and realistically. This gives the sponsor or stakeholders a chance to reconsider whether the change should then be approved or not.

Wasa's Failure - Case Study

D) Communication and Operational Failures - Sinking of the Titanic Ship

On 10th April 1912, the RMS Titanic set sail from Southampton bound for New York City carrying 2,224 people. What happened next is well known, as at 11:40pm on the 14th April, just 4 days into the crossing, she hit an iceberg and sank 2 hours and 40 minutes later, leaving only around 705 survivors.

Titanic story from a project management perspective shows how the decisions made during design, construction, and sea trials (testing) compromised the ship's integrity and left it vulnerable to disaster.

a) The three key stakeholders of the White Star Lines RMS Titanic, JP Morgan (Financier), Bruce Ismay, White Star Chairman and Lord Pirrie, Chairman of Harland and Wolfe (White Stars ship builder of choice), worked together on a strategy to compete against their business rival, Cunard. They decided their Unique Selling Point was luxury rather than speed, with three ultra modern ships, the Olympic, the Titanic and a third ship (the Britannic) to be financed from the profit of the first two. Conflicting priorities of each of the Stakeholders which led to scope creep.

Lessons Learned - Project managers need to understand clearly who the key stakeholders are and their expectations, as well as defining how strategic goals are agreed and the approach for achieving them.

b) Flawed Lessons from the Olympic (which had been badly damaged in a collision earlier) were used to modify Titanic's design to further reduce the number of lifeboats, increase 1st Class accommodation and add extra reinforcing to reduce vibration. The Chief Designer, Carlisle resigned over the lifeboat issue, but his concerns were steadfastly ignored by the stakeholders.

Lessons Learned - Communication and operational failures in projects as scope is changed without consideration of the full impacts.

c) No proper Testing - The collision damage to the Olympic required repairs in the same shipyard building the Titanic - so much so that her sea trials were reduced to half a day because of the marketing pressure not to delay the Titanic's maiden voyage. Her crew were only given 5 days to prepare, so they were not even familiar with the ships layout. This somewhat confused situation was compounded by a last minute change of senior officers. The maiden voyage itself became the sea trial and the operational/management problems were made worse because Ismay was chasing a marketing coup of the fastest crossing. The teams had not had chance to go through the forming, storming and performing journey in preparing for the voyage.

d) Crow nest doesn't have access to binoculars as its with captain rank people only. Hence they have to see if any iceberg on their way through naked eye only. There were no clear roles, operating processes or decision escalation procedures. Interpersonal and communication skills were lacking.

e) A few hours before the collision, wireless operator Jack Phillips received a message from a nearby ship, telling him of icebergs in the area. However, Phillips at the time was taking care of messages to and from Titanic passengers and in doing so, was communicating with a lighthouse at Cape Race, Newfoundland. Unhappy with what he considered a bothersome message, and assuming it was unimportant, Phillips replied brusquely, "Shut up, I am working Cape Race!" As a result, Phillips never received the iceberg warning the ship was trying to send.

Titanic, Project Management Blunders - Case Study

E) Mushroom Management - Debacles of Enron, Worldcom, Lehman Brothers & Satyam

Mushroom Management, also known as Pseudo-Analysis or Blind Development, is a mocking term used to describe the running of a company where the communication channels between the managers and the employees do not work properly. The term alludes to the stereotypical (and somewhat inaccurate) view of mushroom cultivation: "Kept in the dark and periodically given a load of manure".

The main reasons for the development of mushroom management (Keep them in Dark and Feed them Sh*t) within a company can be found at the managerial level. Mushroom management often develops when managers see themselves as the sole decision-makers within the company, rather than the people who lead all the employees towards a shared success.

Of these scandals mentioned below significant amount of information hide to employees, investors as well as lying to other involved parties. The consequences of mushroom management can be extremely detrimental for everyone involved in the company.

Don't miss the fun part !

Image Courtesy - accounting-degree.org

F) Blame Game - Ford and Firestone Tire Issue

The Ford Motor Company had a historically strong relationship with Firestone since its inception, with Henry Ford and Harvey Samuel Firestone being personal friends and even the two families being linked in marriage with their respective grandchildren in 1947.

The Ford-Firestone Tire and Rubber Company dispute transpired in August 2000. In response to claims that their 15-inch Wilderness AT, radial ATX and ATX II tire treads were separating from the tire core—leading to crashes—Bridgestone/Firestone recalled 6.5 million tires. These tires were mostly used on the Ford Explorer, the world's top-selling sport utility vehicle (SUV).

The two companies committed three major blunders early on, say crisis experts :

a) First, they blamed consumers for not inflating their tires properly.

b) Second, they blamed each other for faulty tires and faulty vehicle design.

c) Lastly, they said very little about what they were doing to solve a problem that had caused more than 100 deaths—until they got called to Washington to testify before Congress.

This issue effectively put an ending of a 100-year supply relationship between Ford/Firestone.

Lessons Learned - Have good PR (Public Relations) representation. Have a solid crisis communications plan in place, just in case. Provide quick, up-front and honest answers through your PR plan. Long delays and negative press can kill established name brands.

Ford & Firestone - Case Study

G) Boondoggle - Canada's Gun Registration System

A Boondoggle is a project that is considered a waste of both time and money, yet is often continued due to extraneous policy or political motivations.

In June 1997, Electronic Data Systems and SHL System house started work on a Canadian national firearm registration system. The original plan was for a small IT project that would cost taxpayers only $2 million -- $119 million for implementation which was to be offset by $117 million in licensing fees.

But then, politics got in the way. Pressure from the gun lobbyists and other interest groups resulted in more than 1,000 change orders in just the first two years. The changes involved having to interface with the computer systems of more than 50 agencies and since that integration wasn't part of the original contract, the government had to pay for all the extra work. By 2001, the costs had ballooned to $688 million, including $300 million for support.

But that wasn't the worst part. By 2001, the annual maintenance costs alone were running $75 million a year. A 2002 audit estimated that the program would wind up costing more than $1 billion by 2004 while generating revenue of only $140 million, giving rise to its nickname: "the billion-dollar boondoggle."

Lessons Learned - Define your project scope and freeze specifications before the requests for changes get out of hand. Learn how to control scope creep by utilizing change management and defining Project Scope.

A billion dollar Boondoggle - Case Study

H) No Risk Management - Sydney Opera House

The Sydney Opera House is one of the best-known iconic buildings, recognized around the world as a global symbol of Australia. The Danish architect Jørn Utzon won the architecture competition set out by the New South Wales government for the new building in 1957, and the construction started in 1959. The project was originally scheduled for 4 years, with a budget of AUS $7 million. It ended up taking 14 years to be completed and cost AUS $102 million.

The Sydney Opera House could probably be seen as one of the most disastrous construction projects in history not only from the financial point of view but also for the whole management plan.

Lessons Learned -

a) There was no plan, only an aspiration. When construction started there was no clear concept of how the roof might be constructed. It's not that the estimates were wrong, it's that there was nothing to base the estimates on in the first place.

b) The Sydney Opera House project had no project manager, and it was assumed that Utzon would take the initiative for all decisions regarding design, construction, or development. There were no project evaluation measures or officially in place, and for that reason, goalposts and implementation methods kept on changing. Some sections of the opera house were even built then later demolished, re-designed and built again.

But later this architecture considered as Successful boondoggles - the cost of construction of the Sydney Opera House ballooned over 1,400 percent, but the building has since become an icon for the city and for Australia.

I ) Kongo gumi - The End of a 1,400-Year-Old Business

Japanese temple builder Kongo Gumi, in operation under the founders' descendants since 578, succumbed to excess debt and an unfavorable business climate in 2006. Kongo Gumi also boasted some internal positives that enabled it to survive for centuries. Its last president, Masakazu Kongo, was the 40th member of the family to lead the company.

They survived countless political crises, wars, and natural disasters. They survived the Meiji Restoration in the 1800s, a period in which the government set out to eradicate Buddhism from Japan, and hence, the temple building industry. What brought down a company after 1,428 years?

They even survived two atomic bombs. What Kongo Gumi couldn't survive was debt.

Lessons Learned - This is an incredibly important lesson: debt is a killer. And no one is immune to this inevitability.

a) First, during the 1980 bubble economy in Japan, the company borrowed heavily to invest in real estate. After the bubble burst in the 1992-93 recession, the assets secured by Kongo Gumi's debt shrank in value.

b) Second, social changes in Japan brought about declining contributions to temples. As a result, demand for Kongo Gumi's temple-building services dropped sharply beginning in 1998.

c) Third, no Plan B - own a business, and hold your assets all in just one country, you are putting all of your eggs in one basket. Any economy or natural disaster could lose everything.

Kongo gumi - Case Study

J) Risk Management - FoxMeyer Drugs Bankruptcy

In 1993, FoxMeyer Drugs was the fourth largest distributor of pharmaceuticals in the U.S., worth $5 billion. In an attempt to increase efficiency, FoxMeyer purchased a SAP system and a warehouse automation system and then hired Andersen Consulting to integrate and implement the two in what was supposed to be a $35 million project. By 1996, the company was bankrupt; it was eventually sold to a competitor for a mere $80 million.

The reasons for the failure are familiar. First, FoxMeyer set up an unrealistically aggressive time line, the entire system was supposed to be implemented in 18 months. Second, the warehouse employees whose jobs were affected -- more accurately, threatened -- by the automated system were not supportive of the project, to say the least. After three existing warehouses were closed, the first warehouse to be automated was plagued by sabotage, with inventory damaged by workers and orders going unfilled.

Finally, the new system turned out to be less capable than the one it replaced: By 1994, the SAP system was processing only 10,000 orders a night, compared with 420,000 orders under the old mainframe. FoxMeyer also alleged that both Andersen and SAP used the automation project as a training tool for junior employees, rather than assigning their best workers to it.

In 1998, two years after filing for bankruptcy, FoxMeyer sued Andersen and SAP for $500 million each, claiming it had paid twice the estimate amount only to get the system in a quarter of the intended sites. The suits were settled and/or dismissed in 2004.

Lessons Learned - A risk assessment is critical to the success of a project. Project Risk identification helps organizations identify significant risks, estimate their probability of occurring and evaluate the impact in terms of cost and time. Planning Risk assessment ahead and preventing project failure can help you avoid a horror story like FoxMeyer's.

K) The Hubris Effect - Nokia Fallout

'Hubris' The characteristic of excessive confidence or arrogance, which leads a person to believe that he or she may do no wrong. The overwhelming pride caused by hubris is often considered a flaw in character.

Is Hubris killed Nokia ? In 1999, there was no other phone to have than a Nokia. The brand was at the top of its game with a market share that made it the envy of all other mobile phone brands. Nokia was so big that The Matrix, the biggest science fiction futuristic movie of the spring of 1999, had its heroes wielding a Nokia 7110, with a spring-action slider that popped open for a dramatic effect. The phone was then the natural choice for the movie because Nokia dominated the phone market from 1998 to 2012. The annual revenue for the Finnish company that employed 100,000 people in 120 countries was $30 billion at one point in time. Then, on June 29, 2007, Apple introduced its iPhone. Nokia was baffled. All it could say was that the iPhone battery was rubbish and no one would use it once the consumers figured that out.

Consumers were unimpressed by Nokia's response, and they were quick to abandon Nokia when they depended on its 47 percent market share and failed to respond to Apple's innovative phone. From then, Nokia's market share shrank by double digits each year. It fell and lost customer emotional loyalty after being perched atop the mobile phone category for almost 10 years.

Lessons Learned -

a) First, never rest on your laurels. Nokia got to the top of its industry quickly. But once there, it became complacent in an industry where laziness is fatal. It worried too much about hanging on to its market share, rather than creating new products to excite customers.

b) Second, Nokia became more of a maintainer, more of an iterator, whereas innovation only comes in re-invention and Nokia waited too long to make the next big bold move.

Nokia Fallout - Case Study

L) Risk Management - Columbia Shuttle Disaster

On February 1, 2003 seven astronauts perished when their Columbia Shuttle disintegrated as it reentered the earth's atmosphere. During launch a piece of foam insulation, about the size of a briefcase, broke away from the main propellant tank. The foam struck the left wing seriously breaching the protective panels on its leading edge.

It was not the first time that a section of foam had broken away during launch. In fact, it had happened on every previous flight. But on each of these flights the spacecraft reentered the earth's atmosphere without incident and safely returned home. With no evidence that harm was done to the spacecraft, management assumed that it was a problem of minor significance and that it did not increase the risk level of the flight

Technical or Management Problem ?

Just after the 2003 tragedy occurred many experts concluded that technology was to blame. But a more thorough and comprehensive investigation, undertaken by the Columbia Accident Investigation Board, CAIB, concluded differently. It maintained that management was as much to blame for the failure as was the foam strike. The Board described an organizational culture in which, at every juncture, program managers were resistant to new information. It was a culture in which people were unwilling to speak up or if they did speak up were never heard. In their report they wrote that the organizational failure was a product of NASA's history, its culture, and its politics.

Lessons Learned -

a) Conservatism, a situation in which new information is ignored or given too little weight. Senior management largely ignored the data from previous flights where foam had broken away on every launch; they failed to revise their prior belief that the system was operating properly.

b) Overconfidence. During the flight, engineers, concerned that the foam strike may have caused a problem, asked the Mission Management Team (MMT) to request satellite imagery of the spacecraft. Management, however, was apparently confident that there was no safety issue and a decision was made against imagery. Had the imagery been authorized, and the damage discovered, the conjecture is that a rescue attempt would have had a reasonable chance of success.

Columbia Disaster - Documentary

List can go on continue, send me if you have any case studies, I will be pleased to include them on this blog.

Conclusion -

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. During the course of managing a project, the project manager must monitor activities (and distractions) from many sources and directions. The failures of past projects are opportunities we can harness to increase our chances of success if we share the lessons learned to all of the relevant stakeholders and other decision makers in an organization.

I recall something Dr. Martin Luther King, Jr. said 50 years ago: "If you can't fly, then run. If you can't run, then walk. If you can't walk, then crawl, but whatever you do you have to keep moving forward."

Disclaimers :- It is a personal weblog. The opinions expressed here represent my own and not those of my employer. Just in case, if I say something stupid, it's better to be able to point out that the stupidity is mine, and mine alone. My stupidity! You can't have it! :)

Credit : wikipedia, Youtube, hbr.org, investopedia.com, accounting-degree.org

ABOUT THE AUTHOR: A Technophile, Project/Prog Manager, Blogger, Agile enthusiast, Digital, Delivery & Quality Focused professional.

petersrathe1960.blogspot.com

Source: https://www.linkedin.com/pulse/project-management-lessons-learned-from-failed-samir

Share this post