P. 1
Estimating Techniques Guide

Estimating Techniques Guide

|Views: 69|Likes:
Published by phanindrakishore
Estimation
Estimation

More info:

Categories:Types, Research
Published by: phanindrakishore on Feb 26, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

02/26/2013

pdf

text

original

Sections

  • Introduction
  • Estimating Approaches
  • Top-Down Estimating Approach
  • Bottom-Up Estimating Approach
  • Estimating Approach Comparison
  • Estimating Techniques
  • Ballpark Estimating
  • Proportional Percentage Estimating
  • Comparative
  • Expert Judgment
  • Proportional Estimating
  • Widget Counting
  • Function Point Analysis
  • Feature Points
  • Technique Comparison
  • Estimating Technique Comparison
  • Managing Multiple Estimates
  • Wideband Delphi Technique
  • Weighted or Average Estimate
  • Commercially Available Estimating Tools
  • CHECKPOINT/KnowledgePLAN
  • Overview
  • Estimating Templates
  • General Purpose Templates
  • Staff and Duration Estimating Template
  • Travel Expenses Template
  • Requirements/BAA Proportional Estimate Projection Template
  • ASPIRE Phase Templates
  • Vision and Strategy
  • Business Area Architecture
  • Development
  • Integration
  • Deployment
  • Specialty Area Templates
  • Package-Based Development (PBD) Estimating Template
  • Matrix-Based Iterative Custom Development (ICD) Estimating Template
  • Accelerated Application Development (XAD) Estimating Template
  • Organizational Change
  • Communication Event Estimating Template
  • Stakeholder Group Estimating Template
  • Technical Infrastructure
  • Facilities Infrastructure
  • Estimating Guidelines
  • Project-Wide Guidelines
  • ASPIRE Phase Guidelines
  • Vision and Strategy (ETP)
  • Business Area Architecture (Requirements/BAA)
  • Specialty Areas
  • Package Based Development (PBD)
  • Package Evaluation and Selection (PES) Sub-Phase
  • Iterative Custom Development (ICD)
  • Accelerated Application Development (X/AD)
  • Critical Computer Resources and Facilities Infrastructure
  • Management and Coordination
  • Appendices
  • Estimating Template User Guides
  • Staff and Duration Estimating Templates

Estimating Technique Guide

Estimating Technique Guide Version 1

Estimating Technique Guide - Draft

1

2/26/2013

Estimating Technique Guide

Estimating Technique Guide
Table of Contents Introduction_____________________________________________________________4 Estimating Approaches ____________________________________________________4
Top-Down Estimating Approach ________________________________________________5 Bottom-Up Estimating Approach ________________________________________________5 Estimating Approach Comparison_______________________________________________6

Estimating Techniques ____________________________________________________6
Ballpark Estimating___________________________________________________________6 Proportional Percentage Estimating______________________________________________7 Comparative_________________________________________________________________8 Expert Judgment______________________________________________________________8 Proportional Estimating________________________________________________________8 Widget Counting______________________________________________________________8 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 Accelerated Application Development (XAD) Estimating Template...............................................15 Organizational Change______________________________________________________________15

Estimating Technique Guide - Draft

2

2/26/2013

Estimating Technique Guide
Communication Event Estimating Template.....................................................................................15 Stakeholder Group Estimating Template...........................................................................................15 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_______________________________________________________________________21

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/26/2013

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 Approaches
There are two basic approaches for determining the estimates for a given component of a project, topdown 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

Estimating Technique Guide - Draft

4

2/26/2013

and travel related expenses. The total estimate is apportioned among the components.  The effort to develop a specific function of the completed software system. You can also adjust the hours per activity or task based on the required deliverables. For example.000 hours across the various activities and tasks that comprise a Requirements/BAA. Because of the level of detail required. Since this approach examines the project in much greater detail. lower-level components. Bottom-Up Estimating Approach Using this approach you first identify the low-level components of the project. examines each piece at a detail level. Since this approach looks at the entire project from a fairly high-level view. pagers. This estimating approach is helpful when you have relatively little knowledge of the project requirements or when the project is strictly limited by resources. or the project team’s expertise.  A non-labor item such as a product or service.000 hours. and then total the individual estimates to produce the overall project estimate. printers.  You need some basis for apportioning the overall project estimate across the various subcomponents. code and test the maintain customer address window. it requires more project related information and takes a longer time to develop the estimate. your prior project experience. development software. training. For example.  This approach offers little or no basis for the cost justification of subsequent estimating iterations. your bottom-up estimate is generally more accurate than your top-down estimate. Examples include preparing for or documenting workshops or interviews. if the client has a fixed budget. 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. you may have determined that the total effort for a Requirements/BAA phase is 1. You should also use other estimating methods to cross-validate your results. The definition of a low-level component can vary widely and is very dependent on the type of the project. Examples include PCs. Top-Down Estimating Approach Using this approach you divide an overall estimate into separate. estimate each of these components. and assembles all of the pieces and their estimates to come up with the overall project estimate. you can repeat this process to arrive at estimates for lower-level tasks. you can develop a top-down estimate in a relatively short period of time and with a minimal amount of project related information. For example. If any of the lower-level task estimates is too low you must adjust the top level estimate upward or change the scope of the project. A bottom-up estimating approach breaks the project into pieces. The starting point is an estimate of the size. developing an integration or application test plan. and creating a detail project plan for a subsequent project phase.Estimating Technique Guide into lower-level components. or tasks that make up the project. (Note: This is risky and not generally recommended. Depending on the size and complexity of the project. this estimating approach could be used to identify the level of work that could be delivered for that budget. 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. total effort. 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.Draft 5 2/26/2013 .  There is a tendency to define the scope in terms of the resources allocated rather than in terms of the activities or deliverables.) Disadvantages of this approach include:  You could miss low-level technical issues or special components of the system. or the time required to perform a project. Examples of a low-level component include:  The effort to produce an intermediate product or deliverable. Estimating Technique Guide . installation fees. You can than use an estimating model such as Project Bridge Modeler to apportion the 1.

• Need basis for proportioning estimates across project sub-components.Draft 6 2/26/2013 . training. • Has little or no basis for the cost justification of subsequent estimating iterations. Weaknesses • May miss low-level technical issues. • Tendency to define scope in terms of resources allocated rather than in terms of activities or deliverables. provided you haven’t forgotten anything. effort. • May overlook system-level costs such as integration. it can yield a more accurate estimate than a top-down approach. This approach also helps to identify uncertainties regarding the project requirements or proposed solution.) Estimating Approach Comparison The following diagram illustrates a high-level comparison between these two estimating approaches.  Activities such as management and development coordination cannot be estimated until the underlying task estimates are complete. Once the estimate is developed. a comparative estimate can be Estimating Technique Guide . • Identifies uncertainties in developers’ knowledge of system requirements or proposed solution. peak staff. This technique can be used at any point in the lifecycle. Estimating Techniques The following estimating techniques fit into either the top-down or bottom-up approach. • Requires significant effort to produce • Activities such as management and coordination cannot be estimated until underlying task estimates are complete. Bottom-Up • Enforces relatively thorough analysis before estimation. These uncertainties will often result in assumptions in the estimate and the project’s Statement of Work. are needed. Estimation Approach Strengths Top-Down • Particularly relevant if project is strictly limited by resources.Estimating Technique Guide One advantage of this approach is that it requires a relatively thorough analysis before you begin estimating.  It often requires more information than what is typically available at the time the estimate is required. you need to decide which technique is appropriate and what adjustments. and derived from the QSM SLIM completed projects database. It can be used early in the lifecycle and when no historical information is available. Since you need have a more detailed view of the project requirements when using this approach. Each row represents a consistent set of estimates that may be determined based on any one of the variables estimated using expert judgment.  It requires a significant effort to produce the estimate. each has its own strengths and weaknesses. • Often requires more information than is available at time of estimate. Ballpark Estimating With this estimating technique you use a combination of time. Disadvantages of this approach include:  You may overlook system-level costs such as integration or training. if any. (These tasks are generally estimated based on the duration of the project or as a percentage of the underlying tasks. No one estimating technique is ideal for all situations. • Relatively little knowledge of proposed system required. When estimating a project. • May omit special components of software system.

00% 6. If there are logical groupings of configuration items. the totals can be calculated.00% Estimating Technique Guide . close) .00% 27. Using the factors table. For example. Using the Business Case documentation.00% 5. and using expert judgment. it can be used to expand the known portion into a total estimate. Configuration Items. and Effort in Hours columns for guidance in determining each size estimate. Interfaces.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] Labor Distribution Standard for "Maintenance" Work Types Project Management (start-up. manage.Draft 7 2/26/2013 . If any portion of the labor distribution is estimated. The final estimates can be compared to other estimates for analysis. the Design effort might be estimated as 22% of the Requirements effort. There are different proportional models for different types of life cycles. 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.00% 9. Using the size and category within size. Time in Months.00% Maintenance 12.00% 8. close) . 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. and Testing/Pilot 33% of Requirements effort. At the same time the Category with Size can be determined. a proposed solution is visualized.Development/Enhancement Quality Assurance Reviews Maintenance Analysis (Requirements) [Solution Definition] Development/ Enhancement 15.00% 9. Estimates are developed using the Peak Staff. or Programs in the visualized solution can be identified and entered into Top Down Estimate by CI worksheet. After all Configuration Items are estimated. manage.00% 15. 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 Modules. Proportional Percentage Estimating With this estimating technique you use the size of one component to proportionally estimate the size of another.00% 18. For example: Labor Distribution Standard for "Development / Enhancement" Work Types Project Management (start-up. Construction 45% of Requirements effort. The group total can then be used for a single estimate for size (ESLOC). when the estimated value really does depend proportionally on another factor.00% 12. they may be numbered. The ESLOC estimate is based on 100 Lines of Code per Function Point.Estimating Technique Guide developed using a proportional technique. a size can be determined between Very Very Small and Very Large. The list of configuration items can be sorted by group and combined into a single estimate.00% 13. 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. This technique is very effective when used appropriately. which must be considered in developing proportional estimates. The groupings can then be used to combine individual configuration items into packages of work for estimation by group.

or programming a specific system component. Proportional estimates can be used in combination with other estimating techniques. it should be used only if time is limited or a relatively large uncertainty in the estimate can be tolerated.Estimating Technique Guide 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] 9. For example you have been asked to estimate the custom development for a new telecommunications system. you could develop a comparative estimate for the new telecommunications systems by doubling the actual effort from your reference project. Proportional Estimating With this estimating technique you use the size of one component to proportionally estimate the size of another. The major weakness of this technique is that a project is not thoroughly assessed. after using widget counting to derive the estimate for the Requirements phase of a project and then used proportional factors to estimate the Design. the design effort might be estimated as 40% of the coding effort. You can use this technique for lower-level tasks such as developing a reporting sub-system or a customer maintenance window. you identify project characteristics that can be counted and that are performed on a recurring basis (the “widget”). printer volume. you compare the project at hand.00% 15.00% 40. processor capacity. System and Integration Testing. Using this technique will magnify estimating errors being made elsewhere.Draft 8 2/26/2013 .00% Comparative Using this estimating technique. The comparison does not have to be at a project or phase level. Since this reference project covered roughly 50% of the functionality needed by the new system. Quality Assurance might be estimated as 3% of the total project effort. Previous personal experience or estimating guidelines can help provide these proportionality factors. Code/Unit Test. 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. when the estimated value really does depend proportionally on another factor. Typical widgets may be Estimating Technique Guide . However. with other projects similar in scope and type to produce an estimate. Widget Counting Using this estimating technique. For example. estimate the effort for each type of widget. the target project. Implementation. The comparison is normally performed at a high-level with little reference to detail. For example. It differs from the comparative technique in that the reference projects are not explicitly identified. Therefore. the number of printers might be estimated as one for every 6 users. 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.00% 4. and Deployment phases of the project. You could even add an additional percentage of effort to account for some of the unknowns in the new system.00% 18. You also happen to know of a similar type of project that was also custom developed. 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. This technique is very effective when used appropriately. it should not be used as a crutch to pass the estimating responsibility on to some other component.00% 5. and determine the total effort by applying these estimates against the total number of widgets.

