Role-Based Project Management Software
Project risk management is essential to make projects finish successfully. When projects that have failed miserably are analyzed, in most cases it is found that some unexpected serious crisis has occurred. Risk responses were not planned, the project management team had to improvise. Bad decisions were made causing high level of rework, over cost, delays, etc. Finally it was impossible to deliver the value or to meet the requirements.
Many projects fail because, all of a sudden, unexpected problems arise that make the project worthless. Risks are identified, a risk register is published, risks are reported on status reports, and mitigation strategies are approved. Risks are monitored and controlled. If one only reviews the risk lists and records, it appears that the project is low-risk. All the risks enumerated are at the inconvenience or nuisance level. The risk tracking proceeds without variance until the project is suddenly canceled. Those risks truly important were simply ignored. In words by Tom DeMarco[1]:
“People take elaborate care not to trip over the railroad ties, but nobody can see the oncoming train!”
Some examples of risks management ignoring the “oncoming train”:
- A consulting project to aid business development of SMEs in Egypt funded by government was canceled on March 2011. No steering committee member in Madrid listed the risk of Hosni Mubarak’s fall.
- One software projects in Chile was a financial failure because the prime contractor made us appear as responsible of functional flaws. This was a surprise for the project management team, who always assumed our team was responsible on the technical part of the scope.
- Other example far to my experience, but quite a classic on Risk Management, was the case of the Denver Airport, which opened 15 months later because of a single software program to handle baggage automatically.
As a professional project manager, you want to have problems; you don’t want to be shocked. You try to anticipate to problems that could cause delays or higher costs. You want to manage problems when you have the time, and options are still open. You watch risks continuously to anticipate problems and plan responses before they materialize. You also anticipate positive uncertainties, those that could make the project finish earlier or cheaper.
When problems materialize, you will give a good professional image if you anticipated them and you had a planned response. On each follow-up meeting, you assign time to risk management –it may be enough if you review only the most important ones. When you describe a risk, don’t forget to communicate the risk exposure expressed in money terms. If response is to accept, then take note of when and who decided it in your risk register.
[1] Waltzing with Bears: managing Risk on Software Projects. Ed. Dorset House Publishing, 2003.