In estimation you’ll often run into normal curves, and it’s common to need to classify things into five “bins.” for example, Very Small, Small, Average, Large, and Very Large. It’s helpful to remember that for a statistical sample (> 30 elements), we can treat them all as average with no loss of accuracy; and the distribution should be 5% VS, 25% S, 40% Average, 25% L, 5% VL. |
|
|
Level 4 received a new contract with Washington Liquor and Cannabis control board. |
|
|
All times are Pacific Time!
Free WebEx
Estimating with ExcelerPlan
10/8, 11 AM-12:30 PST
10/22, 11 AM-12:30 PST
11/12, 11 AM-12:30 PST
12/3, 11 AM-12:30 PST
12/17, 11 AM-12:30 PST
To register for demos, email:
Jeff@portal.level4ventures.com |
|
|
Three Day Estimation Training We’ll be offering a 3 day estimation training class taught by William Roetzheim via Webex on 11/17, 11/18, 11/19. Class runs from 9 AM – 1 PM Pacific Time each day. Training is free and includes a 30 day trial license for new customers.
To inquire about registration email:
Jeff@portal.level4ventures.com |
|
|
Ten Estimation Best Practices
Request a free copy of our latest White Paper, Ten Estimation Best Practices. To receive the white paper, email:
Jeff@portal.level4ventures.com |
|
|
|
Sign up for a 3 day live Webex class, taught by William Roetzheim, to be conducted on 11/17-11/19 and receive a 30 day trial copy of ExcelerPlan. |
|
|
|
|
|
|

Ten Best Practices to Avoid IT Project Failure. As discussed in several recent issues of ITCN, a recent article by Capers Jones identified six primary predictors of software project failure, two of which are directly estimation related and two of which (change control and progress tracking) are supported by the estimation process. The six predictors were:
- Accurate estimates were either not prepared or were rejected.
- Accurate estimates were not supported by objective benchmarks.
- Change control was not handled effectively.
- Quality control was inadequate.
- Progress tracking did not reveal the true status of the project.
- 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]
|
|
William@portal.level4ventures.com
|
|
|
 |
|
|
ExcelerSize: This month we continue our discussion of ExcelerSize, a Level 4 proprietary high level object (HLO) catalog set designed to size IT projects excluding purchased other direct charges (ODCs) such as hardware and software licenses (which are covered using separate models). You’ll recall that the catalog elements are grouped into five major categories:
- Project level sizing components that apply to the entire project.
- Application software sizing components.
- Data conversion sizing components.
- Data warehouse sizing components.
- 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.
|
|
|
 |
|
[This guest column reprinted with permission from: “KEYS TO SUCCESS: SOFTWARE MEASUREMENT SOFTWARE ESTIMATING SOFTWARE QUALITY”, Capers Jones, April 2014. Full article available on http://Namcookanalytics.com]
[Editor: This column extracts and summarizes points from the above presentation.]
The following conclusions were reached based on a study of 50 manual versus automated estimates:
- Manual estimates work well < 250 function points.
- Automated estimates are more accurate > 250 function points.
- > 5,000 function points manual estimates are dangerous.
- Automated estimates are usually accurate or conservative.
- Manual estimates grow more optimistic as size increases.

Capers
|
|
|
Dear Tabby:
My friend keeps hanging around with programmers that are real losers. I tell her that they’re dragging her down, but she won’t listen.
signed, Ignored in Indianapolis
Dear Ignored:
There are programmers that have negative productivity. The effort associated with repairing the defects introduced by these developers will actually outweigh the value of the working code that they do write. In some cases this is due to lack of experience, in which case the best approach is a combination of training and restricting the type of work they do to areas that have limited scope. In other cases it is a simple lack of programming aptitude. In that situation, you might investigate reassigning them to the test/QA team. Our experience has been that developers without a strong programming aptitude are often very good at white box testing.
signed, Tabby
|
|
|
 |
Enhanced Export
Version 7.3 (shipping October) adds an enhanced export to Microsoft Project capability. Task dependencies are now exported. You can optionally add a generated task representing the work required for warranty support. Perhaps most important, you can now export hours by labor cost pool (e.g., government versus contractor), and select the specific cost pools to include in the generated Microsoft Project Plan.
|
|
|
|
|
|