Is it a Risk Management Problem?

Managing Risk During Planning

Several years ago, we received a call from a customer asking if we had any techniques for managing risk on development projects.  We said that yes, we did, but that we wanted to understand their situation better before we suggested any techniques in particular.

This organization was a classic high-technology development organization. It had evolved from a startup to a company with several customers and a revenue stream.  Within the previous year, this customer – along with several other startups – had been acquired by a much larger player in the market.  Their products were now becoming more complex and were demanding a modular, parallel development approach.  To cope with the increasing demands from the new parent company for quality products and on-time delivery, the organization was now looking for a more rigorous process (but not too much).

So far so good.

What they wanted, we were told, were some techniques for measuring the risk that the modules and components would not work when they brought them together at the end of development, and before the product was shipped to the customer.

This was one of those moments when we had to ask to confirm that we were hearing correctly:  “… the risk that the software modules would not work together the first time…?”

So Where is the Risk?

The short version of the story is that we ended up doing some process refinement work and delivered some training to all their managers and senior technical staff on managing software development projects.

The longer version went like this:  this was not a risk problem;  it was a planning problem. For risk management techniques to be of any value, there must be some element of uncertainty.  There is no risk that software modules will not work the first time – it is a certainty. This is like the Ottawa automobile dealer that sold snow tires and offered to refund customers’ money if there was no snow in the area that winter – a pretty safe gamble.

What this organization needed was a good dose of realism in planning their projects, as well as a standard series of integration and testing steps after initial development and before shipping.

Now, there is a role for risk planning here:  while we know with confidence that integration and testing will be necessary, it is uncertain how long these steps will be, or how many attempts it will take to get a successfully integrated system.  Risk management could help us settle on a plan that we can be confident in, both in terms of number of steps and the duration of each.  There are several risk management techniques available to us:

• We could schedule the integration tasks to be very long.  This is a cautious approach, often called padding, buffering, or sandbagging.  A bit of buffer can be good;  too much would divert expensive resources from more important tasks.
• If we have the data, we could look at previous experience with integration and derive activities and durations for our current project. This is learning from experience.
• If we were able to estimate ranges for durations of the tasks – a best case (shortest duration), worst case (longest), and most likely case – we could use PERT (Program Evaluation Review Technique) to estimate the expected duration of each task and of the overall schedule.  These are called “three-point estimates.”
• If three-point estimates are available, another, more sophisticated technique – Monte-Carlo simulation – could be used to predict the likelihood of success of the project.

But all of this is secondary.  The first need is for thorough planning, involving all the participating groups.  Then the plan must be subjected to critical examination to ensure that no self-delusion is involved.

At this point, if the planners perceive that a better plan would result if some uncertainties were investigated and dealt with, then it makes sense to apply more rigorous risk analysis and perform some mitigation activities.

We should first deal with what is known - then worry about the unknowns.


Alan R. Boyce  B.A.Sc., MBA, P. Eng., PMP, CMC