windows. audit trails.  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. in terms of user functions rather than programs.  Inquiry—Each unique input/output combination. pages of documentation. even though the project is not necessarily made up purely of widgets. reports.  You must be able to produce an estimate for the effort of each widget type.) 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.Draft 9 2/26/2013 . data. Estimating Technique Guide . Adjusting this function point count based on the overall project complexity. complex) and weight the effort accordingly. However. 2. Translating the function point count to an effort estimate based on a function point delivery rate. Function Point Analysis is the basis for several automated estimating tools. A logical file may span many physical files (e. output display screens. requirement specifications. Decomposing the project or application into a defined set of function types.  Logical Internal File—Any logical group of data held by the system. index.g. developer’s skill level. output. with low algorithmic processing complexity. 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. or objects. maintenance.Estimating Technique Guide menu choices. The result of an inquiry may be a display/report or a transaction file that is accessible by the user. database fields. screens. in which the online user defines an inquiry as input and the system responds immediately with an output. (This is probably the most difficult step. medium.  Output—Any unique unit of data or control information that is procedurally generated by the system for the benefit of the user. and the organization’s line of business.  The effort to develop or complete the project must be reasonably proportional to the number of widgets. and overflow). and test cases. Function Point Analysis This estimating technique is suited for projects that are based on straightforward database input. This is typically done by using the comparative approach based on historical metrics data or by prototyping the implementation of one of the widgets. languages. This would include logical units forming part of printed reports. and messages. described below. 5. 4. and inquiry. database entities. The estimates can be developed from knowledge of the requirements without a detailed design solution being known. You may assign complexity factors to each type of widget (simple. Advantages for using Function Point Analysis include:   The project is viewed from the perspective of the user rather than the developer. Inputs exclude transactions or files that enter the system as a result of an independent process. Assigning a complexity to each of these function types. An input can originate directly from the user or from user-generated transactions from an intermediary system. files.. This includes database tables and records on physical files describing a single logical object. The basic steps involved in this estimating technique include: 1. This provides for a level of independence from the specific hardware platform. 3. that is. Tallying the function types and applying pre-defined weighting factors to these totals to drive a single unadjusted function point count. it is treated as a single logical internal file for sizing purposes. An inquiry is distinct from an output in that it is not procedurally generated.

Estimating Technique Guide  The use of Function Point Analysis is accepted internationally. function points. For typical management information systems. There is also a users group. we have not gathered any estimating guidelines or metrics for function point estimating. For real-time or highly algorithmic systems. which has established standards to help encourage consistency in counting function points. space systems. Feature Points This estimating technique is an extension to the function point analysis technique. there is little difference in the results between Function Points and Feature Points. As a result. Disadvantages for using this estimating approach include:     This approach does not accurately estimate systems that are largely algorithmic such as military systems. However. Since the concept of Function Point Analysis was developed with older technologies and development approaches. and therefore track. robotics. however. you should read one of the published books on this subject. The Function Point count for such systems totals only 60 to 80 percent of the Feature Point count. Note: Before using this estimating technique. the results can be significantly different between these two techniques. Formal training is needed before you can consistently count. Estimating Technique Guide . International Function Point Users Group (IFPUG).Draft 10 2/26/2013 . Function Points can be complicated to administer. process control. The use of function points is not widely accepted within IT Services. both techniques result in nearly the same number of “points”. and middleware. It involves adding a number of algorithms with an average complexity weight and changing the function point weighting in other areas. it is not certain how well this concept applies to newer technologies and development approaches such as object-oriented development. variations of Function Point Analysis are being developed to address the newer technologies and development approaches.

languages. robotics.  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.   Proportional Effective when estimated value really does depend proportionally on another factor (e. even though system is not necessarily made up purely of widgets. Identifies areas where requirements clarification is needed. and process control.Estimating Technique Guide Technique Comparison The following table highlights the strengths and weaknesses of these estimating techniques: Estimation Technique Comparative Strengths Estimate can be very accurate if a suitable analogy can be identified. configuration management). may not be repeatable by anyone other than the “expert”.  Estimating Technique Guide .  Expert Judgment Estimate can be extremely accurate.  Provides independence from hardware platform. user functions rather than programs.  Estimates can be developed from knowledge of requirements without a detailed design solution being known. perspective (e.  Identifies requirements tradeoffs. software management.Draft 11 2/26/2013 ..  Requires formal training.  Must be verified by another method. files).g.g.  Requires previous personal experience or experience-based guideline metrics for proportionality factors.  Often difficult to find comparable projects.  Magnifies size errors if widget effort estimates are incorrect.  Requires formal training.  High risk. developers’ skill at code efficiency.  Same strengths as Function Point Analysis.  Weaknesses Historical data repository required.  Does not yet have overall acceptance.  Single data point.  Consistency encouraged through established international standards for function point counting.. with added benefit of accounting for algorithms and internal processing complexity. not developer.  Does not accurately estimate systems that are largely algorithmic such as military systems. especially those using 4GL.  Assumes effort to develop system is proportional to number of widgets.  Does not have overall acceptance within IT Services. business of organization.  Project viewed from user. report writer.  Can be complicated to administer. or CASE tool environments. quality assurance.  Can magnify estimating errors made in other areas. space systems.  Can be complicated to administer.

This technique consists of the following steps: 1. 3. & ETP Business Area Architecture Development Integration Deployment Development Organizational Change Technical Infrastructure Facilities Infrastructue Year 2000 Development Coordination Project Management Program Management Not Recommended Recommended Optional/ Sanity Check Managing Multiple Estimates The following techniques can be used to manage multiple estimates. misunderstandings.Estimating Technique Guide Estimating Technique Comparison The following diagram illustrates the recommended estimating techniques for the various ASPIRE project phases. The basic goal of this technique is to achieve a more accurate and reliable composite estimate. Estimating Technique Guide . you have various degrees of confidence. 2.Draft 12 2/26/2013 . Wideband Delphi Technique When several estimators are estimating the same project or component. The experts independently develop estimates and give them to the coordinator. This can occur when you have used different techniques to estimate a project or component. the Wideband Delphi technique is useful to enforce convergence of the different estimates. The lead estimator calls a group meeting in which the experts discuss estimation issues. Vision & Stategy. or when you have multiple estimators. and incomplete knowledge. and management and coordination activities. Estimating Techniques Comparative Proportional Expert Judgement Widget Counting Function Point Analysis Feature Point Analysis Specialty Areas Project Phases Mgmt and Coord. specialty areas. thereby reducing the impact of individual biases. The lead estimator presents the same specification to each expert.

this formula will result in an estimate very close to the “realistic estimate”. In most of these tools. quality. 5. and technology assessment. quality estimating.  Estimate the cost of developing systems as well as the cost of developing specifications and user documentation.  Perform side-by-side comparisons of project versions. skills.. Weighted or Average Estimate The technique uses the following formula to derive an average estimate.  Aggregate data across selected projects.Draft 13 2/26/2013 . they have not been calibrated against IT Services projects so you need to apply some judgment when using these tools.g.. and steps 4–6 are repeated until a consensus is reached. and methodologies. Estimating Technique Guide . different projects. value analysis. or a project against other established benchmarks. The lead estimator analyzes the estimates and distributes a summary containing the estimates with their medians. It offers the capability to:  Predict source code size.  Measure all aspects of a software project at a user-defined level of granularity. estimating. measurement. CHECKPOINT integrates sizing. an algorithm is applied to the basic measure of size to produce an estimate of effort (e. evaluate. number of required personnel resources). 6.Estimating Technique Guide 4. and pessimistic is up to the individual(s) developing the estimate. scheduling. Experts review estimates. Commercially Available Estimating Tools There are a number of automated estimating tools available to support estimating efforts. and productivity. from Software Productivity Research Inc. risk analysis.  Perform what-if analysis for a variety of variables including CASE tools.700 software projects. In general. planning. 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. is a knowledge-based software management tool that can analyze. Although these tools have generally been calibrated using a wide range of historical project data at other companies within the industry. and store data about your development projects. schedules. CHECKPOINT/KnowledgePLAN Overview CHECKPOINT.  Estimate projects using a knowledge-base of over 4. Typically. realistic. languages. but excluding rationale. your realistic estimate will be what you feel is the most likely estimate. focusing on where estimates vary widely. The lead estimator calls a group meeting to discuss estimates. and your pessimistic estimate will be your conservative estimate. your optimistic estimate will be your aggressive estimate.  Assess a wide range of software attributes against industry standards for cost.

Business Area Architecture The Estimating and Metrics team currently does not have any templates specific to this ASPIRE phase.5%. Detailed instructions for using these spreadsheets are located in the appendix. Please refer to the Development estimating templates for a complete list. The generic Staff and Duration template could be used for this type of an engagement. provides grand totals for staff count. ASPIRE Phase Templates Vision and Strategy The Estimating and Metrics team currently does not have any templates specific to this ASPIRE phase. Integration Specific estimating templates have not been developed for this phase. and computes an average billing rate. such as the project team. Following is a high-level summary of the templates that the Estimating and Metrics team have obtained. 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. The various Development estimating templates generally use a proportional estimating factor for this phase. The generic Staff and Duration template could be used for this type of an engagement. The second option allows you to specify estimated travel expenses on an individual by individual basis. The spreadsheet calculates the total hours and cost for each role. 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. provide two staff and duration estimating templates. Development A number of estimating templates have been collected that support the Development phase of ASPIRE. The template assumes a custom (ICD) development approach. You simply enter the actual hours from the Requirements/BAA and the spreadsheet projects the remaining project effort based on 7%. and cost. created. The estimating templates. For example. It is based on the assumption that a Requirements/BAA accounts for 7% to 10% of the total project effort. hours. and 10% scenarios. such as IT Services and the client staff. The first option allows you to estimate these expenses as an average for the entire team. You can modify these factors or add additional scenarios. you can specify that there are 40 hours per week. 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.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.Draft 14 2/26/2013 . identify how many individuals will fill this role (fractional values are valid). or modified. contained in the file attachments. the other template allows for two resource groups. One template allows for a single resource group. if you are counting weeks in your duration. The general Staff and Duration estimating template can also be applied to this phase. 8. Travel Expenses Template This template provides you with two options for estimating traveling expenses. The actual spreadsheets have been attached as separate files. Estimating Technique Guide . and specify the duration and hourly billing rate for this role. The template allows you to define a project role.

These totals are linked to a summary worksheet that provides a high-level overview of your estimates.Draft 15 2/26/2013 . Accelerated Application Development (XAD) Estimating Template Two estimating templates are provided. The various Development estimating templates generally use a proportional estimating factor for this phase. included in the spreadsheet. The detail matrix worksheet references additional look-up tables that contain the appropriate estimate based on the type of widget and its complexity. interfaces. The general Staff and Duration estimating template can also be applied to this phase. You can also apply a proportional level of effort for the integration and deployment phases. the estimated effort for each unit. the number of staff working on each activity or work product. Two estimating options are included in this template. As you define each of these widgets. these guidelines are provided later in this document. conversions. or by using a proportional level of effort. 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. This template uses the calculations described in the Estimating Technique Guide . The spreadsheet will compute the total estimated effort for each activity and provide totals by sub-phase. included in the spreadsheet. Two estimating templates are provided. the second supports multiple applications. The project management and coordination phases can be estimated based on a staff and duration template. servers. These totals are linked to a summary worksheet that provides a high-level overview of your estimates. included in the spreadsheet. Each template allows you to identify the key activities and work products for each of the package-based sub-phases. You can also apply a proportional level of effort for the business system design. or by using a proportional level of effort. the second supports multiple applications. You can also apply a proportional level of effort for the integration and deployment phases. and any estimating assumptions or comments. The project management and coordination phases can be estimated based on a staff and duration template. For each activity or work product. and common objects. The spreadsheet will compute the total estimated effort for each activity and provide totals by sub-phase. you can specify the number of units. 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. The project management and coordination phases can be estimated based on a staff and duration template. integration and deployment phases. reports. For each activity or work product. or by using a proportional level of effort. 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. application development completion. the second supports multiple applications.Estimating Technique Guide Deployment Specific estimating templates have not been developed for this phase. and any estimating assumptions or comments. 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. windows. Specialty Area Templates Development Package-Based Development (PBD) Estimating Template Two estimating templates are provided. the estimated effort for each unit. the number of staff working on each activity or work product. Each template allows you to identify the key activities and work products for each of the XAD sub-phases. These widgets can include items such as menus. one supports a single iterative custom-developed application. one supports a single XAD application. one supports a single package-based application. you can rate the complexity of each on a scale from 1 to 10. you can specify the number of units.

simply enter the size of the project team in full-time equivalents. these guidelines are provided later in this document. Technical Infrastructure Specific estimating templates have not been developed for this specialty area. To estimate the number of stakeholder groups based on the overall client size.Draft 16 2/26/2013 . you need to select the appropriate client size and percentage of organizational impact from the respective tables.Estimating Technique Guide Organizational Change estimating guidelines. Facilities Infrastructure Specific estimating templates have not been developed for this specialty area except for Critical Computer Resources. Estimating Technique Guide . To estimate the number of stakeholder groups based on the project team size.

specialty areas. and management and coordination activities. Specialty Areas. if you are trying to estimate an Enterprise Transformation Plan.Draft 17 Development Coordination Business Architecture Project Management Deployment Program Management Integration Process Initiative 2/26/2013 . you need to understand the scope. (Note: In most cases you will be developing the Statement of Work at the same time you are developing your estimates. Be sure to document any assumptions. project management time. and the approach.. especially the scope and approach sections. Refer to the Estimating Process Guide for additional guidelines. and preferably three. and delivery assurance. Using multiple approaches will help ensure a higher level of confidence in the final estimates. There will be cases where your estimating process requires that you update your Statement of Work and visaversa. These should be documented in your Statement of Work. constraints. Although these are often done concurrently.) Estimating Technique Guide . and Management and Coordination Activities Organizational Change Technical Infrastructure Facilities Infrastructure Development Staff and Duration Travel Expenses Estimating Templates: Requirements/Proportional Package Based Dev Iterative Custom Dev Accelerated Application Dev Ballpark Estimating Proportional Percentage . TBD . ASPIRE Phases. Your estimate should include at least one top-down and one bottom-up approach.  To estimate effectively. you will often need to make assumptions to “fill the gaps” in the information needed to create the estimate.  On larger scale estimating efforts. Vision and Strategy Recommended Optional / Sanity Check Not Recommended Estimating Guidelines Project-Wide Guidelines The following estimating guidelines can be applied across all phases of a project.Estimating Technique Guide ASPIRE Methodology Comparison The following diagram illustrates how the various estimating templates support the ASPIRE project phases. or risks that you identify during this process in the Estimating Notebook. travel. For example. an initial draft of your Statement of Work.. You will also need to identify any of the surrounding activities or components... interviews. you should take into account the effort to produce the final deliverables as well as the workshops. These items must also be incorporated into the project’s Statement of Work.  Use at least two. requirements. will be a valuable source of input for your estimating process. estimating approaches or techniques when estimating your project.

number of packages being evaluated. Document these quantifiable units of measure in the Statement of Work and Estimating Notebook.  Include the effort for conducting architecture.  Try to separate the “pricing” from the “estimate”.  When appropriate. design. and development reviews in your estimates.  Use the following guidelines when estimating for project expectations and reviews: • For each project expectation: ½ hour to write. All too often we try to develop an estimate with a maximum price tag in mind and we let the “price” drive the “estimate”. Estimating Technique Guide . • For each project evaluation: 1 hour to write and 1 hour for both individuals to review and discuss.Draft 18 2/26/2013 . • Allow for 1 project evaluation for each team member every four months. Examples include the number of workshops being conducted. number of windows being developed. evaluate and approve estimates from sub-contractors.  Base your estimates on some quantifiable unit of measure. and ½ hour for both individuals (manager and project team member) to review and discuss.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. One rule of thumb is to allow for 4 FTEs for 5 days every quarter. and the number of staff over some fixed duration of time. business function.

Plan on one to two days per page for preparing the final documentation. Cautions Following is a list of potential “gotchas” that could impact your ETP estimates. 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. A good client relationship person is key. A plan that we cannot live with surely is one the client cannot live with. The primary deliverable is a prioritized listing of future steps to achieve the Vision set by the study.750 hours. even for a relatively small project such as an ETP.000 to $350.Draft 19 2/26/2013 . 1996. we must realize that IT Services will need to be prepared to do the work for those estimates. Review these and adjust your estimates.  At the outset of the project. The answer usually does not "fall out" from the work done during the study. Not all of these have been confirmed or validated. Tools.000 range. significant cost overruns and loss of credibility are likely. 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. If expectations are not properly managed. or risk factors accordingly. Manage client expectations on the length of the document to be presented and the depth to which it will extend. The time to develop this plan is often underestimated.    It takes four people approximately six weeks to complete an ETP study. None of the estimating tools that we have used address this phase of a project. Estimating Techniques. client expectations must be carefully managed as to the level of detail that will be provided as a result of the study.) Following are some rules of thumb that have been used on prior projects. 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. and Templates Recommended estimating techniques include comparative and expert judgment. prior experiences. If expectations are not properly managed. You can also use a proportional or widget counting technique to get an alternative estimate.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. The only estimating template that we currently have available for an ETP is the general staff and duration estimating template. The total cost for an ETP seems to be in the $50. significant cost overruns and loss of credibility are likely. assumptions. Assuming a $200/hr billing rate this would translate to 250 to 1. Another critical success factor is the staffing. Client expectations must be carefully managed as to the level of detail that will be provided as a result of the study.    Estimating Technique Guide . and from our various field visits. even for a relatively small project such as an ETP.

how many customers. especially if you are going to use a bottom-up estimating approach. Not all of these have been confirmed or validated. and Templates Recommended estimating techniques include comparative and expert judgment. 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. or competitor surveys be conducted? And if so. prior experiences. Possible estimating tools include Ballpark.                   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. centralized.Estimating Technique Guide Business Area Architecture (Requirements/BAA) General Information The following questions can assist you in sizing the Requirements/BAA effort. You can also use a proportional or widget counting technique to get an alternative estimate. 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. and Proportional Percentage. and from our various field visits. The following staff size/ project duration have been used on prior Requirements/BAA efforts:  Six people for five months Estimating Technique Guide . you will need to adjust your estimates based your specific project. 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. supplier. multinational. 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. The only estimating template we currently have available for a Requirements//BAA is the general staff and duration estimating template. 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. Since the scope and depth of the final deliverable for a Requirements/BAA can vary significantly from project to project.Draft 20 2/26/2013 . QSM Slim. multidivisional. Tools.) Following are some rules of thumb that have been used on prior projects. 1996. suppliers.

Deployment Specific estimating guidelines have not been developed for this phase at this time.Draft 21 2/26/2013 . Following are some general metrics regarding the impacts on subsequent project phases. Your estimate and schedule should reflect this effort. During our field support visits. 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. Accurate estimates are very difficult to produce during the early phases of a project. Review these and adjust your estimates. During our field support visits. Changes in the Requirements/BAA could result in changes that are up to 10 times as much during integration testing.  Three people for three months. or nearly completed. we generally used a proportional factor for this phase. Data modeling metrics:  Four hours per entity using workshops. resist the need for producing downstream estimates for BSD and Development until the Requirements/BAA has been completed.  During the Requirements/BAA phase. focused on data not processes)  Six people for three and a half months. Changes in the Requirements/BAA could result in changes that are 4 to 5 times as much during program construction. These hours are for the data modeler only. Changes in the Requirements/BAA could result in changes 2 to 3 times as much during the BSD phase. Workshops seemed to be the most efficient method. Req /BAA: BSD: ADP: INT: Scope changes are generally 1 to 1. This will help the client in understanding the full impact of the change request.  Changes in scope during the Requirements/BAA will impact later phases of the project.  The overall client culture could increase the time and effort to resolve issues.  The Requirements/BAA effort generally involves intense senior business level participation. Estimating Technique Guide . there tends to be more committee decision making versus individual decision making. reducing the potential “sticker shock” of subsequent phases. Other estimating options include using a staff and duration model or basing the estimates on the number of deployment sites. be sure to include the potential estimate adjustment for later phases as well. assumptions. or risk factors accordingly. This will increase time frames.  When possible. 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. 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  Four people for two months (Decision Support System. Cautions Following is a list of potential “gotchas” that could impact your Requirements/BAA estimates. The Requirements/BAA was for a small division and included all the processes for this division. When applicable.

we have had minimal success with using CA-Estimacs to estimate this type of a project. All of the estimating tools discussed in the prior section provide some level of support for a package-based development approach. A configuration involves setting a software parameter as intended. however. and widget counting. Checkpoint applies mainly to any proposed enhancements and is not recommended for a package-based development effort.  Have a clear definition of an enhancement. A modification is a change to the core software code. and a modification. and procedures may be required. An enhancement involves making a fix using the tools provided by the vendor. Estimating Technique Guide . CA-Estimacs contains a packaged-based lifecycle model. 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. More specific estimating guidelines have also been included for the Package Evaluation and Selection (PES) sub-phase. expert judgment. 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. As a general rule. We have developed a package-based estimating template that can support a single or multiple applications.Draft 22 2/26/2013 . a configuration.  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. The following questions can help you to size your overall PBD effort. Tools. policies.Estimating Technique Guide Specialty Areas Development Package Based Development (PBD) General Information The following estimating guidelines apply to the entire PBD specialty area. and Templates Estimating techniques that apply to a PBD effort include comparative.

1996.  Clients often fail to provide full-time business resources. You will need to adjust your estimates based on your specific project.  We often underestimate vendor and subcontractor efforts. Cautions Following is a list of potential “gotchas” that could impact your PBD estimates. and PowerSoft: Inflate server requirements 4 times the vendor statements.  Earlier software versions are generally prone to bugs and poor software performance.  Although the minimum timeframe for an SAP implementation can be a short as 6 months.  EDI capabilities are non-existent within the Oracle suite of applications. or risk factors accordingly. Not all of these have been confirmed or validated. and interface efforts. General:  We typically under-estimate the development.12 months.  Although the minimum timeframe for an Oracle implementation can be as short as 6 . assumptions. you can usually distribute module specific information.  Multiple database and application software vendors add to the overall risk and complexity. and from our various field visits. Oracle.  Best of breed solutions often require multiple vendors.  For SAP. Estimating Technique Guide . however.) Following are some suggested rules of thumb that you can use when deriving your estimate.2 gig hard drive. Oracle:  Oracle may not be considered true client server.Draft 23 2/26/2013 . SAP:  SAP does not have a distributed data architecture. if it does not have a distributed data architecture. and a 1.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.  An Oracle 2 implementation can be 3 times or more higher than the retail software price. prior experiences. SAP Implementation:  A general rule of thumb is $1 million for an SAP implementation.8 months. the average minimum timeframe for a generic implementation is 9 . Review these and adjust your estimates. Oracle Implementation:  A typical Oracle implementation costs approximately $10 million. 12 18 months is a more realistic minimum timeframe.  Software vendors are generally unwilling to modify their software.  A minimum client PC requirement is a Pentium processor with 24 meg of memory. conversion. An SAP implementation is often 2 times longer than an Oracle implementation.  A SAP R3 implementation can be 10 times or more higher than the retail software price.

