Estimating Technique Guide
Estimating Technique Guide
Version 1
Estimating Technique Guide - Draft
1
2/5/2016
Estimating Technique Guide
Estimating Technique Guide
Table of Contents
Introduction ____________________________________________________________4
Estimating Approaches ___________________________________________________5
Top-Down Estimating Approach ______________________________________________ 5
Bottom-Up Estimating Approach ______________________________________________ 5
Estimating Approach Comparison _____________________________________________ 6
Estimating Techniques ___________________________________________________7
Ballpark Estimating _________________________________________________________ 7
Proportional Percentage Estimating____________________________________________ 7
Comparative _______________________________________________________________ 8
Expert Judgment ___________________________________________________________ 8
Proportional Estimating _____________________________________________________ 8
Widget Counting ____________________________________________________________ 9
Function Point Analysis ______________________________________________________ 9
Feature Points _____________________________________________________________ 10
Technique Comparison _____________________________________________________ 11
Estimating Technique Comparison ___________________________________________ 12
Managing Multiple Estimates ________________________________________________ 12
Wideband Delphi Technique ________________________________________________________ 12
Weighted or Average Estimate ______________________________________________________ 13
Commercially Available Estimating Tools ___________________________________13
CHECKPOINT/KnowledgePLAN ____________________________________________ 13
Overview _______________________________________________________________________ 13
Estimating Templates ___________________________________________________14
General Purpose Templates __________________________________________________ 14
Staff and Duration Estimating Template............................................................................................ 14
Travel Expenses Template ................................................................................................................. 14
Requirements/BAA Proportional Estimate Projection Template ....................................................... 14
ASPIRE Phase Templates ___________________________________________________ 14
Vision and Strategy _______________________________________________________________ 14
Business Area Architecture _________________________________________________________ 14
Development ____________________________________________________________________ 14
Integration ______________________________________________________________________ 14
Deployment _____________________________________________________________________ 15
Specialty Area Templates ___________________________________________________ 15
Development ____________________________________________________________________ 15
Package-Based Development (PBD) Estimating Template ............................................................... 15
Matrix-Based Iterative Custom Development (ICD) Estimating Template ....................................... 15
Estimating Technique Guide - Draft
2
2/5/2016
Estimating Technique Guide
Accelerated Application Development (XAD) Estimating Template ................................................ 15
Organizational Change ____________________________________________________________ 15
Communication Event Estimating Template ..................................................................................... 15
Stakeholder Group Estimating Template ........................................................................................... 16
Technical Infrastructure ____________________________________________________________ 16
Facilities Infrastructure ____________________________________________________________ 16
Estimating Guidelines ___________________________________________________17
Project-Wide Guidelines ____________________________________________________ 17
ASPIRE Phase Guidelines ___________________________________________________ 19
Vision and Strategy (ETP) __________________________________________________________ 19
Business Area Architecture (Requirements/BAA)________________________________________ 20
Development ____________________________________________________________________ 21
Integration ______________________________________________________________________ 21
Deployment _____________________________________________________________________ 22
Specialty Areas ____________________________________________________________ 22
Development ____________________________________________________________________ 22
Package Based Development (PBD) ................................................................................................. 22
Package Evaluation and Selection (PES) Sub-Phase ......................................................................... 24
Iterative Custom Development (ICD) ................................................................................................ 26
Accelerated Application Development (X/AD) ................................................................................. 33
Organizational Change ____________________________________________________________ 36
Technical Infrastructure ____________________________________________________________ 38
Critical Computer Resources and Facilities Infrastructure _________________________________ 38
Management and Coordination ______________________________________________ 39
Appendices ____________________________________________________________40
Estimating Templates _______________________________________________________ 40
Estimating Template User Guides ____________________________________________ 40
Staff and Duration Estimating Templates ______________________________________________ 40
Travel Expenses Template __________________________________________________________ 40
Requirements/BAA Proportional Estimate Projection Template _____________________________ 40
Package-Based Development (PBD) Estimating Template _________________________________ 41
Matrix-Based Iterative Custom Development (ICD) Estimating Template _____________________ 42
Accelerated Application Development (XAD) Estimating Template _________________________ 44
Communication Event Estimating Template ____________________________________________ 45
Stakeholder Group Estimating Template _______________________________________________ 46
Estimating Technique Guide - Draft
3
2/5/2016
Estimating Technique Guide
Estimating Technique Guide
Introduction
Company Management has stated that there has been some history of Significant Project Cost and Schedule
Overruns. Issues identified included:
 Many project over-runs are attributed to poor estimates. Current estimating techniques are
perceived to be inconsistent, baseless, and inaccurate.
 There is a tremendous financial risk associated with poor estimating techniques. High estimates
can result in lost business opportunities. Low estimates increase the risk of project over-runs.
 There is an inconsistent use of a disciplined estimating process. This problem occurs in the sales
process and in estimating subsequent phases in an ongoing project.
 There is disagreement and no general consensus on the best techniques for system development
estimates.
 There is little or no guidance for estimating Accelerated application, package-based system
development, Non-traditional system development such as object-oriented development or Internet
/ Intranet development, Non-system development projects such as Performance Improvement
Initiatives, Vision and Strategy, Business Architecture, IT Re-engineering, and Organization
Change.
 Few tools exist to support estimating and the usability and validity of these tools is not universally
accepted.
The purpose of this Estimating Technique Guide, along with the Estimating Process Guide, is to begin to
address several of these issues. It will not resolve all of these issues. However, it can be an effective
vehicle that allows us to share our collective experiences. Although the targeted audience of this guide is IT
Services Consulting and Systems Integration, our goal is to utilize and share knowledge and experiences
across all of IT Service’s divisions. Specific goals for this guide include:
 Identifying estimating approaches, techniques, models and tools that have been used on prior IT
Services engagements. There are a number of techniques, models and tools that are being used
across the division. There are probably an equal number of opinions on which ones are the most
effective. This guide identifies some of the most common techniques, models, and tools. It does
not try to cover all of them; nor does it attempt to single out which technique, model and tool is the
most effective. In reality, there is no “universal” technique that applies to all types of projects;
each technique is valuable when used for the appropriate type of project. The key is to have an
awareness of what techniques, models, and tools are available so that you apply the best set of
techniques, models, and tools for your specific project.
 Sharing information on the techniques, models, and metrics that have been used for various
project phases. Many of the metrics defined are rules of thumb that have come from specific
projects. Many of these have not been confirmed or compared against other projects so you will
need to apply your judgment accordingly. This guide also includes some “gotchas” that were
identified from past experiences; hopefully these will help you to avoid similar pit-falls as you
develop your estimates.
 Fostering communication regarding estimating and metrics between project team members,
projects, business units, regions, and divisions. This guide, in and of itself, will not make us better
estimators. All of us need to experiment and communicate our experiences with these techniques,
models, and tools so that we can further define and refine them.
Estimating Technique Guide - Draft
4
2/5/2016
Estimating Technique Guide
Estimating Approaches
There are two basic approaches for determining the estimates for a given component of a project, top-down
and bottom-up. IT Services highly recommends that you estimate a project using both of these approaches.
A top-down estimating approach takes an estimate for an entire project and breaks it down into lower-level
components. Since this approach looks at the entire project from a fairly high-level view, you can develop a
top-down estimate in a relatively short period of time and with a minimal amount of project related
information. A bottom-up estimating approach breaks the project into pieces, examines each piece at a
detail level, and assembles all of the pieces and their estimates to come up with the overall project estimate.
Since this approach examines the project in much greater detail, it requires more project related information
and takes a longer time to develop the estimate. Because of the level of detail required, your bottom-up
estimate is generally more accurate than your top-down estimate.
Top-Down Estimating Approach
Using this approach you divide an overall estimate into separate, lower-level components. The starting
point is an estimate of the size, total effort, or the time required to perform a project. The total estimate is
apportioned among the components, or tasks that make up the project, according to a predefined formula as
well as taking into account experience from similar projects and any known external dependencies that may
act as constraints. For example, you may have determined that the total effort for a Requirements/BAA
phase is 1,000 hours. You can than use an estimating model such as Project Bridge Modeler to apportion
the 1,000 hours across the various activities and tasks that comprise a Requirements/BAA. You can also
adjust the hours per activity or task based on the required deliverables, your prior project experience, or the
project team’s expertise.
Depending on the size and complexity of the project, you can repeat this process to arrive at estimates for
lower-level tasks. After completing the top down estimates for the lower-level tasks you must validate your
estimate by checking to make sure that each of the lower-level estimates makes sense. If any of the lowerlevel task estimates is too low you must adjust the top level estimate upward or change the scope of the
project. You should also use other estimating methods to cross-validate your results.
This estimating approach is helpful when you have relatively little knowledge of the project requirements or
when the project is strictly limited by resources. For example, if the client has a fixed budget, this
estimating approach could be used to identify the level of work that could be delivered for that budget.
(Note: This is risky and not generally recommended.)
Disadvantages of this approach include:
 You could miss low-level technical issues or special components of the system.
 This approach offers little or no basis for the cost justification of subsequent estimating iterations.
 There is a tendency to define the scope in terms of the resources allocated rather than in terms of
the activities or deliverables.
 You need some basis for apportioning the overall project estimate across the various subcomponents.
Bottom-Up Estimating Approach
Using this approach you first identify the low-level components of the project, estimate each of these
components, and then total the individual estimates to produce the overall project estimate. The definition
of a low-level component can vary widely and is very dependent on the type of the project. You should
ensure that all of your low-level components are identified in or mapped to a Work Breakdown Structure
(WBS) or Statement of Work to ensure that you have accounted for all of the project’s components.
Examples of a low-level component include:
Estimating Technique Guide - Draft
5
2/5/2016
Estimating Technique Guide
 The effort to produce an intermediate product or deliverable. Examples include preparing for or
documenting workshops or interviews, developing an integration or application test plan, and
creating a detail project plan for a subsequent project phase.
 The effort to develop a specific function of the completed software system. For example, code and
test the maintain customer address window.
 A non-labor item such as a product or service. Examples include PCs, printers, pagers,
development software, installation fees, training, and travel related expenses.
One advantage of this approach is that it requires a relatively thorough analysis before you begin estimating.
Since you need have a more detailed view of the project requirements when using this approach, it can yield
a more accurate estimate than a top-down approach, provided you haven’t forgotten anything. This
approach also helps to identify uncertainties regarding the project requirements or proposed solution.
These uncertainties will often result in assumptions in the estimate and the project’s Statement of Work.
Disadvantages of this approach include:
 You may overlook system-level costs such as integration or training.
 It often requires more information than what is typically available at the time the estimate is
required.
 It requires a significant effort to produce the estimate.
 Activities such as management and development coordination cannot be estimated until the
underlying task estimates are complete. (These tasks are generally estimated based on the duration
of the project or as a percentage of the underlying tasks.)
Estimating Approach Comparison
The following diagram illustrates a high-level comparison between these two estimating approaches.
Estimation Approach
Strengths
Top-Down
 Particularly relevant if project is
strictly limited by resources.
 Relatively little knowledge of
proposed system required.
Bottom-Up
 Enforces relatively thorough
analysis before estimation.
 Identifies uncertainties in
developers’ knowledge of system
requirements or proposed solution.
Estimating Technique Guide - Draft
6
Weaknesses
 May miss low-level technical issues.
 Has little or no basis for the cost justification
of subsequent estimating iterations.
 May omit special components of software
system.
 Need basis for proportioning estimates across
project sub-components.
 Tendency to define scope in terms of
resources allocated rather than in terms of
activities or deliverables.
 May overlook system-level costs such as
integration, training.
 Often requires more information than is
available at time of estimate.
 Requires significant effort to produce
 Activities such as management and
