4 Estimating Models
The most accurate and reliable estimate for a project can be developed when all of the elements of the WBS have been identified with a reasonable degree of reliability and when the RBS has been defined with the desired degree of certainty. This estimate is referred to as the bottom-up estimate, and it is derived from detailed information that is contained in the WBS and RBS at the time of the estimate.
Detailed and accurate estimates require substantial definitive information about the project. They also require a relatively large amount of time and effort for estimating. Therefore, a balance should be struck between the time spent on estimating, the accuracy of the results, and the degree of accuracy required by the stakeholders at the point in the project life.
EARLY ESTIMATES
A project needs estimates for cost and duration even when there is very little information about the project, so that it can be authorized for implementation. Unfortunately, the amount of detail required for a detailed estimate will not be available until a major portion of the project has been designed and implemented. The WBS elements, the resource costs, or the assignment pattern for the various WBS elements might not have been defined. Notwithstanding, the project stakeholders must have indications of the cost and duration of the project to approve it for the earliest stages of implementation. Therefore, an abbreviated version of the WBS and RBS must be developed during the inception stages of the project to formulate a rough estimate of cost and duration for preliminary decision purposes.
As the information in these structures is enhanced, and as each of these structures is expanded in line with available project detail, the project estimate will become more reliable. For example, the initial estimate might be conducted with a WBS that is extended only to Level One and with an RBS that is extended only to Level Two. Then, when more information becomes available, the estimate would be with a Level Three WBS and a Level Five RBS. Depending on the organization, the first estimate is sometimes called “conceptual” or “order of magnitude.” This first estimate can be developed using any one of several models, although the analogous estimating technique is used most often for conceptual estimates.
Availability of historical data is paramount in developing and using estimating models, and in the general process of estimating. Specifically, earned value calculations of previously executed projects offer reliable data for testing budgeted cost estimates, thereby offering an opportunity for continuous improvement of accuracy and reliability of the cost estimating process.
Historical data will provide a basis for more reliable conceptual estimates during the initiation stages and for more detailed and realistic plans during the detailed planning stages. Historical project data for construction and industrial projects span several decades and a multitude of project types under numerous implementation constraints. Unfortunately, software and system development projects do not enjoy the same luxury because many software and system development projects are regarded as vastly different from those in the historical database.
In addition to the historical data, the project manager’s experience in formulating estimates will contribute to the quality of the estimates for the project. Seasoned project managers often are able to develop estimates that are somewhat realistic because they address all of the important aspects of the deliverables. This elusive experience factor that can allow the project manager to improve the accuracy of an early estimate of the cost and duration of the project, even if they are developed using inexact methods. The experience of the project manager will continue to be a factor in the project’s success as it moves into the implementation stages and as the project team must focus on the challenges of optimizing the inevitable changes in cost, schedule, and scope.
During the project’s inception phase, very little project-specific information is available, and therefore the estimate is not very accurate (see Figure 4-1). Part of the reason for this inaccuracy is that the probability of undesirable events occurring is very high during the early stages of the project (see Figure 4-2). However, the consequences and associated costs of modifying project objectives are not significant during the early project stages because the effort spent up to that point on the design and implementation of the project is very small (see Figures 4-3 and 4-4).
Figure 4-1
Knowledge of Details
Figure 4-2
Uncertainties and Risks
Figure 4-3
Ease in Changing the Scope
It would be ideal, although neither realistic nor likely, if all of the project information were available at the time the early estimates are made and if no changes were made to the scope beyond this point in the project. Given that the likelihood of changes occurring in the project scope and project environment at later stages of the project life is almost certain, making midstream changes to the project direction will have significant financial consequences. Sometimes, it is the effects of these scope clarifications or changes that make the original estimate seem highly inaccurate.
It is against this backdrop, and being painfully sensitive to the real possibility of myriad changes during the implementation phase of the project, that the project manager must develop rough estimates for the project during its formative stages. The refinements of the cost and duration estimates are based on more detailed information about the project and are made in the context of new or modified client requirements.
Generally speaking, the changes to the project plans are the results of changes in client requirements, project environment, and technology of the project content, as well as errors. Errors can be divided into errors in design, errors in estimates and schedules, and errors in implementation.
Early estimates, by their very nature, are based on sketchy data and will not have a high degree of accuracy. By comparison, estimates performed late in the development cycle are based on a much wider set of information and thus are very accurate. In other words, early estimates are inaccurate and difficult to make, yet they become the basis for project comparison and for developing guidelines for the final project funding.
When the project is in its inception phases, only a small amount of information is available about the specifics of the project, and yet an estimate is needed to make a decision on the viability of the project and the profitability of the resulting product. It bears repeating that, even though an estimate is needed at that time, those who use the estimate must be made aware of its inaccuracies.
Some organizations hold the project managers to the early estimates of the project. Enlightened organizations allow systematic and logical changes to the project budget throughout the project life cycle.
Given that the project manager will make the estimate as accurate as possible considering the data available, the project stakeholders should keep the limitations of early estimates in mind when selecting projects based on them and during the cost management process, particularly if the project is selected for implementation based on the early estimates. Nonetheless, a preliminary estimate is needed for making project decisions, even though it will have to be made before project objectives are clarified, project scope is defined, requirements are fully spelled out, functions are clearly defined, and project constraints have been fully formulated.
During the early stages of the project, and in the absence of extensive and detailed information about it, project managers use a variety of tools and techniques in formulating the project estimate. These usually are based on models that have proven to be successful during previous estimating efforts, in this project or in others. These models use mathematical expressions, from the very simple to the very complex, or a multitude of assumptions to estimate the cost, duration, and resource demands of a single activity, an assembly, or the entire project as a function of one or more input variables.
The techniques project managers use to make preliminary project estimates include analogous, parametric, modular, ratio, and range estimating. The selection of the technique depends on organizational policies, the project manager’s experience, and the amount of information available to the project manager at the time of the estimate.
Normally, estimate models are very easy to use, and they provide a quick prediction of the cost of the project, although the accuracy is not very high, particularly if the model is based on generic historical data rather than on discipline-specific historical data. Therefore, any amount of effort that is spent on customizing the model to a specific project environment within an industry will have significant rewards in terms of increased accuracy and reliability.
Again, the success of the development and use of estimating models is highly dependent upon the experience and competency of project managers and project team members, as well as reliable historical information. Equally important, the enterprise environment should give the project managers applicable incentives to conduct such continuous improvements.
Models used for software and systems development projects use some or all of the following data in arriving at the rough estimate of the project:
• System size
• Manpower skill
• Resource availability
• Specificity of project objectives
• Clarity of requirements
• Operating system features
• Environmental characteristics
• Extent of new technologies involved in the project.
Likewise, models used for construction and industrial projects use the following data in the process of predicting the project cost and duration:
• Industry and project type
• Capacity and quantity
• External and usable size
• Overall weight
• Project location
• Extent to which novel materials, tools, and techniques are required for the project.
Formalizing when, how often, and how estimates of cost and duration should be performed depends on the type of project, the prevailing organizational procedures, and the degree to which the organization is concerned with project cost and any overruns. Ideally, intermediate cost and duration estimates should be performed several times during the project life, and not necessarily at budget authorization milestones. Frequently enhancing the estimate, through regular reviews of all of the cost components, will improve the accuracy of the estimate. It also will provide substantial historical data for refining and enhancing the estimating models of future projects.
Using the earned value method provides an opportunity to test earlier cost estimates of the current project and improve the accuracy of initial and intermediate cost estimates of future projects. With the advent of powerful software and the use of a detailed RBS-WBS in tandem, the estimate update process will become automatic and almost continuous.
BOTTOM-UP ESTIMATING
With a detailed WBS and RBS, a project manager can make a systematic and accurate estimate of the project’s required resources—and, therefore, its cost. Once deliverable-oriented WBS elements have been developed for a project, producing a detailed cost estimate becomes a simple matter of mapping the WBS onto the RBS and assigning the appropriate resources to individual WBS elements.
This methodical approach may initially require some extra effort; but if an organization regularly produces and maintains its RBS families, the process becomes remarkably straightforward. Thus, the project manager’s anxiety about cost estimating will decrease, and the organization will achieve significant efficiencies in planning, scheduling, and monitoring.
Here the WBS and the RBS work together: Mapping a project’s WBS onto the RBS links project activities with specific available resources. After mapping the WBS onto the RBS (represented schematically in Figure 4-5), the money necessary for the project can be estimated by adding the products of the resource quantities demanded by the WBS and the corresponding RBS unit costs. That is, for each element at the lowest level of the WBS, multiply the desired quantity of the resource by its cost per unit of appropriate measure to yield cost. The sum of the cost estimates of all of the WBS elements, individually derived from estimating the resource amounts, is equivalent to the total cost estimate. The resource quantity, known as effort, itself is a product of the resource intensity and duration.
Figure 4-5 captures the essentials of the process of using the WBS and RBS in tandem for developing elemental estimates. Begin at the lowest level of the WBS, which can be denoted as Level N. Calculate the cost of each element by multiplying the quantity of required resources by the unit cost of each resource. The unit cost is obtained from the RBS. The important point here is that the details are not hidden. The category of the resource, its intensity, and its duration are clearly indicated as part of this calculation. For example, if a project needs three brick layers for four days to build a wall, then the category is brick layer, the intensity is three workers, the duration is four days, and the effort is 12 worker days. At a unit cost of $300 per worker per day, the cost is $3,600.
Using the above elemental estimate, the total cost of the project can be found by adding all these costs together. So many numbers are somewhat unwieldy, however, and such a direct calculation of going directly to the top of the WBS might hide some additional useful information that can be obtained easily. Therefore, in the next step, move up a level to determine—now by simple addition—the total quantity of resources necessary for all elements at level N-1, grouped by resource category. Repeat the process, proceeding from bottom to top, until each element of the WBS shows the total resources it requires, grouped by category. In addition to the cost, we now have the resource utilization values for all sub-units defined in the WBS.
Once the calculations are extended to Level Zero, the project’s total resource utilization and cost have been determined, as have the total resource utilization and the cost of all intermediate elements of the WBS. As in any method of estimating, the calculated project estimate must be checked against experiential data and the subjective knowledge of project management professionals familiar with this type of project.
Once the first estimate has been developed, the project manager must verify that the estimate for the total cost of the project is reasonable. Since poor overall estimates often result from inadvertent omissions of key elements in the WBS and the RBS, enhancement of the project plan primarily involves filling the logical gaps in the WBS by modifying, deleting, or adding to the current WBS elements.
Correction also may include improving elemental estimates at the lowest levels, but an elemental estimate should not be changed arbitrarily from what one believes is the best estimate. Further, the estimate values for those items that are above Level N should not be changed, as these items can be regarded as the parents of lower-level items. The reason for this exclusion is that all parents’ estimates are derived from sums of lower-level estimates and not from direct input.
Project planning documents, including the estimate, should be treated as living documents. As new information becomes available, the WBS, RBS, elemental estimates, and schedule network logic must be updated and refined. In turn, these changes will trigger changes in the overall cost duration of the project. Ideally, these enhancements should be conducted frequently rather than only for specific administrative milestones and budget deadlines. In other words, at every update opportunity, the enhanced WBS (and if necessary, an enhanced RBS) should be used to refine the elemental estimates.
A well-defined, accurate, consistent, and regularly updated WBS and RBS will significantly improve the likelihood that the project will be successful, by facilitating clear plans and good communication. Using a good WBS with an accurate RBS, one can ask detailed cost and resource questions about the project, such as:
• What is the total number of worker hours needed for module A?
• How many worker hours of chemists do we need for modules A, B, and C?
When these elemental and total estimates are combined with a good schedule, questions can then be asked that involve detailed time and resource issues together, such as:
• How many programmers do we need across the entire project in July?
• How many engineers do we need for module C during July?
• Would the demand for client-side programmers be reduced next July if we postpone module B by three months?
• How many more analysts would we need next February if the scope of module D were doubled?
• How would doubling the scope of module G affect project cost, schedule, and resource requirements?
• If Module F were to be delayed six months, what would the resulting cost and schedule look like?
It is highly advisable to develop an optimum project plan—that is, a plan that is unencumbered with milestone constraints and low resource availability and, therefore, is poised to deliver the project in the most efficient and cost-effective manner. This plan should then be considered the pristine project plan. Then, the schedule could be altered to meet client requirements in resources or milestones, with possible impact on project cost. To sum up, rather than starting with a constrained project plan and using it as a baseline, a pristine plan should be the base of comparisons for all plan changes.
ACCURACY
Depending on the time the estimate is prepared and on the volume and quality of historical data available to the project manager at that time, the spectrum of estimates ranges from the very rough to the very detailed. An estimate can be viewed as simply a prediction of the final values of project cost and duration once the project is fully implemented. Thus, the expression of accuracy of the estimate is somewhat akin to the expression of the probability that the actual cost of the project will match this prediction (Anonymous2 1999; Vigder and Kark 1994). As noted, this probability, or accuracy, is very low during the early stages of the project and relatively high during the later stages.
Experience in construction and industrial projects has shown that, due to monitoring and reporting inaccuracies, even the estimates that are prepared late in project life are not expected to be more accurate than 3–4 percent. As a general rule, if all the project information is available, which usually occurs in the later stages of the project, the accuracy of the estimate is probably around 3 percent. Therefore, the actual value may be 97–103 percent of the estimate. At the other end of the spectrum, if very little information is available, the accuracy may degrade to 233 percent. In other words, the actual value of the cost of the project might be 33–333 percent of the estimate. Looking at some completed projects, in construction and system development, the cost overrun has been even more than 233 percent. Notwithstanding, estimates developed during the inception process, and in the absence of much project-specific historical information, generally are accurate to an order of magnitude, i.e., the final cost will range from 30 percent to 330 percent of the initial conceptual estimate.
If sufficient project-specific historical data are available to a project manager with ample experience in this area, then that project manager will be able to determine the realistic accuracy of the conceptual estimate, regardless of whether the accuracy is better or worse than an order of magnitude. The key is that if the project manager is more experienced, and more informed, about the current project or about previous similar projects, the estimate will be more useful to the stakeholders because it is more accurate.
For purposes of convenience and standardization in communication, organizations assign specific names for estimates at discrete points in the project life cycle. Such naming convention exists because many organizations require estimate updates only at a few points during the life cycle. Figure 4-6 shows the most common categorization of estimates for external and internal projects. The important thing to remember is that not all organizations use all of these titles. Some organizations may use a subset to identify the estimates prepared for their projects. Some organizations may also use titles that are not on this list.
Figure 4-6
Cost Estimate Titles
It is safe to assign degrees of accuracy to each of these names in internal communications, but it is fair to say that not all organizations attribute the same characteristics and accuracies to a specific estimate label. For example, organizational procedures might specify that if an estimate is labeled as preliminary, then it will be expected to have an accuracy of 30 percent. Regardless of what it is called, the accuracy of the estimate is determined by the nature and accuracy of the historical data, the estimating technique that the project manager has used in formulating it, and the competence of the project manager preparing it.
For purposes of consistency and for communicating across wider administrative boundaries, sometimes organizations adopt titles that are recommended by professional societies such as the Association for the Advancement of Cost Engineering and the Project Management Institute. These professional societies prescribe that, as a general rule, the accuracy of the first formalized and published estimate should be better than -40 percent and +100 percent. For example, the estimator should be reasonably certain that the final actual cost of a project that is initially estimated at $100 should be between $60 and $200.
As the project progresses through its life-cycle stages, and as the detailed project objectives and the data necessary for the estimate become available, more accurate estimates become possible. To use the WBS as a base of reference, when very little information is available about a project, only Level Zero of the WBS, which is the total project, can be estimated using any one of the models described here. Once more information becomes available, individual Level One elements can be estimated, again using these models. The estimate for the project will then be the summary of Level One elements and a more accurate estimate.
Again, as more information becomes available, Level Two items of the WBS will be defined and estimated. Finally, once the project has been divided into its smallest units and planned at the lowest level of the WBS, the lowest-level units will be estimated using experience or appropriate models (see Figure 4-7). Then, these estimates are rolled up to Level One items and to the total project estimate to determine the cost and duration of the project.
The estimate of the total project will be reasonably accurate primarily because all of the elements have been accounted for and estimated. Likewise, the more detailed logic network and the more accurate elemental duration estimate will yield a more reliable project duration.
Alternately, one might consider an array of estimating models, each targeted for a specific point in the project life cycle. During the early stages of the project, when only total-project estimates are sufficient, one would use analogous estimating techniques. Then, once the project gets fleshed out a bit, perhaps to Level Two, parametric estimating models and tools would be used. When the project has been expanded to Levels Three and Four, a bottom-up estimating structure would be established. In turn, this bottom-up estimating structure would be the platform for continuous enhancements to the WBS, RBS, and estimate (see Figure 4-7).
Although simple estimating models are not very accurate estimating tools for the total project if applied only at Level Zero, these models are frequently used, implicitly or explicitly, for estimating lowest-level elements of a project even during its advanced stages. If no calculation biases are built into the estimating structure, and if the WBS has a large number of lowest-level elements, the repetition and the rollup process will balance the inaccuracies of the models by which the estimates of the lower level elements were prepared.
Estimating models compute the values of a set of dependent outputs, such as cost, duration, or resource utilization, as a function of the values of a set of independent inputs. The timing of the estimate affects how much information is available and how reliable it is. Very early estimates are based on sparse and incomplete data regarding the project and the development process, and thus are not very accurate.
PARAMETRIC ESTIMATING
The terms “parametric estimating” and “modular estimating” refer to two estimating models that have been used in different industries and therefore have taken on different names. These two models are essentially very similar in usage, principle, and underlying structure. After describing their similarities and differences, we will use the term “parametric estimating” to refer to both of these techniques collectively.
Modular estimating is normally used for projects that have physical deliverables, such as refineries, power stations, office buildings, or manufacturing plants. Using this approach, the facility is characterized by indices describing the quantity and size of several key components, such as power rating and number of pumps, physical size of pumps and turbines, size of the plant floor, capacity and number of cranes, etc. The modular model then uses historical data and predictive formulas that have been developed for the characteristics of the modules to develop estimates for the project’s cost, duration, and the amount of resources necessary. Modular estimating is used primarily in construction, process, and manufacturing projects (Figure 4-8).
Similar to the modular model, the parametric model uses historical data as the basis of its predictive features. However, the characteristics that will become the input into the process are based primarily on performance indicators such as speed, accuracy, tolerance, reliability, user-friendliness, error rate, and complexity of the environment of the deliverables. Parametric estimating is used primarily in software development and system development projects. The output of parametric models includes the cost and duration of major phases, total project cost, and resource requirements.
Figure 4-8
Modular and Parametric Models
Generally speaking, parametric/modular models calculate the dependent variables of cost and duration on the basis of one or more independent variables. These independent variables are quantitative indices of performance or physical attributes. More sophisticated models can provide a multitude of levels of estimates depending on the input information available. If, during the early stages of the project, a small array of data regarding the project is available, a rough cost estimate is provided for the project. However, if a large array of project data becomes available later in the project’s life cycle, more accurate estimates containing estimates of resources and duration will be calculated using the same model.
A parametric model for a construction or process project would use the data provided by the user on any or all of the following characteristics: project type, frame material, exterior material, ground conditions, desired floor space, and roof type. Then, using the general relationships developed between these input variables and the output variables, the model would provide an estimate of some or all of the output variables. The output variables include cost of the design process, cost of the structure, size of major equipment, optimum size of the construction crew, size of the parking lot, duration of the structure construction and equipment installation, and overall project duration (see Figure 4-9).
Figure 4-9
Construction and Industrial Projects
Input variables for a parametric estimate for a software development project include desired reliability, database size, complexity of technology, size of the deliverable, lines of code, pages of website, number of database records, queries per second, maximum error rate, and function points. The function points index is determined from a weighted summation of user requirements in the areas of inputs, outputs, logic files, inquiries, and interfaces. Other inputs include indicators of project environment and quantified or semi-specific project team characteristics, such as skill level, physical location, and administrative affiliation.
Output variables include resources needed for requirement analysis, system design, system coding, testing, integration, documentation, and system transition. Sometimes the output values include cost and duration of project elements and, by extension, those of the entire project (see Figure 4-10).
Many organizations have developed proprietary parametric models for projects in their own specialty. Depending on the organizational environment and the nature of targeted projects, these models use different statistically derived algorithms—which in turn would use different sets of input and output data—in calculating the output variables based on the input variables. Normally, parametric estimate models are refined and fine-tuned for specific projects within specific industries. These models are, or should be, regularly evaluated, validated, calibrated, and customized for accuracy and appropriateness.
Figure 4-10
Systems Development Projects
Given that the time frame for using the parametric model is the same as that for project selection and project initiation, the estimates of cost and duration developed by the parametric model are usually used for establishing a preliminary budget for the project. In turn, this preliminary budget will be used to compare its financial desirability with the enterprise’s other projects.
The utility of parametric estimates will be dramatic if the process is used to develop several estimates for alternate configurations of the same potential project. However, it would be extremely dangerous to use the results of a parametric model to develop definitive budgets, unless the organization is so enlightened that it allows major budget modifications as the estimate matures throughout the life of the project.
ANALOGOUS ESTIMATING
Analogous techniques are among the simplest forms of estimating. In this process, the project manager believes there is significant similarity between the proposed project and projects in the historical database. Analogous models tend to be less complex, easier to use, and more inexact than parametric models. They normally are used for early estimates that are called order of magnitude, conceptual, or ballpark estimates. These early estimates are used to formulate rough estimates for various options and to determine the relative viability of a given project in the process of screening alternative projects.
Given that the purpose of analogous models is to develop order of magnitude estimates based on scarce information, the project manager might be forced to make several assumptions about some of the project’s environmental or functional characteristics, such as design attributes, systems engineering process, implementation techniques, and resource availability. It would be helpful to document the assumptions together with the estimate to refine the estimating process for future projects.
When developing the analogous estimate, the project manager should locate and use the values of as many of the following deliverable indices as available: type, functions, requirements, design characteristics, capacity, size, location, cost constraints, and quality expectations. Here again, the project manager’s experience will be the deciding factor in judging the proposed project to be similar to those in the database that have formed the basis for developing and customizing the model.
Since the analogous estimating technique is based on actual experience, some software development project managers contend that such estimating has limited use in that industry because, in many instances, no truly similar projects exist in the historical database and that software and system development projects have no true historical precedents. These concerns should subside as more informed project managers collect and refine historical project data on software project languages, development methodologies, resource utilization, and complexity of system development projects—together with cost and schedule history, of course.
The analogous estimate tools described here are ratio estimating, range estimating, the three-quarters rule, the square-root rule, and the two-thirds rule. The significance of the structure of these models is that they were devised before the days of PCs, and thus they contain relatively simple, but powerful, processes for making manual computations more straightforward.
In the absence of extensive historical data for a specific project, these basic models can provide a good first approximation for the estimate of project cost and duration. If these models are customized for each industry sector, the accuracy and reliability of the results will be substantially higher. Therefore, the project manager should keep detailed records of the performance of ongoing projects in order to provide further data for that specific model. Such performance data can conveniently be used to develop refined exponents or ratios for use in estimating the forthcoming projects. The refinement can be focused on a specific industry or even a specific organization within that industry.
Until the full complement of project details for individual elements of the WBS becomes available, the project manager will provide an analogous estimate of the total project based on minimal project-specific information. With expanded information about the project, the project manager develops analogous estimates of the items at the lower levels of the WBS, for example, Levels One and Two. Then, as additional information becomes available, lower level items are estimated. Thus, estimates of project cost and duration gradually become more accurate, complete, and definitive.
The key is that by using a WBS as the base of reference, two subsequent estimates are not new estimates; they simply are enhancements of the original estimate. Therefore, any variances between two successive estimates can be explained and defended more logically and rationally.
Ratio Estimating
This estimating technique is interchangeably called equipment ratio or capacity factor. It is one of the more frequently used forms of estimating in construction, industrial, and process projects. Its premise is that there is a linear relationship among the cost and duration of the project and one or more of the basic features of the proposed project. The basic deliverable features to be quantified and used in this process can be related to either physical attributes or performance characteristics. The so-called ratios or factors are refined from personal experience, company files, or published industry-specific data. Although ratio estimating is deceptively simple, given an extensive array of historical data, it can be a very powerful tool in developing quick estimates for prospective projects.
Examples of ratio estimating include:
• Experience has shown that the cost of major turbines and generators in a power generation plant is nearly 30 percent of the total cost of the plant.
• In a construction project, the total cost of the project is twice that of the materials and embedded equipment.
• The cost of the high-level design of a systems development project is nearly 30 percent of the total cost of the project.
• Only 20 percent of the cost and effort of a systems project is spent in coding.
• Seventy-five percent of the cost of a systems development project is for labor.
• The cost of the engineering design of a facility is nearly 8 percent of the total budget of the project.
(Anonymous2 1999; Anonymous4 2000; Anonymous5 1999; Vigder and Kark 1994.)
Further, there have been extensive efforts in developing a relationship between the estimated lines of code and the total cost of a systems development project, although this ratio is highly specific to the operating system and system architecture.
Range Estimating
Another approach to increasing the reliability of early estimates is to define the range of possible values for the cost of a specific element. The advantage of this technique is that the estimator embeds the accuracy of the estimate in the estimate itself. Thus, an upper limit and lower limit are cited for each of the Level One elements of the project, and the summation of these limits provides an upper and lower limit for the cost of the total project. Similarly, these two limits, combined with a network logic diagram, can provide two different predictions for the delivery duration: shortest and longest. Obviously, as more information about the project becomes available, the range between the highest and lowest numbers of cost and duration will narrow.
A more sophisticated form of this technique is called triple point estimating, in which three separate numbers are cited for cost and duration: most optimistic, most likely, and most pessimistic. This concept was the foundation of the PERT technique, by which probabilistic project duration is obtained by using multiple durations defined for individual activity durations. Then, in addition to the deterministic project duration defined by the estimator’s prediction, a range of probable and likely duration values is computed.
Range estimating uses the same statistical fundamentals in estimating total project cost based on probabilistic elemental costs. Thus, in addition to providing one number as the total possible cost of an element of the WBS, which reflects the opinion of the project manager, two other values are also provided. One is the most pessimistic estimate and the other is the most optimistic estimate. Using these three values, the calculated most likely cost for the element, or the project, can be determined.
Equally useful, if this three-value set is available for all of the elements of a fully developed WBS, is a Monte Carlo random number generation tool, which can be used to develop a statistically likely cost for the project. This three-number set will allow development of probability distributions for the project cost and a probable cost for the project based on random selection of elemental estimates.
In many cases, the most likely values derived from the application of this statistical method are higher than the deterministic values derived from the summation of single-estimate values provided by the project manager. This revelation highlights the premise that project managers and project estimators are fundamentally optimistic and hence tend to underestimate the cost and duration of a project. Figure 4-11 shows the calculation of elemental values of most likely costs based on the three values provided by the project manager.
Figure 4-11
Analogous Estimating Rules of Thumb
If the three estimate values provided by the project manager are 5, 8, and 35, the most likely estimate for that element, as provided by this model, is 12. The net result of using this model is that the estimate becomes steered toward the mean of the optimistic and pessimistic values, primarily because the deterministic value is dangerously close to the most optimistic value. On the other hand, if the three estimates provided by the project manager are 5, 20, and 35, the most likely value predicted by this model will be 20; note that 20 is the estimate that was considered most likely by the project manager. The point is not that every deterministic estimate should be the mean of optimistic and pessimistic values, but that project managers should not be overly optimistic in estimating every aspect of the project.
Finally, although range estimating is normally used to develop a WBS fully, they are far more valuable when the WBS elements have not been fully defined beyond the first and second levels and when the cost of these elements is at the order-of-magnitude accuracy.
The Three-Quarters Rule
The three-quarters rule provides a simple method of developing the estimate for a proposed project’s cost by comparing the capacity of the existing and the proposed deliverable. The capacity index can be the size, speed, complexity, or accuracy of the deliverable in question. The decision as to which index to use for the rough estimate will depend on the project’s objectives, on whatever information is available at the time the estimate is made, and finally on the experience of the project manager.
Given that the relationship between any two facets of the project and the total cost may not follow the same pattern, several different size or capacity indices might produce several different estimates for the new project. Averaging the resulting estimates will provide a more accurate estimate. Therefore, for best results, as many indices as possible should be used to determine the estimate—that is, of course, if there are enough historical data to use in developing several ratio relationships in a given project. Then, by simple or weighted averaging of these individual estimates, a more tempered project estimate can be obtained.
This estimating rule is a slightly more sophisticated version of the ratio estimating technique. The ratio technique uses a linear relationship between the equipment size and total cost, whereas the three-quarters rule uses an exponential function in predicting the overall project cost.
The three-quarters rule is based on the formula shown in Figures 4-12 and 4-13. Its premise is that if the ratio of the capacities, or sizes, of the proposed and current projects is raised to the power of three-fourths, it will provide an indicator of the ratio of the cost of the two projects. This technique can be used to make extrapolations or interpolations either graphically or computationally, and both can be performed using spreadsheet software. If the historical database includes data for only one similar project, this technique can be used numerically.
Figure 4-12
Analogous Estimating Rules of Thumb
Figure 4-13
Analogous Estimating Rules of Thumb (Variables)
Figure 4-14
Three-Quarters Rule (Estimate Cost of a House Based on the Number of Bedrooms)
However, if the database contains data for several similar projects, the graphic technique might be more convenient.
Figure 4-14 shows the computational application of this rule to predict the cost of houses with two, five, or six bedrooms, in which the only cost information that the project manager has is the cost for a three-bedroom house. Figure 4-15 shows a graphic application of the same example. If a log-log scale is employed when using the graphic application of this method, the model data will be displayed in a straight line, which would make visual interpolation very easy. Figure 4-16 shows the application of this technique to the cost of apartment complexes based on the number of units in each complex.
Figure 4-15
Three-Quarters Rule (Estimate Cost of a House Based on the Number of Bedrooms)
Figure 4-16
Three-Quarters Rule (Estimate Cost of a Complex Based on the Number of Apartment Units)
If enough industry-specific or organization-specific data are available, this technique can be refined to reflect the specifics of that particular capacity index for projects in that organization. Then, for future estimates, a customized variation of this technique will be used to arrive at more accurate conceptual estimates. This modification can be referred to as the modified three-quarters rule.
Thus, using the existing data, an exponent other than three-fourths will be suggested for this particular project environment. Again, the cost exponent will be different for different capacity indices; therefore, a different exponent must be developed for each capacity index. The resulting estimates can then be combined to formulate a more refined one.
Figure 4-17 shows how an exponent of .96 was obtained for a particular class of construction projects. Computing and recording the value of the exponents are necessary only in the computational method. If you use the graphic method, you need not be aware of the value of the exponent. Thus, using a straight-line extrapolation, or interpolation, you can determine the cost of the proposed project.
Figure 4-18 shows a graphic application of this extrapolation technique without any specific reference to the value of the exponent. Using as few as two data points, the straight line defining the model can be defined based on which future estimates can be made very quickly. Figure 4-19 shows the application of this model to estimate the cost of airport expansions (Remer and Wong 1996). This model used the cost of completed airports, such as Newark, JFK, and Hartsfield, to develop a conceptual estimate for the total cost of Denver Airport. The capacity index that was used for comparison was the size of the terminal in square feet.
Figure 4-17
Modified Three-Quarters Rule (Estimate Cost of a House Based on the Number of Bedrooms)
Figure 4-18
Modified Three-Quarters Rule (Estimate Cost of a House Based on the Number of Bedrooms)
Figure 4-19
Modified Three-Quarters Rule (Estimate Cost from Capacity or Size)
The Square-Root Rule
The square-root technique will allow the project manager to predict the duration of a proposed project on the basis of the costs and durations of the existing project and the cost of the proposed project. The square-root rule is based on the formula that is shown in Figure 4-12. The premise of this rule is that the square root of the ratio of the costs of the proposed and current projects will provide an indicator of the ratio of their duration.
Figures 4-20 and 4-21 show the application of the computational mode of this technique to determine the cost and construction duration of a 340-room dormitory at a time when the only pieces of information available are the cost and duration of the construction of 200-room dormitory. Figure 4-22 shows the graphic representation of a model developed from historical highway construction data.
With existing data from previous similar projects, an industry-specific exponent can be developed. This modification can be referred to as the modified square-root technique. Figures 4-23 and 4-24 show the computational and graphic development of the exponent for process plants on the basis of existing projects. The graphic or the computational method then can be used for future projects. Figure 4-25 shows the graphic application of this technique to the airport expansion data mentioned in the previous section.
Figure 4-20
Square-Root Rule (Dormitory Estimate Duration from Cost)
Figure 4-21
Square-Root Rule (Dormitory Estimate Duration from Cost)
Figure 4-22
Square-Root Rule (Highway Project Estimate Duration from Cost)
The Two-Thirds Rule
The two-thirds technique will allow the project manager to sharpen the estimate of a proposed project’s cost or duration if the project contains several concurrent and similar activities. This adjustment is intended to refine the estimates when the same project personnel are assigned to similar tasks within the project or within a unified program to similar projects.
Figure 4-23
Modified Square-Root Rule (Estimate Duration from Cost)
Figure 4-24
Modified Square-Root Rule (Estimate Duration from Cost)
The two-thirds rule is based on the formula shown in Figure 4-12. Its premise is that raising the ratio of the number of concurrent subsystems to the power of two-thirds will provide an indicator of the ratio of the duration of the two projects. Examples include building several apartment complexes at the same time, designing several web pages at the same time, building several specialty airplanes at the same time, installing several servers at the same time, or pulling several sets of fiberoptic cables at the same time.
Figure 4-25
Modified Square-Root Rule (Airport Expansion Estimate Duration from Cost)
Although the example using this model addresses only the duration of the project, the presumption is that the multiple concurrent systems will affect the cost of the project in the same manner as they affect the duration. Finally, as in previous models, a sufficient amount of historical data will allow customization of the exponent of this model to specific project environments, maybe with different exponents for cost and duration.
EXPERT JUDGMENT
The expert judgment technique involves consulting one or more experts to validate the estimate of the proposed project against the experience and understanding of the experts, who will consider the details of project complexities and characteristics in tempering the estimate or concurring with it. Many semi-experienced project managers depend on more experienced project managers and experts in the field to validate a project’s conceptual estimates, regardless of how the semi-experienced project manager prepared the estimate. Even experienced project managers often consult with their peers to fine-tune what they believe is a reasonable estimate.
Primarily, using an expert judgment opinion is somewhat akin to identifying and using the results of a parametric technique of a personal nature, which is based on intuition, experience, and unarticulated indices. Nonetheless, until such time that these unspoken extrapolations of parametric techniques are formalized, expert judgment will remain one of the more reliable sources of checking the accuracy of the estimates, particularly in software and systems development projects.
NORMALIZATION
If the historical data available to the project managers cover projects completed over several years and many different locations, they must be normalized for time and location before using them in the estimating model. Thus, before the cost and duration of a proposed project can be predicted from historical data, the historical values of cost and duration need to be adjusted and normalized in the light of time and location differences between the proposed project and those that formed the basis for the model (see Figure 4-26).
The term “time” refers to the time span from the year in which the project in the database was completed until today. The inflation rate, or the time value of money, would provide a simple multiplier that can be used to adjust the estimated cost of the proposed project based on the actual costs of existing projects. The term “location adjustment” would account for the differences in salaries and cost of materials in different locations. The comparison between the cost of living at locations of the database projects and that of the proposed project would be another normalization issue.
For example, if the database contains information from projects that have been performed in the United States, and if the proposed project is to be performed in China or Italy, differences in locality-based cost factors must be considered when finalizing the estimate for project cost. This adjustment is conducted by a simple ratio adjustment. For example, once the time-adjusted estimate of a project is determined, then that estimate will be adjusted again by a factor of, say, 1.12 to account for the project cost difference in those two locations.
Figure 4-26
Sample Computations