Following is a list of scope questions that should be considered.  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. or technical requirements been identified? Estimating Technique Guide .  Has a vision and strategy (ETP) been conducted? If so. These items should be addressed in the project’s Statement of Work.  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. 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. are they willing to change their business process for the package or visa versa. to what extent? If not. platform. for example.  Is contract negotiation part of the project scope?  Does the project scope include the Technical Infrastructure Acquisition (TIA)? If so.Draft 24 2/26/2013 . you may need to estimate all of the related equipment costs. 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.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.  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.

Draft 25 2/26/2013 . Not all of these have been confirmed or validated. accessibility. allow for 20 days or more for each major module. prior experiences. Accounts Payable. and project management. Master Scheduling. Hackett Group. and Templates The same techniques.  Interfaces with other systems or packages.  Client’s expectations of IT Services developing a vendor short list. You should try to compare their definition with an APICS reference.  Confusion or misinterpretation of the client’s definition of specified business processes. Cautions Following is a list of potential “gotchas” that could impact your PES estimates. MRP. A major module is defined as a major functional subsystem.  Vendor meetings with the client. or HRSP. For example. and multicultural capabilities or requirements. ERP/ MRPII has 15 major modules: General Ledger. 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. Inventory. Review these and adjust your estimates. Payroll.  Each major module will cost $25k or higher. AICPA.  A PES project should be staffed with one person per functional area such as financial. You will need to adjust your estimates based on your specific project. and from our various field visits. tools. Estimating Technique Guide .  Be sure to validate a vendor’s integrity through references.  Level of organizational change required versus planned. Human Resources. 1996. and logistics for distributing and receiving RFP or RFS responses. Shop Floor Control.  When selecting the final package. manufacturing. and templates identified for a package-based development effort also apply to the PES sub-phase. and Standard Costing.  The minimum cost for a PES is $100K. Tools.  Ensure that there is a real business value. The staff should be experienced. Order Entry. multinational. assumptions.Estimating Technique Guide Estimating Techniques.  Consider the vendor’s location. technical.  Multi-lingual. WIP. distribution. or risk factors accordingly. This time does not include the SDL. Accounts Receivable. MPS. The minimum duration of 3 months elapsed time is needed to accommodate scheduling issues. Bill of Material. avoid a weighted point system as the ultimate decision maker.  When estimating the selection process. Purchasing.) Following are some rules of thumb that you can use when deriving your estimate.

