The are numerous conjectures about waste of software project estimates. Most are based on personal opinion divorced from the business processes of writing sofwtare for money.
From the Introduction of the book to the left.
Good estimates are key to project (and product) success. Estimates provide information to make decisions, define feasible performance objectives, and plans. Measurements provide data to gauge adherence to performance specifications and plans, make decisions, revise designs and plans, and improve future estimates and processes.
Engineers use estimates and measurements to evaluate the feasibility and affordability of proposed products, choose amoung alternatives designs, assess risk, and support business decisions. Engineers and planners estimate the resources needed to develop, maintain, enhance, and deploy a product. Project planners use the estimated staffing level to identify needed facilities.
Planners and managers use the resource estimates to compute project cost and schedule, and prepare budgets and plans. Estimates of product, project and process characteristics provide "baselines"to assess progress the execution of the project. Managers compare compare estimates and actual values to identify deviations from the project plan and to understand the causes of the variation.
For products, engineers compare estimates of the technical baseline to observed performance to decide if the product meets its functional and operational requirements. Process capability baselines establish norms for process performance. Managers use these norms to control the process and detect compliance problems. Process engineers use capability baselines to improve the production process.
Bad estimates affect everyone associated with the project - the engineers and managers, the customer who buys the product, and sometimes even the stockholders of the company responsible for delivering the software. Incomplete or inaccurate resource estimates for a project mean that the project may not have enough time and money to complete the required work.
If you work in a domain where none of these conditions are in place, then by all means don't estimate.
If you do recognize some or all of these conditions, then here's a summary of the reasons to estimate and measure, from the book.
- Product Size, Performance, and Quality
- Evaluate feasibility of requirements
- Analyze alternative product designs
- Determine the required capacity and performance of hardware.
- Evaluate product performance - accuracy, speed, reliability, availability, and all the ...ilities. (ACA web site missed answering this question).
- Identify and assess technical risks
- Provide technical baselines for tracking and controlling - this is called Closed Loop Control. No steering targets with measures of actual performance assessed against desired performance is called Open Loop Control.
- Project Effort, Cost, and Schedule - yes Virginia real business managers need to know when you'll be done, how much it will cost, and what you'll deliver on that day for that cost. And yes Virginia there is no Santa Claus
- Determine project feasibility in terms of cost and time
- Identify and assess project risks - Risk Management is how Adults Manage Projects - Tim Lister
- Negotiate achievable commitments
- Prepare realistic plans and budgets
- Evaluate business value - cost versus benefit is how business stay in business
- Provide cost and schedule baseline for tracking and controlling
- Process Capability and Performance
- Predict resource consumption and efficiency
- Establish norms of expected performance - back to the steering targets
- Identify opportunities for improvement.
