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.

What are we talking about?

The first thing we need to do is define some very important terms that are often misused (I am the first to admit I have been guilty!).  I went to good old Dictionary.com and looked up the following:

• uncertainty - 1. the state of being uncertain; doubt; hesitancy; 2. an instance of uncertainty, doubt, etc.; 3. unpredictability; indeterminacy; indefiniteness.
• probability - 1. the quality or fact of being probable (duh!); 2. a strong likelihood or chance of something; 4. Statistics. a. the relative possibility that an event will occur, as expressed by the ratio of the number of actual occurrences to the total number of possible occurrences; b. the relative frequency with which an event occurs or is likely to occur.
• risk - 1. exposure to the chance of injury or loss; a hazard or dangerous chance; 2. Insurance. a. the hazard or chance of loss; b. the degree of probability of such loss.
• buffer - 1. an apparatus at the end of a railroad car, railroad track, etc., for absorbing shock during coupling, collisions, etc.; 4. a person or thing that shields and protects against annoyance, harm, hostile forces, etc., or that lessens the impact of a shock or reversal; 5. any reserve moneys, negotiable securities, legal procedures, etc., that protect a person, organization, or country against financial ruin.

The simple fact that we have to estimate something means we are uncertain; we have doubt, and that makes us hesitant to commit resources to a development project.  How uncertain we are translates into risk (an exposure to losing money or customers), because we may not achieve the project goals (deliver in 12 months, or keep the cost under $2 million).  Probability is simply the likelihood of an event or occurrence.  Only in relation to insurance, is probability used to define risk (as stated above).  My personal preference is to consider them separately.  

Risk is subjective; it’s a matter of personal or corporate tolerance for potential loss, compared to potential gain.  No matter your tolerance level, everyone appreciates the security of a cushion between themselves and potential loss; a buffer.  And if any of your projects have been like the ones I managed, you may feel like you are the buffer (see definition 4.)!  For development projects, buffer is a contingency, or management reserve.  It is usually money, but can also represent schedule days or effort hours.

What is the goal?

The goal of software project estimation is to come up with a reasonable, defensible work plan, hopefully based upon past experience.  If the predicted effort and duration are in line with your known capabilities, the plan is reasonable.  

If you don't have a historical database of projects, relevant history trend lines can be substituted for your own data.  If the estimate is within +/- one standard deviation of the average, it is reasonable.

The plan is defensible if the size and PI used for the estimate are based on reliable data.  Here is where the uncertainty comes in.  When we have unknowns, we must make assumptions.  In SLIM-Estimate, we can quantify the uncertainty for both Effective Size and PI.  Size is specified by entering two parameters:  the expected value (510 Objects), and range of uncertainty (no lower than 450, and no higher than 600).  With these two inputs, you can define a probability curve to account for your uncertainty.  

Your size estimate will carry more uncertainty early in the life cycle, and will depend upon how well you understand the requirements, and the rigor of your size estimation techniques. A PI calculated from your history carries less uncertainty than selecting a PI from the QSM database.

Are we done yet?

Let’s assume you have done your best to model your project’s life cycle methodology, estimate size and PI, and you’ve produced a reasonable, defensible estimate.  Your job is done if the Effort, Cost, and Duration of the proposed project meet the specified goals or constraints and are consistent with either relevant history or your own past performance.  The amount of risk associated with this estimate is due to uncertainty on the inputs, and is reported in the cost and schedule probability charts and reports.  Your work plan is the 50% solution detailed on the Solution Panel.

 Alas, rarely do the project constraints match our reasonable work plan.  Often more work is required to create a work plan you can commit to. 

In the next blog post, I will talk about the difference between the reasonable work plan, and the commit-to work plan (sometimes called the ‘risk-buffered’ solution) and explain why most of the work to quantify and buffer against risk is done in SLIM-Estimate.  In the third blog post, we’ll look at the definition of Control Bounds, how to configure them based upon the commit-to work plan, and the different sources of risk that arise once the project has begun.