Feasibility and Budgetary Analysis
The purpose of the Feasibility/Budgetary estimate is to determine the estimated final cost with sufficient accuracy to support accurate prioritization of competing projects and the allocation of sufficient funds in future accounting periods to support the actual project procurement. Problems with estimation accuracy (the standard deviation of the estimate) will distort project prioritization decisions. Problems with estimation bias will result in future funding shortfalls that will create problems for multiple projects as the budgets are re-allocated.
In many ways, these early stage estimates are the most difficult. The Cost Analyst is asked to estimate the cost to build something that is often only understood at the highest level of granularity. A common mistake is to attack the problem by looking for pieces of the puzzle that are well understood, defining those to a high degree of granularity, estimating those, adding some kind of fudge factor for the unknown components, and using that as your estimate. This is wrong for two reasons. First, a lot of time is spent on the well understood components to achieve a high degree of precision, but that precision is lost when the total effort is created. So it wastes time. Second, this approach gives a sense of understanding of the project that is overly confident, thereby failing to adequately compensate for the areas of unknown and resulting in a tendency to underestimate (sometimes badly). Worse yet, the detail in some areas can mask this lack of overall completeness from a reviewer with oversight responsibility.
One alternate approach is to use a parametric modeling approach that makes heavy use of estimation by analogy concepts. The steps involved are as follows:
- Break the problem domain down into components where there is data available for analogous components. This might be the entire product, or a part of the product.
- Use engineering judgment to select where this project lies for that component on a ranked list of the analogous components. Interpolate or extrapolate if necessary.
- Use the HLO count for the analogous component as input to the parametric model for this component.
- Set adjusting variables specific to this project.
- Generate the estimate for this component.
- Repeat for other components, then sum.
Often you’ll use this approach for the labor components needed to create the component (e.g., programming); then use cost estimating relationships (CERs) to create the estimates for other project roles such as project management.
- A second approach often works well when you are replacing an existing item.
- Count the size of the existing item using a suitable set of HLOs;
- Adjust the count down using reuse equations if you expect to get any reuse of the design or portions of the existing system;
- Add to the count based on anticipated expansion of capabilities;
- Set adjusting variables specific to this project;
- Estimate the effort.
A third approach works well in an environment where you are primarily making on-going modifications to existing systems.
- Identify the impacted systems;
- Make a guess at the degree of impact (e.g., very small, small, average, large, very large). If you can’t guess, use average;
- Use historic data about HLO equivalent effort for modifications to that system.
- Set adjusting variables specific to this project; and
- Estimate the effort.
In our experience, these approaches can consistently generate estimates within +/- 50% with less than 5% bias, and standard deviations closer to +/- 25% are often achievable for any given organization. Further, the time required to generate the estimates is less than half the time required using other techniques.