Вы находитесь на странице: 1из 21

Developing and Deploying High-Performance Parametric Cost

Estimating Systems with CostMetrix

John P. Harrell, President


NHYSOFT, Inc.

ABSTRACT
Companies develop proprietary parametric cost models because they need fast, accurate cost
estimates, and have specific estimating needs that cannot be met using commercial cost models.
CostMetrix is a revolutionary set of software products from NHYSOFT, Inc., designed to simplify
the development and use of custom parametric cost models. ModelBuilder and Estimator are the
program modules which provide a complete cost estimating solution, from the initial cost model
design stage through validation and deployment to staff members for project cost estimating with
customized reports. CostMetrix ModelBuilder is used to design, validate, and document parametric
cost models, and CostMetrix Estimator is used to generate cost estimates based on ModelBuilder cost
models.

In this paper, some of the benefits of proprietary parametric cost models are discussed and the key
features of ModelBuilder and Estimator are described, including how they are used to develop and
deploy proprietary parametric cost estimating systems. Examples are shown of cost model
development and parametric cost estimating relationship (CER) derivation using ModelBuilder, and
cost estimate preparation and rationale generation using Estimator.

INTRODUCTION
Cost estimating is a critical business function in many industries such as manufacturing, engineering,
and construction. For these, the quality of the project cost estimates can determine the ultimate success
or failure of the company. Parametric cost models are powerful tools that can provide accurate
project cost estimates in a fraction of the time and effort of traditional methods. Indeed, they are so
effective that the U.S. Department of Defense (DoD) stated in the Parametric Estimating Handbook
that using parametric cost models “can result in significantly reduced proposal development,
evaluation, and negotiation costs, and associated cycle time reductions”.

Parametric cost models fall into two general categories; commercial and proprietary (i.e., company-
developed). Commercial parametric models earned the name because they are marketed commercially
for cost estimating purposes. They contain cost estimating relationships (CERs) derived from the past
experience of multiple companies in a general industry category. While they can provide valuable
insights with an industry average cost estimate, they have the following drawbacks.

• Since they are based on costs accumulated from many companies, they must first be
“calibrated” to provide accurate estimates for a specific company.
• They use cost parameters such as quantity, size, weight, type of packaging, and
manufacturing rate. Cost parameters unique to a specific company typically cannot be
incorporated into the framework of a commercial cost model.
• It is difficult, if not impossible to customize commercial cost models to conform to a
company’s unique business processes or culture. For example, there is little or no ability to
tailor the individual cost elements of a commercial cost model to meet the specific
requirements of each proposal.

1
• The annual license or usage fees for commercial cost models can be quite costly. In many
cases, the costs are beyond the means of small companies.

On the other hand, proprietary cost models are developed by a company for their own use based on
their own historical cost data. A key reason companies develop proprietary parametric cost models is
because they have estimating needs that cannot be met using commercial parametric models. Some of
the specific advantages of proprietary cost models are:

• Since the cost model is based on the company’s own historical cost data, it is effectively self-
calibrated.
• The cost elements of a proprietary cost model can be structured to conform to a company’s
specific business processes and tailored to meet the requirements of each proposal.
• The algorithms and estimating methods in a proprietary cost model can be optimized to best
represent the specific products, cost-drivers, technologies, processes, and business culture of
the company.
• Company-unique cost parameters can be used to achieve the most accurate cost estimating
relationships.
• The cost estimating relationships in a proprietary cost model are the property of the company
that developed them and no annual license fees are required to use them.

For these reasons, a well-designed proprietary cost model is generally more flexible and provides
more accurate estimates than a commercial model. Unfortunately, until recently there has been a lack
of specialized tools to assist the individual or company in the development and use of proprietary cost
models, particularly cost models that rely on historical cost data for the derivation of CERs.

CostMetrix is an integrated set of Windows-based software programs from NHYSOFT, Inc., created
specifically to facilitate the development and use of proprietary parametric cost models. These
programs were designed to solve the real-world problems of parametric cost model development and
deployment.

