By Paul Glen
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.
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
For a very small investment, projects can prevent huge overruns or at least fail
prior to their occurring.
- Test the likelihood of the threat occurring
- Reduce the probability that the threat will occur
- Reduce the impact should it
Risk Management in the Microsoft Solution Framework
The Microsoft Solutions Framework provides a simple and effective approach to
risk management. The steps involved are:
The keys to implementing successful and cost effective risk management are:
- Identify project risks
- Analyze the risks
- Plan what to do about them
- Track progress to plans
- Control the risk management process
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
- Examine project risks on a regular schedule. It has to
be a process rather than an event.
- Use the information and tasks generated in the risk management
process to guide the project plan.
- Use everyone in the process.
- Treat risk identification as a positive value.
About the Author:
Paul Glen is the author of "Leading Geeks: How to Manage and Lead People Who Deliver
Technology" (Jossey Bass Pfeiffer, 2002) and Principal of C2 Consulting. C2 Consulting
helps clients build effective technology organizations. Paul Glen regularly speaks
for corporations and national associations across North America. For more information
go to http://www.c2-consulting.com.
He can be reached at email@example.com.