coordination cannot be estimated until
underlying task estimates are complete.
2/5/2016
Estimating Technique Guide
Estimating Techniques
The following estimating techniques fit into either the top-down or bottom-up approach. No one estimating
technique is ideal for all situations; each has its own strengths and weaknesses. When estimating a project,
you need to decide which technique is appropriate and what adjustments, if any, are needed.
Ballpark Estimating
With this estimating technique you use a combination of time, effort, peak staff, and derived from the QSM
SLIM completed projects database. Each row represents a consistent set of estimates that may be
determined based on any one of the variables estimated using expert judgment.
This technique can be used at any point in the lifecycle. It can be used early in the lifecycle and when no
historical information is available. Once the estimate is developed, a comparative estimate can be
developed using a proportional technique. The final estimates can be compared to other estimates for
analysis.
Using the Business Case documentation, a proposed solution is visualized, and using expert judgment, the
Modules, Interfaces, Configuration Items, or Programs in the visualized solution can be identified and
entered into Top Down Estimate by CI worksheet.
Using the factors table, a size can be determined between Very Very Small and Very Large. At the same
time the Category with Size can be determined. Estimates are developed using the Peak Staff, Time in
Months, and Effort in Hours columns for guidance in determining each size estimate.
Using the size and category within size, the table is completed by locating the effort hours and ESLOC in
the top down factors table and entering them into the Effort Estimate and ESLOC columns in the Top Down
Estimate by CI worksheet. After all Configuration Items are estimated, the totals can be calculated.
If there are logical groupings of configuration items, they may be numbered. The groupings can then be
used to combine individual configuration items into packages of work for estimation by group.
The list of configuration items can be sorted by group and combined into a single estimate.
The total of the group can be used to create one estimate for the group using the top down factors table to
locate the total. The group total can then be used for a single estimate for size (ESLOC). The ESLOC
estimate is based on 100 Lines of Code per Function Point, with a productivity index assumed to be slightly
less than the average productivity of companies in the SLIM database having a SEI CMM Level 2
productivity index.
Proportional Percentage Estimating
With this estimating technique you use the size of one component to proportionally estimate the size of
another. For example, the Design effort might be estimated as 22% of the Requirements effort;
Construction 45% of Requirements effort, and Testing/Pilot 33% of Requirements effort.
This technique is very effective when used appropriately, when the estimated value really does depend
proportionally on another factor. There are different proportional models for different types of life cycles,
which must be considered in developing proportional estimates.
Consideration needs to be given to whether the current estimate is for an effort that is more like a
Development/Enhancement effort or a Maintenance effort. If any portion of the labor distribution is
estimated, it can be used to expand the known portion into a total estimate.
For example:
Estimating Technique Guide - Draft
7
2/5/2016
Estimating Technique Guide
Labor Distribution Standard for "Development / Enhancement" Work Types
Project Management (start-up, manage, close) - Development/Enhancement
Quality Assurance Reviews
Development / Enhancement Analysis (Requirements) [Solution Definition]
Development / Enhancement External Design
Development / Enhancement Internal Design
Development / Enhancement Procedures and Training
Development / Enhancement Construction (Code/Unit Test) [Solution Generation]
Development / Enhancement Test [Solution Validation]
Development / Enhancement Implementation [Solution Deployment]
Development/
Enhancement
15.00%
5.00%
15.00%
13.00%
12.00%
6.00%
27.00%
18.00%
9.00%
Labor Distribution Standard for "Maintenance" Work Types
Project Management (start-up, manage, close) - Development/Enhancement
Quality Assurance Reviews
Maintenance Analysis (Requirements) [Solution Definition]
Maintenance External Design
Maintenance Internal Design
Maintenance Procedures and Training
Maintenance Construction (Code/Unit Test) [Solution Generation]
Maintenance Test [Solution Validation]
Maintenance Implementation [Solution Deployment]
Maintenance
12.00%
8.00%
9.00%
9.00%
18.00%
4.00%
40.00%
15.00%
5.00%
Comparative
Using this estimating technique, you compare the project at hand, the target project, with other projects
similar in scope and type to produce an estimate. The comparison is normally performed at a high-level
with little reference to detail. This technique relies heavily on the experience of the estimators and their
ability to gauge the target project in relation to the comparative data available. For example you have been
asked to estimate the custom development for a new telecommunications system. You also happen to know
of a similar type of project that was also custom developed. Since this reference project covered roughly
50% of the functionality needed by the new system, you could develop a comparative estimate for the new
telecommunications systems by doubling the actual effort from your reference project. You could even add
an additional percentage of effort to account for some of the unknowns in the new system. The comparison
does not have to be at a project or phase level. You can use this technique for lower-level tasks such as
developing a reporting sub-system or a customer maintenance window.
This technique is useful as a “sanity check” for an estimate produced by another method. It can also be
useful for estimating low-level components such as documentation, printer volume, processor capacity, or
programming a specific system component.
The major weakness of this technique is that a project is not thoroughly assessed. Therefore, it should be
used only if time is limited or a relatively large uncertainty in the estimate can be tolerated. This technique
also requires some type of historical data to compare against.
Expert Judgment
This technique relies on the extensive experience and judgment of the estimator to compare the
requirements for the component being estimated against all projects in his/her previous experience. It
differs from the comparative technique in that the reference projects are not explicitly identified.
Proportional Estimating
With this estimating technique you use the size of one component to proportionally estimate the size of
another. For example, Quality Assurance might be estimated as 3% of the total project effort; the design
Estimating Technique Guide - Draft
8
2/5/2016
Estimating Technique Guide
effort might be estimated as 40% of the coding effort; the number of printers might be estimated as one for
every 6 users. Previous personal experience or estimating guidelines can help provide these proportionality
factors.
This technique is very effective when used appropriately, when the estimated value really does depend
proportionally on another factor. However, it should not be used as a crutch to pass the estimating
responsibility on to some other component. Using this technique will magnify estimating errors being made
elsewhere.
Proportional estimates can be used in combination with other estimating techniques. For example, after
using widget counting to derive the estimate for the Requirements phase of a project and then used
proportional factors to estimate the Design, Code/Unit Test, System and Integration Testing,
Implementation, and Deployment phases of the project.
Widget Counting
Using this estimating technique, you identify project characteristics that can be counted and that are
performed on a recurring basis (the “widget”), estimate the effort for each type of widget, and determine the
total effort by applying these estimates against the total number of widgets. Typical widgets may be menu
choices, windows, screens, reports, database entities, database fields, requirement specifications, pages of
documentation, and test cases. You may assign complexity factors to each type of widget (simple, medium,
complex) and weight the effort accordingly.
Use the following criteria when determining whether you should be using this estimating technique:
 There must be enough detail information to allow you to identify and count the widgets.
 The effort to develop or complete the project must be reasonably proportional to the number of
widgets, even though the project is not necessarily made up purely of widgets.
 You must be able to produce an estimate for the effort of each widget type. This is typically done
by using the comparative approach based on historical metrics data or by prototyping the
implementation of one of the widgets.
Function Point Analysis
This estimating technique is suited for projects that are based on straightforward database input, output,
maintenance, and inquiry, with low algorithmic processing complexity. Function Point Analysis is the basis
for several automated estimating tools. The basic steps involved in this estimating technique include:
1.
Decomposing the project or application into a defined set of function types, described below.
2.
Assigning a complexity to each of these function types.
3.
Tallying the function types and applying pre-defined weighting factors to these totals to drive a
single unadjusted function point count.
4.
Adjusting this function point count based on the overall project complexity.
5.
Translating the function point count to an effort estimate based on a function point delivery rate.
(This is probably the most difficult step.)
Function points are viewed from the perspective of the system boundary and are comprised of the following
types:
 Input—Any data or control information provided by the user that adds or changes data held by the
system. An input can originate directly from the user or from user-generated transactions from an
intermediary system. Inputs exclude transactions or files that enter the system as a result of an
independent process.
Estimating Technique Guide - Draft
9
2/5/2016
Estimating Technique Guide
 Output—Any unique unit of data or control information that is procedurally generated by the
system for the benefit of the user. This would include logical units forming part of printed reports,
output display screens, audit trails, and messages.
 Inquiry—Each unique input/output combination, in which the online user defines an inquiry as
input and the system responds immediately with an output. An inquiry is distinct from an output in
that it is not procedurally generated. The result of an inquiry may be a display/report or a
transaction file that is accessible by the user.
 Logical Internal File—Any logical group of data held by the system. This includes database
tables and records on physical files describing a single logical object. A logical file may span
many physical files (e.g., index, data, and overflow). However, it is treated as a single logical
internal file for sizing purposes.
 External Interface File—Each logical group of data that is input to or output from the system
boundary to share that data with another system.
Advantages for using Function Point Analysis include:

The project is viewed from the perspective of the user rather than the developer, that is, in terms of
user functions rather than programs, files, or objects.

The estimates can be developed from knowledge of the requirements without a detailed design
solution being known. This provides for a level of independence from the specific hardware
platform, languages, developer’s skill level, and the organization’s line of business.

The use of Function Point Analysis is accepted internationally. There is also a users group,
International Function Point Users Group (IFPUG), which has established standards to help
encourage consistency in counting function points.
Disadvantages for using this estimating approach include:

This approach does not accurately estimate systems that are largely algorithmic such as military
systems, space systems, robotics, process control, and middleware.

Function Points can be complicated to administer. Formal training is needed before you can
consistently count, and therefore track, function points.
The use of function points is not widely accepted within IT Services. As a result, we have not
gathered any estimating guidelines or metrics for function point estimating.


Since the concept of Function Point Analysis was developed with older technologies and
development approaches, it is not certain how well this concept applies to newer technologies and
development approaches such as object-oriented development. However, variations of Function
Point Analysis are being developed to address the newer technologies and development
approaches.
Feature Points
This estimating technique is an extension to the function point analysis technique. It involves adding a
number of algorithms with an average complexity weight and changing the function point weighting in other
areas. For typical management information systems, there is little difference in the results between Function
Points and Feature Points, both techniques result in nearly the same number of “points”. For real-time or
highly algorithmic systems, however, the results can be significantly different between these two techniques.
The Function Point count for such systems totals only 60 to 80 percent of the Feature Point count. Note:
Before using this estimating technique, you should read one of the published books on this subject.
Estimating Technique Guide - Draft
10
2/5/2016
Estimating Technique Guide
Technique Comparison
The following table highlights the strengths and weaknesses of these estimating techniques:
Estimation
Technique
Comparative
Strengths
Weaknesses


Estimate can be very accurate if a suitable
analogy can be identified.

Expert
Judgment



Estimate can be extremely accurate.
Identifies areas where requirements
clarification is needed.
Identifies requirements tradeoffs.



Proportional

Effective when estimated value really does
depend proportionally on another factor (e.g.,
software management, quality assurance,
configuration management).


Widget
Counting

Effective for systems that can be characterized
by widgets


Function
Point
Analysis





Feature
Point

Well suited for standard Management
Information System projects with little internal
processing complexity, especially those using
4GL, report writer, or CASE tool environments.
Project viewed from user, not developer,
perspective (e.g., user functions rather than
programs, files).
Estimates can be developed from knowledge of
requirements without a detailed design solution
being known.
Provides independence from hardware
platform, languages, developers’ skill at code
efficiency, business of organization.
Consistency encouraged through established
international standards for function point
counting.
Same strengths as Function Point Analysis,
with added benefit of accounting for algorithms
and internal processing complexity.







Estimating Technique Guide - Draft
11
Historical data repository
required.
Often difficult to find
comparable projects.
Must be verified by another
method.
High risk; may not be repeatable
by anyone other than the
“expert”.
Single data point.
Requires previous personal
experience or experience-based
guideline metrics for
proportionality factors.
Can magnify estimating errors
made in other areas.
Magnifies size errors if widget
effort estimates are incorrect.
Assumes effort to develop
system is proportional to number
of widgets, even though system
is not necessarily made up purely
of widgets.
Does not accurately estimate
systems that are largely
algorithmic such as military
systems, space systems, robotics,
and process control.
Does not have overall
acceptance within IT Services.
Can be complicated to
administer.
Requires formal training.
Does not yet have overall
acceptance.
Can be complicated to
administer.
Requires formal training.
2/5/2016
Estimating Technique Guide
Estimating Technique Comparison
The following diagram illustrates the recommended estimating techniques for the various ASPIRE project
phases, specialty areas, and management and coordination activities.
Mgmt and
Coord.
Specialty Areas
Project Phases
Feature
Point
Analysis
Function
Point
Analysis
Widget
Counting
Proportional
Expert
Judgement
Comparative
Estimating Techniques
Vision & Stategy, & ETP
Business Area Architecture
Development
Integration
Deployment
Development
Organizational Change
Technical Infrastructure
Facilities Infrastructue
Year 2000
Development Coordination
Project Management
Program Management
Optional/
Sanity Check
Recommended
Not
Recommended
Managing Multiple Estimates
The following techniques can be used to manage multiple estimates. This can occur when you have used
different techniques to estimate a project or component; you have various degrees of confidence, or when
you have multiple estimators.
Wideband Delphi Technique
When several estimators are estimating the same project or component, the Wideband Delphi technique is
useful to enforce convergence of the different estimates. The basic goal of this technique is to achieve a
more accurate and reliable composite estimate, thereby reducing the impact of individual biases,
misunderstandings, and incomplete knowledge. This technique consists of the following steps:
1.
The lead estimator presents the same specification to each expert.
2.
The lead estimator calls a group meeting in which the experts discuss estimation issues.
3.
The experts independently develop estimates and give them to the coordinator.
Estimating Technique Guide - Draft
12
2/5/2016
Estimating Technique Guide
4.
The lead estimator analyzes the estimates and distributes a summary containing the estimates with
their medians, but excluding rationale.
5.
The lead estimator calls a group meeting to discuss estimates, focusing on where estimates vary
widely.
6.
Experts review estimates, and steps 4–6 are repeated until a consensus is reached.
Weighted or Average Estimate
The technique uses the following formula to derive an average estimate. In general, this formula will result
in an estimate very close to the “realistic estimate”.
EV = (1{O} + 4{R} + 1{P}) / 6
where:
EV = Estimate Value
O = Optimistic Estimate
R = Realistic Estimate
P = Pessimistic Estimate
Note: The definition of optimistic, realistic, and pessimistic is up to the individual(s)
developing the estimate. Typically, your optimistic estimate will be your aggressive
estimate, your realistic estimate will be what you feel is the most likely estimate, and
your pessimistic estimate will be your conservative estimate.
Commercially Available Estimating Tools
There are a number of automated estimating tools available to support estimating efforts. In most of these
tools, an algorithm is applied to the basic measure of size to produce an estimate of effort (e.g., number of
required personnel resources). Although these tools have generally been calibrated using a wide range of
historical project data at other companies within the industry, they have not been calibrated against IT
Services projects so you need to apply some judgment when using these tools.
CHECKPOINT/KnowledgePLAN
Overview
CHECKPOINT, from Software Productivity Research Inc., is a knowledge-based software management
tool that can analyze, evaluate, and store data about your development projects. CHECKPOINT integrates
sizing, planning, scheduling, estimating, quality estimating, measurement, risk analysis, value analysis, and
technology assessment. It offers the capability to:
 Predict source code size.
 Estimate the cost of developing systems as well as the cost of developing specifications and user
documentation.
 Estimate projects using a knowledge-base of over 4,700 software projects.
 Measure all aspects of a software project at a user-defined level of granularity.
 Assess a wide range of software attributes against industry standards for cost, quality, schedules,
and productivity.
 Aggregate data across selected projects.
 Perform side-by-side comparisons of project versions, different projects, or a project against other
established benchmarks.
 Perform what-if analysis for a variety of variables including CASE tools, languages, skills, and
methodologies.
Estimating Technique Guide - Draft
13
2/5/2016
Estimating Technique Guide
Estimating Templates
There are a variety of estimating templates or spreadsheets being used throughout the organization to assist
with our project estimating efforts. Following is a high-level summary of the templates that the Estimating
and Metrics team have obtained, created, or modified. The actual spreadsheets have been attached as
separate files. Detailed instructions for using these spreadsheets are located in the appendix.
General Purpose Templates
Staff and Duration Estimating Template
This template provides a simple spreadsheet to compute the total hours and cost based on the anticipated
level of staffing and length of the project. The template allows you to define a project role, identify how
many individuals will fill this role (fractional values are valid), and specify the duration and hourly billing
rate for this role. The spreadsheet calculates the total hours and cost for each role, provides grand totals for
staff count, hours, and cost, and computes an average billing rate. The template also allows you to specify a
duration to hour conversion factor so that the total hours and cost are calculated on a per hour basis. For
example, if you are counting weeks in your duration, you can specify that there are 40 hours per week. The
estimating templates, contained in the file attachments, provide two staff and duration estimating templates.
One template allows for a single resource group, such as the project team; the other template allows for two
resource groups, such as IT Services and the client staff.
Travel Expenses Template
This template provides you with two options for estimating traveling expenses. The first option allows you
to estimate these expenses as an average for the entire team. The second option allows you to specify
estimated travel expenses on an individual by individual basis.
Requirements/BAA Proportional Estimate Projection Template
This template allows you to do a simple projection of the remainder of a project based on the actuals from
the Requirements/BAA phase. It is based on the assumption that a Requirements/BAA accounts for 7% to
10% of the total project effort. You simply enter the actual hours from the Requirements/BAA and the
spreadsheet projects the remaining project effort based on 7%, 8.5%, and 10% scenarios. You can modify
these factors or add additional scenarios. The template assumes a custom (ICD) development approach.
ASPIRE Phase Templates
Vision and Strategy
The Estimating and Metrics team currently does not have any templates specific to this ASPIRE phase.
The generic Staff and Duration template could be used for this type of an engagement.
Business Area Architecture
The Estimating and Metrics team currently does not have any templates specific to this ASPIRE phase.
The generic Staff and Duration template could be used for this type of an engagement.
Development
A number of estimating templates have been collected that support the Development phase of ASPIRE.
Please refer to the Development estimating templates for a complete list.
Integration
Specific estimating templates have not been developed for this phase. The various Development estimating
templates generally use a proportional estimating factor for this phase. The general Staff and Duration
estimating template can also be applied to this phase.
Estimating Technique Guide - Draft
14
2/5/2016
Estimating Technique Guide
Deployment
Specific estimating templates have not been developed for this phase. The various Development estimating
templates generally use a proportional estimating factor for this phase. The general Staff and Duration
estimating template can also be applied to this phase.
Specialty Area Templates
Development
Package-Based Development (PBD) Estimating Template
Two estimating templates are provided; one supports a single package-based application, the second
supports multiple applications. Each template allows you to identify the key activities and work products
for each of the package-based sub-phases. For each activity or work product, you can specify the number of
units, the estimated effort for each unit, the number of staff working on each activity or work product, and
any estimating assumptions or comments. The spreadsheet will compute the total estimated effort for each
activity and provide totals by sub-phase. These totals are linked to a summary worksheet that provides a
high-level overview of your estimates. You can also apply a proportional level of effort for the integration
and deployment phases. The project management and coordination phases can be estimated based on a staff
and duration template, included in the spreadsheet, or by using a proportional level of effort.
Matrix-Based Iterative Custom Development (ICD) Estimating Template
This estimating template allows you to build a bottom-up estimate based on the number of “widgets” being
developed. These widgets can include items such as menus, reports, windows, servers, interfaces,
conversions, and common objects. As you define each of these widgets, you can rate the complexity of
each on a scale from 1 to 10. The detail matrix worksheet references additional look-up tables that contain
the appropriate estimate based on the type of widget and its complexity. The spreadsheet accumulates totals
for each type of widget and links these totals to a summary worksheet to provide a high-level summary of
your estimates. You can also apply a proportional level of effort for the business system design, application
development completion, integration and deployment phases. The project management and coordination
phases can be estimated based on a staff and duration template, included in the spreadsheet, or by using a
proportional level of effort. Two estimating templates are provided; one supports a single iterative customdeveloped application, the second supports multiple applications.
Accelerated Application Development (XAD) Estimating Template
Two estimating templates are provided; one supports a single XAD application, the second supports
multiple applications. Each template allows you to identify the key activities and work products for each of
the XAD sub-phases. For each activity or work product, you can specify the number of units, the estimated
effort for each unit, the number of staff working on each activity or work product, and any estimating
assumptions or comments. The spreadsheet will compute the total estimated effort for each activity and
provide totals by sub-phase. These totals are linked to a summary worksheet that provides a high-level
overview of your estimates. You can also apply a proportional level of effort for the integration and
deployment phases. The project management and coordination phases can be estimated based on a staff and
duration template, included in the spreadsheet, or by using a proportional level of effort.
Organizational Change
Communication Event Estimating Template
This estimating template assists in estimating the effort to design and deliver communication events using
the calculations described in the Organizational Change estimating guidelines; these guidelines are provided
later in this document. Two estimating options are included in this template.
Estimating Technique Guide - Draft
15
2/5/2016
Estimating Technique Guide
Stakeholder Group Estimating Template
This estimating template assists in estimating the number of stakeholder groups based on either the project
team’s size or the overall size of the client. This template uses the calculations described in the
Organizational Change estimating guidelines; these guidelines are provided later in this document. To
estimate the number of stakeholder groups based on the project team size, simply enter the size of the
project team in full-time equivalents. To estimate the number of stakeholder groups based on the overall
client size, you need to select the appropriate client size and percentage of organizational impact from the
respective tables.
Technical Infrastructure
Specific estimating templates have not been developed for this specialty area.
Facilities Infrastructure
Specific estimating templates have not been developed for this specialty area except for Critical Computer
Resources.
Estimating Technique Guide - Draft
16
2/5/2016
Estimating Technique Guide
ASPIRE Methodology Comparison
The following diagram illustrates how the various estimating templates support the ASPIRE project phases,
specialty areas, and management and coordination activities.
Program
Management
Development
Coordination
Project
Management
Facilities
Infrastructure
Organizational
Change
Technical
Infrastructure
Process
Initiative
Deployment
Integration
Development
Business
Architecture
Vision and
Strategy
ASPIRE Phases, Specialty Areas, and Management and Coordination Activities
Staff and Duration
Estimating Templates:
Travel Expenses
Requirements/Proportional
Package Based Dev
Iterative Custom Dev
Accelerated Application Dev
Ballpark Estimating
Proportional Percentage
... TBD ...
Optional /
Sanity Check
Recommended
Not Recommended
Estimating Guidelines
Project-Wide Guidelines
The following estimating guidelines can be applied across all phases of a project. Refer to the Estimating
Process Guide for additional guidelines.
 Use at least two, and preferably three, estimating approaches or techniques when estimating your
project. Using multiple approaches will help ensure a higher level of confidence in the final
estimates. Your estimate should include at least one top-down and one bottom-up approach.
 On larger scale estimating efforts, you will often need to make assumptions to “fill the gaps” in the
information needed to create the estimate. Be sure to document any assumptions, constraints, or
risks that you identify during this process in the Estimating Notebook. These items must also be
incorporated into the project’s Statement of Work.
 To estimate effectively, you need to understand the scope, requirements, and the approach. These
should be documented in your Statement of Work. You will also need to identify any of the
surrounding activities or components. For example, if you are trying to estimate an Enterprise
Transformation Plan, you should take into account the effort to produce the final deliverables as
well as the workshops, interviews, travel, project management time, and delivery assurance.
(Note: In most cases you will be developing the Statement of Work at the same time
you are developing your estimates. There will be cases where your estimating
process requires that you update your Statement of Work and visa-versa.
Although these are often done concurrently, an initial draft of your Statement of
Work, especially the scope and approach sections, will be a valuable source of
input for your estimating process.)
Estimating Technique Guide - Draft
17
2/5/2016
Estimating Technique Guide
 Breakdown the project deliverables and work products into more manageable pieces by creating a
work breakdown structure (WBS) that contains all of the components of the proposed solution.
 Base your estimates on some quantifiable unit of measure. Examples include the number of
workshops being conducted, number of windows being developed, number of packages being
evaluated, and the number of staff over some fixed duration of time. Document these quantifiable
units of measure in the Statement of Work and Estimating Notebook.
 Include the effort for conducting architecture, business function, design, and development reviews
in your estimates. One rule of thumb is to allow for 4 FTEs for 5 days every quarter.
 When appropriate, evaluate and approve estimates from sub-contractors.
 Try to separate the “pricing” from the “estimate”. All too often we try to develop an estimate with
a maximum price tag in mind and we let the “price” drive the “estimate”.
 Use the following guidelines when estimating for project expectations and reviews:

For each project expectation: ½ hour to write, and ½ hour for both individuals (manager
and project team member) to review and discuss.

For each project evaluation: 1 hour to write and 1 hour for both individuals to review and
discuss.

Allow for 1 project evaluation for each team member every four months.
Estimating Technique Guide - Draft
18
2/5/2016
Estimating Technique Guide
ASPIRE Phase Guidelines
Vision and Strategy (ETP)
General Information
Several interviews with project teams indicate that the "soft deliverables" associated with an ETP allow a
fair amount of flexibility in the duration of the study. Client expectations must be carefully managed as to
the level of detail that will be provided as a result of the study. If expectations are not properly managed,
significant cost overruns and loss of credibility are likely, even for a relatively small project such as an
ETP. Another critical success factor is the staffing. A good client relationship person is key, as well as one
or two solid Business Analysts and a good Technical Architect who can take a pragmatic approach and
make fact-based recommendations.
Estimating Techniques, Tools, and Templates
Recommended estimating techniques include comparative and expert judgment. You can also use a
proportional or widget counting technique to get an alternative estimate. None of the estimating tools that
we have used address this phase of a project. The only estimating template that we currently have available
for an ETP is the general staff and duration estimating template.
Estimating Rules of Thumb
(Note: The following estimating rules of thumb have been collected from a variety of sources including an
Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field
visits. Not all of these have been confirmed or validated.)
Following are some rules of thumb that have been used on prior projects.

It takes four people approximately six weeks to complete an ETP study.

Plan on one to two days per page for preparing the final documentation.

The total cost for an ETP seems to be in the $50,000 to $350,000 range. Assuming a $200/hr
billing rate this would translate to 250 to 1,750 hours.
Cautions
Following is a list of potential “gotchas” that could impact your ETP estimates. Review these and adjust
your estimates, assumptions, or risk factors accordingly.

At the outset of the project, client expectations must be carefully managed as to the level of detail
that will be provided as a result of the study. If expectations are not properly managed, significant
cost overruns and loss of credibility are likely, even for a relatively small project such as an ETP.

The primary deliverable is a prioritized listing of future steps to achieve the Vision set by the
study. The time to develop this plan is often underestimated. The answer usually does not "fall
out" from the work done during the study.

Manage client expectations on the length of the document to be presented and the depth to which it
will extend. Will we estimate IT Services involvement or leave the numbers "generic"? Will
dollars be associated with the estimates? Will the estimates be considered "IT Service’s bid" for
the work?

In the likely event that the plans for the future studies become budgeted numbers for the client, we
must realize that IT Services will need to be prepared to do the work for those estimates. A plan
that we cannot live with surely is one the client cannot live with.
Estimating Technique Guide - Draft
19
2/5/2016
Estimating Technique Guide
Business Area Architecture (Requirements/BAA)
General Information
The following questions can assist you in sizing the Requirements/BAA effort, especially if you are going to
use a bottom-up estimating approach.

How many user representatives will be involved with the Requirements/BAA effort? How many
representatives will be providing requirements?

How many interviews will you conduct? Include interviews at the executive level as well as firstlevel management.

How many departments or locations will be involved?

What is the client’s overall organizational structure? For example is the client’s organization
largely regulatory, multinational, multidivisional, centralized, or decentralized?

What is the scope baseline as defined by each of the six domains of change?

What deliverables is the client expecting to be delivered? What is the expected level of detail for
these deliverables?

How many process threads will you be addressing? Is the client looking for a business process
redesign or a business process improvement?

How many conceptual data entities are expected to be involved?

How many workshops are you expecting to conduct? How many individuals will be attending
these workshops? What are the time box assumptions for each workshop?

How many best practice interviews are you expecting to conduct?

How many legacy systems are involved?

Will customer, supplier, or competitor surveys be conducted? And if so, how many customers,
suppliers, or competitors will be targeted?

Do we have already identified an industry or business best practice for this type of client?

Will there be a final presentation?

Who will do the final sign-off; I/S or the business users? How many individuals will be reviewing
or approving deliverables?

Will you need to create a business case for action?

Will the client be using a value discipline? Has this already been established?

How many alternative architectures is the client expecting?
Estimating Techniques, Tools, and Templates
Recommended estimating techniques include comparative and expert judgment. You can also use a
proportional or widget counting technique to get an alternative estimate. Possible estimating tools include
Ballpark, QSM Slim, and Proportional Percentage. The only estimating template we currently have
available for a Requirements//BAA is the general staff and duration estimating template.
Estimating Rules of Thumb
(Note: The following estimating rules of thumb have been collected from a variety of sources including an
Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field
visits. Not all of these have been confirmed or validated.)
Following are some rules of thumb that have been used on prior projects. Since the scope and depth of the
final deliverable for a Requirements/BAA can vary significantly from project to project; you will need to
adjust your estimates based your specific project.
Estimating Technique Guide - Draft
20
2/5/2016
Estimating Technique Guide
The following staff size/ project duration have been used on prior Requirements/BAA efforts:
 Six people for five months
 Four people for two months (Decision Support System; focused on data not processes)
 Six people for three and a half months. The Requirements/BAA was for a small division and
included all the processes for this division.
 Three people for three months.
Data modeling metrics:
 Four hours per entity using workshops. These hours are for the data modeler only. Workshops
seemed to be the most efficient method.
Cautions
Following is a list of potential “gotchas” that could impact your Requirements/BAA estimates. Review
these and adjust your estimates, assumptions, or risk factors accordingly.
 The Requirements/BAA effort generally involves intense senior business level participation. Your
estimate and schedule should reflect this effort.
 The overall client culture could increase the time and effort to resolve issues.
 During the Requirements/BAA phase, there tends to be more committee decision making versus
individual decision making. This will increase time frames.
 When possible, resist the need for producing downstream estimates for BSD and Development
until the Requirements/BAA has been completed, or nearly completed. Accurate estimates are
very difficult to produce during the early phases of a project.
 Changes in scope during the Requirements/BAA will impact later phases of the project. Following
are some general metrics regarding the impacts on subsequent project phases. When applicable, be
sure to include the potential estimate adjustment for later phases as well. This will help the client
in understanding the full impact of the change request; reducing the potential “sticker shock” of
subsequent phases.
Req /BAA:
Scope changes are generally 1 to 1.
BSD:
Changes in the Requirements/BAA could result in changes 2 to 3
times as much during the BSD phase.
ADP:
Changes in the Requirements/BAA could result in changes that are
4 to 5 times as much during program construction.
INT:
Changes in the Requirements/BAA could result in changes that are
up to 10 times as much during integration testing.
Note: If you have already provided estimates for subsequent phases, knowing
the estimating drivers that were used for these later phases will also help you
to identify the overall impact of the scope changes.
Development
Refer to the Development estimating guidelines for each of the specific Development paths.
Integration
Specific estimating guidelines have not been developed for this phase at this time. During our field support
visits, we generally used a proportional factor for this phase. Other estimating options include using a staff
and duration model or basing the estimates on the number of test scenarios that need to be executed.
Estimating Technique Guide - Draft
21
2/5/2016
Estimating Technique Guide
Deployment
Specific estimating guidelines have not been developed for this phase at this time. During our field support
visits, we generally used a proportional factor for this phase. Other estimating options include using a staff
and duration model or basing the estimates on the number of deployment sites.
Specialty Areas
Development
Package Based Development (PBD)
General Information
The following estimating guidelines apply to the entire PBD specialty area. More specific estimating
guidelines have also been included for the Package Evaluation and Selection (PES) sub-phase. The
following questions can help you to size your overall PBD effort.
 Have a clear definition of an enhancement, a configuration, and a modification. An enhancement
involves making a fix using the tools provided by the vendor. A configuration involves setting a
software parameter as intended. A modification is a change to the core software code. As a
general rule, Do Not Make Modifications!
 Does the package include any modules that are provided by ancillary vendors?
 Will the project include a Requirements/BAA? What is the extent will the business processes
change; is the client expecting a process improvement or a reengineering of its business processes?
 Is a Technical Infrastructure included?
 Will the project include PSD through implementation? Does the project scope include any
production support? Any Training?
 What is the messaging infrastructure (mainframe component)?
 Does the project scope include data mapping?
 Does the project scope include Organizational change for IS or the business community?
 Does the project scope include a gap analysis? What percentage of change is the client expecting?
 Will the project team have direct or intermediary contact with the users and decision makers?
 How involved will the user community be?
 Will IT Services have overall project control or will we be shadow-managing?
 Does the project scope include a pilot? Does it include a roll-out?
 What other tools (IT or project management) will be required for this project?
 How much experience does the client have with the proposed platform? How sophisticated is the
client with this platform? Additional support, policies, and procedures may be required.
 How will the application or data be distributed across locations? Will the application or data be
distributed over time?
 Who (IT Services or client) will be responsible for managing the software vendor?
Estimating Techniques, Tools, and Templates
Estimating techniques that apply to a PBD effort include comparative, expert judgment, and widget
counting. All of the estimating tools discussed in the prior section provide some level of support for a
package-based development approach. CA-Estimacs contains a packaged-based lifecycle model; however,
we have had minimal success with using CA-Estimacs to estimate this type of a project. Checkpoint applies
mainly to any proposed enhancements and is not recommended for a package-based development effort.
We have developed a package-based estimating template that can support a single or multiple applications.
Estimating Technique Guide - Draft
22
2/5/2016
Estimating Technique Guide
Estimating Rules of Thumb
(Note: The following estimating rules of thumb have been collected from a variety of sources including an
Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field
visits. Not all of these have been confirmed or validated.)
Following are some suggested rules of thumb that you can use when deriving your estimate. You will need
to adjust your estimates based on your specific project.
SAP Implementation:
 A general rule of thumb is $1 million for an SAP implementation.
 A SAP R3 implementation can be 10 times or more higher than the retail software price.
 Although the minimum timeframe for an SAP implementation can be a short as 6 months; 12 - 18
months is a more realistic minimum timeframe. An SAP implementation is often 2 times longer
than an Oracle implementation.
Oracle Implementation:
 A typical Oracle implementation costs approximately $10 million.
 An Oracle 2 implementation can be 3 times or more higher than the retail software price.
 Although the minimum timeframe for an Oracle implementation can be as short as 6 - 8 months,
the average minimum timeframe for a generic implementation is 9 - 12 months.
Cautions
Following is a list of potential “gotchas” that could impact your PBD estimates. Review these and adjust
your estimates, assumptions, or risk factors accordingly.
General:
 We typically under-estimate the development, conversion, and interface efforts.
 Clients often fail to provide full-time business resources.
 Best of breed solutions often require multiple vendors.
 Multiple database and application software vendors add to the overall risk and complexity.
 We often underestimate vendor and subcontractor efforts.
 Earlier software versions are generally prone to bugs and poor software performance.
 For SAP, Oracle, and PowerSoft: Inflate server requirements 4 times the vendor statements.
 Software vendors are generally unwilling to modify their software.
SAP:
 SAP does not have a distributed data architecture; however, you can usually distribute module
specific information.
Oracle:
 Oracle may not be considered true client server; if it does not have a distributed data architecture.
 EDI capabilities are non-existent within the Oracle suite of applications.
 A minimum client PC requirement is a Pentium processor with 24 meg of memory, and a 1.2 gig
hard drive.
Estimating Technique Guide - Draft
23
2/5/2016
Estimating Technique Guide
Package Evaluation and Selection (PES) Sub-Phase
General Information
Understanding the scope of the PES is a critical factor when deriving your estimate. Following is a list of
scope questions that should be considered. These items should be addressed in the project’s Statement of
Work.
 Has a vision and strategy (ETP) been conducted? If so, to what extent? If not, will part of the
PES need to address the vision and strategy?
 Does PES also include the relevant activities of the Requirements/BAA or is this being estimated
separately?
 Will the PES selection process result in vendor’s submitting a response to either a Request For
Proposal (RFP) or a Request For Solution (RFS)? An RFS will involve more effort.
 Is contract negotiation part of the project scope?
 Does the project scope include the Technical Infrastructure Acquisition (TIA)? If so, you may
need to estimate all of the related equipment costs.
 Will IT Services be managing the project or only assisting the client in managing this effort?
 What will be the client’s involvement in the PES? What is the client’s experience level with PES?
 What is the scope of the end package; for example, will it be used solely for AR or will it also be
used for order management?
 Is the client looking for an integrated packaged solution or is the client looking for a best of breed
solution?
 What are the client’s budget thresholds?
 What are the business drivers behind this initiative?
 How many packages are you planning on evaluating? What is your evaluation approach for the
top packages?
 What is the client’s timeframe for choosing and installing the packaged solution?
 What is the acceptance process? What is the acceptance criteria? These should be identified in
the project’s Statement of Work.
 Does the client have a current or prior relationship with potential vendors? Are there any political
issues that you need to be aware of?
 How many functions or process threads is the new package going to address? How does this
compare to the current system?
 Does the client have a list of requirements?
 Are there any unique functions specific to the client’s industry or the client’s company? Is the
client considering being an industry center of excellence?
 How many interfaces are you anticipating? Are there multiple systems or platforms?
 Will the packaged solution be an enterprise-wide solution?
 What is the client’s guiding principle towards business process change; are they willing to change
their business process for the package or visa versa.
 What is the I/S strategy for or their view towards the package or the package’s architecture? Is the
package’s architecture in alignment with current I/S strategy? Will it be accepted by the I/S
organization?
 Have the equipment, platform, or technical requirements been identified?
Estimating Technique Guide - Draft
24
2/5/2016
Estimating Technique Guide
Estimating Techniques, Tools, and Templates
The same techniques, tools, and templates identified for a package-based development effort also apply to
the PES sub-phase.
Estimating Rules of Thumb
(Note: The following estimating rules of thumb have been collected from a variety of sources including an
Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field
visits. Not all of these have been confirmed or validated.)
Following are some rules of thumb that you can use when deriving your estimate. You will need to adjust
your estimates based on your specific project.
 The minimum cost for a PES is $100K. The minimum duration of 3 months elapsed time is
needed to accommodate scheduling issues.
 A PES project should be staffed with one person per functional area such as financial, distribution,
manufacturing, technical, and project management. The staff should be experienced.
 Each major module will cost $25k or higher. A major module is defined as a major functional
subsystem. For example, ERP/ MRPII has 15 major modules: General Ledger, Accounts Payable,
Accounts Receivable, Order Entry, Purchasing, Inventory, Payroll, Human Resources, Bill of
Material, Shop Floor Control, WIP, Master Scheduling, MRP, MPS, and Standard Costing.
 When estimating the selection process, allow for 20 days or more for each major module. This
time does not include the SDL.
Cautions
Following is a list of potential “gotchas” that could impact your PES estimates. Review these and adjust
your estimates, assumptions, or risk factors accordingly.
 Interfaces with other systems or packages.
 Confusion or misinterpretation of the client’s definition of specified business processes. You
should try to compare their definition with an APICS reference, AICPA, Hackett Group, or HRSP.
 Multi-lingual, multinational, and multicultural capabilities or requirements.
 When selecting the final package, avoid a weighted point system as the ultimate decision maker.
 Ensure that there is a real business value.
 Be sure to validate a vendor’s integrity through references.
 Level of organizational change required versus planned.
 Client’s expectations of IT Services developing a vendor short list.
 Consider the vendor’s location, accessibility, and logistics for distributing and receiving RFP or
RFS responses.
 Vendor meetings with the client.
Estimating Technique Guide - Draft
25
2/5/2016
Estimating Technique Guide
Iterative Custom Development (ICD)
General Information
Estimating Techniques, Tools, and Templates
All of the estimating techniques and tools discussed in prior sections provide some level of support for an
iterative custom development effort. The matrix based ICD estimating template is also an effective tool for
this type of project.
Estimating Rules of Thumb
(Note: The following estimating rules of thumb have been collected from a variety of sources including an
Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field
visits. Not all of these have been confirmed or validated.)
Following are some rules of thumb that you can use when deriving your ICD estimate. You should adjust
your estimates based on your specific project.
 Following are some general metrics for additional “support” staff. These individuals are in
addition to a full-time project manager, system architect, DBA, application architect, and test
coordinator.
Team Leaders: When a team lead is monitoring 3 or less developers; 50% of this individual’s time
can be allocated for team leader activities and the other 50% to development activities. If the
team leader is monitoring up to 6 developers, then 100% of the individual’s time needs to be
allocated to team leader activities. Note: If you are using Widget Counting to estimate the
development effort, the team leader activities are additional hours.
Additional Managers: Consider adding one additional FTE for every 15 -16 team members.
Technical Support: Consider adding one additional FTE for every 3 - 4 boxes, servers, networks,
or databases.
 Following are some general metrics for interfaces. These hours include technical design,
programming, and unit testing of one program:
Simple (Extract and Post):
80 hours
Medium:
160 hours
Complex (multiple
systems or conversions):
240 hours
 Following are some general PowerBuilder/ PowerTools metrics. These hours are for coding and
unit testing 2-tier applications; you will need to adjust these for more complex 3-tier applications.
These estimates are based on an existing, approved prototype. For estimates in excess of 88
hours, try to breakdown into simpler tasks in order to accurately estimate the progress of this task.
Simple:
24 - 32 hours
Medium:
40 - 48 hours
Complex:
80 - 88+ hours
Note:
Simple Window: Contains 1-2 simple objects such as a drop down data
window or single line edits. There can be a simple query done in this
window that does a select from a single table. Many of the data
maintenance windows fall into this category.
Estimating Technique Guide - Draft
26
2/5/2016
Estimating Technique Guide
Medium Window: Contains several simple data objects or 1-2 complex
data windows that have SQL selects with multiple table joins, simple
updates or deletes from the database.
Complex Window: Contains 3 - 6 data windows with multiple objects on
the window. Complex data queries, updates, inserts and deletes across
multiple data tables. Performance considerations are critical in this
window and extra effort should be taken to make sure that this window is
as efficient as possible.
 Following are some general ANSI “C” coding and unit testing metrics. Note: The hour estimates
for the complex functions are in excess of 80 hours. If these are greater than 120 hours, you need
to break these down into simpler tasks, such as sub-functions within the main business process.
Simple:
40 hours
Medium:
80 hours
Complex:
80 - 120+ hours
Note:
Simple Function: Does not contain a lot of complex computation or data manipulation .
There can be a simple query done in this function that does a select from a single table.
Medium Function: A more complex function that has data manipulation,
multiple table (2-4) joins in the SQL, and has cursor management within
the function.
Complex Function: Contains data manipulation, multiple table (4 or more)
joins in the SQL, and has multiple cursor management within the function,
dynamic memory allocation for structures in support of complex data
manipulation. A complex C function can also contain complex queries,
inserts, updates and deletes from the database.
 Following are some general metrics for stored procedures. Note: These estimates were based on
Oracle stored procedures. The project team’s System Architect needs to be familiar with the
stored procedure functionality and know when is it beneficial to use a stored procedure versus a C
function or visa versa. These hours are for design, code, and unit testing.
Simple:
10 hours
Medium:
20 hours
Complex:
40+ hours
Note:
Simple Procedure: Contains a single simple query. Does not contain any logic.
Medium Procedure: Contains 1-2 transactions, simple logic within the
stored procedure, simple cursor manipulation, simple exception handling.
Complex Procedure: Contains complex program logic, complex data
manipulation, multiple table (4 or more) joins in the logic, and has multiple
cursor management with in the stored procedure. This stored procedure
can have multiple transactions processing within the procedure, complex
queries, inserts, updates and deletes from the database, and complex
exception handling.
Estimating Technique Guide - Draft
27
2/5/2016
Estimating Technique Guide
 Following are some general metrics for creating a database. Note: Estimates are based on creating
a physical build with a first cut at optimization, average database size, single database and location
with primary indices. Estimates do not include performance turning. The average is
approximately 3 hours per table.
Simple (less than 25 tables):
80 hours
Medium (less than 70 tables):
160 hours
Complex (greater than 70 tables):
240 hours
 The following metrics can be used to determine the effort for creating a logical data model:
Four attributes per hour
Five relationships per hour
One entity per hour

Following are some general conversion metrics. These estimates include the design, code, and
unit testing for each conversion program. The actual conversion effort is not included.
Simple:
120 hours
Simple-Medium:
160 hours
Medium:
200 hours
Medium-Complex:
280 hours
Complex:
400 hours
Note:
Simple Conversion: A simple extract and post program. Expect that less than 10% of the
conversion programs to be classified in this category.
Simple-Medium Conversion: Expect approximately 10% of the conversion programs to
be classified in the category.
Medium Conversion: Expect to have approximately 10 - 20% of the conversion programs
to be classified in this category.
Medium-Complex Conversion: Expect to have approximately 20 - 50% of the conversion
programs to be classified in this category.
Complex Conversion: Expect to have over 50% of the conversion programs to be
classified in this category.
 Following are some guidelines for developing Oracle Forms. These following estimates are for
Forms 4.0 and they assume that the form has been generated through Designer/2000. (If the form
was created manually, and additional 12 to 20 hours should be added to the estimates depending
on the number of blocks, fields, canvases, and list values contained in the window.)
Simple:
24 hours
Medium:
40 hours
Complex:
64 hours
Very Complex:
104 hours
Note: It is not certain whether these estimates only include just the development of these
forms or whether these estimates include development and unit testing.
Estimating Technique Guide - Draft
28
2/5/2016
Estimating Technique Guide
Simple: A simple form is one that contains only one block and requires few edits or
validations.
Medium: A medium form is one that contains two or three blocks and a moderate amount
of additional processing logic.
Complex: A complex form is one that contains two or more blocks and requires a
substantial amount of additional processing logic.
Very Complex: A very complex form is similar to a complex form, except that the
additional processing logic itself is complex.
 Following are some guidelines for developing Oracle Reports.
Simple:
8 hours
Medium:
16 hours
Complex:
32 hours
Very Complex:
48 hours
Note: It is not certain whether these estimates only include just the development of these
reports or whether these estimates include development and unit testing.
Simple: A simple report is one that contains only one query and requires little formatting.
Medium: A medium report is one that contains two or three queries and a moderate
amount of formatting.
Complex: A complex report is one that contains two or more queries and requires a
substantial amount of formatting.
Very Complex: A very complex report is one that contains two or more queries and
requires a significant amount of formatting.
 Following are some guidelines for developing Oracle Zooms. The following estimates cover any
custom zooms written to allow users to jump from one application form to another with the
possibility of performing some processing once the user arrives at the new application form. (This
is similar in concept to a “hot key”.)
Note: Zooms are commonly used with Oracle’s character-based version. They are not commonly used
(might not be supported) in their GUI version.
Simple:
16 hours
Medium:
32 hours
Complex:
56 hours
Very Complex:
80+ hours
Note: It is not certain whether these estimates only include just the development of these
zooms or whether these estimates include development and unit testing.
Simple: A simple zoom is one that only has one zoom event and few zoom steps and has
little or no effect on the zoom-to location.
Medium: A medium zoom is one that may have only one zoom event but several soom
steps or have some effect on the zoom-to location.
Complex: A complex zoom is one that has several zoom events each with several zoom
steps that perform some function in the zoom-to location. (For example, copy data from
source to destination, execute an automatic query at the destination, or update data either
the source or destination location.)
Estimating Technique Guide - Draft
29
2/5/2016
Estimating Technique Guide
Very Complex: A very complex zoom is one where significant actions take place at both
the source and destination locations using combinations of queries and triggers in multiple
steps in each event.
 Following are some guidelines for developing Oracle Alerts.
Simple:
8 hours
Medium:
16 hours
Complex:
32 hours
Very Complex:
48 hours
Note: It is not certain whether these estimates only include just the development of these
alerts or whether these estimates include development and unit testing.
Simple: A simple alert is one that incorporates simple SQL code to respond to well
defined events or to perform very routine actions such as cleaning obsolete data out of a
table. report is one that contains only one query and requires little formatting.
Medium: A medium alert is one that incorporates more detailed actions in response to
events and contain more complex SQL.
Complex: A complex alert is one that might require several elegantly formatted detailed
and summary actions in response to an event.
Very Complex: A very complex alert is one that requires interaction with the operating
system in conjunction with detailed actions.
 Estimate 40 hours of effort to develop one hour for hands-on (classroom-type) training with labs.
 Estimate 8 hours of effort to develop one page (8.5 x 11) of user documentation.
 Following are some generic custom development metrics. There numbers were based on a small
sampling of projects and should be adjusted based on the knowledge of the specific project
environment. The metrics assume that the development is client/ server using C++ or Visual
Basic. They do not account for 4GL tools, prototyping, database activities, performance
engineering, team leadership, or other support activities. The total hours cover design, code, unit
test, and limited application/ integration testing.
Simple
Medium
Complex
Design
10
17
34
Code
24
40
80
Test
4
8
16
38
65
130
Total:
Note:
These numbers seem to be on the low side when compared to other metrics provided
above. Also it is uncertain at this time whether unit testing is covered in the “coding” or
“testing” phase.

For completing a program, the following percentages can be used to break-down an estimate:
Review Specification:
5%
Code Program:
15%
Compile Program:
15%
Estimating Technique Guide - Draft
30
2/5/2016
Estimating Technique Guide

Code Review:
5%
Create Test Plan:
15%
Review Test Plan:
5%
Unit Test Program:
35%
Obtain Program Sign-off:
5%
Following is a proportional percentage by project phase:
Requirements
/BAA:
10%
BSD:
20%
Construction:
40%
Testing/ Pilot:
30%
Notes:
 Construction includes unit testing.
 Testing and Pilot includes:

String and Integration Testing:

User Acceptance Testing:
40% of effort
40% of effort
 Performance Testing:
20% of effort
As a reasonable sanity check for these phases, calculate the effort based on the anticipated staff count
and duration. (Calculate each phase separately.)
Cautions
Following is a list of potential “gotchas” that could impact your ICD estimates. Review these and adjust
your estimates, assumptions, or risk factors accordingly.
 Being forced to estimate the entire project up-front. Try to avoid estimating forward from the
Requirements/BAA, especially if the Requirements/BAA has not been completed.
 3-Tier environments add an additional layer of complexity. Adjust your estimates accordingly.
 The DBA staff being expected to build all stored procedures. Instead, allow the Application staff
to build the procedures and have the DBA staff review them.
 It is essential to have a frozen architecture before you begin development.
 Failure to include time for all levels of testing; especially system and performance testing.
 Failure to distinguish between the various components of the application architecture: e.g.
PowerBuilder, C, and stored procedures.
 Be sure to anticipate an lower level of utilization for client staff. Try to place these resources on
non-critical paths.
 Remember to make allowances for computer operations. You will need them for critical items
such as network support, backups, and DASD management.
 Allocate time for project manager, system architect (technical analyst), application architect
(business analyst), test coordinator, and DBA roles. These individuals should be allocated for the
entire ICD phase. Note: you can never bring in the test coordinator too soon. This individual will
need time to understand the project-specific business requirements.
 System complexity can have a huge multiplier effect on your estimates.
Estimating Technique Guide - Draft
31
2/5/2016
Estimating Technique Guide
 It is essential for the development staff to understand what “done” means before program
development begins. One definition of done: A developer is done with a module when all coding
has been completed, the code has been desk checked, the unit test plan has been completed and
executed, all software documentation has been completed, and peer (or management) reviews of
the code, test plan and results, and software documentation have been completed.
 Include time to account for miscellaneous development problem solving. These are generally
unanticipated problems. Consider conducting regular meetings with key staff to look forward for
unplanned tasks and potential workarounds.
 We occasionally forget to account for fixed support staff (architects, project managers, team
leaders) when we adjust end dates due to schedule slips.
 Avoid being too aggressive with complexity ratings. We generally rate programs as easy when
they really have a medium complexity.
 The time required to select a vendor, purchase hardware or software components, or implement
hardware or software components can impact the project schedule. Try to allow for these potential
schedule delays.
 A mix of application languages will impact the level of effort. Adjust your estimates accordingly.
 We typically under-estimate the number of interfaces, interface testing, legacy system
modifications, and legacy system testing.
 We typically under-estimate conversions and the effort to cleanse the data. You may want to
consider timeboxing manual data conversions. Data quality will be low and you could expect to
have to cleanse 75% of the data.
 We typically under-estimate or forget to estimate the effort needed to create a physical data design
and to physically place the data on the server.
 Be sure to identify and inventory interfaces and conversion programs.
 We should determine if legacy system retirement is within the scope of the project. New systems
rarely map directly to the systems that they are replacing. The effort to completely retire a legacy
system is much more than just developing a new one.
 Performance Testing:
 We typically under-estimate or forget to estimate stress and performance testing efforts.
 We also need to differentiate between benchmarking and performance testing.
 Need to have target performance levels from the client. The performance levels should focus
on business functionality not screen or program response.
 Need to estimate the effort for selecting , purchasing, and training in the use of performance
tools.
 Need to estimate the performance testing architecture and infrastructure.
 Hint: Simulate an realistic system loading during user acceptance testing. This will slow down
performance during early user acceptance testing so the client does not develop unrealistic
expectations for the system’s final response time.
 Conduct pre-development walkthroughs to identify potential performance problems before the
application is built.
Estimating Technique Guide - Draft
32
2/5/2016
Estimating Technique Guide
Accelerated Application Development (X/AD)
General Information
The following guidelines are based on two X/AD client/server projects; they provide a high-level structure
for composing a project plan. Both of these projects were 1 year in duration. The technology employed on
these projects was PowerBuilder for the GUI development, C for the server development, a UNIX database
server, and a 2-teir client/server design.
Estimating Techniques, Tools, and Templates
Estimating techniques that apply to an XAD effort include comparative, expert judgment, and widget
counting. We have not tried to use any of the estimating tools, discussed in the prior section, for estimating
an XAD engagement. We have developed two XAD estimating templates, one that supports a single
application and one that supports multiple applications.
Estimating Rules of Thumb
BSD Estimating Guidelines:
The goal of the BSD phase was to develop a proof of concept prototype of the application, design the
business processes, define the logical database design, and to design the architecture of the application.
The BSD was completed in 12 weeks. The phase was broken down as follows:
 Six weeks for business process design, prototype development, and data design.
 Six weeks for application architecture design, common object definition, database creation,
development environment setup, and development estimating.
The BSD phase was staffed with a Project Manager, Systems Architect, Team Leads, Data Modeler,
and a DBA.
Estimating Technique Guide - Draft
33
2/5/2016
Estimating Technique Guide
Timebox Estimating Guidelines:
The duration of each timebox was 5-6 weeks; four weeks for development and 1-2 weeks for testing
and delivery to the users for acceptance testing. While the development for a timebox was underway,
the users were completing acceptance testing for the previous timebox.
The project team consisted of one or more team leads, each with 3-4 developers. A team lead is NOT
responsible for any development. Their time is consumed by managing the developers, planning the
next timebox, and assisting the users in acceptance testing. A project should assign as many
development teams (1 team lead with 3-4 developers) as the project needs. There was also a full-time
DBA, part-time logical data modeler, full-time project manager, full-time systems architect, and fulltime test coordinator.
During the application architecture design in BSD, the number of timeboxes for applications
development was defined. The application estimates were prepared using ICD estimating guidelines.
Common objects and application frameworks were developed in the first timebox. Subsequent
timeboxes contained the development work in a logical sequence based on the work to be done. Each
timebox contained a mixture of simple and complex tasks based on the level of experience of the staff.
Note: No developer should have a task that lasts more than two weeks.
After the timeboxes for new development were defined, one additional timebox was added to the
schedule. This timebox was used to complete user change requests, bug fixes, enhancements, and any
schedule overruns.
Integration Testing Estimating Guidelines:
After completing all of the timeboxes, an integration testing phase was completed. This phase was
used for performance tuning, final user acceptance, data conversion, user training, and business site
preparation. (Note: If four or fewer timeboxes were used, the integration testing phase should be
equal to two timeboxes (10-12 weeks). If more than four timeboxes were used, this phase should be
equal to three timeboxes (15-18 weeks.)
The project staff consisted of:
Project Manager
System Architect
All the team leads
Half of the development staff
DBA
Success Factors

It is critical to have a test coordinator on staff as soon as possible so that he or she understands the
business rules of the application. The user test plans should be business rule based, so that you are
testing the application from the end user’s perspective and not the developer’s perspective.

Having a prototype to show the user community the proof of concept and then get sign-off on the
prototype, helps to better estimate the size of the project.

The users are completing acceptance testing concurrent with development. They are testing the
deliverable from the previous timebox.

Having the data model defined ahead of development helped out greatly. This is not to say there
won’t be any changes to the data model along the way, but it avoids slowing down development
while the data model is created.
Estimating Technique Guide - Draft
34
2/5/2016
Estimating Technique Guide

It is critical to have a System Architect during the design phases and then guide the development
team to make sure the entire application works together. This person should review all developed
software for consistency, adherence to standards, and usability. The System Architect should be
on the project until the system is deployed.
Cautions
None have been identified.
Estimating Technique Guide - Draft
35
2/5/2016
Estimating Technique Guide
Organizational Change
General Information
The following estimating guidelines were collected during one of our field visits. You will need to adjust
these to fit your specific project environment.
Estimating Techniques, Tools, and Templates
The current estimating techniques being used for estimating organizational change include comparative,
expert judgment, proportional, and widget counting. None of the estimating tools, discussed in the prior
section, appear to address organizational change activities. We have developed two estimating templates.
One that can help estimate the effort to design and deliver communication events, and a second that can be
used to estimate the number of stakeholder groups.
Estimating Rules of Thumb
(Note: The following estimating rules of thumb have been collected from a variety of sources including an
Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field
visits. Not all of these have been confirmed or validated.)
The following guidelines are intended to provide a high-level idea of the amount of time required. You will
need to adjust these estimates based on your project and team-related experience.
Organizational Change as an overall level of effort:

One person, 50% of time, for the duration of the project. Expect the Subject Matter Expert to
spend most of his or her time during the phase transitions (beginning and end of each phase.)

A minimum of 5% of the overall effort to a maximum of 40% of selected project phases. For
a systems integration project, use a proportional estimate of 10% - 15% of the overall effort.
Communication Plans:
The following formula can be used to estimate the effort to design and deliver communication events.
The complexity of the engagement, the types of communication vehicles, the general readiness for
change, and the length of the engagement are all factors that can influence this estimate.
(# of stakeholder groups * # of project phases * # of hours per event * # of stages of acceptance)
Notes:

Estimating the number of stakeholder groups is discussed later in this section.

Two guidelines have been given for estimating the hours per event. These guidelines
include planning, designing, developing, approving, and deploying the communication
event.
1.
Two days to plan, design, approve, and execute an event. (This does not apply
to a very sophisticated event such as a video component.)
2.
An average of 4 to 20 hours per change enabling communication event.
 The number of stages of acceptance is 5.
Another formula for estimating the amount of time required for change enabling communication
follows. This formula guideline includes the time required ( in days) to plan, design, draft, and deploy
the communication.
(Effort = F * S * P * J)
where:
F = Complexity factor as calculated below
S = Number of stakeholder groups
P = Number of project phases (example, ETP and Requirements/BAA equals two phases)
J = Judgment factor (use 5 for low-end, 10 for average, and 15 for high-end complexity)
Estimating Technique Guide - Draft
36
2/5/2016
Estimating Technique Guide
To compute the Complexity Factor (F), use the following table to categorize the degree of change,
anticipated resistance, type of change and number of stakeholder groups. Multiply the factor for
each category to determine the complexity factor.
Degree of
Change
Anticipated
Resistance
Type of Change
Minor
1.0
No Resistance
1.0
Anticipated Change
1.0
Number of
Stakeholder
Groups
1 - 9 stakeholder groups
1.0
Moderate
1.2
Some Resistance
1.2
Tactical (business
unit)
1.2
10 - 25 groups
1.2
Major
1.4
Much Resistance
1.4
Strategic (organization)
1.4
More than 25 groups
1.4
Example 1: Assume the change is minor, with some resistance anticipated, for a tactical
change, and 7 stakeholder groups are involved -- the complexity factor (F) would be 1.0 x 1.2
x 1.2 x 1.0 = 1.44. Using this factor, we could estimate the effort during a Requirements/BAA
to equal about 100 days.
(Effort = F x S x P x J -- or -- 1.44 x 7 x 1 x 10 = 100)
Example 2. Assume the change is major, with much resistance anticipated, for a strategic
change, and 12 stakeholder groups have been identified -- the complexity factor (F) would be
1.4 x 1.4 x 1.4 x 1.2 = 3.95. Using this factor, we could estimate the effort during a
Requirements/BAA to equal about 475 days. (Effort = F x S x P x J -- or -- 3.95 x 12 x 1 x
10 = 475)
Stakeholder Groups:
The following guidelines have been defined for estimating the number of stakeholder groups.

Minimum number of stakeholder groups for a small engagement is 4 (executive sponsors, project
management, project team, and impacted business unit.)

Minimum number of stakeholder groups for an enterprise-wide engagement is 6 (executive
sponsors, project management, project team, extended project team, subject matter experts, and
organization as a whole.)

To calculate the lower boundary of the number of stakeholder groups: divide the number of fulltime project team members (FTEs including client staff) by four and add two. ((project team FTEs
/ 4) + 2)

To calculate the upper boundary of the number of stakeholder groups: divide the number of fulltime project team members by two and add four. ((project team FTEs / 2) + 4)

To estimate the number of stakeholder groups bases on the company size and percent of employees
impacted by the change use the following tables to multiply the size (CS) factor by the percent of
organizational change (PO) factor:
Company
Size
CS factor
100
500
1,000
5,000
10,000
50,000
100,000
500,000
2
3
4
5
6
7
8
9
Percent of Organization
Impacted by Change
PO factor
Estimating Technique Guide - Draft
Up to 10%
10 to 30%
25 to 80%
50 to 100%
1
2
3
4
37
2/5/2016
Estimating Technique Guide
For example: Your client has approximately 5,000 total employees. The project is expected to
only impact the corporate office, which accounts for 20% of the company. The estimated number
of stakeholder groups is 10. (CS (5) * PO (2) = 10)
Roles and Responsibilities:
Assuming that your are creating a role (job description) from scratch and have some starting material,
use 4 hours per role as a guideline. This can range from as low as 2 hours to as high as 12 hours per
role.
Training and Education
Assuming the forum will be traditional, instructor-led training, use a guideline of 10 hours of
development time for each hour of delivery. This could range as high as 80 hours of development time
per hour of delivery for world-class instructor script and participant guides.
Cautions
None have been identified.
Technical Infrastructure
No specific estimating guidelines have been identified at this time.
Critical Computer Resources and Facilities Infrastructure
No specific estimating guidelines have been identified at this time. Critical Computer Resources may be
estimated
Critical Computer resource planning and estimating is an on-going activity, conducted at startup, testing,
implementation, and deployment. It is accomplished in conjunction with preparing and updating of the
Project Management Plan and the Software Development Plan. The planning and analysis of computer
resource use should be conducted monthly as an integral part of the project performance and exercised in
conjunction with ongoing project tracking and oversight.
Computer resources planning, acquisition, and use one monitored in project startup and performance
tracking activities. The prime objective is to develop a plan for estimating and acquiring computer resources
and then to analyze the use so that hardware requirements are satisfied.
Steps for Planning/Estimating are:
1.
At project start up, the PM conducts a meeting with all section managers of all key activities.
2.
Each section manager identifies their staff’s roles and responsibilities, directs correlating staff
duties and skills and computer resource use.
3.
The attendees review the estimated resource use and the responsibilities for all technical and
administrative personnel. The review considers the type of equipment for all personnel and the
peak periods of performance for all devices or units.
Review and analysis are dictated by the types of activities (e.g., terminal access, word processing,
database, financial spread sheets). The equipment is then listed in direct relationship to the staff
and contract performance.
In addition, the task order team and contract staffing (if applicable) consider the work allocation
and equipment needs that were planned into the task order performance. The hardware acquisition
Estimating Technique Guide - Draft
38
2/5/2016
Estimating Technique Guide
will be a part of the project, standard contract and task order negotiation (if applicable). The
planning and estimation for production or development hardware platforms will be developed in
accordance with hardware feasibility and sizing studies that are included in task performance
criteria.
If a new project or new task order requires new hardware, all documents and planning materials
developed in previous stages are used for project, task order and computer resource planning. In
addition, a current hardware configuration from a system specification and a current hardware use
report from the Operations and Maintenance Team may be used.
The current Hardware Acquisition Plan from the Software Development Plan and project/ontract
budget provide insight to the equipment that is available and what new equipment is planned for
the future.
The computer resources acquisition plans for a task order is built to reflect any required increase in
current or planned contract hardware capabilities; a simpler update is developed for the task or
contract budget. The project/task order plan is then used to update the contract and site plans for
hardware acquisition.
4.
The Analysis and Design Manager maps the acquisition strategy against the staffing profile or an
existing plan to develop a new resource acquisition plan and budget.
5.
The Analysis and Design Team manager maps the acquisition strategy on a timeline. The timeline
developed and provided to the section managers for review.
6.
The Analysis and Design Manager review the plan with the PM and the accounting and finance
personnel. The plan is used to update the planned hardware expenditure for the contract.
7.
The system administrators monitor the use of critical computer resources and report the use to the
PM monthly as the project progresses.
8.
The Project Manager and the section managers review the use report to analyze use of memory and
the storage, usage of network, channel capacity, and device capacity. The current use of resources
is compared to acquisition of future resources, adjustments are made to the acquisition plans, and
changes are proposed to the client.
Management and Coordination
Specific estimating guidelines have not be developed for this phase at this time. In general, the total
management and coordination effort should be approximately 15% to 20% of the total project effort. A
common guideline is to use a 1 to 6 ratio. During our field support visits, we generally used a staff and
duration model to estimate development coordination, project management, and program management. If
the team lead activities have not been included in the other project phases, be sure to include them here.
Estimating Technique Guide - Draft
39
2/5/2016
Estimating Technique Guide
Appendices
Estimating Templates
Please refer to the additional file attachments for these spreadsheets. If you did not receive these file
attachments or if you have any questions on how to use these spreadsheets, please contact any of the
Estimating and Metrics team members.
Estimating Template User Guides
The following user guides provide some general directions on how to use each of the estimating templates.
Staff and Duration Estimating Templates
Two estimating spreadsheets have been provided. One allows for a single resource group, such as the entire
project team. The second allows for two resource groups, such as IT Services and the client staff. Each
spreadsheet allows you to compute the total hours and cost by project team role. Each spreadsheet
calculates the total hours and cost for each role, provides grand totals for staff count, hours, and cost, and
computes an average billing rate.
The user defined fields are in “blue”. The spreadsheet that allows for two groups of resources provides subtotals for each group along with aggregated totals. Either of these spreadsheets can be tailored to your
specific estimating needs. Potential customization options include:

Modifying the IT Services and Client spreadsheet to represent billable and non-billable effort.

Modifying either spreadsheet to specify hours and costs by project phase, timebox, release, or
development build.
To use these spreadsheets:
1.
Enter the duration to hour conversion factor. This cell is used to calculate hours based on the
duration that you have entered. The duration used in the template is weeks, so the duration to hour
conversion factor has been set to 40 hours.
2.
For each unique project role, enter a role description, the number of resources (count), the length
of duration, and the hourly billing rate for this role. Add or delete roles as needed.
Travel Expenses Template
This spreadsheet provides you with two options for estimating travel related expenses. The first worksheet.
Option 1, allows you to identify the project’s duration (in weeks), team size, and the estimated expenses for:
airfare, lodging, cab/ auto, meals, parking, and miscellaneous expenses. Totals are provided of each
category; these are calculated based on the weekly expense amount, project duration, and team size. A
grand total is also provided. The second worksheet, Option 2, allows you to specify the above expense
categories and project duration on an individual by individual basis. This worksheet provides total weekly
and project expenses by individual. It also provides totals for each expense category , the overall project,
and computes an average weekly travel expense based on the total project expenses and the total number of
weeks. Either of these worksheets can be easily customized to meet your specific project requirements.
Requirements/BAA Proportional Estimate Projection Template
This spreadsheet projects the hours for the remaining phases of a project based on the actual hours from the
Requirements/BAA phase. It is based on the assumption that a Requirements/BAA accounts for 7% to 10%
of the total project effort. Simply enter the actual hours from the Requirements/BAA and the spreadsheet
projects the remaining project effort based on 7%, 8.5%, and 10% scenarios. You can modify the
proportional factors or add additional scenarios. The template assumes a custom (ICD) development
approach.
Estimating Technique Guide - Draft
40
2/5/2016
Estimating Technique Guide
Package-Based Development (PBD) Estimating Template
Two estimating templates are provided; one supports a single package-based application, the second
supports multiple applications. Each template allows you to identify the key activities and work products
for each of the package-based sub-phases. For each activity or work product, you can specify the number of
units, the estimated effort for each unit, the number of staff working on each activity or work product, and
any estimating assumptions or comments. The spreadsheet will compute the total estimated effort of each
activity and provide totals by sub-phase. These totals are linked to a summary worksheet that provides a
high-level overview of your estimates. You can also apply a proportional level of effort for the integration
and deployment phases. The project management and coordination phases can be estimated based on a staff
and duration template, included in the spreadsheet, or by using a proportional level of effort.
Both estimating templates consist of a spreadsheet with multiple worksheets that allow to you enter the
necessary details and summarize the overall results. One spreadsheet supports a single package-based
application. The other supports multiple applications. The user defined fields are in “blue”. Either of these
spreadsheets can be easily customized to fit your specific project needs.
Single Application Spreadsheet:
This spreadsheet contains three worksheets.
1.
The estimate total worksheet, Est Ttl, summarizes the project sub-phases, calculates the subphase’s percentage of the overall estimate, and displays the total estimated hours.
2.
The package-based development detail worksheet, PBD Details, contains all of the estimating
details by sub-phase. Use this worksheet to enter the key activities, deliverables, estimating
drivers, and comments for each sub-phase. The worksheet will provide sub-totals for each subphase and an overall estimate. The sub-totals are automatically linked to the estimate total
worksheet.
3.
The management and development coordination worksheet, Mgmt, allows you to enter a staff and
duration estimate for this effort. The total management and development coordination hour
estimate is automatically linked to the estimate total worksheet.
To use this estimating template:
1.
Complete the PBD Details worksheet:
a)
Enter the estimating details on the PBD Details worksheet. The template contains some general
activities for each of the package-based development sub-phases. Modify these activities to meet
your specific project requirements. Define the key deliverables, estimating drivers, and comments
for each activity. The estimating drivers should include:

The unit of measure; such as a workshop, business function, timebox, or package.

The number of units.

The estimated effort to complete each unit.

The average number of staff involved in completing the activity.
b) For the team leadership activity, enter the number of staff being managed and the percentage of
team lead responsibility.
(Note: Another option would be to include the team lead activities in the management
and development coordination worksheet.)
c)
2.
The worksheet will calculate sub-totals for each sub-phase and provide an overall summary at the
bottom of the worksheet. The summary contains both hours and a percentage of the total effort.
These hour totals are automatically linked to the estimate total worksheet.
Complete the Mgmt worksheet:
a)
Complete the staffing and duration template for the management and development coordination
effort. For each role, enter a description, number of staff, and duration. The template currently
Estimating Technique Guide - Draft
41
2/5/2016
Estimating Technique Guide
assumes that the duration is specified in 40 hour weeks. Adjust the hour computation to meet your
specific requirements.
b) The worksheet will compute the total management and development coordination hours and
automatically link this total to the estimate total worksheet.
3.
Complete the Est Ttl worksheet:
a)
Define the hour conversion factor; cell P3. This conversion factor is currently defined as 8 hours
to convert the hour estimate to man-days. If you prefer to have man-months or man-years, adjust
this factor accordingly.
b) Enter the proportional factors for Integration and Deployment. The percentages currently defined
in the worksheet are for illustration purposes only.
c)
As a option, you can define the management and coordination effort as a proportional factor;
similar to the Integration and Deployment project phases rather than using a staff and duration
estimate. To do this, enter the appropriate proportional factor and adjust the cell formula for the
phase hours accordingly.
Multiple Application Spreadsheet:
This spreadsheet contains the same three worksheets as the single application spreadsheet plus an additional
summary worksheet. This additional worksheet, PBD Summary, provides an hour and percentage summary
for each application.
To use this estimating template, use the steps outlined for the single application spreadsheet. The only
difference is in the PBD Details worksheet. This worksheet allows you to enter detailed estimating
information for each application area. The template currently allows for 3 application areas. You can
adjust the Est Ttl, PBD Summary, and PBD Detail worksheets to add or subtract application areas.
Matrix-Based Iterative Custom Development (ICD) Estimating Template
Two estimating templates provided; one supports a single iterative custom-developed application, the
second supports multiple applications. Both templates allow you to build a bottom-up estimate based on the
number of “widgets” being developed. These widgets can include menus, reports, windows, servers,
interfaces, conversions, common objects. As you define each of these widgets, you can rate the complexity
of each widget on a scale from 1 to 10. The detail matrix worksheet references additional look-up tables
that contain the appropriate estimates based on the type of widget and its complexity. You can adjust these
look-up tables to reflect your specific project environment. The spreadsheet accumulates totals for each
type of widget and links these totals to a summary worksheet to provide a high-level summary of your
estimates. You can also apply a proportional level of effort for the business system design, application
development completion, integration and deployment phases. The project management and coordination
phases can be estimated based on a staff and duration template, included in the spreadsheet, or by using a
proportional level of effort.
Both templates consist of a spreadsheet with multiple worksheets that allow to you enter the necessary
details and summarize the overall results. One spreadsheet supports a single custom-developed application.
The other supports multiple applications. The user defined fields are in “blue”. Either of these
spreadsheets can be easily customized to fit your specific project needs.
Single Application Spreadsheet:
This spreadsheet contains four worksheets.
1.
The estimate total worksheet, Est Ttl, summarizes the project sub-phases, calculates the subphase’s percentage of the overall estimate, and displays the total estimated hours.
2.
The program matrix worksheet, PGM Matrix, defines and categories all of the widgets that need to
be developed. The template currently allows for menus, windows, reports, C functions, Tuxedo
Estimating Technique Guide - Draft
42
2/5/2016
Estimating Technique Guide
services, interfaces, conversions, Oracle forms, and common functions. Use this worksheet to
enter the widgets that need to be developed for each category. The worksheet will provide subtotals for each category and an overall total. The sub-totals are automatically linked to the estimate
total worksheet.
3.
The management and development coordination worksheet, Mgmt, allows you to enter a staff and
duration estimate for this effort. The total management and development coordination hour
estimate is automatically linked to the estimate total worksheet.
4.
The estimate matrices worksheet, EST Matrices, contains estimating matrices for a variety of
different types of widgets. For each type or category of widget this worksheet contains estimates
for 10 levels of complexity, level 1 being the simplest and level 10 being the most complicated.
The program matrix worksheet uses these estimate matrices as a look-up table. For example, if
you enter a PowerBuilder window with a complexity level of 5 on the program matrix worksheet;
that worksheet will reference the PowerBuilder estimate matrix and retrieve the per unit estimate
for a level 5 complexity window.
To use this estimating template:
1.
Complete the PGM Matrix worksheet:
a)
Enter the widgets that need to be developed into the appropriate categories. For each entry you
can specify the name of the widget, cross-reference information, the number of units, and its level
of complexity on a scale of 1 to 10. The worksheet will retrieve the per unit estimate from the
estimate matrices worksheet, compute a total hour and day estimate based on the number of units
specified, and calculate totals. Category and overall totals are provided.
b) The categories contained on this template can be modified to meet your specific project.
Additional categories can also be created if needed. If you do modify or add additional categories,
corresponding changes will also need to be made to the other worksheets.
(Caution: The per unit estimate column in this worksheet is extremely sensitive with
the row and column coordinates within the estimate matrices worksheet. Be
careful that you have defined the correct row and column coordinates when
modifying this column.)
2.
Complete the Mgmt worksheet:
a)
Complete the staffing and duration template for the management and development coordination
effort. For each role, enter a description, number of staff, and duration. The template currently
assumes that the duration is specified in 40 hour weeks. Adjust the hour computation to meet your
specific requirements.
(Note: Be sure to include the team lead activities in this worksheet. They have not
been accounted for in the prior worksheet.)
b) The worksheet will compute the total management and development coordination hours and
automatically link this total to the estimate total worksheet.
3.
Complete the Est Ttl worksheet:
a)
Define the hour conversion factor; cell P3. This conversion factor is currently defined as 8 hours
to convert the hour estimate to man-days. If you prefer to have man-months or man-years, adjust
this factor accordingly.
b) Enter the proportional factors for the BSD, ADC, Integration, and Deployment phases. The
percentages currently defined in the worksheet are for illustration purposes only.
c)
As a option, you can define the management and coordination effort as a proportional factor;
similar to the Integration and Deployment project phases rather than using a staff and duration
estimate. To do this, enter the appropriate proportional factor and adjust the cell formula for the
phase hours accordingly.
Estimating Technique Guide - Draft
43
2/5/2016
Estimating Technique Guide
Multiple Application Spreadsheet:
This spreadsheet contains the same worksheets as the single application spreadsheet plus two additional
worksheets:
1.
An ICD Summary worksheet that provides an hour and percentage summary for each application.
2.
An additional ICD Matrix worksheet for a second application area.
To use this estimating template, use the steps outlined for the single application spreadsheet. Repeat the
ICD Matrix steps for each application area. The template currently allows for 2 application areas. You can
adjust the spreadsheet to add more application areas.
Accelerated Application Development (XAD) Estimating Template
Two estimating templates are provided; one supports a single XAD-based application, the second supports
multiple applications. Each template allows you to identify the key activities and work products for each of
the XAD-based sub-phases. For each activity or work product, you can specify the number of units, the
estimated effort for each unit, the number of staff working on each activity or work product, and any
estimating assumptions or comments. The spreadsheet will compute the total estimated effort of each
activity and provide totals by sub-phase. These totals are linked to a summary worksheet that provides a
high-level overview of your estimates. You can also apply a proportional level of effort for the integration
and deployment phases. The project management and coordination phases can be estimated based on a staff
and duration template, included in the spreadsheet, or by using a proportional level of effort.
Both estimating templates consist of a spreadsheet with multiple worksheets that allow to you enter the
necessary details and summarize the overall results. One spreadsheet supports a single XAD-based
application. The other supports multiple applications. The user defined fields are in “blue”. Either of these
spreadsheets can be easily customized to fit your specific project needs.
Single Application Spreadsheet:
This spreadsheet contains three worksheets.
1.
The estimate total worksheet, Est Ttl, summarizes the project sub-phases, calculates the subphase’s percentage of the overall estimate, and displays the total estimated hours.
2.
The XAD-based development detail worksheet, XAD Details, contains all of the estimating details
by sub-phase. Use this worksheet to enter the key activities, deliverables, estimating drivers, and
comments for each sub-phase. The worksheet will provide sub-totals for each sub-phase and an
overall estimate. The sub-totals are automatically linked to the estimate total worksheet.
3.
The management and development coordination worksheet, Mgmt, allows you to enter a staff and
duration estimate for this effort. The total management and development coordination hour
estimate is automatically linked to the estimate total worksheet.
Estimating Technique Guide - Draft
44
2/5/2016
Estimating Technique Guide
To use this estimating template:
1.
Complete the XAD Details worksheet:
a)
Enter the estimating details on the XAD Details worksheet. The template contains some general
activities for each of the package-based development sub-phases. Modify these activities to meet
your specific project requirements. Define the key deliverables, estimating drivers, and comments
for each activity. The estimating drivers should include:

The unit of measure, such as a prototype set, business function, or entities.

The number of units.

The estimated effort to complete each unit.

The average number of staff involved in completing the activity.
b) For the team leadership activity, enter the number of staff being managed and the percentage of
team lead responsibility.
(Note: Another option would be to include the team lead activities in the management
and development coordination worksheet.)
c)
2.
The worksheet will calculate sub-totals for each sub-phase and provide an overall summary at the
bottom of the worksheet. The summary contains both hours and a percentage of the total effort.
These hour totals are automatically linked to the estimate total worksheet.
Complete the Mgmt worksheet:
a)
Complete the staffing and duration template for the management and development coordination
effort. For each role, enter a description, number of staff, and duration. The template currently
assumes that the duration is specified in 40 hour weeks. Adjust the hour computation to meet your
specific requirements.
b) The worksheet will compute the total management and development coordination hours and
automatically link this total to the estimate total worksheet.
3.
Complete the Est Ttl worksheet:
a)
Define the hour conversion factor; cell P3. This conversion factor is currently defined as 8 hours
to convert the hour estimate to man-days. If you prefer to have man-months or man-years, adjust
this factor accordingly.
b) Enter the proportional factors for Integration and Deployment. The percentages currently defined
in the worksheet are for illustration purposes only.
c)
As a option, you can define the management and coordination effort as a proportional factor;
similar to the Integration and Deployment project phases rather than using a staff and duration
estimate. To do this, enter the appropriate proportional factor and adjust the cell formula for the
phase hours accordingly.
Multiple Application Spreadsheet:
This spreadsheet contains the same three worksheets as the single application spreadsheet plus an additional
summary worksheet. This additional worksheet, XAD Summary, provides an hour and percentage summary
for each application.
To use this estimating template, use the steps outlined for the single application spreadsheet. The only
difference is in the XAD Details worksheet. This worksheet allows you to enter detail estimating
information for each application area. The template currently allows for 3 application areas. You can
adjust the Est Ttl, XAD Summary, and XAD Detail worksheets to add or subtract application areas.
Communication Event Estimating Template
This estimating template assists in estimating the effort to design and deliver communication events. The
spreadsheet contains two worksheets, each represents an estimating option. The first worksheet, Option 1,
Estimating Technique Guide - Draft
45
2/5/2016
Estimating Technique Guide
allows you to estimate the hours needed to design and deliver communication events based on the number
of stakeholder groups, number of project phases, the estimated hours per event, and the number of stages of
acceptance. To use this worksheet, simply enter the correct values. The estimated effort in is hours and is
based on the calculations described in the Organizational Change estimating guidelines.
The second worksheet, Option 2, allows you to estimate the effort based on four complexity factors, number
of stakeholder groups, number of project phases, and a judgment factor. To use this spreadsheet, select the
desired values from each of the four complexity factor tables. These tables are used to categorize the
degree of change, the level of anticipated change, the number of stakeholder groups (within a range), and
the type of change. Next enter the actual number of stakeholder groups, the number of project phases, and a
judgment factor. The worksheet will calculate the estimated hours for designing and delivering
communication events based on the calculations described in Organizational Change estimating guidelines.
Stakeholder Group Estimating Template
This estimating template assists in estimating the number of stakeholder groups. The spreadsheet contains
two worksheets. The first worksheet, Team Size, allows you to estimate the number of stakeholder groups
based on the size of the project team. To use this worksheet, simply enter the project team size in full-time
equivalents. Fractional sizes are permitted. This worksheet will provide a low-end, high-end, and average
estimated number of stakeholder groups based on the calculations described in the Organizational Change
estimating guidelines.
The second worksheet, Client Size, allows you to estimate the number of stakeholder groups based on the
overall size of the client and the percentage of organizational impact. To use this worksheet, simply select
the appropriate client size by entering a “1” in the correct category. You can only make one selection.
Next select the percentage of organizational impact by entering a “1” in the correct category. Again, you
can only select one category. The worksheet will compute the estimated number of stakeholder groups
based on the calculations described in the Organizational Change estimating guidelines.
Estimating Technique Guide - Draft
46
2/5/2016