ModelBuilder is used for cost model development and validation, whereas Estimator is used for
creating cost estimates with those cost models. This paper describes the major steps involved in
developing, validating, and using a parametric cost model with ModelBuilder and Estimator. In
describing this process, many of the features and capabilities of the two programs will be shown, and
some of the common considerations and cost model techniques will be illustrated.

USING MODELBUILDER TO DEVELOP COST MODELS

ModelBuilder was created specifically to facilitate the development of proprietary parametric cost
models and makes the process faster, easier, and less expensive than using other tools or manual
methods. Some of the features that make ModelBuilder so effective for cost model development are:

• ModelBuilder uses an activity-based cost element structure, so multiple tasks can be defined
to represent the major work elements of the project. Each task can have its own cost
estimating relationships for labor, material, or other direct costs. This allows you to build cost
models that are very sophisticated, yet easy to use and flexible enough to adapt to diverse
estimating needs.
• It includes a powerful Solver that can automatically derive parametric cost estimating
relationships using historical data compiled from your company’s prior projects. It provides a

2
real-time graphical representation of the CER and analyzes the curve fit accuracy and
correlation using standard statistical measures to help the developer assess the quality of the
cost model.
• ModelBuilder can automatically adjust material and other direct costs based on escalation
tables to calibrate historical costs to current year dollars.
• ModelBuilder can also incorporate known cost estimating relationships for tasks.
• ModelBuilder performs cost risk analysis which can help companies determine the potential
cost variance before the project starts.
• It automatically generates a comprehensive set of reports that fully document the cost model
and its CER statistics for internal review or audit purposes.
• It has a logical screen layout and consistent data entry format that makes it easy to maintain
and update cost models, even by someone other than the original developer. New historical
data can be entered and CERs updated in minutes rather than days.
• ModelBuilder cost models can be easily and securely distributed to cost estimators for fast,
efficient estimating with CostMetrix Estimator.

The process of developing, validating, and documenting a parametric cost model with ModelBuilder is
illustrated in the seven basic steps described below.

Step 1 – Define the Task List

The first step in building a cost model with ModelBuilder is to identify the key work elements or
activities that make up the business process being modeled. For example, assume that your
company designs and manufactures turbopumps and you wish to develop a cost model to estimate
the cost of the design process for bidding and proposal purposes. You have historical cost data
from past design projects that will be used to help build the cost model. After studying the past
projects, you determine that the design process actually consists of the following six key tasks.

Requirements Development
Design Layout
Drafting
Analysis
Design Review
Project Management

In addition, the Analysis task can be broken down into three subtasks1:

Computation Fluid Dynamics (CFD) Analysis


Stress Analysis
Bearing Life Analysis

In a ModelBuilder cost model, each of these tasks can have its own unique cost estimating
relationships for labor, material, and/or other direct costs (ODC). These work elements have been

1
The depth to which tasks are broken down in a cost model depends on the specific estimating needs. In
general, the cost elements should be broken down until the scope of each one is clearly definable. If
possible, they should each relate to a single basic function or work activity, and be characterized by no
more than two or three principle cost driving parameters. The task list should also be structured to afford
estimators adequate flexibility in selecting tasks appropriate for each cost proposal.

3
assembled into a hierarchical Task List shown in Figure 1 below, which also highlights some of the
key features of the main window of ModelBuilder.
Main Function Buttons

Task List Task Summary Info Tab Parameter Catalog

Figure 1. Features of the ModelBuilder main window

The Task List uses a tree structure format where task and subtasks are displayed much like files and
folders are displayed for a disk drive. Tasks and subtasks are added and deleted using the control
buttons directly above the Task List. Tasks can also be dragged from one position in the list to another
to rearrange their order.

