Mitigating Risk from Scope Uncertainty

Typically it is difficult to estimate the LOE of a project given only a preliminary scope statement. In cases of high degree of scope ambiguity, the Lead may recommend that the Chartering Authority authorize a Requirements-Only Phase of the charter. The Lead should provide LOE for this phase. If the Requirements-Only Phase is approved, the Applications Team performs the requirements analysis and returns a new estimate of the LOE for the rest of the project. The Chartering Authority will again review the charter and vote on whether to proceed.

Despite the name “Requirements Phase,” the true focus of the phase is to reduce schedule risk by reducing uncertainty around the LOE to complete the project. This will be accomplished by the means of doing requirements. Keeping this in mind will direct the focus of the requirements gathering activities.

Generally speaking, LOEs are typically underestimated at the beginning of a project. This is not because people are underestimating what they see, it is because there is always a fair amount of scope that they do not see. This is scope that will need to be done which is not known/identified at the beginning (in the preliminary scope statement) and so goes without being estimated. The take-away is that is that the group should first concentrate on getting a handle on the breadth of the requirements (Use Cases) so it at least knows everything that is on the plate. After that, it can go about figuring out how big each of those things is. So first eliminate the "unknown unknowns" so that we are left only with "known unknowns".

When the team knows the breadth then it can start looking at the depth. The length of the Requirements-Only Phase should not be set with the goal of gathering all of the requirements; it should be set with the goal of reducing LOE uncertainty enough to make a confident estimate. Requirements will continue to be refined through the Development and Test phase. Therefore, assume that not all the requirements will be fleshed out by the end of the Requirements phase. This means that prioritization is needed. Prioritize based on the need to reduce uncertainty.

The approach to take is to flesh out the requirements and estimate a small number of representative Use Cases. With that information in hand, one can quickly make reasonable back-of-the-envelope LOE estimates of other use cases without fleshing out their requirements. In other words, look at Use-Case-X (which has not been fleshed out), reason through the general similarities/differences with Use-Case-A (which has been fully fleshed out and estimated) and come up with a number of how big it is in comparison. Does it look to be about the same size, twice the size, 1.5 times the size? Then give Use-Case-X a preliminary estimate based on the size of Use-Case-A times this scaling factor. This gives us a fairly reasonable estimate of the whole product given the information in hand.

The next Use Case chosen to investigate should be one that is hard to estimate (i.e. we don't have confidence in an estimate) typically because it is different from the others Use Cases already analyzed. So we do this iteratively, analyzing the Use Cases in a priority based on the analysis's return on investment of reducing LOE uncertainty. Keep doing that until time runs out. This continually refines the estimates. Any unanalyzed requirements will need addition LOE for completing the requirements. Do not forget to add that to the estimate.

Accounting for Scope Uncertainty in Estimates

We should also capture uncertainly more explicitly. We can have a statistical variance associated with the Use Case estimates (lower variance for analyzed Use Cases and higher variance for unanalyzed ones) then we can do a statistical calculation to determine variance in the sum total LOE. This yields an amount of buffer time to add into the final estimate.

For example, consider this data, with estimates in staff days shown in the “E1 = Estimate (likely)” column. We may be underestimating. So create another estimate in which we are 95% confident that the Use Case or task can be completed in that amount of time or less.

Example Estimation Calculation Worksheet

Given the E1 and E2 estimates, we compute the standard deviation. Since 95% is about two standard deviations from the mean (2σ), we compute the standard deviation (σ) as σ = (E2 – E1) / 2.

The variance is defined as the square of the standard deviation. So compute Variance = σ2.

Sum the E1 estimates to get a total estimate (E1-Sum: highlighted cell with value 19). We also need to compute the standard deviation. To do so, we sum the variances then take the square root of that sum. (Total-StdDev: highlighted cell with value 5.5339859).

Use total standard deviation as padding on the estimate to account for uncertainty. Simply add it to the E1-Sum to get the Total Estimate (highlighted cell with value 24.5)