| Requirement Creep: I’m often asked about approaches to dealing with changing requirements during the life of the project. Capers Jones found that requirements tend to change at the rate of 9% to 18% per year, with a mean of about 1% change per month. I’ve found that organizations with tight scope management, which includes many government projects, can reduce the rate of requirement change to between 3% and 12% per year, with a mean of 7% per year. ExcelerPlan uses 7% as the default for these projects, but allows adjustments for specific projects. |
|
|
| MB-Level 4 in Germany closed a deal to provide ExcelerPlan to a large manufacturing organization. |
|
|
All times are Pacific Time!
Free WebEx
Estimating with ExcelerPlan
5/14, 11 AM-12:30 PST
5/28, 11 AM-12:30 PST
6/11, 11 AM-12:30 PST
6/25, 11 AM-12:30 PST
7/9, 11 AM-12:30 PST
7/23, 11 AM-12:30 PST
To register for demos, email:
Edward@portal.level4ventures.com |
|
|
Three Day Estimation Training
We’ll be offering a 3 day estimation training class taught by William Roetzheim via Webex on 5/5, 5/6, and 5/7. Class runs from 9 AM – 1 PM Pacific Time each day.
To inquire about registration email:
Edward@portal.level4ventures.com |
|
|
Estimating Tools on GSA
I was doing a search on the GSA Advantage eLibrary, looking for competing estimation tools that were available on the GSA Schedule 70. The only tool I could find that was available was ExcelerPlan. If you’re aware of other cost estimation tools that are available on the GSA Schedule 70, I’d be curious in hearing about them. Or if we really are the only tool that’s available, that’s all the more reason to buy ExcelerPlan!
Edward
Director of Sales and Marketing
|
|
|
|
|
| Sign up for a 3 day live Webex class, taught by William Roetzheim, to be conducted on 5/5-5/7 and receive a 30 day trial copy of ExcelerPlan. |
|
|
|
|
|
|
 Some Causes of Poor Estimates: I used to conduct a simple experiment when lecturing about cost estimating. I would tell my audience to estimate the total monetary value of all coins in the pockets and purses of people in this room. You have 10 seconds to come up with your estimate and write it on a piece of paper.
Then for the second part of the experiment I would have people “Estimate the same total again. This time, take sixty seconds to estimate. Write down your estimate.”
By tabulating the estimates (both versions) and comparing the result with actual numbers, we consistently found that the second estimate was more accurate. This was not surprising, as with more time people could do things like count the number of people in the room. But the real point came next. By a show of hands, I consistently found that about half the people had exactly the same estimate both times. This experiment demonstrated the fact that once people make an estimate, they are reluctant to deviate from that estimate. And the more they commit to an estimate (as in writing it down, or doing a presentation to management), the more reluctant they are to change the estimate even when later facts provide better information. In fact, for most people (and organizations), the majority of project estimates are one of these non-estimates:
- New estimate = last estimate
- New estimate = last estimate + permissible slip
- New estimate = last estimate – past slip
- Estimate = expected right answer
- Estimate = expected right answer + X
We’ll continue to explore causes of poor estimates next month.
|
| |
|
William@portal.level4ventures.com
|
|
|
 |
|
|
|
ExcelerSize: Last month we discussed 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 discuss application software sizing components. These are the workhorse components of your estimation catalog. Most projects will have some of them, and many projects will consist exclusively of this component area. Application software sizing components are:
- Batches: Processes that accept inputs, do processing, and create outputs.
- Business Requirements: Requirements that require development work but that are not understood enough yet (technically) to size with another component.
- Extensions: Coded functionality that is added to an existing, stable application.
- Forms (Inbound and Outbound): Predefined documents, normally in PDF, with mappings and connectors that allow data to move between the form and the database.
- Interfaces: Connectors (normally asynchronous) between computer applications or devices.
- Page: User interface page, including behind the scenes logic and data persistence layer.
- Report: Online or hard copy output, including behind the scenes logic and data persistence layer.
- Service: Discrete process to process (or process to device) function, normally synchronous.
- Table: Table in a database.
- Workflow: Collection of rules for document or process flow (the document and the workflow are counted separately).
Next month we’ll continue this discussion, talking about data conversion sizing components.
|
|
|
|
|
[This guest column reprinted with permission from: “MINIMIZING THE RISK OF LITIGATION: PROBLEMS NOTED IN BREACH OF CONTRACT LITIGATION,” Capers Jones, July 2014. Full article available on http://Namcookanalytics.com]
[Editor: This column continues the discussion of litigation risk factors from last month’s edition.]
Problem 4: Poor Software Milestone Tracking
Once a software project is underway, there are no fixed and reliable guidelines for judging its rate of progress. The civilian software industry has long utilized ad hoc milestones such as completion of design or completion of coding. However, these milestones are notoriously unreliable. Tracking software projects requires dealing with two separate issues: 1) Achieving specific and tangible milestones; 2) Expending resources and funds within specific budgeted amounts.
Every milestone should be based on completing a review, inspection, or test. Just finishing up a document or writing code should not be considered a milestone unless the deliverables have been reviewed, inspected, or tested. In the litigation where the author worked as an expert witness, these criteria were not met. Milestones were very informal and consisted primarily of calendar dates, without any validation of the materials themselves. Also, the format and structure of the milestone reports were inadequate. At the top of every milestone report problems and issues or “red flag” items should be highlighted and discussed first. Failing or delayed projects usually lack of serious milestone tracking. Activities are often reported as finished while work was still on going. Milestones on failing projects are usually dates on a calendar rather than completion and review of actual deliverables.
In more than a dozen legal cases involving projects that failed or were never able to operate successfully, project tracking was inadequate in every case. Problems were either ignored or brushed aside, rather than being addressed and solved. Because milestone tracking occurs throughout software development, it is the last line of defense against project failures and delays. Milestones should be established formally, and should be based on reviews, inspections, and tests of deliverables. Milestones should not be the dates that deliverables more or less were finished. Milestones should reflect the dates that finished deliverables were validated by means of inspections, testing, and quality assurance review.
Next month: Flawed Outsource Agreements that Omit Key Topics
Capers
|
|
|
|
 Dear Tabby:
My boyfriend likes crowds and big parties, but I prefer intimate dinners for two. He says that “it takes a village to create an estimate.” Does it really?
signed, Overwhelmed in Ohio
Dear Overwhelmed:
Most organizations use a bottom up approach to estimation, which requires that every group that will be impacted (e.g., project management, development, testing, engineering, etc.) needs to look at every project to create their estimate. With this approach, it really does require that a lot of people be involved in estimation. But a better (more efficient and more effective) approach is to use a small number of full-time estimators that estimate all projects. With that approach, a typical Fortune 300 company can meet all of the organization’s IT estimation requirements with 2-3 estimators plus a part-time manager and a part-time administrative support person.
signed, Tabby
|
|
|
|
|
Sneak Peak: Export
Version 7.2 of ExcelerPlan is currently in beta testing. The most significant new feature is an export capability to various file formats, notably Clarity and Microsoft Project. One of the big advantages of this new ExcelerPlan capability is that your Clarity PPM and Microsoft Project plans will now include detailed resource allocations for each project month based on the optimal labor distributions calculated by ExcelerPlan. If you’d like to test the beta release, or suggest additional target interfaces for version 7.2, email william@portal.level4ventures.com.
|
|
|
|
|
|