The main window also includes the Parameter Catalog, a list of all the parameters used in the cost
model. While parameters can be simple numerical quantities such as weight, size, or the number of
parts, ModelBuilder also allows you to employ special types of parameters such as grade lists, scales,
and computed parameters, for more sophisticated cost models. Because of space limitations in this
paper, the reader is referred to the ModelBuilder User’s Guide for a detailed explanation of these types
of parameters.

The Task Summary Info tab on the main window is where two important pieces of information about
the selected task are specified; the task description and type. The task description is used to
communicate the basic meaning and scope of each task. It is displayed to cost estimators when the
cost model is used with Estimator. The task type options are explained in the next section.

4
Step 2 – Assign Task Types

Tasks can be assigned one of six basic types, depending on the type of CER the task will use.
Summary tasks (indicated by the Σ icon) are created automatically whenever subtasks are entered. The
cost of a Summary task is simply the cost of all subtasks under it in the task list hierarchy. As for the
other tasks, the general guidelines shown in Table 1 are used to assign types.

Table 1. Guidelines for assigning task types in ModelBuilder

Case CER Types Used


CER known. Can be a fixed cost, a function of task Fixed (F)
duration, or any explicit function of parameter Level of Effort (L)
values and/or the cost of other tasks
Explicit Formula (E)
Cost estimate to be entered manually Manual Entry (M)
CER unknown but historical data available Parametric (P)

Fixed Cost Tasks –


If the cost estimate for a specific task is known to be a fixed amount of labor, material, and/or
ODC, then a Fixed Cost type should be assigned. For example, the first task in this cost model,
Requirements Development, is designated a Fixed Cost task. The task type is assigned by
selecting the task with the mouse and clicking the Fixed Cost button on the Task Summary Info
tab of the main window. ModelBuilder will then display an F icon in front of the task name to
indicate its type at a glance.

Level of Effort Tasks –


If the cost estimate for a specific task is known to be proportional to the duration of that task,
then a Level of Effort type is assigned. For example, the Project Management task is a Level of
Effort type because the cost is based on the length of the task. For Level of Effort tasks,
ModelBuilder displays an L icon.

Explicit Formula Tasks –


For tasks that have other types of known CERs, an Explicit Formula type can be used. For
these, CER formulas may be entered for labor, material and/or other direct costs, and may
include parameter variables and/or variables relating to the cost of other tasks in the cost model.
Design Review is an Explicit Formula task that uses a CER based on the new design fraction
(percent new design) of the pump. For Explicit Formula tasks, ModelBuilder displays an E
icon.

Manual Entry Tasks –


If a third party (such as a subcontractor) must provide the estimate for a task, then the Manual
Entry type is assigned. This type lets the cost estimator enter labor, material, and other direct
costs for that task manually. Bearing Life Analysis is a Manual Entry task. For this type,
ModelBuilder displays an M icon.

5
Parametric Tasks –
If the CER for a task is not known, but historical cost information is available from multiple
past projects, then a Parametric task should be used to derive CERs automatically. This is a
very powerful type of task in ModelBuilder and its use will be discussed in more detail in the
next section. For this type, ModelBuilder displays a P icon.

The task type is quite simply assigned by selecting the task name in the Task List and clicking the
appropriate task type button on the Task Summary Info tab on the main window.

Step 3 – Assign Parameters to Parametric Tasks and Enter Historical Data

Parametric tasks are one of the most powerful features of ModelBuilder because the Solver can
automatically derive multivariable CERs from “raw” historical cost data. Therefore, the cost model
developer does not have to manually process reams of cost data to develop CERs. It also does not
require an in-depth knowledge of statistical analysis techniques.

ModelBuilder evaluates the parameters that you consider to be cost drivers, seeking to identify
correlation between actual costs and parameter values on multiple past projects. Parameters are
assigned to each task by dragging them from the Parameter Catalog in the upper right hand region of
the main window, and dropping them onto the Parameter Assignments tab for each Parametric task, as
illustrated in Figure 2. This creates links (i.e., mathematical associations) between the parameters and
the tasks. Parameters can be assigned independently to the labor, material, or ODC categories of a task
and three independent CERs will be derived.

