Saturday, October 5, 2024

Should You Euthanize Your Project?

You probably haven’t thought about inviting Dr. Kevorkian to one of your project meetings, but maybe you should. Although you might not want to join Dr. Kevorkian’s well publicized crusade to legalize physician assisted suicide, he has some very valuable lessons to teach us about delivering successful IT projects.

As IT professionals, we frequently find ourselves desperately trying to keep dying projects alive, when we should perhaps consider whether to help them die gracefully. My version of the good doctor’s position is the counter-intuitive idea of “Rush to Failure.” If your project is going to fail anyway, kill it after spending only $10,000 rather than $10 Million.

Why would I want to “Rush to Failure”?

There’s a well-known but rarely discussed dirty little secret in the IT world. We’ve got an absolutely abysmal track record when it comes to delivering projects. According to a recent study done by the Standish Group 28% of software development projects are canceled without ever delivering anything, and another 46% of these projects eventually deliver late or over budget. Combined, that means that three quarters of development projects can be classified as failing at some level.

Unfortunately, it gets worse. According to the Gartner Group, approximately 80% of projects will fail to meet major business objectives or will only meet them with extra effort from the vendor, client or both. Gartner even recommends using this as a fundamental assumption for strategic planning. (An assumption!! It’s more like an indictment!)

Given that this is the current state of the art in IT projects, we can either continue to assume that all projects are worth saving, or we can consider Dr. Kevorkian’s example.

Proactive Risk Management

Of course, the hard part is identifying which projects to kill and when. It won’t be apparent from looking at the traditional project management tools such as schedules, task lists, budgets, Gantt charts, pert charts or resource lists. A missed milestone or a late task is not sufficient information to take wise action. The only project management tool that can be helpful in identifying the proper course of action is also the least used of all tools, risk management.

Proactive risk management refers to the constant identification of and action planning for project threats. Among the popular project management tools, risk management occupies a unique position. It is the only tool designed to deal with the complexity of reality.

Standard project management tools are designed to help make assumptions and estimates about the unknowable reality of a project. They help simplify reality to make it manageable, but in doing so lose much of the most important information about a project, the risks. Project plans don’t contain information about issues and events that might come up. Plans are about certainty. Reality is uncertain.

Risk management attempts to capture and manage the subtle nature of the unknown. Project threats from all foreseeable sources are identified and quantified providing a basis for early decision-making.

This information is the key to effective application of “Rush to Failure.” The probability and significance of project threats form the foundation for wise action. Once a threat has been identified and analyzed, actions can usually be planned to:

  1. Test the likelihood of the threat occurring
  2. Reduce the probability that the threat will occur
  3. Reduce the impact should it

For a very small investment, projects can prevent huge overruns or at least fail prior to their occurring.

Risk Management in the Microsoft Solution Framework

The Microsoft Solutions Framework provides a simple and effective approach to risk management. The steps involved are:

  1. Identify project risks
  2. Analyze the risks
  3. Plan what to do about them
  4. Track progress to plans
  5. Control the risk management process

The keys to implementing successful and cost effective risk management are:

  1. Examine project risks on a regular schedule. It has to be a process rather than an event.
  2. Use the information and tasks generated in the risk management process to guide the project plan.
  3. Use everyone in the process.
  4. Treat risk identification as a positive value.

If you follow these basic guidelines, you can become the counter-intuitive hero, capable of saving immense amounts of money and time, by following the rule “Rush to Failure.”

Paul Glen is an IT management consultant and the author of the award-
winning book “Leading Geeks: How to Manage and Lead People Who Deliver
Technology” (Jossey-Bass Pfeiffer,2003). He regularly speaks for
corporations and national associations across North America. For more
information go to: http://www.paulglen.com. He can be reached at
info@paulglen.com.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles