10 Step Estimating Process Checklist – this should be tuned to the individual companies needs.
10 Step Summary
| Estimation Step | |
| 1. Define Scope & Purpose | |
| 2. Identify Technical Baseline and GR&A | |
| 3. Collect Data | |
| 4. Software Sizing (new and reused) | |
| 5. Prepare Baseline Estimate | |
| 6. Identify Risk items | |
| 7. Estimate Validation and Review | |
| 8. Build a Project Plan | |
| 9. Document Estimate | |
| 10. Track Project |
| Ground Rules | |
| Assumptions | |
| Risks |
Step One: Establish Estimate Scope and Purpose
The first step in the journey of software estimation is to establish the estimate’s scope and purpose. This is the foundation upon which the entire estimation process is built, and it’s crucial to get it right.
| Initials of Analyst when Complete | Item | Notes/Description |
| Identify the Scope; is this an EAC, ETC… Also, is integration of this software to other software included? If so, list the other programs that it integrates with that are included here. A portion of SEIT? | ||
| Define the purpose of the estimate (to determine cost, schedule, staffing…) | ||
| Point of Contact: establish one or more points of contact: technical data, contract data, requirements information… |
Step Two: Establish Technical Baseline, Ground Rules and Assumptions
The second step in the software estimation process is to establish the technical baseline, ground rules, and assumptions. This step is crucial in setting the stage for a realistic and reliable estimate.
| Initials of Analyst when Complete | Item | Notes/Description |
| Technical baseline. This description will be used as the WBS structure to enter into SEER-SEM. This must include at a minimum each CSCI, their relationship to each other and the outside world (integration), and any currently planned builds/deliveries. Builds/deliveries must be clearly identified, non-delivered builds are much less expensive than actual deliveries. | ||
| Ground rules: a list of all the known conditions surrounding the development (e.g. developer must use DO178b…) | ||
| Assumptions: a list of all the information necessary to complete an estimate, but not available to the analyst (e.g. hardware will be available when needed…) |
Step Three: Collect Data
The third step in the software estimation process is data collection.
| Initials of Analyst when Complete | Notes/Description and Source of the Estimate/Actuals | Item |
| Customize the SEER-SEM data collection worksheets. (i.e. fill in all the parameters that you can using the available documentation so as to minimize the time required from the customer.) | ||
| Complete the customized SEER-SEM data collection worksheets for each CSCI (major computer program). | ||
| Review the data for reasonableness. | ||
| Re-check any parameters in question with the contractor/developer (if possible) |
Step Four: Software Sizing
The fourth step in the software estimation process is sizing. This step is all about determining the size of the software that will be developed, which is a critical factor in estimating the cost, effort, and duration of the project.
| Initials of Analyst when Complete | Item | Notes/Description and Source of the Estimate/Actuals |
| Size estimate for all new software to be developed (least, likely, and most). (Make sure the SLOC or Function Point definition is clear) | ||
| Size actuals/estimate for all pre-existing code to be used. | ||
| ReWork parameters evaluated for all pre-existing software. | ||
| All COTS software identified. | ||
| Secondary methodology used for the size estimates. | ||
| Growth factors applied to size estimates. | ||
| Any prototyped code identified. |
Step Five: Prepare the Baseline Estimate
The fifth step in the software estimation process is to prepare the baseline estimate.
| Initials of Analyst when Complete | Item | Notes/Description |
| Enter all the data in SEER-SEM | ||
| Input notes for each parameter (even if the note says KBase used) | ||
| Analyst review the inputs to make sure they are correct | ||
| Analyst review the outputs to make sure things look right. (This will be done in MUCH more detail in Step 7) | ||
| Analyst and developing contractor together review the inputs (if possible) to either make sure the 2 parties are in agreement, of the differences are documented. | ||
| In a spreadsheet (or similar document) make a comparison of this baseline estimate to the previous one. (if one exists). Note the differences between each estimate. (Use Estimate Track.xls as a basis for the format.) |
Step Six: Quantify Risks and Risk Analysis
The sixth step in the software estimation process is to quantify risks and perform risk analysis.
| Initials of Analyst when Complete | Item | Notes/Description |
| List all the Risks associated with the development of each CSCI (major software program) | ||
| Determine which risks will be included in the estimate (document these decisions in the Ground Rules and Assumptions) | ||
| Decide how to “show/brief” the risks: all included in the estimate; included in the estimate one at a time to show the potential impact of each risk individually . . . |
Step Seven: Estimate Validation and Review Checklist
(This is just a checklist to review the estimate, not the actual estimate process.)
| Initials of Analyst when Complete | Item | Notes/Description |
| Productivity: does the estimated productivity look reasonable within the industry standards and the developing organizations current ability | ||
| Staffing: can/will the developing organization be able to meet the estimated required staffing plan currently and in the future | ||
| Size: have the size estimates been checked for reasonableness and is growth included | ||
| Top 10 Cost Drivers: do the top 10 cost drivers match the program (i.e. if Security is a top cost driver, does the program indeed require security . . .) | ||
| Schedule: if the schedule doesn’t fit into the “master” schedule for the program, what has been done | ||
| Risk: have risks been identified and included in the estimate. Also check the risk/confidence level used to create the estimate. | ||
| Cost: if cost is being used, has the labor rate been verified and a list of costs/included been checked |
Step Eight: Prepare a project plan based on the estimate
The eighth step in the software estimation process is to generate a project plan. (SEER-SEM Client for Microsoft Project is the tool to do this.)
Step Nine: Document the estimate and the lessons learned
The ninth step in the software estimation process is to document the estimate and lessons learned.
| Initials of Analyst when Complete | Item | Notes/Description |
| Verify that each parameter selected has an associated note/rationale. | ||
| If there is more than one version of the estimate, verify that each are properly documented | ||
| Make sure the ground rules and assumptions are attached to the estimate. | ||
| Document any special circumstances surrounding the estimate (e.g. estimate done for schedule only . . .) |
Step Ten: Track the project throughout the development
The last step in the software estimation process is to update the estimate.
| Initials of Analyst when Complete | Item | Notes/Description |
| Collect the required data using the SEER-PPMC Metrics Collection data form. | ||
| Using your baseline estimate, enter the data collected above into SEER-PPMC. | ||
| Present and use the data as required by your program. |
The evolution of estimation practices, challenges and best practices, and the utilization of advanced cost estimation tools to transform the estimation of notional project design from a complex challenge into a strategic asset in project management….
In the architectural marvel that is modern business, ESG (Environmental, Social, and Governance) stands as the foundational pillar, especially within the manufacturing sector. Just as a well-constructed building requires a solid foundation, every ESG component ensures a manufacturing enterprise’s stability, resilience, and longevity….
WHAT IS A ROM AND WHY DO I NEED ONE? Project managers—whether they work for a software development company, a manufacturing company, or an engineering design firm—are faced with the common challenge of estimating…
Quantitative software measurement extends significant benefits to IT organizations. Relatively few successful, robust, and mature measurement frameworks have been implemented. Function Pointscontinues to be the “de facto” standard for software measurementaround the world. “When…
Share this:
Get access to news
Sign up to get relevant news in your inbox - never miss it!