Drag

Figure 2. Parameters are assigned to tasks by dragging and dropping

6
ModelBuilder archives past project cost and parameter information in a database. Figure 3 shows the
Project Data window where labor, material, and ODC are entered on a project-by-project and task-by-
task basis. Costs can be entered in any number of user-defined cost categories. For example, labor
categories consist of the various labor grades used by the company. Individual material categories
might be defined for items such as parts, raw materials, and tools, and ODC categories might include
travel, reproduction, data processing, etc. For convenience, escalation rates can be entered and
ModelBuilder will adjust all material and ODC entries to current-year equivalent values automatically.
A total of eight past projects were used in this cost model.

Figure 3. Historical cost and parameter information is entered on


the Project Data window

Step 4 – Use the Solver to Derive Parametric CERs


After the historical data are entered, the Solver is run. The function of the Solver is to extract CERs,
and to present a graphical and statistical evaluation of the results to assist the cost model designer in
assessing the quality and validity of the CERs. The Solver computes the best CER it can fit through
the historical data points, using successive optimizations and refinement of parameter influence
coefficients. With three or more historical data points, it can compute a 2nd order polynomial CER
(although a control is provided to restrict it to linear CERs if desired). Other aspects of the Solver
algorithm can be controlled as well to help achieve the best (most reasonable) CERs.

7
For each task, the Solver displays the historical cost data points in a graphics window and the CER is
represented by a curve that passes through the data set, as shown in Figure 4. In addition to this
graphical feedback, the Solver also displays statistics indicating the quality of the fit of the CER
through the data set. ModelBuilder also has a Parameter Correlation report which lists any parameters
that do not correlate, i.e., do not show a positive statistical trend with respect to any of the assigned
tasks, and the CER Coefficient report lists the actual coefficients of the CERs computed for each
Parametric task.

Figure 4. The Solver extracts multivariable CERs from historical data

Another method of evaluating CER quality is through the Prediction Accuracy reports. ModelBuilder
uses the validation method recommended by the DoD Parametric Estimating Handbook wherein the
actual cost of past projects is compared to estimates generated using the CERs. The Prediction
Accuracy reports show the percentage error between the actual costs and the CER predictions for each
task in the database.

Step 5 – Enter CERs for Fixed Cost, Level of Effort, and Explicit Formula Tasks

8
Fixed Cost, Level of Effort, and Explicit Formula tasks allow you to enter CERs manually, rather than
using the Solver to derive them from historical data. The process of entering known CERs varies
somewhat depending on the task type.

For the Requirements Definition task, a fixed cost CER is defined by dragging and dropping cost
categories from the Cost Category Catalog onto the Fixed Cost Detail tab. In this example, the Sr.
Engineer and Clerk labor categories were dragged onto the labor assignments tab for this task, and
estimates of 26 and 8.5 hours respectively were entered, as shown in Figure 5. As a result, when this
task is used in a cost estimate, those labor hour estimates will be used.

Entering the CER for a Level of Effort task is similar to a Fixed Cost task, with the exception that
weekly costs are entered rather than fixed costs. The duration of a Level of Effort task is calculated
from the planned task dates entered into Estimator by the user.

Drag

Drop

Figure 5. Fixed cost CERs are entered by dragging and dropping


cost categories

Explicit Formula tasks use CER formulas entered explicitly by the cost model developer to estimate
labor, material, and ODC. For example, a known CER could be entered to estimate the number of
labor hours based on one or more parameters. Explicit CER formulas can also include variable
references that refer to the costs of other tasks in the cost model, so the cost of one task can be
calculated from another. The user can also specify how the estimated costs are broken down (by
percent) into multiple labor, material, or ODC categories.

9
Step 6 – Review, Refine, and Validate the Cost Model

