| We mentioned elsewhere that ExcelerPlan automatically includes a budget for defect repair as part of your estimate. That estimate is based on defect rates in accordance with the benchmark rates, which are displayed on the Results-Maintenance worksheet. If your defect rate is significantly higher than the forecast defect levels, you may use the Defect Repair HLO object to estimate the cost of fixing those higher than anticipated defects. But be careful, because if you exceed the benchmark defect levels by too much, you’re in a recovery/turnaround situation, which is a topic we’ll be discussing next month. |
|
|
| Level 4 received an estimation related contract with the Department of General Services. |
|
|
All times are Pacific Time!
Free WebEx
Estimating with ExcelerPlan
8/13, 11 AM-12:30 PST
8/27, 11 AM-12:30 PST
9/10, 11 AM-12:30 PST
9/24, 11 AM-12:30 PST
10/8, 11 AM-12:30 PST
10/22, 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 |
|
|
Pay it Forward
Hopefully you’re finding ITCN a useful newsletter providing estimation related value added each month, along with a bit of humor and minimal selling. If so, please use the link below to Forward to a Friend, or if this copy was forwarded to you, to subscribe yourself.
Edward
Director of Sales and Marketing
|
|
|
|
|
| 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. |
|
|
|
|
|
|
When do we estimate? When people think about estimation for a project, the tendency is to think of this as a one-time event that happens sometime during planning. But the reality is that multiple estimates will be prepared for the same project, at different points in time and for different purposes. Let’s look at the most common estimation events.
Feasibility Study/governance/budgeting: An organization will need to take multiple candidate projects; estimate the costs and benefits of each; select those that offer the greatest value; and budget for the selected work.
Project implementation or acquisition: You’ll need to estimate the time and effort, then break that down by WBS task and labor role as part of your project planning for implementation work. If you’ll be buying the solution as part of an acquisition, you’ll need to do a cost reasonableness and cost realism analysis.
Change control during project execution: During the project there will be some scope changes. Those scope changes need to be estimated so that you’ll know the impact on the cost, schedule, and level of effort for each proposed change in scope.
Recovery/Turn-around: A special type of estimation work is required in a recovery or turn-around situation for troubled projects. A big part of this work involves analyzing the quality/usability of work performed to date so that an accurate estimate of work to complete the project can be prepared.
Transition to M&O: After a project is deployed, it transitions to a maintenance and operations mode where there are on-going annual costs to keep the system operational, and those costs must be estimated.
Transition from vendor to customer operation: It’s common for the system integrator to operate the newly deployed system for a period of time, but eventually the system will often transition to maintenance and operation by the customer organization. The cost of this transition process, and the final costs to maintain and operate the system by the customer organization, both must be estimated.
Next month we’ll discuss recovery/turn-around estimation in more depth.
|
| |
|
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 discuss application support sizing components. The components we’ll discuss are configuration; defect repair; patch; and RA Uplift. When counting application support components, it’s important to not double count in situations where support is built in to other components. For example, each ExcelerSize component includes an allowance for effort to repair defects introduced when the component is built. Counting each forecast defect separately would be double counting.
Configuration: A configuration change is a set of data that is entered and that then drives application behavior. Examples include security roles; payroll tax settings; and firewall configuration settings.
Defect Repair: Used to estimate the work to repair an existing defect. Repair of defects introduced during development is included with the development catalog element (e.g., report, page). This item is for pre-existing defects. Typically, this is used for a remediation project to come in and clear a defect backlog.
Patch: Used to estimate the effort required to install a vendor software patch. Patches are different from upgrades in that functionality does not change. Patches installed during a project are already included in that project budget. This is for estimating a small stand-alone project to install a vendor patch.
RA Uplift: A Reference Architecture (RA) is a set of closely related infrastructure components. Examples would be .Net, Internet Explorer, Oracle 11g. An uplift is a version upgrade.
Next month we’ll discuss ExcelerSize object modifiers.
|
|
|
|
|
[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.]
Summary and Results
Successful software projects can result from nothing more than avoiding the more serious mistakes that lead to disaster: 1) Look at the actual benchmark results of similar projects; 2) Make planning and estimating formal activities; 3) Plan for and control creeping requirements; 4) Use formal inspections as milestones for tracking project progress; 5) Include pre-test static analysis and inspections in quality control; 6) Collect accurate measurement data during your current project, to use with future projects; 7) Make sure with attorneys that contracts have suitable clauses for requirements growth and quality levels of delivered materials. Omitting these two topics can lead to very expensive litigation later.
Overcoming the risks shown here is largely a matter of opposites, or doing the reverse of what the risk indicates. Thus a well-formed software project will create accurate estimates derived from empirical data and supported by automated tools for handling the critical path issues. Such estimates will be based on the actual capabilities of the development team, and will not be arbitrary creations derived without any rigor. The plans will specifically address the critical issues of change requests and quality control. In addition, monthly progress reports will also deal with these critical issues. Accurate progress reports are the last line of defense against failures.
Capers
|
|
|
|
 Dear Tabby:
My girlfriend keeps telling me that she’s too busy for a date because she need to analyze the requirements for 50 custom reports so she can figure out how many are highly complex; how many are average; and how many are simple. Does this seem like a good excuse to you?
signed, Waiting in Wichita
Dear Waiting:
I think you might want to start looking for a new girlfriend. The Central Limit Theorem (CLT) tells us that for quantities over 30 the reports can all be considered average with no loss in accuracy. In fact, the CLT often applies for quantities as low as 10 or 15 if the items being estimated are typical (i.e., not skewed). So there is no reason for her to be determining the complexity of each individual report.
signed, Tabby
|
|
|
|
|
Baseline
Version 7.2 adds a “Baseline” button to the Results-Summary worksheet. The most obvious impact of pressing this button is that the Baseline Size (FPE) is updated with the current project scope. Saving this value prior to updating the estimate will allow you to keep track of scope creep during the project. But starting with ExcelerPlan 7.2, we also maintain estimate trend data in the background, and pressing Baseline clears the trend data and starts collecting trend data going forward from this point in time. While not particularly useful at the moment, ExcelerPlan 7.3 (shipping in October) will display trend charts showing trendlines for things like size/scope, cost, effort, and performance. Version 7.2 introduces the trend capability in background so that estimates prepared now will have valid data when version 7.3 ships.
|
|
|
|
|
|
