3 Biggest Causes Of Project Failure
Project failure. It’s a subject that’s discussed over and over again. According to the research done by Project Management Institute, more projects are actually failing and it’s causing us to lose time and money. We want our projects to be on time and within budget but the reality is far from that. Don’t you hate that? On time and within budget? When actually, only about 53% of projects are completed on time and 49% are completed within the original budget.
Whether project failure is caused by the project not meeting its goals, the timeframe, the budget, scope creep, or something completely different, we normalize it. It just happens so often that we seem to ignore any deviance that occurs.
We want to take a few steps back in history in this article. We are going to take you back to the 70s and the 80s to discuss what happened to NASA Space Shuttle Challenger and the tragic Tenerife Airport disaster. It turns out that you can learn a lot about the what causes project failure from these two incidents.
Two completely different scenarios. Failures that had the cost of human lives.
NASA Space Shuttle Challenger was supposed to launch the orbit for the tenth time on January 28, 1986. It never happened. It exploded about 73 seconds after lift-off resulting the death of the seven crew members that were on board.
The Tenerife Airport disaster is the deadliest accident in aviation history. On March 27, 1977, two Boeing 747 jets collided on the runway of Tenerife Airport. The accident took the lives of 583 people.
It might seem that the two disasters have as little to do with each other as they do with the projects you are planning resources for. However, the analysis of the two incidents shows that both of them could have been avoided using the same resource management and project leading principles.
1. CLEAR COMMUNICATION PATHWAYS AND STRUCTURE
The NASA Space Shuttle Challenger blew up because there had been three abnormally cold nights in California to which the launch vehicle was exposed. The cold made the O-ring on one of the solid rocket boosters become brittle. A tiny thing that anyone could have missed, right?
Regardless, what happened wasn’t solely the case of poor risk management. It was also the case of poor communication. Prior to the Challenger’s launch, NASA was warned about the O-rings. However, since there wasn’t a clear communication strategy, the people that were deciding the launch of the shuttle had no knowledge about the safety concerns of the engineers and the engineers had no proper way to report the concerns to the decision-makers.
The decisions made at the Tenerife airport on the day of the accident were partly caused by faulty communication, too. Although there are strict communication protocols regarding communication prior to takeoff, it still happened.
The heavy accent of the air traffic controller mixed with overlapping radio transmissions and confirmation bias lead to one of the Boeing's co-pilot's reading back the ATC clearance and adding “we are now at takeoff” to which the tower replied with “OK...”. The tower obviously interpreted the co-pilot’s sentence to be “We are now at takeoff (position)” but not as “We are now taking-off”.
A few moments later, the biggest crash of aviation history happened.
30% of projects fail because of inadequate or poor communication. That’s why project communications plans exist. That’s why every project team member has to follow the rules set by project communications plans. Every time. Experts must have a way to communicate with the managers. All your stakeholders must get the information they need to make decisions. If there’s a protocol, it must be followed. If you are not sure, don’t assume. Ask.
Some things can easily be communicated using a central resource management tool - who's doing what, where's the equipment being used etc. You can also use the tool for leaving smaller notes about the changes. However, even those kind of small things should be regulated, don't leave it out from your communications plan.
2. THE FLATTER THE BETTER
In NASA’s case, the engineers didn’t have a way to notify the decision-makers of what can happen to the O-rings when exposed to cold conditions. Partly because there wasn’t a project communications plan and partly because of the hierarchy of the organization.
An analysis showed that the explosion of the Challenger could have been avoided if NASA’s management hierarchy would have been more ‘flat’. Flatter management structure allows project teams to work more fluidly and cohesively rather than by direction from upper management.
Hierarchy is the reason behind the fact that no one questioned the decision of the pilot to take off as well. That’s why hierarchy is also one of the reasons why two Boeing 747s collided on the runway of Tenerife Airport. In the 1970s the pilot was considered as the ‘Master of the Skies’.
Although the co-pilot dared to point out that there was no ATC clearance, and the flight engineer shyly asked if the other Boeing was on the runway, no one actually confronted the flight captain to make him stop what he was about to do.
This is why you as a team leader and a project manager need to make sure that your team feels like they can talk to you. Make collaboration a norm. Collaboration reduces ambiguities and ambiguities are what cause mistakes.
Make asking for advice a thing you should always do rather than the last resort. If it isn’t the case now, you need to make conscious steps to change the way authority is perceived by your organization. That’s the way your team will stop patching up timesheets and reports to cover their asses. That’s how you won’t feel that your team has developed defensive attitudes during project status meetings.
The right amount of authority is a good thing at times but too much of it will kill collaboration. Don’t let that happen.
All of your team member should have an access to the resource shedules. That way they'll feel more engaged in the decision-making process. As an added bonus, the team will know what others are doing. A transparent planning process is also beneficial to the sales team. They'll know when resources are free and when a new project can be taken on. Consider a resource management tool with pricing per resource instead the more common per user approach.
3. TAKE YOU OUT OF THE EQUATION
Although there were engineers and even upper-level managers that knew that the O-rings might cause problems during the launch of Challenger, the event was still not postponed. The program was highly publicized. It was supposed to be the first time a civilian was on board of a space shuttle. There already had been delays in the schedule. It was actually already the 7th attempt. That’s where human error kicked in. The pressure built up. For each their own.
The information didn’t reach the people that could have made the decision that could have saved seven lives. According to The Space Safety Magazine, NASA had a conference call with Morton Thiokol, the manufacturer of the O-rings. The concerns of an engineer Roger Boisjoly were pushed back. “My God, Thiokol, when do you want me to launch — next April?” said one of the shuttle program managers attending the teleconference.
On the day of the tragic accident, the two Boeings had been waiting at Tenerife for more than three hours. Both flight crews were under pressure to leave the airport due to the regulatory cap for maximum flight and duty time. If either of the planes should have stayed at the airport for much longer, it would have meant additional costs as well as further inconvenience for the passengers.
The captain that made the decision to take off was impatient because of the time-pressure which influenced how he dealt with information. His judgment on what he heard was biased. He had his mind set on leaving the airport as soon as possible.
Every problem you’ll ever encounter will seem like the most important problem because your problems are you-shaped. The upper management pressuring you because of the delays can seem like an attack on everything that is sacred. The fact that your resource planning leads to your team falling behind on schedule might seem like the most important thing to focus on.
You having to succeed with the project to get the promotion might seem like the ultimate goal. Now, I’m not saying that your problems aren’t ever the top priority. They are. Sometimes.
However, there are times where you running to solve your own problems first will snowball into something that can’t be solved. You should be able to make the distinction between problems that are yours and the problems that are really affecting your projects.
When assessing situations, always take yourself out of the equation, generate alternative actions, and identify possible risks. Take a step back and understand when you are making it about yourself.
Not all projects are the same but they fail for the same reasons. When making critical decisions consider lessons learned but be sure that you haven’t just been normalizing deviance.
Read further on how to solve these problems by defining your resource management strategy.