After the Solver is run for each parametric task, the correlation and prediction accuracy results are
reviewed. Initially, one or more of the parameter assignments may not show positive correlation based
on the historical data, or the accuracy of some parametric CERs may be poorer than desired. When
this occurs, the following steps are commonly taken.

• Parameter assignments may be removed from tasks where those parameters do not show
positive correlation as cost drivers.
• New parameters may be identified and assigned to tasks in a process of refining CER
prediction accuracy. Fortunately, the Solver makes it very easy to add new parameters and
test for correlation.
• Some CER solutions may be manually reduced from 2nd order polynomials to linear
relationships if linear CERs provided more reasonable cost prediction characteristics.
• Historical data points that appear to be significantly out of trend with respect to the other data
points may be reviewed. After investigation, if these are determined to be influenced by
unusual circumstances then they may be adjusted or eliminated from the historical data set in
accordance with the guidelines of the Parametric Estimating Handbook.

The determination of when a cost model is “complete” or “validated” is based on experience,


judgement, and common sense. In general, a cost model should be refined until the following criteria
are met.

• The quality of sample estimates it generates are considered to be at least as good as those
obtained using the “best” manual methods (although in much less time and with much less
effort using the cost model).
• All logical parameter assignments have been tested and there are no other obvious ways to
improve the cost model.

The ease of achieving these criteria depends on many factors including the quality and quantity of
historical cost data, and the maturity and repeatability of the processes being modeled. No parametric
modeling application can extract well-behaved CERs from poorly-behaved or corrupted historical
data. In other words, well-defined and controlled processes can be modeled with much better results
than processes influenced by random or poorly understood factors.

Step 7 – Submit the Cost Model for Internal Approval

After the cost model is completed, it is normally submitted to company management for internal
approval for use in estimating. ModelBuilder facilitates this process by providing a complete set of
preformatted reports that document every important detail of the cost model including tasks,
parameters, historical data, CERs, parameter correlation, and CER accuracy statistics. A total of 23
different reports can be printed for the cost model data package.

In addition, several sample cost estimates are typically prepared to evaluate the reasonableness of the
results. This is an important step, even if the CER accuracy statistics seem satisfactory.

The next section of this paper will describe the use of Estimator to create cost estimates using this cost
model.

10
PRODUCING PROJECT COST ESTIMATES USING ESTIMATOR

Estimator transforms the normally laborious and time-consuming process of producing cost estimates
into a simple point and click process. With the industry’s most advanced graphical interface for
parametric cost estimating, it can significantly reduce estimate development and evaluation costs and
associated cycle time while providing consistently high-quality cost estimates. Some of the elements
that make Estimator so effective for estimating are:

• A checklist format that helps makes selecting tasks and entering parameters quick and easy.
• Point and click importing of bid rates.
• Automatic material and ODC escalation adjustments.
• Continuous display of cost estimates while tasks are selected and parameters are entered.
• Flexibility to add cost elements not included in the cost model.
• The capability for quick and easy sensitivity and what-if analyses.
• A wide range of charts and graphs to help the cost estimator assess spending profiles and
resource requirements.
• A comprehensive set of reports that fully document the estimate and its basis (i.e., rationale).

Estimator can use any ModelBuilder cost model as the basis of an estimate. For example, you could
have a family of cost models for different types of projects, processes, or services, and use Estimator
to generate estimates with any or all of them. Estimator can read the contents of a ModelBuilder cost
model but cannot edit it.

Figure 6 shows the main window of Estimator upon starting the program. The main features will be
illustrated as the process of creating a sample estimate is described.

Step 1 – Start a New Cost Estimate

The first step is to start a new cost estimate. This is done by selecting New under the File menu, or by
simply clicking on the New Estimate speedbutton. Every cost estimate includes summary information
such as the name of the project, customer, estimator, and a brief project description. Figure 7 shows
the Project Information dialog box, which opens automatically upon starting a new cost estimate.
Some sample summary information has been entered for this example. Notice that relevant data such
as the WBS item number, project and proposal numbers, departmental codes, etc. can be entered and
saved with the estimate, although this information is optional. Summary information can also be
imported from another estimate; an option that saves time if several related estimates are being made
on the same project.

