October 2015

1. Accurate estimates were either not prepared or were rejected.
2. Accurate estimates were not supported by objective benchmarks.
3. Change control was not handled effectively.
4. Quality control was inadequate.
5. Progress tracking did not reveal the true status of the project.
6. The contracts omitted key topics such as quality and out of scope changes.

During Level 4’s work with government agencies and private companies, we have identified ten estimation best practices that are predictors of healthy project governance and successful project performance.   This article shares those best practices.
 
One: Estimate early and often. Leading agencies prepare cost estimates at the idea stage, well before a project even becomes a project. These early stage estimates support effective governance by providing the basis for accurate analysis of the costs and benefits of competing initiatives. Lagging agencies have only a vague idea of project cost at the idea stage, and select projects largely based on the personality and energy of the sponsor. Leading agencies update cost estimates throughout the project life, using these estimates to support alternative and feasibility analysis, budgeting, acquisition, and scope management. Lagging agencies prepare estimates once, then don’t revise those estimates until the project exceeds the planned budget.
 
Two: Require independence. Leading agencies prepare independent government cost estimates using estimators that are independent from the initiative being estimated. Leading agencies are aware that government estimates prepared by the individuals closely associated with the project have a built-in bias toward underestimation ranging from 17% to 32% . Lagging agencies rely on contractor estimates, even though contractors have an inherent conflict of interest that prevents them from achieving true objectivity in estimation.
[…to be continued]

1. Project level sizing components that apply to the entire project.
2. Application software sizing components.
3. Data conversion sizing components.
4. Data warehouse sizing components.
5. Application support sizing components.

This month we’ll continue our discussion of ExcelerSize object modifiers, focusing on Area.
 
Area is another form of complexity modifier that increases/decreases the assigned FPE based on the selection. It differs from complexity in that it is more objective. Area may also be used as a sort/filter parameter by project managers when assigning work.
 
Area settings may vary by HLO catalog. For ExcelerSize the available settings are (discussed on the following slides):

• Application Service Provider (ASP).
• Internally Developed.
• Vendor Package.
• Vendor Software Upgrade.
• Module-Core.
• Module-Very Complex.
• Module-Complex.
• Module-Typical.
• Module-Simple.
• Module-Very Simple.
• User Experience Only.

These settings have the following meanings:
Application Service Provider (ASP): The software runs on a central server with each client having their own data space and data configuration.
 
Internally Developed: The software is/was developed by this organization, or customizations have created a situation where the software is completely unique to this organization.
 
Vendor Package: The software is a COTS package, typically with configurations and extensions for each customer.
 
Vendor Software Upgrade: This component is a customer specific modification to a vendor package.
 
User Experience Only: The effort estimate will be for the user experience design only.
 
Module Complexity: These are primarily used for work that involves modifications to a large, existing system. Typically this will be changes to a COTS product such as SAP, although they could be useful for a large, stable internal application where you are estimating small enhancement efforts.

• Module refers to an integrated but separately purchased component of the system. Examples for SAP would include R/3 (core), Human Resources, Financial, Asset Management, and Production Planning.
• Module complexity refers to how difficult it is to make changes within that module. It is based on the inherent complexity of the module itself, not the work for this HLO catalog item. So once it is defined for a module it will normally not change.
• If you will be doing on-going estimation for a large system (e.g., SAP), you should do an inventory of installed modules and assign the complexity settings to each module one-time, then use those settings going forward.
• Module complexity are a normal curve, so roughly 5% VC, 25% C, 40% T, 25% S, 5% VS.