system architect. and from our various field visits. the team leader activities are additional hours. approved prototype. 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. and unit testing of one program: Simple (Extract and Post): Medium: Complex (multiple systems or conversions): 80 hours 160 hours 240 hours  Following are some general PowerBuilder/ PowerTools metrics. The matrix based ICD estimating template is also an effective tool for this type of project.88+ hours Note: Simple Window: Contains 1-2 simple objects such as a drop down data window or single line edits. application architect.  Following are some general metrics for interfaces. and test coordinator. These individuals are in addition to a full-time project manager.) Following are some rules of thumb that you can use when deriving your ICD estimate. Team Leaders: When a team lead is monitoring 3 or less developers.Draft 26 2/26/2013 . Tools. prior experiences. 50% of this individual’s time can be allocated for team leader activities and the other 50% to development activities. You should adjust your estimates based on your specific project. Technical Support: Consider adding one additional FTE for every 3 . 1996. Additional Managers: Consider adding one additional FTE for every 15 -16 team members. Estimating Technique Guide . Not all of these have been confirmed or validated. There can be a simple query done in this window that does a select from a single table. programming. DBA. or databases. servers. If the team leader is monitoring up to 6 developers. Note: If you are using Widget Counting to estimate the development effort. These estimates are based on an existing. Simple: Medium: Complex: 24 .48 hours 80 . networks.4 boxes. For estimates in excess of 88 hours.32 hours 40 .  Following are some general metrics for additional “support” staff.Estimating Technique Guide Iterative Custom Development (ICD) General Information Estimating Techniques. try to breakdown into simpler tasks in order to accurately estimate the progress of this task. and Templates All of the estimating techniques and tools discussed in prior sections provide some level of support for an iterative custom development effort. Many of the data maintenance windows fall into this category. you will need to adjust these for more complex 3-tier applications. These hours include technical design. then 100% of the individual’s time needs to be allocated to team leader activities. These hours are for coding and unit testing 2-tier applications.

