Risk Management
How do the uncertainty ranges in SLIM-Estimate relate to Control Bounds in SLIM-Control?
I am often asked this question during SLIM Training classes. I remember wondering about that myself. It is a logical question since SLIM-Estimate workbooks are often imported into SLIM-Control to create the baseline project plan. The answer is ‐‐ they are not directly related, because uncertainty ranges, probability curves, and control bounds are designed to perform different tasks. This post is the first in a series looking at risk associated with an estimate, risk of your project plan, and handling deviations from the plan.
For More Accurate Software Estimates, Avoid Hidden Risk Buffers
A colleague of mine recently sent me a blog post explaining the difference between project contingency and padding. The blogger made the distinction that padding is what often gets added to an individual’s estimate of the effort required to perform a task (in her example, a software development task) to account for project ‘unknowns’. The estimator determines the most likely required effort, then pads it with a little more effort in order to arrive at an estimate to which he or she can commit. Thus, padding represents an undisclosed effort reserve (and implied schedule reserve) to buffer against potential risk. Contingency reserve, she explains, is “an amount of money in the budget or time in the schedule seen and approved by management. It is documented. It is measured and therefore managed.” Ms.
Managing Software Risk via "Whether Forecasting"
Here's a risk question for you:
If today’s weather forecast predicts a 40% chance of rain and it actually rains, was that forecast “inaccurate”? If the weather channel predicts a 40% chance of rain, but the sun shines all day, was the forecast “accurate”?
Software project estimates, like weather forecasts, should always be accompanied by some explicit attempt to quantify the risk that the actual outcome will differ significantly from the estimated outcome. Estimates delivered without explicit risk assessment are more like targets: goals someone wants to achieve.
Why Does Project Size Grow?
Seen from an airplane window, the ground looks almost two dimensional. Only the largest features: cities, rivers, and mountain ranges, stand out against the background. The true complexity of the terrain only becomes apparent after we land and have to navigate through congested traffic, bad weather, and one-way streets.
Software projects are similar. Staffing and budget plans are often based on high level requirements that tell us what needs to be done, but not how to accomplish it. As business objectives are translated into the actions that need to be taken and the work products that must be produced, the size of the project, whether expressed in lines of code, function points, or RICEF objects, increases along with the time and effort required to create them.
Managing Risk on Iterative Developments
Managing risk for a single project is a fairly well understood problem. If the project contains multiple releases and they are independent, risk management remains fairly straightforward:
A software development project is going to proceed concurrently with the development of a new piece of hardware required to implement the software. Scheduled completion dates for both developments have been determined and a project plan has been created. Both projects can proceed independently until their respective completions (probably an unwarranted assumption, but this is a simple example!). Both projects must succeed in order for overall success to be achieved.
