Controlled Flight into the Ground

[article]
Summary:

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,

About the author

Peter Clark's picture Peter Clark

Peter Clark has twenty years of experience in industrial automation. He currently manages teams working in materials handling, especially baggagehandling systems. A regular columnist on StickyMinds.com, Peter can be reached at pclark@jerviswebb.com.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03