Good estimates are the key to project success. Estimates provide information to the decision makers to assess adherence to performance specifications and plans, make decisions, revise designs and plans, and improve future estimates and processes.
We use estimates and measurements to evaluate the feasibility and affordability of products being built, choose between alternatives designs, assess risk, and support business decisions. Engineers compare estimates if technical baselines of observed performance to decide of the product meets its functional and performance requirements. These are used by management to control processes and detect compliance problems. Process manager use capability baselines to improve production processes.
Developers, engineers, and planners estimate resources needed to develop, maintain, enhance and deploy products, Project planners use estimates for staffing, facilities. Planners and managers use estimates for resources to determine project cost and schedule and prepare budgets and plans.
Managers compare estimates - cost and schedule baselines - and actual values to determine deviations from plan and understand the root causes of those deviations needed to take corrective actions. Estimates of product, project, and process characteristics provide baselines to assess progress during the project.
Bad estimates affect all participants in the project or product development process. Incomplete and inaccurate estimates mean inadequate time and money available for increasing the probability of project success.
The Nature of Estimation
The verb estimate means to produce a statement of the approximate value of some quantity that describes or characterizes an object. The noun estimate refers to the value produced by the verb. The object can be an artifact - software, hardware, documents - or an activity - planning, development, testing, or process.
We make estimates because we cannot directly measure the value of that quantity because:
- The object is inaccessible
- The object does not exist yet
- The Measurement would be too expensive
Reasons to Estimate and Measure Size, Cost and Schedule
- Evaluate feasibility of requirements.
- Analyze alternative designs and implementations.
- Determ required capacity and speed of produced results.
- Evaluate performance - accuracy, speed, reliability, availability and other ...ilities.
- Identify and assess technical risks.
- Provide technical baselines for tracking and guiding.
Reasons to Estimate Effort, Cost, and Schedule
- Determine project feasibility in terms of cost and schedule.
- Identify and assess risks.
- Negotiate achievable commitments.
- Prepare realistic plans and budgets.
- Evaluate business value - cost versus benefit.
- Provide cost and schedule baselines for tracking and guiding.
Reasons to Estimate Capability and Performance
- Predict resource consumption and efficiency.
- Establish norms for expected performance.
- Identify opportunities for improvement.
There are many sources of data for making estimates, some reliable some not. Human subject matter expert based estimates have been shown to be the least reliable, accurate and precise due to the biases involved in the human processes of developing the estimate. estimates based on past performance, while useful, must be adjusted for the statistical behaviors of the past and the uncertainty of the future.
If the estimate is misused in any way, this is not the fault of the estimate - both noun and verb - byt simply bad management. Fix that first, then apply proper estimating processes.
If your project or product development effort does none of these activities or has no need for information on which to make a decision, then estimating is likely a waste of time.
But before deciding estimate are the smell of dysfunction, with NO root cause identified for corrective action check with those paying your salary first, to see what they have to say about your desire to spend their money in presence of uncertainty with the absence of an estimate to see what they say.
† This post is extracted from Estimating Software Intensive Systems: Project, Products and Processes, Dr. Richard Stutzke, Addison Wesley. This book is a mandatory read for anyone working in a software domain on any project that is mission critical. This means if you need to show up on or before the need date, at or below your planned cost, with the needed capabilities - Key Performance Parameters , without which the project will get cancel - then you're going to need to estimate all the parameters of your project, If your project doesn't need to show up on time, stay on budget, or can provide less than the needed capabilities, no need to estimate. Just spend your customer's money, she'll tell you when to stop.