The button on the lower left corner of the Project Information dialog box can be used to enter a brief
résumé of the estimator’s qualifications. This information adds credibility to a cost estimate and is
typically required for U.S. Government contract proposals.

11
Speedbuttons Main Function Buttons

Project
Summary
Section

Task List
Panel
Task Detail
Section

Parameter
List

Task Direct
Cost Display

Figure 6. Features of the Estimator main window

Figure 7. Summary information about the project being estimated is entered


on the Project Information dialog box.

12
When the Project Information dialog box is closed, the project name, task name, project number,
proposal number, WBS item number, option code, and start date are displayed in the Project Summary
section of the main window. This provides a continuous display of this reference information while an
estimate is being prepared.

Step 2 – Select the Cost Model for the Estimate

The next step is to select a ModelBuilder cost model to use as the basis of the estimate. Estimator will
use the task and CER data in the cost model to display information and prompts to the user and
compute the task cost estimates. The Cost Model button on the main window opens a dialog box that
allows you to browse the computer hard drive (or the network) for the cost model file. For this
example, the cost model described earlier in this paper was selected.

Upon reading the cost model file, Estimator displays the Task List on the main window as shown in
Figure 6. While this list resembles the one displayed in ModelBuilder, a checkbox is now included
next to each task name in Estimator. This is how individual tasks are selected for inclusion in the cost
estimate. The checkbox turns a task on or off. The default state for all tasks upon starting a new cost
estimate is deactivated (unchecked), and each task that is appropriate for the project being estimated
must be deliberately activated (checked). In so doing, the user can customize the task selection of each
estimate to suit the project requirements.

The main window also displays the description of each task when its name is selected in the Task List.
This helps the user clearly understand the essence of each task, so the appropriate tasks can be
activated for the project. Estimator also displays the Task Type so the user knows what type of
information is needed to generate the estimate (i.e., task start and end dates, parameter values).

Step 3 – Activate Tasks

The next step is to activate the tasks that are appropriate for the project being estimated by clicking the
checkboxes next to the respective task names. As each one is activated, Estimator will prompt the user
to enter associated task dates and parameter values.

For example, when the Requirements Development task is activated, Estimator prompts the user to
enter the estimated start and end dates of this task. Since it is a Fixed Cost task, parameter values are
not needed to estimate the cost. The cost model contains the fixed cost relationship that allows
Estimator to estimate 34.5 hours of labor for this task as shown in Figure 8. It also knows that this is
broken down into 26 hours of Sr. Engineer labor and 8.5 hours of Clerk labor (although only the total
of 34.5 hours is displayed in the Task Direct Cost section).

To compute the direct cost in dollars, Estimator needs to know the hourly rate of each labor category.
In general, labor rates effective at the midpoint date of the project period would be used. This
information is entered on the Rates dialog box shown in Figure 9, which is opened by clicking the
Rates button on the main window. It allows the hourly labor rate of each labor category used in the
cost model to be entered. It also allows you to enter the burden rates that should be applied to labor,
material, and ODC, in addition to other overhead, general and administrative (G&A) rates, and fee if
applicable. The rates on this dialog box can also be imported from rate files on your hard drive or
network.

13
Figure 8. Estimator main window with one task activated.

Figure 9. Bid rates are entered on the Rates dialog box.

14
When the Rates dialog box is closed, Estimator automatically updates the cost calculation for each
task and displays burdened labor dollars and task total direct cost. The total cost estimate including
overhead, G&A, and fee is displayed in the status bar in the bottom right corner of the main window.

When a Level of Effort task is activated, Estimator prompts the user to enter the estimated start and
end dates of the task. Since the cost estimate for a Level of Effort task is based on the duration of the
task, no parameter values are needed to estimate the cost.

