Controlled Flight into the Ground


Perfectly good airplanes will sometimes crash for no apparent reason. The root cause is often pilot error. This is called "controlled flight into the ground." Seemingly well-run projects can also crash and burn. In this week's column, Peter Clark provides some indicators that will help you prevent your projects from falling victim to a controlled flight into the ground.

I was watching a program the other day on air disasters. One of the case studies involved an L-1011 cargo plane that crashed in Florida, killing everyone on board. Examination of the voice recorder revealed the crew had ignored repeated warnings to pull up because they had been distracted by the malfunction of another warning indicator. The aircraft was operating properly and the crew was in control, but a series of bad judgments resulted in literally flying the plane straight into the ground. Aviators call this "controlled flight into the ground." 
This piqued my interest, so I Googled the phrase "controlled flight into the ground." I found a site maintain by civil aviation authorities that briefly describes several scenarios. A common thread was "the pilot lost situational awareness"–a fancy way of saying the pilot is unable to process all of the information he receives into the proper context. Typical causes of this were lack of training for the conditions present, over-reliance on a single navigational aid, or fatigue.  

Throughout my career working on projects, I have witnessed and participated in my share of projects that have flown into the ground. These were "under control" projects–they had schedules; the schedules were regularly updated; plus, budget, quality, and process metrics were being maintained. But somehow, the project team, especially the project manager, eventually flew the project into the ground. 
Project often fly into the ground because teams spend too much time looking backward, rather than looking where they are going. Symptoms of projects with 20-20 hindsight include: 

  • Data being collected on the project is not used as feedback to control the project. 
  • The project team slips on the project schedule, but doesn't produce and track a recovery plan. 
  • The amount of open issues spiral upwards, but the team doesn't factor additional testing or additional remediation time into costs to complete. 
  • The project team sees that sixty percent of the available budget has been expended, while being only thirty percent complete, and doesn't do anything to control project scope. 

Relying on a single indicator to try to control the plane is just as bad. Teams will attempt to control project costs by eliminating testing or inspections, which causes quality problems to skyrocket. Then teams will attempt to control bug counts by fixing every bug, rather than triaging, causing costs and schedules to go out of control. Teams must maintain a balanced view of key project metrics for cost, quality, schedule, and process. 
The root cause for over reliance on a single metric often results from a lack of training of the project team, most likely the project manager (PM). Untrained PMs can only rely on their past experience to interpret the metrics presented. When novel situations arise, they are unable to put the metrics into the proper context. Upper management may also pressure PMs to optimize a single metric, usually either cost or schedule. This causes other areas (i.e. quality) to get much worse, creating delivery delays and increased overall costs. 
Projects also lose situational awareness when they descend into "fire-fighting mode." The team spends so much of their time putting out fires that they lose the ability to adequately monitor the project and build the project context. The project lurches out of control and flies all over the sky as team members attempt to optimize one area, causing future problems in others. 
Here are some steps you can take if you think your project is going to have a controlled flight into the ground: 

  • Recognize the Problem–backward looking project metrics, reliance on a single metric, and excessive fire fighting are all warning signs of controlled flight into the ground. 
  • Gain Altitude–Immediately establish a safety margin for your project and gain some breathing room. This will probably require taking a hit either with your management or your customer, or both. Explain the problem and the steps needed to bring the project back under control. 
  • Regain Situational Awareness–Gather all of the necessary metrics to establish the big picture. Meet with team members, both individually and as a group, to determine the meaning of these metrics. 
  • Establish a New Flight Plan–Establish a new plan to complete the project. Be sure to include adequate time for maintaining your situational awareness. Get buy-in for the plan from the team, your management, and your customer.  

There is little point in collecting project data if you're not using it to regularly and actively control your project. This will only benefit whoever replaces you. If you are not going to use project data to proactively address problems, then the time spent collecting data could be better spent fighting the fires that will inevitably break out. It's like the old saw about teaching the pig to dance–it's frustrating to you and annoying to the pig.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.