Medium Function: A more complex function that has data manipulation. This stored procedure can have multiple transactions processing within the procedure. simple cursor manipulation. and complex exception handling. Complex Function: Contains data manipulation.120+ hours Note: Simple Procedure: Contains a single simple query. and has multiple cursor management with in the stored procedure. There can be a simple query done in this function that does a select from a single table. Complex data queries.Estimating Technique Guide Medium Window: Contains several simple data objects or 1-2 complex data windows that have SQL selects with multiple table joins. If these are greater than 120 hours. simple updates or deletes from the database. Estimating Technique Guide .  Following are some general ANSI “C” coding and unit testing metrics. and unit testing.Draft 27 2/26/2013 . you need to break these down into simpler tasks. Simple: Medium: Complex: Note: Simple Function: Does not contain a lot of complex computation or data manipulation . Complex Window: Contains 3 . dynamic memory allocation for structures in support of complex data manipulation. such as sub-functions within the main business process. and has multiple cursor management within the function. complex data manipulation. multiple table (2-4) joins in the SQL.6 data windows with multiple objects on the window. and has cursor management within the function. simple logic within the stored procedure. 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. Complex Procedure: Contains complex program logic. Note: These estimates were based on Oracle stored procedures. multiple table (4 or more) joins in the SQL. Simple: Medium: Complex: 10 hours 20 hours 40+ hours 40 hours 80 hours 80 . These hours are for design. code. inserts. updates and deletes from the database. A complex C function can also contain complex queries. updates and deletes from the database. inserts and deletes across multiple data tables.  Following are some general metrics for stored procedures. updates. inserts. complex queries. Note: The hour estimates for the complex functions are in excess of 80 hours. simple exception handling. Does not contain any logic. multiple table (4 or more) joins in the logic. Medium Procedure: Contains 1-2 transactions. Performance considerations are critical in this window and extra effort should be taken to make sure that this window is as efficient as possible.

The actual conversion effort is not included. single database and location with primary indices. (If the form was created manually. Expect that less than 10% of the conversion programs to be classified in this category.0 and they assume that the form has been generated through Designer/2000. Note: Estimates are based on creating a physical build with a first cut at optimization. Simple: A simple form is one that contains only one block and requires few edits or validations. canvases. The average is approximately 3 hours per table. Simple: Simple-Medium: Medium: Medium-Complex: Complex: 120 hours 160 hours 200 hours 280 hours 400 hours Note: Simple Conversion: A simple extract and post program. Complex Conversion: Expect to have over 50% 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.20% of the conversion programs to be classified in this category. and additional 12 to 20 hours should be added to the estimates depending on the number of blocks.  Following are some guidelines for developing Oracle Forms. code.Estimating Technique Guide  Following are some general metrics for creating a database. Estimates do not include performance turning. Estimating Technique Guide . These following estimates are for Forms 4. Simple (less than 25 tables): Medium (less than 70 tables): Complex (greater than 70 tables): 80 hours 160 hours 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.Draft 28 2/26/2013 . Medium Conversion: Expect to have approximately 10 .50% of the conversion programs to be classified in this category. These estimates include the design. and unit testing for each conversion program.) Simple: Medium: Complex: Very Complex: 24 hours 40 hours 64 hours 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. fields. and list values contained in the window. Medium-Complex Conversion: Expect to have approximately 20 . average database size.

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. Very Complex: A very complex report is one that contains two or more queries and requires a significant amount of formatting. Complex: A complex form is one that contains two or more blocks and requires a substantial amount of additional processing logic. 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. Estimating Technique Guide . Simple: Medium: Complex: Very Complex: 16 hours 32 hours 56 hours 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. or update data either the source or destination location.  Following are some guidelines for developing Oracle Zooms. execute an automatic query at the destination.Draft 29 2/26/2013 . Simple: Medium: Complex: Very Complex: 8 hours 16 hours 32 hours 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. 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. Very Complex: A very complex form is similar to a complex form. (For example. copy data from source to destination.  Following are some guidelines for developing Oracle Reports. They are not commonly used (might not be supported) in their GUI version. except that the additional processing logic itself is complex.) Note: Zooms are commonly used with Oracle’s character-based version. Simple: A simple report is one that contains only one query and requires little formatting. (This is similar in concept to a “hot key”. 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.  Following are some guidelines for developing Oracle Alerts. Complex: A complex report is one that contains two or more queries and requires a substantial amount of formatting.Estimating Technique Guide Medium: A medium form is one that contains two or three blocks and a moderate amount of additional processing logic. Medium: A medium report is one that contains two or three queries and a moderate amount of formatting.) 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.

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.  Medium 17 40 8 65 Complex 34 80 16 130 10 24 4 38 For completing a program. Very Complex: A very complex alert is one that requires interaction with the operating system in conjunction with detailed actions. performance engineering. The metrics assume that the development is client/ server using C++ or Visual Basic.Estimating Technique Guide Simple: Medium: Complex: Very Complex: 8 hours 16 hours 32 hours 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.Draft 30 2/26/2013 . The total hours cover design. unit test. They do not account for 4GL tools. Complex: A complex alert is one that might require several elegantly formatted detailed and summary actions in response to an event. Medium: A medium alert is one that incorporates more detailed actions in response to events and contain more complex SQL. the following percentages can be used to break-down an estimate: Review Specification: Code Program: Compile Program: Code Review: Create Test Plan: Review Test Plan: Unit Test Program: Obtain Program Sign-off: 5% 15% 15% 5% 15% 5% 35% 5% Estimating Technique Guide . prototyping. code. Also it is uncertain at this time whether unit testing is covered in the “coding” or “testing” phase. report is one that contains only one query and requires little formatting.  Estimate 8 hours of effort to develop one page (8. team leadership.5 x 11) of user documentation.  Estimate 40 hours of effort to develop one hour for hands-on (classroom-type) training with labs. or other support activities. and limited application/ integration testing.  Following are some generic custom development metrics. database activities. There numbers were based on a small sampling of projects and should be adjusted based on the knowledge of the specific project environment. Simple Design Code Test Total: Note: These numbers seem to be on the low side when compared to other metrics provided above.

 System complexity can have a huge multiplier effect on your estimates. PowerBuilder. and software documentation have been completed. application architect (business analyst). the unit test plan has been completed and executed.  3-Tier environments add an additional layer of complexity.) Cautions Following is a list of potential “gotchas” that could impact your ICD estimates. and DBA roles.  Failure to include time for all levels of testing. especially if the Requirements/BAA has not been completed. C. test plan and results.  Testing and Pilot includes: • String and Integration Testing: 40% of effort • User Acceptance Testing: 40% of effort • Performance Testing: 20% of effort As a reasonable sanity check for these phases. test coordinator. especially system and performance testing. or risk factors accordingly.  Being forced to estimate the entire project up-front. calculate the effort based on the anticipated staff count and duration. These are generally unanticipated problems. Try to avoid estimating forward from the Requirements/BAA. This individual will need time to understand the project-specific business requirements. Instead. Consider conducting regular meetings with key staff to look forward for unplanned tasks and potential workarounds. Estimating Technique Guide . Adjust your estimates accordingly. system architect (technical analyst). allow the Application staff to build the procedures and have the DBA staff review them. assumptions.  Include time to account for miscellaneous development problem solving. the code has been desk checked.  It is essential to have a frozen architecture before you begin development. You will need them for critical items such as network support.  Remember to make allowances for computer operations. One definition of done: A developer is done with a module when all coding has been completed. Review these and adjust your estimates. and peer (or management) reviews of the code.  Allocate time for project manager. all software documentation has been completed.Draft 31 2/26/2013 .g. backups. and DASD management. (Calculate each phase separately.  We occasionally forget to account for fixed support staff (architects.  It is essential for the development staff to understand what “done” means before program development begins. Try to place these resources on non-critical paths. team leaders) when we adjust end dates due to schedule slips. Note: you can never bring in the test coordinator too soon. and stored procedures.  The DBA staff being expected to build all stored procedures.  Failure to distinguish between the various components of the application architecture: e.Estimating Technique Guide  Following is a proportional percentage by project phase: Requirements /BAA: BSD: Construction: Testing/ Pilot: 10% 20% 40% 30% Notes:  Construction includes unit testing. project managers. These individuals should be allocated for the entire ICD phase.  Be sure to anticipate an lower level of utilization for client staff.

Data quality will be low and you could expect to have to cleanse 75% of the data. Adjust your estimates accordingly.  The time required to select a vendor. interface testing.  Need to estimate the performance testing architecture and infrastructure.  We typically under-estimate the number of interfaces.  We typically under-estimate conversions and the effort to cleanse the data. The effort to completely retire a legacy system is much more than just developing a new one. purchasing.  We should determine if legacy system retirement is within the scope of the project. and training in the use of performance tools.  Hint: Simulate an realistic system loading during user acceptance testing.  We also need to differentiate between benchmarking and performance testing.  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. 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.  A mix of application languages will impact the level of effort. You may want to consider timeboxing manual data conversions.Draft 32 2/26/2013 . or implement hardware or software components can impact the project schedule.  Need to estimate the effort for selecting . purchase hardware or software components.Estimating Technique Guide  Avoid being too aggressive with complexity ratings.  Performance Testing:  We typically under-estimate or forget to estimate stress and performance testing efforts. Try to allow for these potential schedule delays. We generally rate programs as easy when they really have a medium complexity.  Be sure to identify and inventory interfaces and conversion programs. and legacy system testing.  Need to have target performance levels from the client. Estimating Technique Guide . The performance levels should focus on business functionality not screen or program response. legacy system modifications. New systems rarely map directly to the systems that they are replacing.  Conduct pre-development walkthroughs to identify potential performance problems before the application is built.

Estimating Technique Guide Accelerated Application Development (X/AD) General Information The following guidelines are based on two X/AD client/server projects. and development estimating. Both of these projects were 1 year in duration. and widget counting. Systems Architect. and a 2-teir client/server design. for estimating an XAD engagement. Team Leads.  Six weeks for application architecture design. Estimating Technique Guide . prototype development. database creation. a UNIX database server. discussed in the prior section. Estimating Techniques. define the logical database design. The BSD was completed in 12 weeks. and a DBA. Tools. Estimating Rules of Thumb BSD Estimating Guidelines: The goal of the BSD phase was to develop a proof of concept prototype of the application. The technology employed on these projects was PowerBuilder for the GUI development. design the business processes. expert judgment. and data design. The phase was broken down as follows:  Six weeks for business process design.Draft 33 2/26/2013 . common object definition. C for the server development. We have not tried to use any of the estimating tools. Data Modeler. and to design the architecture of the application. development environment setup. and Templates Estimating techniques that apply to an XAD effort include comparative. they provide a high-level structure for composing a project plan. We have developed two XAD estimating templates. one that supports a single application and one that supports multiple applications. The BSD phase was staffed with a Project Manager.

full-time project manager.  Having a prototype to show the user community the proof of concept and then get sign-off on the prototype. (Note: If four or fewer timeboxes were used. planning the next timebox. Each timebox contained a mixture of simple and complex tasks based on the level of experience of the staff. one additional timebox was added to the schedule. and assisting the users in acceptance testing. bug fixes.  The users are completing acceptance testing concurrent with development. Note: No developer should have a task that lasts more than two weeks.Draft 34 2/26/2013 . data conversion. The user test plans should be business rule based. While the development for a timebox was underway. This is not to say there won’t be any changes to the data model along the way. Estimating Technique Guide .) 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. part-time logical data modeler. the number of timeboxes for applications development was defined. There was also a full-time DBA. the users were completing acceptance testing for the previous timebox. so that you are testing the application from the end user’s perspective and not the developer’s perspective. If more than four timeboxes were used.  Having the data model defined ahead of development helped out greatly. This phase was used for performance tuning. This timebox was used to complete user change requests. full-time systems architect. After the timeboxes for new development were defined. user training. During the application architecture design in BSD. final user acceptance. this phase should be equal to three timeboxes (15-18 weeks. enhancements. an integration testing phase was completed. and fulltime test coordinator. each with 3-4 developers.Estimating Technique Guide Timebox Estimating Guidelines: The duration of each timebox was 5-6 weeks. The project team consisted of one or more team leads. four weeks for development and 1-2 weeks for testing and delivery to the users for acceptance testing. Their time is consumed by managing the developers. A team lead is NOT responsible for any development. and business site preparation. Integration Testing Estimating Guidelines: After completing all of the timeboxes. the integration testing phase should be equal to two timeboxes (10-12 weeks). A project should assign as many development teams (1 team lead with 3-4 developers) as the project needs. They are testing the deliverable from the previous timebox. and any schedule overruns. but it avoids slowing down development while the data model is created. Subsequent timeboxes contained the development work in a logical sequence based on the work to be done. helps to better estimate the size of the project. The application estimates were prepared using ICD estimating guidelines. Common objects and application frameworks were developed in the first timebox.

and usability.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. Estimating Technique Guide . This person should review all developed software for consistency. The System Architect should be on the project until the system is deployed. Cautions None have been identified.Draft 35 2/26/2013 . adherence to standards.

ETP and Requirements/BAA equals two phases) J = Judgment factor (use 5 for low-end. These guidelines include planning. draft. and deploy the communication. for the duration of the project. and a second that can be used to estimate the number of stakeholder groups. design.  The number of stages of acceptance is 5. Estimating Techniques. 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. use a proportional estimate of 10% . 1996. prior experiences. and from our various field visits. (# 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. discussed in the prior section. proportional. (This does not apply to a very sophisticated event such as a video component. the types of communication vehicles. (Effort = F * S * P * J) where: F = Complexity factor as calculated below S = Number of stakeholder groups P = Number of project phases (example. You will need to adjust these estimates based on your project and team-related experience. Two days to plan. Organizational Change as an overall level of effort:  One person. We have developed two estimating templates. For a systems integration project. designing.) A minimum of 5% of the overall effort to a maximum of 40% of selected project phases.15% of the overall effort. approving. None of the estimating tools. and deploying the communication event. and widget counting. Expect the Subject Matter Expert to spend most of his or her time during the phase transitions (beginning and end of each phase.) An average of 4 to 20 hours per change enabling communication event.Estimating Technique Guide Organizational Change General Information The following estimating guidelines were collected during one of our field visits.  Communication Plans: The following formula can be used to estimate the effort to design and deliver communication events. approve. and 15 for high-end complexity) Estimating Technique Guide .) The following guidelines are intended to provide a high-level idea of the amount of time required.Draft 36 2/26/2013 . 10 for average. Not all of these have been confirmed or validated. 50% of time. design. 2. and Templates The current estimating techniques being used for estimating organizational change include comparative. and execute an event.  Two guidelines have been given for estimating the hours per event. You will need to adjust these to fit your specific project environment. the general readiness for change. One that can help estimate the effort to design and deliver communication events. Another formula for estimating the amount of time required for change enabling communication follows. The complexity of the engagement. Tools. appear to address organizational change activities. developing. expert judgment. and the length of the engagement are all factors that can influence this estimate.  1. This formula guideline includes the time required ( in days) to plan.

for a strategic change.4 Much Resistance 1. project management.44 x 7 x 1 x 10 = 100) Example 2. ((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 2 500 3 1. and impacted business unit. (CS (5) * PO (2) = 10) Estimating Technique Guide . project team. subject matter experts.0 Moderate 1.2 x 1.95 x 12 x 1 x 10 = 475) Stakeholder Groups: The following guidelines have been defined for estimating the number of stakeholder groups.0 1 . Using this factor. for a tactical change.4 x 1.000 8 50 to 100% 4 500.the complexity factor (F) would be 1.Draft 37 2/26/2013 .0 = 1. The project is expected to only impact the corporate office. anticipated resistance.4 Example 1: Assume the change is minor.) Minimum number of stakeholder groups for an enterprise-wide engagement is 6 (executive sponsors. project management.000 9    Percent of Organization Impacted by Change PO factor 10 to 30% 2 For example: Your client has approximately 5. Assume the change is major. we could estimate the effort during a Requirements/BAA to equal about 100 days. with some resistance anticipated.   Minimum number of stakeholder groups for a small engagement is 4 (executive sponsors. Degree of Change Anticipated Resistance Type of Change Number of Stakeholder Groups Minor 1. use the following table to categorize the degree of change.Estimating Technique Guide To compute the Complexity Factor (F). type of change and number of stakeholder groups.or -.0 Anticipated Change 1.000 7 25 to 80% 3 100. we could estimate the effort during a Requirements/BAA to equal about 475 days. ((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.4 More than 25 groups 1. which accounts for 20% of the company.0 No Resistance 1.or -.000 4 Up to 10% 1 5.2 = 3.2 10 . Using this factor.95.2 x 1. and 12 stakeholder groups have been identified -.2 Major 1. The estimated number of stakeholder groups is 10.2 Some Resistance 1. (Effort = F x S x P x J -.4 x 1. with much resistance anticipated.000 5 10. and 7 stakeholder groups are involved -. and organization as a whole.3.000 6 50. (Effort = F x S x P x J -.1.25 groups 1.9 stakeholder groups 1. extended project team.) 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.44.4 Strategic (organization) 1. Multiply the factor for each category to determine the complexity factor.000 total employees.4 x 1.2 Tactical (business unit) 1.0 x 1.the complexity factor (F) would be 1. project team.

and deployment. It is accomplished in conjunction with preparing and updating of the Project Management Plan and the Software Development Plan. terminal access. Critical Computer Resources and Facilities Infrastructure No specific estimating guidelines have been identified at this time. If a new project or new task order requires new hardware. Training and Education Assuming the forum will be traditional. The equipment is then listed in direct relationship to the staff and contract performance. Cautions None have been identified. Steps for Planning/Estimating are: 1. Technical Infrastructure No specific estimating guidelines have been identified at this time. the task order team and contract staffing (if applicable) consider the work allocation and equipment needs that were planned into the task order performance. and use one monitored in project startup and performance tracking activities.g. word processing. In addition. The review considers the type of equipment for all personnel and the peak periods of performance for all devices or units. all documents and planning materials developed in previous stages are used for project. directs correlating staff duties and skills and computer resource use. database. task order and computer resource planning.Estimating Technique Guide Roles and Responsibilities: Assuming that your are creating a role (job description) from scratch and have some starting material. instructor-led training. financial spread sheets). The hardware acquisition will be a part of the project. In Estimating Technique Guide . 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. Review and analysis are dictated by the types of activities (e. At project start up. This can range from as low as 2 hours to as high as 12 hours per role. The attendees review the estimated resource use and the responsibilities for all technical and administrative personnel. 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. 2. acquisition. testing.Draft 38 2/26/2013 . use 4 hours per role as a guideline. the PM conducts a meeting with all section managers of all key activities. 3. use a guideline of 10 hours of development time for each hour of delivery. standard contract and task order negotiation (if applicable). implementation. Each section manager identifies their staff’s roles and responsibilities.. This could range as high as 80 hours of development time per hour of delivery for world-class instructor script and participant guides. Critical Computer Resources may be estimated Critical Computer resource planning and estimating is an on-going activity. conducted at startup. 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.

adjustments are made to the acquisition plans.Draft 39 2/26/2013 . the total management and coordination effort should be approximately 15% to 20% of the total project effort. a simpler update is developed for the task or contract budget. The Analysis and Design Manager review the plan with the PM and the accounting and finance personnel. The current use of resources is compared to acquisition of future resources. The timeline developed and provided to the section managers for review. The system administrators monitor the use of critical computer resources and report the use to the PM monthly as the project progresses. project management. The Analysis and Design Team manager maps the acquisition strategy on a timeline. 5. The project/task order plan is then used to update the contract and site plans for hardware acquisition.Estimating Technique Guide addition. 6. we generally used a staff and duration model to estimate development coordination. A common guideline is to use a 1 to 6 ratio. 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 Project Manager and the section managers review the use report to analyze use of memory and the storage. channel capacity. 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. and device capacity. 4. and changes are proposed to the client. be sure to include them here. If the team lead activities have not been included in the other project phases. usage of network. Estimating Technique Guide . In general. a current hardware configuration from a system specification and a current hardware use report from the Operations and Maintenance Team may be used. The computer resources acquisition plans for a task order is built to reflect any required increase in current or planned contract hardware capabilities. and program management. 8. Management and Coordination Specific estimating guidelines have not be developed for this phase at this time. 7. The plan is used to update the planned hardware expenditure for the contract. During our field support visits.

the length of duration. the number of resources (count). Either of these spreadsheets can be tailored to your specific estimating needs. release. Each spreadsheet allows you to compute the total hours and cost by project team role. It is based on the assumption that a Requirements/BAA accounts for 7% to 10% of the total project effort. enter a role description. meals.Estimating Technique Guide Appendices Estimating Templates Please refer to the additional file attachments for these spreadsheets. Totals are provided of each category. and computes an average weekly travel expense based on the total project expenses and the total number of weeks. and cost. such as the entire project team. hours. For each unique project role. The user defined fields are in “blue”. This worksheet provides total weekly and project expenses by individual. Add or delete roles as needed. It also provides totals for each expense category . project duration. allows you to identify the project’s duration (in weeks). allows you to specify the above expense categories and project duration on an individual by individual basis. 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. The second allows for two resource groups. Travel Expenses Template This spreadsheet provides you with two options for estimating travel related expenses. Enter the duration to hour conversion factor. and the hourly billing rate for this role. This cell is used to calculate hours based on the duration that you have entered. One allows for a single resource group. or development build. and 10% scenarios. The first worksheet. and team size. Either of these worksheets can be easily customized to meet your specific project requirements. these are calculated based on the weekly expense amount. Simply enter the actual hours from the Requirements/BAA and the spreadsheet projects the remaining project effort based on 7%. so the duration to hour conversion factor has been set to 40 hours. Option 2. 8. The spreadsheet that allows for two groups of resources provides sub-totals for each group along with aggregated totals.5%. Modifying either spreadsheet to specify hours and costs by project phase. and computes an average billing rate. Potential customization options include:   Modifying the IT Services and Client spreadsheet to represent billable and non-billable effort. Staff and Duration Estimating Templates Two estimating spreadsheets have been provided. Each spreadsheet calculates the total hours and cost for each role. timebox. 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.Draft 40 2/26/2013 . Option 1. cab/ auto. You can modify the proportional factors or add additional scenarios. and miscellaneous expenses. the overall project. Estimating Technique Guide . 2. The template assumes a custom (ICD) development approach. provides grand totals for staff count. If you did not receive these file attachments or if you have any questions on how to use these spreadsheets. lodging. A grand total is also provided. The second worksheet. The duration used in the template is weeks. team size. To use these spreadsheets: 1. and the estimated expenses for: airfare. such as IT Services and the client staff. parking.

The template currently assumes that the duration is specified in 40 hour weeks. To use this estimating template: 1. enter a description. The project management and coordination phases can be estimated based on a staff and duration template. The estimated effort to complete each unit. you can specify the number of units. Single Application Spreadsheet: This spreadsheet contains three worksheets.Draft 41 2/26/2013 . You can also apply a proportional level of effort for the integration and deployment phases. Estimating Technique Guide . PBD Details. summarizes the project sub-phases. The estimating drivers should include: • The unit of measure. 1. The template contains some general activities for each of the package-based development sub-phases. The sub-totals are automatically linked to the estimate total worksheet. the number of staff working on each activity or work product. (Note: Another option would be to include the team lead activities in the management and development coordination worksheet. For each role. contains all of the estimating details by sub-phase. 3. The package-based development detail worksheet. such as a workshop. The summary contains both hours and a percentage of the total effort. estimating drivers. • • The number of units. and comments for each activity. Either of these spreadsheets can be easily customized to fit your specific project needs. The spreadsheet will compute the total estimated effort of each activity and provide totals by sub-phase. Each template allows you to identify the key activities and work products for each of the package-based sub-phases. The worksheet will provide sub-totals for each subphase and an overall estimate. Define the key deliverables. deliverables.) c) The worksheet will calculate sub-totals for each sub-phase and provide an overall summary at the bottom of the worksheet. timebox. For each activity or work product. and duration. The management and development coordination worksheet. Est Ttl. Modify these activities to meet your specific project requirements. enter the number of staff being managed and the percentage of team lead responsibility. and any estimating assumptions or comments. Adjust the hour computation to meet your specific requirements. the second supports multiple applications. Both estimating templates consist of a spreadsheet with multiple worksheets that allow to you enter the necessary details and summarize the overall results. or by using a proportional level of effort. These hour totals are automatically linked to the estimate total worksheet. and displays the total estimated hours. The total management and development coordination hour estimate is automatically linked to the estimate total worksheet. b) For the team leadership activity. The user defined fields are in “blue”. business function. One spreadsheet supports a single package-based application. Mgmt. 2. one supports a single package-based application. calculates the subphase’s percentage of the overall estimate. and comments for each sub-phase. Use this worksheet to enter the key activities. included in the spreadsheet. Complete the Mgmt worksheet: a) Complete the staffing and duration template for the management and development coordination effort. 2. the estimated effort for each unit. number of staff. estimating drivers. The estimate total worksheet. allows you to enter a staff and duration estimate for this effort. • The average number of staff involved in completing the activity. These totals are linked to a summary worksheet that provides a high-level overview of your estimates. The other supports multiple applications.Estimating Technique Guide Package-Based Development (PBD) Estimating Template Two estimating templates are provided. Complete the PBD Details worksheet: a) Enter the estimating details on the PBD Details worksheet. or package.

Both templates allow you to build a bottom-up estimate based on the number of “widgets” being developed. enter the appropriate proportional factor and adjust the cell formula for the phase hours accordingly. The only difference is in the PBD Details worksheet. windows. PBD Summary. use the steps outlined for the single application spreadsheet. Est Ttl. This worksheet allows you to enter detailed estimating information for each application area. one supports a single iterative custom-developed application. cell P3. and displays the total estimated hours. C functions. reports. This additional worksheet. Oracle forms. conversions. The other supports multiple applications. integration and deployment phases. The template currently allows for 3 application areas. PGM Matrix. If you prefer to have man-months or man-years. 2. Either of these spreadsheets can be easily customized to fit your specific project needs.Draft 42 2/26/2013 . Matrix-Based Iterative Custom Development (ICD) Estimating Template Two estimating templates provided. Multiple Application Spreadsheet: This spreadsheet contains the same three worksheets as the single application spreadsheet plus an additional summary worksheet. Use this worksheet to enter the widgets that need to be developed for each category. 1. interfaces. You can adjust the Est Ttl. or by using a proportional level of effort. you can define the management and coordination effort as a proportional factor. 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. interfaces. The program matrix worksheet. Tuxedo services. The percentages currently defined in the worksheet are for illustration purposes only. One spreadsheet supports a single custom-developed application. common objects. windows. The estimate total worksheet. Estimating Technique Guide . adjust this factor accordingly. You can also apply a proportional level of effort for the business system design. defines and categories all of the widgets that need to be developed. provides an hour and percentage summary for each application. application development completion.Estimating Technique Guide b) The worksheet will compute the total management and development coordination hours and automatically link this total to the estimate total worksheet. included in the spreadsheet. These widgets can include menus. Single Application Spreadsheet: This spreadsheet contains four worksheets. and common functions. The project management and coordination phases can be estimated based on a staff and duration template. The sub-totals are automatically linked to the estimate total worksheet. Complete the Est Ttl worksheet: a) Define the hour conversion factor. reports. Both templates consist of a spreadsheet with multiple worksheets that allow to you enter the necessary details and summarize the overall results. you can rate the complexity of each widget on a scale from 1 to 10. The template currently allows for menus. b) Enter the proportional factors for Integration and Deployment. To use this estimating template. The detail matrix worksheet references additional look-up tables that contain the appropriate estimates based on the type of widget and its complexity. similar to the Integration and Deployment project phases rather than using a staff and duration estimate. calculates the subphase’s percentage of the overall estimate. servers. conversions. As you define each of these widgets. summarizes the project sub-phases. and PBD Detail worksheets to add or subtract application areas. c) As a option. the second supports multiple applications. This conversion factor is currently defined as 8 hours to convert the hour estimate to man-days. 3. To do this. The worksheet will provide sub-totals for each category and an overall total. The user defined fields are in “blue”. You can adjust these look-up tables to reflect your specific project environment. PBD Summary.

and Deployment phases. level 1 being the simplest and level 10 being the most complicated. 4. EST Matrices. Estimating Technique Guide .) b) The worksheet will compute the total management and development coordination hours and automatically link this total to the estimate total worksheet. The management and development coordination worksheet. that worksheet will reference the PowerBuilder estimate matrix and retrieve the per unit estimate for a level 5 complexity window.) 2. adjust this factor accordingly. enter a description. ADC. corresponding changes will also need to be made to the other worksheets. For example. Be careful that you have defined the correct row and column coordinates when modifying this column. c) As a option. The estimate matrices worksheet. and calculate totals. Adjust the hour computation to meet your specific requirements. (Caution: The per unit estimate column in this worksheet is extremely sensitive with the row and column coordinates within the estimate matrices worksheet. allows you to enter a staff and duration estimate for this effort. Complete the Est Ttl worksheet: a) Define the hour conversion factor. Complete the PGM Matrix worksheet: a) Enter the widgets that need to be developed into the appropriate categories. b) Enter the proportional factors for the BSD. cross-reference information. similar to the Integration and Deployment project phases rather than using a staff and duration estimate. you can define the management and coordination effort as a proportional factor. The template currently assumes that the duration is specified in 40 hour weeks. contains estimating matrices for a variety of different types of widgets. For each entry you can specify the name of the widget. The worksheet will retrieve the per unit estimate from the estimate matrices worksheet. If you do modify or add additional categories. The program matrix worksheet uses these estimate matrices as a look-up table. the number of units. The total management and development coordination hour estimate is automatically linked to the estimate total worksheet.Estimating Technique Guide 3. Integration. number of staff. compute a total hour and day estimate based on the number of units specified. Category and overall totals are provided. (Note: Be sure to include the team lead activities in this worksheet. To do this. b) The categories contained on this template can be modified to meet your specific project. and duration. 3. and its level of complexity on a scale of 1 to 10. Mgmt. if you enter a PowerBuilder window with a complexity level of 5 on the program matrix worksheet.Draft 43 2/26/2013 . cell P3. If you prefer to have man-months or man-years. They have not been accounted for in the prior worksheet. The percentages currently defined in the worksheet are for illustration purposes only. Additional categories can also be created if needed. Complete the Mgmt worksheet: a) Complete the staffing and duration template for the management and development coordination effort. enter the appropriate proportional factor and adjust the cell formula for the phase hours accordingly. This conversion factor is currently defined as 8 hours to convert the hour estimate to man-days. To use this estimating template: 1. For each type or category of widget this worksheet contains estimates for 10 levels of complexity. For each role.

2. and any estimating assumptions or comments. 2. 3.Estimating Technique Guide Multiple Application Spreadsheet: This spreadsheet contains the same worksheets as the single application spreadsheet plus two additional worksheets: 1. Mgmt. The project management and coordination phases can be estimated based on a staff and duration template. The estimate total worksheet. The total management and development coordination hour estimate is automatically linked to the estimate total worksheet. allows you to enter a staff and duration estimate for this effort. You can adjust the spreadsheet to add more application areas. Accelerated Application Development (XAD) Estimating Template Two estimating templates are provided. The user defined fields are in “blue”. Use this worksheet to enter the key activities. The XAD-based development detail worksheet. Single Application Spreadsheet: This spreadsheet contains three worksheets. The other supports multiple applications. and comments for each sub-phase. For each activity or work product. 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. you can specify the number of units. Repeat the ICD Matrix steps for each application area. Estimating Technique Guide . estimating drivers.Draft 44 2/26/2013 . deliverables. Both estimating templates consist of a spreadsheet with multiple worksheets that allow to you enter the necessary details and summarize the overall results. or by using a proportional level of effort. one supports a single XAD-based application. To use this estimating template. calculates the subphase’s percentage of the overall estimate. the estimated effort for each unit. XAD Details. and displays the total estimated hours. Each template allows you to identify the key activities and work products for each of the XAD-based sub-phases. The sub-totals are automatically linked to the estimate total worksheet. the second supports multiple applications. contains all of the estimating details by sub-phase. the number of staff working on each activity or work product. included in the spreadsheet. The management and development coordination worksheet. Either of these spreadsheets can be easily customized to fit your specific project needs. The worksheet will provide sub-totals for each subphase and an overall estimate. 1. An ICD Summary worksheet that provides an hour and percentage summary for each application. The template currently allows for 2 application areas. An additional ICD Matrix worksheet for a second application area. One spreadsheet supports a single XAD-based application. Est Ttl. use the steps outlined for the single application spreadsheet. summarizes the project sub-phases. The spreadsheet will compute the total estimated effort of each activity and provide totals by sub-phase.

The template contains some general activities for each of the package-based development sub-phases. XAD Summary. These hour totals are automatically linked to the estimate total worksheet. XAD Summary. • • The number of units. b) For the team leadership activity.Estimating Technique Guide To use this estimating template: 1. The percentages currently defined in the worksheet are for illustration purposes only. Complete the XAD Details worksheet: a) Enter the estimating details on the XAD Details worksheet. Modify these activities to meet your specific project requirements. number of staff. enter the number of staff being managed and the percentage of team lead responsibility. Complete the Est Ttl worksheet: a) Define the hour conversion factor. and the number of stages Estimating Technique Guide . If you prefer to have man-months or man-years. Complete the Mgmt worksheet: a) Complete the staffing and duration template for the management and development coordination effort. you can define the management and coordination effort as a proportional factor. estimating drivers. Define the key deliverables. To do this. or entities. Adjust the hour computation to meet your specific requirements. The template currently assumes that the duration is specified in 40 hour weeks. This worksheet allows you to enter detail estimating information for each application area. The template currently allows for 3 application areas.) c) The worksheet will calculate sub-totals for each sub-phase and provide an overall summary at the bottom of the worksheet. The first worksheet. This conversion factor is currently defined as 8 hours to convert the hour estimate to man-days. The only difference is in the XAD Details worksheet. allows you to estimate the hours needed to design and deliver communication events based on the number of stakeholder groups. (Note: Another option would be to include the team lead activities in the management and development coordination worksheet. The summary contains both hours and a percentage of the total effort. This additional worksheet. The spreadsheet contains two worksheets. 2. number of project phases. b) The worksheet will compute the total management and development coordination hours and automatically link this total to the estimate total worksheet. c) As a option. cell P3. each represents an estimating option. enter the appropriate proportional factor and adjust the cell formula for the phase hours accordingly. such as a prototype set. and XAD Detail worksheets to add or subtract application areas. 3. enter a description. Option 1.Draft 45 2/26/2013 . b) Enter the proportional factors for Integration and Deployment. use the steps outlined for the single application spreadsheet. and comments for each activity. adjust this factor accordingly. • The average number of staff involved in completing the activity. similar to the Integration and Deployment project phases rather than using a staff and duration estimate. the estimated hours per event. business function. Communication Event Estimating Template This estimating template assists in estimating the effort to design and deliver communication events. and duration. provides an hour and percentage summary for each application. Multiple Application Spreadsheet: This spreadsheet contains the same three worksheets as the single application spreadsheet plus an additional summary worksheet. The estimating drivers should include: • The unit of measure. The estimated effort to complete each unit. You can adjust the Est Ttl. To use this estimating template. For each role.

simply select the appropriate client size by entering a “1” in the correct category. Fractional sizes are permitted. This worksheet will provide a low-end. simply enter the correct values. number of project phases. Stakeholder Group Estimating Template This estimating template assists in estimating the number of stakeholder groups. The estimated effort in is hours and is based on the calculations described in the Organizational Change estimating guidelines. You can only make one selection. These tables are used to categorize the degree of change. To use this worksheet. Option 2. To use this spreadsheet.Draft 46 2/26/2013 . Again. the number of project phases. Next select the percentage of organizational impact by entering a “1” in the correct category. Estimating Technique Guide . 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. and average estimated number of stakeholder groups based on the calculations described in the Organizational Change estimating guidelines. number of stakeholder groups.Estimating Technique Guide of acceptance. and a judgment factor. Client Size. you can only select one category. Next enter the actual number of stakeholder groups. the level of anticipated change. allows you to estimate the effort based on four complexity factors. The worksheet will calculate the estimated hours for designing and delivering communication events based on the calculations described in Organizational Change estimating guidelines. allows you to estimate the number of stakeholder groups based on the size of the project team. and a judgment factor. The second worksheet. simply enter the project team size in full-time equivalents. select the desired values from each of the four complexity factor tables. The first worksheet. and the type of change. high-end. the number of stakeholder groups (within a range). The spreadsheet contains two worksheets. The worksheet will compute the estimated number of stakeholder groups based on the calculations described in the Organizational Change estimating guidelines. Team Size. The second worksheet. To use this worksheet.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->