When a Parametric task is activated, Estimator displays the parameters associated with that task in the
Parameters table. Figure 10 shows the main window with the Design Layout task activated. The task
type is displayed and the user is prompted to enter the task start and end dates, as well as the values of
several parameters needed to compute the estimate for this task. In this example, the parameter values
have been entered and Estimator has calculated the cost of the task and added it to the estimate total.

Figure 10. Estimator displays relevant parameters


when Parametric tasks are activated.

As shown in Figure 10, parameters are not limited to simple numerical values. They may be grade
lists of discrete values that represent a cost or complexity factor. They can also be scales, or computed
values based on a formula defined by the cost model designer. Estimator will display a drop-down list
of valid options for parameters that have discrete values.

15
When an Explicit Formula task2 is activated, Estimator displays parameters associated with that task
(if any) in the Parameters table. Figure 11 shows the main window with the Design Review task
activated and selected. The task type is displayed and the user is prompted to enter the task start and
end dates, as well as an estimate of the New Design Fraction, a parameter that relates to the fraction of
the pump design that is new versus design adapted from a previous pump. In this case Estimator
calculates the estimate of 56 labor hours based on the CER in the cost model.

Figure 11. Estimator displays relevant parameters


when Explicit Formula tasks are activated.

Estimator keeps track of all parameter values globally, and each parameter has a single unique value
for the entire cost estimate, even if it is used in multiple tasks. Therefore, if you change the value of a
parameter, Estimator will automatically change its value accordingly in all tasks where it is used.

When a Manual Entry task is activated, Estimator activates a dialog box that allows the user to enter
labor, material, and ODC estimates manually for that task. Figure 12 shows the Manual Entry Detail
dialog box with direct labor estimates entered by labor category for the Bearing Life task. When the
dialog box is closed, Estimator uses those estimates for the task and adds them to the estimate total.
2
Explicit Formula tasks may have parameters like Parametric tasks. However, unlike a Parametric task,
which has a CER derived by ModelBuilder’s Solver from historical project data, the CER for an Explicit
Formula task is defined explicitly by the cost model developer.

16
Figure 12. Estimates for Manual Entry tasks are entered
on the Manual Entry Detail dialog box.

Summary tasks are shown in gray italic text in the Task List, indicating that they cannot be activated.
The cost of a Summary task is simply the sum of all the activated tasks under it in the task hierarchy.
Clicking on a Summary task name displays the cost of all of its activated subtasks in the Task Direct
Cost section.

The user can continue to activate tasks and enter parameter information as needed to compile a
complete cost estimate for a project. The cost estimate may include all the tasks in the Task List, or a
subset thereof. At any time, the user can view a summary breakdown of the costs by clicking on the
Cost Summary button. This displays the Cost Estimate Summary window (see Figure 13) which lists
the cost breakdown by category.

Step 4 – Review Costs and Spreads

After all the appropriate tasks are activated and relevant parameter values have been entered, the cost
estimate should be reviewed for reasonableness. Estimator provides several ways of reviewing the
cost estimate results, including:

Direct cost by task –


Direct cost can be viewed on a task-by-task basis by selecting each activated task in the
Task List and viewing cost in the Task Direct Cost section of the main window.

Total estimated cost including burden, overhead, G&A, and fee –


The total estimated cost is displayed in the bottom right hand corner of the main window.
This display can also be changed to total labor hours, total labor cost ($), total material
cost ($), or total other direct cost ($).

Total cost by category –


The total cost by labor, material, and ODC category can be displayed using the Cost
Summary button, which opens the Cost Estimate Summary window.

Cost by category and by month –


The cost on a month-by-month basis over the duration of the project can be displayed
using the charting features of Estimator.

17
Figure 13. A summary of the project cost estimate is shown in the
Cost Estimate Summary window.

The total cost is frequently the main objective of a cost estimate. However, the cost profile over the
duration of the project is also frequently an important consideration. Estimator provides charts of
month-by-month cost during the proposed project to help the cost user and management evaluate the
reasonableness of the estimate and assess staffing and other resource requirements.

Figure 14 shows a sample chart of Sr. Engineer labor hours plotted by calendar month as a bar graph
with the cumulative labor hours overlaid. Similar charts can also be generated for any material or
ODC category, or total cost by month.

These are powerful analysis capabilities that help the user provide better cost estimates and support the
application of government contracting initiative such as Design-to-Cost and Cost As an Independent
Variable (CAIV). Task, parameter, and date changes can be made rapidly and evaluated easily and
quickly so cost estimates can be optimized to best suit the project requirements and cost constraints.

18
Figure 14. Cost can be plotted by month in any category
to assess resource requirements and cost profiles.

Step 5 – Print Reports

When the cost estimate refinement and review is completed, a complete set of reports can be
generated in just a few mouse clicks. First, the Reports dialog box (see Figure 15) is opened by
clicking on the Reports button on the main window. This dialog box displays a list of the
preformatted reports that are available for viewing and printing. Click the Select All button to select
all the report checkboxes, then click the View/Print button.

Estimator displays each report in sequence in the Report Viewer. Figure 16 shows the first report
(Schedule1) which is a summary sheet for the estimate that includes a description of the work being
estimated, the estimating organization, rationale statement, cost model being used, cost estimator’s
name and resume, etc. The logo for all reports can be specified to provide a customized appearance.

Other reports document details such as tasks, parameters, bid rates, cost breakdown by task and
category, cost summary, etc. Collectively, these reports provide a complete set of rationale for each
cost estimate at the click of a mouse. This information, along with a copy of the cost model data
package, comprises a cost proposal that is able to support a detailed audit. In fact, this estimating and
rationale system has been examined by DCAA auditors and accepted in every case.

19
Figure 15. Fifteen reports can be generated to document every
key detail of your cost estimate.

Figure 16. The Report Viewer is for browsing and printing any of
the 15 preformatted reports.

20
CONCLUSIONS
ModelBuilder and Estimator have been created to make the development, validation, documentation,
deployment, and maintenance of proprietary parametric cost estimating systems faster, easier, and less
costly. Utilizing intuitive graphical user interfaces, they provide analysts and cost estimators with a set
of practical, yet powerful tools for developing and using proprietary parametric cost models. As a
result, they facilitate the use of parametric estimating techniques by companies in a broad range of
fields and industries.

This paper provides a brief overview of the features and use of these products. Some features and
capabilities are only touched upon or are not described at all due to space limitations. For more
information, contact NHYSOFT at www.nhysoft.com.

REFERENCES

DoD Parametric Cost Estimating Initiative Working Group, 1999, “Parametric Estimating Hand-
book”, Second Edition.

BIOGRAPHY

John P. Harrell is the President of NHYSOFT, Inc., and principle architect of the ModelBuilder and
Estimator software products for parametric cost estimating. He has a Bachelors Degree in Mechanical
Engineering from Louisiana State University (1977) and a Masters Degree in Engineering from the
University of California at Los Angeles (1980). He is a member of the International Society of
Parametric Analysts (ISPA), the Society of Cost Estimating and Analysis (SCEA), the American
Institute of Aeronautics and Astronautics (AIAA), and has 23 years experience in the aerospace
industry. As a mechanical engineer, Mr. Harrell has extensive experience in product design and
development, project management, and cost estimation including experience developing and using
cost estimating systems for government contract cost proposals. Mr. Harrell’s experiences in project
cost estimating led him to the conclusion that special-purpose software tools were needed to facilitate
the development, validation, and use of proprietary parametric cost models. Mr. Harrell began
development of ModelBuilder and Estimator in 1996 and NHYSOFT, Inc. was founded in 1999.

Mr. Harrell can be contacted at NHYSOFT, Inc., Mission Viejo, CA 92692. Phone: (949) 367-2911,
Fax: (208) 279-7016, Email: jpharrrell@nhysoft.com.

21

Вам также может понравиться