Software estimation demystifying the black art

1. 1Name the milestone you are actually at, not the one the calendar says. Use the Cone's milestones: Initial Concept, Approved Product Definition, Requirements Complete, User Interface Design Complete, Detailed Design Complete, Software Complete. If the product definition is not agreed, you are at Initial Concept, whatever the schedule claims.
2. 2Audit decisions, not dates. Uncertainty comes from how undecided feature-related issues will be resolved, so list the open scope decisions: which features are in or out, how they behave, how the interface works. Progress is the share of those decisions made.
3. 3Read the Cone's variability at that milestone and treat it as the best case. The vertical axis shows the error found in estimates made by skilled estimators. At the widest point the figure's label is 4x, and the labels narrow toward 1.25x and 1.0x. Unskilled or rushed estimates will not beat that band.
4. 4Present the estimate as a range with that width. Do not collapse it into a single number. The Cone says the estimate is subject to predictable uncertainty at this stage, so a point value overstates what you know.
5. 5Match the decomposition grain to the stage. Early, estimate by feature area. Later, by marketing requirements. Then by detailed or engineering requirements. In the endgame, by developer and tester task-based estimates. Finer slices before the decisions exist create false precision.
6. 6Schedule the decisions that narrow the Cone. The Cone does not narrow itself, and only resolved decisions shrink it. Early decisions are few but carry very high impact, so settle product definition and top-level requirements first.
7. 7Re-estimate at each milestone and record the range. Compare the new range with the old one to see whether the narrowing you expected actually occurred.
8. 8Bias the first number upward. The industry has an underestimation problem rather than a neutral one, so the key challenge is to make estimates bigger. Place the commitment where the current Cone width can absorb it.

The passages give the Cone's shape but no worked project, so this is an illustration built on the figure's labels. A team at Initial Concept produces a 20-staff-month estimate. The Cone's top label at that stage is 4x, so the honest upper bound is about 80 staff months. The estimate does not hold up as a single number. The team then settles the Approved Product Definition, which means few, very high-impact decisions are resolved. They re-estimate and the range tightens. Late in the project, the labels show only 1.25x of error, which is tight enough to commit against. The same data also shows why early commitment is risky. At Initial Concept, a number close to the low end sits at the bottom of a range that is 4x wide. Task-based estimates then replace feature-area estimates as decisions get finer-grained. The pattern follows the source's logic that the number of decisions grows while the impact of each one shrinks.

• If the product definition is not approved, then quote a wide range and do not commit to a point value. You are still at the widest part of the Cone.
• If a stakeholder asks for a tighter estimate without new decisions, then name the open decisions and offer to narrow the range after they are made. The Cone does not narrow itself.
• If the estimate is being built from developer and tester tasks while requirements are still moving, then step back to feature-area or requirements-level decomposition. Granularity should follow project progress.
• If your range is narrower than the Cone allows at this milestone, then widen it. Skilled estimators land inside the Cone, so a narrower band signals overconfidence or pressure.
• If you must pick between a high and a low single number, then choose the higher one. The industry's systematic error is underestimation.

• Treating the Cone as a calendar. The tell: you claim a milestone by date while major scope decisions, such as features in or out, are still open.
• Expecting estimation skill to beat the Cone. The tell: a narrow range at Initial Concept, justified by 'we are experienced.' The Cone already reflects skilled estimators.
• Waiting for the Cone to shrink on its own. The tell: no one owns resolving requirements, and the range stays the same across several re-estimates.
• Over-decomposing too early. The tell: a detailed task list built before top-level requirements are settled, giving a precise-looking number with a wide actual error.
• Collapsing the range to one number under pressure. The tell: the plan carries only a single figure, and the underestimation pattern that the passages describe as typical of the industry follows.

• ▸Date of estimate: record when the estimate was made.
• ▸Current milestone: pick one of Initial Concept, Approved Product Definition, Requirements Complete, User Interface Design Complete, Detailed Design Complete, Software Complete.
• ▸Evidence for milestone: state the decision or artifact that proves you reached it.
• ▸Open scope decisions: list the feature-related decisions still unresolved and who owns each.
• ▸Cone variability at this milestone: copy the multiplier from Figure 4-1 for this stage (4x at the widest).
• ▸Point estimate: the central number, effort, cost, or features.
• ▸Range to communicate: apply the Cone variability to the point estimate and write the resulting range.
• ▸Decomposition grain used: feature area, marketing requirements, detailed requirements, or developer and tester tasks, and whether it fits the milestone.
• ▸Decisions planned before next re-estimate: list what must be settled and the next milestone check.

1. 1Set the accuracy bar by decision utility, not by the tightest number. The source separates the 'science' of estimation (sophisticated organizations moving from ±10% to ±5%) from the 'art' (the typical organization trying to avoid errors of 100% or more). Techniques in the 'art' set cut error to about 25% or less, which the source calls 'about as useful as most projects need.' Write down the control decisions the estimate must support, such as scope cuts, staffing, or date commitments. Judge the estimate against those decisions.
2. 2State every estimate as a range with a stated confidence, not a single point. The source frames estimates as probability statements. Its test is a range 'just wide enough to give you a 90% confidence in including the correct answer.' Write the low and high figures and the confidence they carry.
3. 3Calibrate your ranges before trusting them. Take the source's quiz approach: give 90%-confident ranges for quantities you do not know, then count how many fall inside. If far fewer than 90% of your ranges contain the true answer, your ranges are too narrow, which is the usual failure. Widen them. Software work routinely means estimating in unfamiliar domains, new technologies, and unidentified personnel, so wide ranges are normal.
4. 4Check where pressure toward narrow ranges comes from. The source reports that much of it is self-induced, from professional pride and the false belief that narrow means better. Verify that an external source is really demanding narrowness. Also note Jorgensen and Sjoberg's finding that customer expectations shift estimates and estimators are typically not conscious of it. Keep the estimate separate from the target you are being handed.
5. 5Anchor the estimate in data, not opinion. Use historical data and calibration, which the source says account for organizational influences, avoid subjectivity and unfounded optimism, and reduce estimation politics. Prefer a simple, explainable formula over a complex one. For example, Effort = NumberOfRequirements * AverageEffortPerRequirement, with the average taken from your own past projects. The source warns that complex formulas rest on assumptions that real projects undermine.
6. 6Estimate with several methods and compare. Plot each method's range. Discard overly generic methods that are not well founded, then look at where the remaining ranges converge. The source notes that including weak estimates hides the real convergence, and removing them makes it visible. Weight the better-founded methods more heavily.
7. 7Document the assumptions behind the estimate and re-estimate as the project's uncertainty narrows. The source treats the Cone of Uncertainty as a core source of estimation error and treats early estimates as inherently wide. Record what the estimate assumes about scope and requirements, and revisit it when those assumptions change.
8. 8Present the range and its confidence to project leadership in a form they can act on. The source points to percentage-confident and case-based presentations, and to Chapters 22 and 23 for handling pressure. Leadership should be able to see what level of control action the range implies.

The source gives the real-world baseline: across many studies (Standish Group, Jones, ISBSG, and others), about one quarter of projects are delivered on time, one quarter are canceled, and about half are late, over budget, or both. Apply it to a portfolio of four projects. You should expect roughly one on-time delivery, one cancellation, and two overruns, and decisions made on single-point estimates will not prepare you for that spread. Now take an organization whose estimates are off by 100% or more. The source says its priority is not the mathematically intensive work of improving ±10% to ±5%, because those techniques need strong math and commercial tools. Its priority is moving to roughly 25% error with simple methods. At 25% the estimate is accurate enough to support control decisions. At 100% error it cannot tell leadership whether a target is feasible. To get there, the team replaces a single date with a 90%-confident range. It checks that range against the quiz-style calibration test. It derives effort from NumberOfRequirements times an average effort per requirement taken from its own history, and it cross-checks with a second method. If the ranges converge, leadership decides on that overlap. If one method sits far from the others and is generic, the team drops it.

• If your organization's estimates miss by 100% or more, then adopt simple art-of-estimation techniques (ranges, historical data, simple formulas) before considering sophisticated mathematical models.
• If your 90%-confident ranges keep missing the actual value, then widen them. Narrow ranges are not a sign of a better estimate.
• If someone demands a narrower range, then first check whether the pressure is actually external or self-induced. If it is external, handle it through presentation and negotiation, not by shrinking the range.
• If multiple methods disagree, then remove the overly generic or poorly founded ones and look for convergence among the rest before committing.
• If a complex formula and a simple formula-plus-historical-average give similar answers, then use the simple one. It is easier to explain, check, and defend.

• Chasing precision instead of utility: spending effort on getting from ±10% to ±5% while the real error is 100% or more. The tell: sophisticated tools and tight numbers alongside projects that still blow their dates.
• Overconfident narrow ranges: ranges that contain the true answer well under 90% of the time. The tell: repeated surprises and an estimate of 'about X' that is never revised.
• Absorbing customer or management expectations unconsciously: the estimate drifts toward the desired answer without the estimator noticing (Jorgensen and Sjoberg's finding). The tell: the estimate lands conveniently on the target, and you cannot point to data that produced it.
• Trusting complex formulas over data: assuming a formula with many parameters must be more accurate than a simple one. The tell: the estimate cannot be explained, and its inputs are not drawn from your own history.
• Blending weak and strong estimates together: averaging in generic methods hides the real convergence. The tell: a wide, muddy composite range that supports no decision.

• ▸Decision this estimate must support: name the control decision (scope cut, staffing, date commitment) leadership will make from it.
• ▸Required accuracy: state the error level that decision can tolerate (the source treats about 25% or less as useful for most projects).
• ▸Estimate range (low / high): write both ends, not a single point.
• ▸Confidence level: state the probability the range contains the actual value (target 90%).
• ▸Calibration check: record how many of your last practice ranges contained the true answer. If well under 90%, widen.
• ▸Source of pressure on range width: mark self-induced or external. If external, name who and the target they gave.
• ▸Method 1 and its basis: name the technique and the historical data it draws on (e.g., NumberOfRequirements × your own average effort per requirement).
• ▸Method 2 range and convergence: record a second method's range, flag any generic or poorly founded method to exclude, and note where the remaining ranges overlap.
• ▸Key assumptions and re-estimate trigger: list assumptions (scope, requirements) and the change that forces a new estimate.

1. 1Separate three things in writing before work starts: the estimate (a prediction), the target (a desired business objective), and the commitment (a promise). The source's chapter 1 treats these as distinct concepts, and blurring them is a named cause of estimation problems. Control steers toward the target and the commitment. The estimate is the baseline you steer from, so it cannot be bent to match the target.
2. 2Build the baseline from a realistic estimate, not a hoped-for one. Use simple, understandable techniques (count, compute, judge, with calibration against historical data) rather than complex formulas. The source says the 'art' of estimation gets error to about 25% or less, which is as useful as most projects need. Typical organizations are instead off by 100% or more. Record the estimate as a range or probability statement, not a single number.
3. 3Review the estimate before you adopt it as the baseline. The source's data shows average error is lower for reviewed estimates than for off-the-cuff ones. Treat an unreviewed estimate as a draft, not a control baseline.
4. 4Write down the scope decisions that fix the baseline: what the project will deliver and what it will not deliver. The source says the Cone of Uncertainty does not narrow itself. You narrow it by making decisions that remove sources of variability, and those decisions go both ways (in-scope and out-of-scope).
5. 5Track requirements change against that baseline. Unstable requirements are a named source of estimation error, and the source includes a Cone variant that allows for requirements increases. Plan for some growth explicitly. When a scope decision is reversed, treat it as widening the Cone and re-estimate rather than absorbing it silently.
6. 6Steer actively across all three levers: scope, resources, and schedule. When actuals diverge from the baseline, choose which lever to adjust (cut or defer scope, change resources, move the schedule) and re-forecast. Do not just let the divergence accumulate. Avoid the 'Cloud of Uncertainty', which the source says arises when a project is neither well controlled nor well estimated and carries more error than the Cone represents.
7. 7Feed the outcome back into the next baseline. Boeing's improvement came with historical data used for all project estimates. Keep completed-project actuals so the next estimate is calibrated, because estimation accuracy and project control reinforce each other.
8. 8Treat predictability as the goal alongside speed. The source notes that, offered a shorter average schedule with higher variability or a longer one with lower variability, most businesses choose the second. Control effort should aim at reducing variability, not only at hitting a date.

The source shows what control plus estimation does at the organization level. Schlumberger improved its estimation results from an average overrun of 35 weeks to an average underrun of 1 week over successive half-year periods. Boeing's estimation error shrank as its organizations reached higher CMM levels, and in the strongest results historical data was used for all project estimates. U.S. Air Force projects showed the same pattern of dramatically improved predictability at higher CMM levels. The source reports that one client delivers 97% of its projects on time and within budget, and that Telcordia reported 98%. Its conclusion is that accurate results 'cannot be accomplished through estimation practices alone'; they must also be supported by effective project control. Contrast this with the typical organization in the source, whose estimates run about 100% low and where about three quarters of projects are late or fail. The practical reading: an estimate is a baseline, and leadership then manages scope, resources, and schedule against it. The source's own illustration is the Cone of Uncertainty. It narrows only because decisions about what to deliver and what not to deliver remove variability, and it widens again if those decisions change.

• If someone hands you a date and calls it an estimate, then classify it as a target, produce an independent estimate, and steer by comparing the two rather than adjusting the estimate to fit.
• If an estimate has not been reviewed or calibrated against historical data, then do not lock it as the control baseline. Off-the-cuff estimates carry higher average error.
• If a scope or requirements decision is reversed or new requirements arrive, then expect the Cone to widen: re-estimate and pick a lever (scope, resources, schedule) explicitly rather than absorbing the change.
• If the project is both poorly controlled and poorly estimated, then expect the Cloud of Uncertainty (error beyond the Cone) and fix scope stability and the baseline before debating precision.
• If you are tempted to adopt a complex formula or many adjustment factors for precision, then prefer simple formulas with few factors. More adjustment factors give subjectivity more room, and the art-level goal is about 25% error, not 5%.

• Treating estimation as a purely predictive act by an impartial estimator disconnected from planning and prioritization. The tell: the estimate is produced once and nobody owns steering toward it.
• Conflating target, estimate, and commitment. The tell: the 'estimate' always equals the requested date, and variance only surfaces at the end.
• Expecting the Cone to narrow on its own over time. The tell: no explicit scope decisions are recorded, and uncertainty stays wide late in the project.
• Letting requirements drift without re-baselining. The tell: scope grows while the original estimate and schedule stay unchanged, and the overrun shows up as a surprise.
• Chasing sophisticated estimation precision while ignoring basics such as review and historical data. The tell: elaborate formulas with many adjustment factors, yet no completed-project actuals and no peer review of the numbers.

• ▸Target (business objective): state the desired date/scope/cost as given, labeled as a target, not an estimate.
• ▸Estimate (range): record the prediction as a range or probability statement, and name the technique and historical data used.
• ▸Commitment: record what leadership has actually promised, to whom, and the date it was made.
• ▸Review status: note who reviewed the estimate, when, and what changed as a result.
• ▸In-scope decisions: list what the project will deliver, with date decided.
• ▸Out-of-scope decisions: list what the project will not deliver, with date decided.
• ▸Change log: record each scope or requirements change, the date, and the lever chosen (scope, resources, or schedule) to absorb it.
• ▸Actuals vs. baseline: note current effort, schedule, and scope status against the baseline at each checkpoint.
• ▸Re-estimate trigger and lessons: record any reversed decision that widened the Cone, plus actuals to add to the historical data.

1. 1Reframe before you walk in: there is no pie to divide. You and the executive, salesperson, or marketer sit on the same side of the table, and the project either succeeds for everyone or fails for everyone. Write down the shared interest (a project set up to succeed) and open with it.
2. 2Classify each number on the table as an estimate, a target, or a commitment. Executives rarely distinguish them, so the technical lead does it. Ask yourself: is this person asking 'how long will it take?' or 'can you build a plan to hit this date?' The two are different requests.
3. 3Do your homework on the business side. Identify external constraints (trade show, regulatory compliance date, competitive bid, quarter boundary) and say out loud that you understand the requirement and take it seriously. Acknowledging that a deadline exists does not mean agreeing it is achievable.
4. 4Separate the people from the problem. Expect executives to be assertive by nature and by job description, and expect them to want visibility and commitment early. Treat this as a fixed condition and plan the conversation around it. They also know things about the business and market that you don't.
5. 5Document and communicate the assumptions behind your estimate. Where you must use an assumption you think is unrealistic, make the estimate anyway but record the assumption, so you can point back to it if the project invalidates it and the estimate needs revising.
6. 6Express uncertainty explicitly, for example with plus-or-minus qualifiers (such as 6 months, +4 months, -1 month). Size the qualifiers to one standard deviation each side if you want about 68% coverage; use wider ones for more confidence. A range makes the conversation about risk, not a single contestable number.
7. 7Focus on interests, not positions. Ask what the date protects (the trade show, the revenue quarter, the bid) and invent options for mutual gain: cutting scope, phasing delivery, adding resources, or moving the commitment point.
8. 8Insist on objective criteria: historical data, documented assumptions, and the Cone of Uncertainty. Educate nontechnical stakeholders on the cost of cutting estimates without cutting work, framed as doing what is best for the organization. Negotiate the commitment separately from the estimate, so a target never replaces the analytically derived estimate.

The source's own trade-show exchange shows the failure and the repair. An executive says: 'We need this software ready in 3 months for a trade show. I can't give you any more team members. Here's the feature list.' The project lead returns with 'five months.' The executive hears a lead who doesn't get the business; the lead hears an irrational demand for five months of work in three. The cause is that the executive was giving a target and asking for a plan to hit it, while the lead supplied an estimate. A constructive version starts by stating that the trade-show date matters and is understood. The lead then separates the 5-month estimate from the 3-month target and records the assumptions behind the estimate. Next, the lead asks what the trade show requires: a full feature set, or a demonstrable subset? The options become cutting or prioritizing features from the list, or phasing delivery. Both sides test those options against objective criteria (the estimate, its assumptions, and the range) instead of arguing 3 versus 5. The outcome is a commitment negotiated on its own terms, not the target quietly standing in for the estimate.

• If the executive's number is a target rather than a request for an estimate, then give your estimate separately and work on a plan to hit the target (scope, staffing, phasing) instead of defending or abandoning your number.
• If an external constraint (regulatory date, trade show, competitive bid) is stated, then acknowledge it explicitly before discussing feasibility; the existence of a requirement does not make it possible.
• If you are forced to use an assumption you think is unrealistic, then make the estimate, document the assumption, and refer to it when revising.
• If you feel pressure to narrow your range, then first check whether it comes from outside or from yourself; only negotiate when the source is truly external.
• If the discussion drifts into who wins, then restate the shared interest (all win or all lose) and move to objective criteria and options for mutual gain.

• Treating the discussion as antagonistic pie-splitting: you trade pieces of schedule for concessions. Tell: you are bargaining the number up and down with no new options on the table.
• Presenting a bare estimate with no stated assumptions, so there is nothing to point back to when conditions change. Tell: you can't explain why the estimate must be revised.
• Letting a target be called an 'estimate,' which gives it unearned objectivity. Tell: the team plans around the 3-month date as if it were analytically derived.
• Defending your position without acknowledging the business requirement, so the executive concludes you don't get it. Tell: the executive repeats the deadline louder.
• Assuming executives will change, or avoiding the negotiation because you dislike it. Tell: you arrive unprepared and concede early, a pattern the source ties to technical staff being poor at defending estimates.

• ▸Shared interest: one sentence stating how project success benefits both you and the stakeholder.
• ▸Number on the table: record the figure and classify it as estimate, target, or commitment.
• ▸External constraints: list fixed dates, costs, or competitive pressures, and the line you will say to show you take them seriously.
• ▸Stakeholder's underlying interest: what the number protects (event, revenue quarter, bid, etc.).
• ▸Estimate with range: the core estimate plus plus-or-minus qualifiers and what they represent (e.g., one standard deviation).
• ▸Documented assumptions: list each assumption, flagging any you think are unrealistic.
• ▸Options for mutual gain: at least three alternatives (scope cut, phased delivery, staffing, date change) to propose.
• ▸Objective criteria: the data or principles you will use to judge options (historical data, Cone of Uncertainty).
• ▸Education point: one fact to explain to the stakeholder, such as the cost of cutting estimates without cutting work.

1. 1Define predictability as variance, not as hitting a date. For every project, record three planned-versus-actual pairs: cost, schedule, and features delivered. Compute each variance as (actual − planned) ÷ planned. Predictability is how small these three variances are across projects, not on one lucky project.
2. 2Adopt the accuracy yardstick the source calls the most common standard: estimates within 25% of actual results, 75% of the time. Apply it to your portfolio. Count the projects whose actual result landed within ±25% of the estimate and divide by total projects. Below 75% means you have a predictability problem, not a one-off miss.
3. 3Record the direction of every miss as well as its size. The source's industry data shows estimates about 100% low is typical, and about three quarters of projects are delivered late or fail. If your misses are mostly one-sided (late, over budget), the cause is systematic bias, not random noise, so fix the method rather than ask people to try harder.
4. 4Make every single-point estimate carry its probability. All single-point estimates are associated with a probability, explicitly or implicitly. State it as the chance of finishing on or before a date, or at or below a cost. Give ranges wide enough for 90% confidence of including the correct answer. Do not narrow them to look more precise.
5. 5Test for self-induced pressure before you fight external pressure. The source finds that much of the push toward narrow ranges comes from professional pride or past bosses. Ask: did anyone actually demand this range? If not, widen it. If so, take it to presentation and negotiation, not to the estimate itself.
6. 6Compare every estimate to the business target and treat a gap as risk information. Per Tip #9, a mismatch between target and estimate means the project might not succeed. Act early, when the high-leverage options still exist: redefine scope, increase staff, move your best staff onto the project, stagger delivery of functionality, or decide the project is not worth doing.
7. 7Feed actuals back into the next estimate. Boeing used historical data for all project estimates as its error fell at higher CMM levels. After each project, log estimate versus actual and use that history to calibrate. This is what the Air Force, Boeing and Schlumberger data point to as the route to predictability.
8. 8Recheck the portfolio each period. Plot average overrun (or underrun) per period, as Schlumberger did per half-year, and watch the trend. Predictability is achieved when the average and the spread both shrink.

Schlumberger tracked its estimation results by half-year period. Its average overrun was 35 weeks at the start of the improvement effort and an average underrun of 1 week at the end. That is a move from large, one-sided error to near-zero error. The U.S. Air Force projects show the same pattern from another angle: actual results as a percentage of estimates were widely scattered at low CMM levels and tightened dramatically at higher levels. Boeing's estimation error also shrank at higher CMM levels, with historical data used for all project estimates. At the best end, one of the author's client companies delivers 97% of its projects on time and within budget, and Telcordia reports 98%. The lesson for your own use: measure variance per period, find the bias direction (these organizations began with overruns), and treat calibration against history as the lever. A good estimate is not one that hits exactly; the benchmark is within 25% of actual, 75% of the time.

• If fewer than 75% of your projects land within 25% of the estimate, then treat estimation as a process problem: start collecting historical data before changing anything else.
• If your misses are mostly in one direction (e.g., about 100% low), then correct the systematic bias with calibration to past actuals. Do not add padding at random.
• If an executive says they want flexibility and predictability, then recall that at least 8 of 10 executives chose knowing cost, schedule, and functionality in advance over changing their minds about features. Confirm which they actually value before optimizing for either.
• If the estimate and the business target do not match, then act now while the high-leverage options (scope, staffing, staggered delivery, cancel) are open. Waiting leaves only 'overrun schedule and budget' or 'cut painful amounts of functionality'.
• If you cannot estimate with complete accuracy, then err toward overestimation. The source says the penalties for underestimation are more severe. Do not use this as a license to pad; state a probability and a range.

• Measuring predictability on one project. The tell: someone cites a single on-time delivery as proof, with no portfolio percentage within ±25%.
• Narrowing ranges to look confident. The tell: ranges that rarely contain the actual result, and the 'pressure' turns out to be self-induced when you ask who demanded it.
• Assuming outcomes are symmetric around the estimate (a bell curve). The tell: surprises are only ever in one direction. The source says there is a limit to how well a project can go but no limit to how many problems can occur.
• Letting a target-versus-estimate mismatch persist. The tell: the gap is known and discussed, but no scope, staffing, or go/no-go decision is made, so only overrun or feature-cutting remains.
• Treating 'meets estimate' as proof nothing changed. The tell: the delivered project differs from the one estimated, yet the outcome is judged successful because the numbers are close. Track feature variance separately from cost and schedule.

• ▸Project name and period: identify the project and the half-year or quarter you are reporting.
• ▸Planned vs. actual cost: enter both figures and compute (actual − planned) ÷ planned.
• ▸Planned vs. actual schedule: enter both dates or durations and compute the same variance.
• ▸Planned vs. actual features delivered: list committed vs. delivered features and note scope changes since the estimate.
• ▸Within ±25%? (Y/N per dimension): mark whether each variance falls inside the 25% band.
• ▸Direction of miss: record over or under for each dimension to expose systematic bias.
• ▸Stated confidence of original estimate: record the probability or range (e.g., 90%) attached to the estimate at the time.
• ▸Target vs. estimate gap at kickoff: note any mismatch and the corrective action taken (scope, staffing, staggered delivery, cancel).
• ▸Portfolio hit rate: count of projects within ±25% ÷ total projects, compared with the 75% benchmark.

1. 1Define success as three commitments you can check: functionality, resources (budget), and time frame. The source's working test is whether you delivered 'about the level of functionality intended, using about the level of resources planned, in about the time frame targeted.' Write all three down before work starts.
2. 2Separate estimate, target, and commitment. Chapter 1 treats blurring these as a root cause of so-called estimation problems. Record the business target, the estimate, and the commitment as three distinct lines.
3. 3Attach a probability to every number. A single-point estimate is never 100% likely, and the source's example is that '18 weeks' is only 10% likely. Restate it as '18 to 24 weeks', a best case and worst case, or '90% confident in 24 weeks'.
4. 4Choose where in the range you commit (optimistic end, pessimistic end, or the middle) and know which one you chose, so you can plan around it.
5. 5Compare the commitment with the business target. If the gap is small, you may close it by preparing carefully or squeezing schedule, budget, or feature set. If the gap is large, the targets themselves must be reconsidered, as with the suitcase: leave clothes home or take the bigger bag.
6. 6Adjust your success odds for project size. Jones's data shows on-time delivery falling from 81% at 10 FP to 14% at 100,000 FP, and cancellation rising from 2% to 65%. Treat a large project's 'on time' commitment as a high-risk bet, not a default.
7. 7Log the assumptions on functionality, staffing, and priorities. They nearly always change during the project, and that breaks any clean check of estimate accuracy. When they change, re-baseline openly and record that the delivered project is not the one originally estimated.
8. 8At closeout, score the three dimensions against the commitment (functionality, resources, time frame) and record the result as historical data. Do not score against the original naked point estimate.

The source cites The Standish Group data: 28% of projects were delivered on time and within budget, 18% failed outright, and the rest were late. About three quarters were late or failed. Jones's size table adds a second lens. A 10 FP (1,000 LOC) project is on time 81% of the time and canceled 2%. A 10,000 FP (1,000,000 LOC) project is on time 28% and canceled 48%. Take a hypothetical team quoting '18 weeks' for a mid-size project. The source says 18 weeks alone is only 10% likely, so the team restates it as '18 to 24 weeks' and commits to 24, a 90% confident figure. If the business target is 18 weeks, the 6-week gap becomes an explicit decision: cut scope, add budget, or move the target. Success is then judged on delivering about the intended functionality, resources, and time frame against that commitment. The Standish Group does not even have an 'early' category, so don't treat early delivery as the measure either.

• If you see a single-point estimate, then ask what its probability is before accepting it as a commitment.
• If the gap between target and estimate is small, then plan more carefully or squeeze schedule, budget, or features. If it is large, then renegotiate the targets rather than hoping to close it by effort.
• If the project is large (the source's data shows 1,000 FP and above), then expect markedly lower on-time odds and higher cancellation risk, and commit to the pessimistic end of the range.
• If functionality, staffing, or priorities change mid-project, then re-baseline and say so. Do not judge success against the original estimate.
• If you feel pressure to narrow a range, then check whether it is self-induced. If it is external, use the estimate presentation and negotiation techniques the source points to in Chapters 22 and 23.

• Treating a naked number as a commitment. The tell is an estimate with no stated probability or range.
• Treating success as predictive accuracy of the original estimate. The tell is blaming 'bad estimates' after assumptions have changed. The source says that accuracy cannot be assessed, so judge by whether the project delivered what was intended.
• Reading on-time delivery as the only success dimension. The tell is hitting the date while functionality or budget quietly slips, and the three-part definition then fails.
• Ignoring project size when committing. The tell is applying a small-project confidence level to a very large project.
• Narrowing ranges to look more professional or to satisfy a boss or customer. The tell is a range too narrow to hold the 90% confidence level, with pressure that turns out to be partly self-induced.

• ▸Business target (functionality / budget / date): Record what the business wants, kept separate from the estimate.
• ▸Estimate as range: Give best case and worst case, not a single point.
• ▸Stated confidence: Give the percent confident attached to the range (e.g., 90%).
• ▸Commitment point: Record where in the range you commit and why.
• ▸Target-vs-commitment gap: Note the difference; mark small (control it) or large (renegotiate targets).
• ▸Project size class (FP/LOC): Note the size and the relevant on-time and cancellation risk from Jones's table.
• ▸Key assumptions: List functionality, staffing, and priority assumptions behind the estimate.
• ▸Change log: Record each assumption change and the re-baselined commitment.
• ▸Closeout result: Score delivered functionality, resources used, and time frame against the commitment.

1. 1Separate the four terms before any number is spoken. When an executive says 'we need this in 3 months,' ask whether this is a target, an estimate, a commitment, or a request for a plan to hit a target. Most executives do not distinguish them, so the technical leader has to. Say the label out loud and write it in the notes.
2. 2Never answer a target with a single-point estimate in the same breath. Go back, compute from size to effort to schedule, and return with the output. Tip #69: take the output as given and change it only by changing the inputs and recomputing.
3. 3Present estimates as ranges that match your real confidence. Avoid artificially narrow ranges, because wide ranges are not a sign of incompetence. Do not label a range '90% confident' unless a statistical analysis supports it. Quiz-takers who believe they are 90% confident behave closer to 30% confident.
4. 4Use more than one estimation technique and look for convergence. If the techniques disagree, find the factors causing the difference and keep reestimating until the results converge to within about 5% (Tips #66-67). Bring the converged result, not one number, to the stakeholder.
5. 5When a stakeholder challenges the estimate, move the debate to inputs. Walk through assumptions such as staff capability ratings and calibrate against historical data. Do not trade a rating like 'programmer capability' for a more comfortable number, because each concession silently cuts the estimate (23% in one example, 39% in another).
6. 6If the estimates agree and the business target disagrees, trust the estimates (Tip #68). Present the gap as a decision for the stakeholder: change the inputs (features, staff, schedule) or accept the risk.
7. 7Announce the reestimation plan in advance (Tip #76). Tell stakeholders when you will reestimate and that the range will tighten as the project proceeds, so that a later revision reads as planned process, not failure.
8. 8When you reestimate after a missed deadline, base the new estimate on actual progress, not planned progress (Tip #74). Present it with the evidence.

The source's own example: an executive says, 'We need this software ready in 3 months for a trade show. I can't give you any more team members.' The project lead returns with 5 months. The executive hears a failure to grasp business reality, and the lead hears irrationality. The cause is that the executive asked for a plan to hit a target but the lead answered with an estimate. A better move is to name the difference: 'The estimate is 5 months. The target is 3. Here are the levers that could close the gap.' The stakes show in a real case from the passages: multiple estimates converged to within 5% of the 'most accurate estimate,' but the client chose the business target of 5 calendar months and 25 staff months. The project delivered after 14 calendar months and about 80 staff months, with far less functionality than planned. A lead who has earned trust by showing converged estimates, labeled targets, and a stated reestimation plan has a far better chance that the client picks the estimate.

• If a stakeholder gives you a date and asks 'how long,' then treat it as a target and ask what is fixed (features, staff, date) before you give an estimate.
• If multiple techniques converge and the business target disagrees, then recommend the estimate and present the target as a risk decision (Tip #68).
• If someone asks you to change an assumption in the estimation model (such as team capability), then change it only if you can justify it with historical data; otherwise hold the input and let the output stand.
• If you cannot back a confidence percentage with statistical analysis, then do not state one; give a range instead.
• If a deadline has been missed, then reestimate from actual progress and communicate it as part of the plan you announced earlier, not as a surprise.

• Answering a target with a number: the executive and lead talk past each other and each concludes the other is irrational. Tell: the conversation ends with 'Didn't you hear me?'
• Overpromising on precision: using narrow ranges or an unearned '90% confident' label to look competent. Tell: you overrun your '90%' schedule more than 1 time in 10.
• Negotiating assumptions instead of inputs: letting an executive reset capability ratings to 'average' to make the estimate shrink. Tell: the estimate drops (23%, 39%) without any change in the team or the work.
• Letting the target stand in for the estimate: staff start calling the target an 'estimate,' which gives it unearned objectivity. Tell: no one can show the analysis behind the number.
• Surprise reestimation: revising the estimate after a miss without having said you would. Tell: stakeholders read the revision as failure and not as a planned refinement.

• ▸Stakeholder and request (verbatim): write exactly what was asked, e.g., 'ready in 3 months for the trade show.'
• ▸Classification: mark each item as target, estimate, commitment, or plan request.
• ▸Fixed constraints: list what the stakeholder says cannot change (staff, features, date).
• ▸Estimation methods used: list each technique and its output (effort, schedule).
• ▸Convergence check: note the spread between techniques; continue until within about 5%, or record the factors causing the gap.
• ▸Range presented: low/high values and the basis for the confidence stated (no percentage unless statistically derived).
• ▸Key assumptions: list inputs such as team capability ratings and their historical basis.
• ▸Gap to target and options: state the difference and the levers (features, staff, schedule) that could close it.
• ▸Reestimation schedule: dates or milestones when you will reestimate and how the range is expected to tighten, communicated in advance.

1. 1Start small: collect four data points from each completed project: size (lines of code or another countable output measured after release), effort (staff months), calendar time (months), and defects (classified by severity). Two or three completed projects give you enough to calibrate several commercial estimation tools and to compute simple ratios.
2. 2Write a definition for each of the four measures before you collect anything. For size, decide how you treat: test and system test code, code reused from prior versions, open source or third-party library code, blank lines and comments, class interfaces, data declarations, and logical lines split across physical lines.
3. 3Apply the same definitions to every project. The source says the particular answer matters little; consistency matters, so that whatever assumptions are baked into the data carry forward consciously into new estimates. Inconsistent definitions can shift the numbers by a factor of 2 or more and make the data meaningless.
4. 4Define effort and calendar time just as carefully (what kinds of work and which staff are included), because the same cautions apply to those measures as to size.
5. 5Compute your own productivity ratios, such as lines of code per staff month, from the completed projects. Look at the range, not only the average.
6. 6Calibrate by choosing a planning assumption from that range and entering it into your model or formula, replacing industry-average productivity. State it with its basis: for example, 'we've averaged 300 to 450 delivered LOC per staff month, so we've calibrated at 400, a little optimistic but within a prudent planning range.'
7. 7Use the calibrated model to compute new estimates. Prefer your historical data over tweaking Cocomo II's 22 adjustment factors; the source says it is easier and more accurate.
8. 8Keep collecting after each project and recalibrate. Use the data to settle productivity arguments, since productivity is whatever the data says it is.

The source contrasts two estimates of the same project. Calibrated with industry-average data, the effort estimates span about a factor of 10, from roughly 25 to 250 staff months. Calibrated with the organization's own historical productivity data, they span only about a factor of 4, from roughly 30 to 120 staff months. Suppose your completed projects show 300 to 450 delivered lines of code per staff month. You calibrate at 400, which you judge slightly optimistic but prudent, and divide estimated size by that figure to get effort. When a stakeholder says 'my team is below average' or pushes for more optimism, you point to the data rather than to opinions about the programmers. A non-technical stakeholder has little to argue with in 'we've averaged 300 to 450.' The narrower range and the neutral basis are the two payoffs.

• If you have no historical data, then start with size, effort, calendar time, and defects from even two or three finished projects rather than waiting for a full metrics program.
• If a data definition is ambiguous (reused code, comments, test code), then pick one answer and apply it to every project; consistency beats the choice itself.
• If your recorded range is wide (such as 300 to 450 LOC per staff month), then calibrate to a defensible, prudent point inside it and say openly whether it leans optimistic.
• If a discussion turns to whether a team is above or below average, then redirect to the historical numbers; productivity is whatever the data says.
• If you are choosing between historical data and adjusting Cocomo II's 22 factors for the estimate itself, then use the historical data; use the factors for insight into project strengths and weaknesses.

• Collecting too much, too early, with loose definitions. The tell: size or effort figures for different projects can't be compared, and differ by a factor of 2 or more depending on who counted.
• Counting size inconsistently (reused, third-party, blank, comment, or test lines handled differently per project). The tell: the same team shows wildly different LOC per staff month with no change in how it works.
• Using industry-average productivity when you have your own data. The tell: effort outcomes spread across roughly a factor of 10 instead of about 4.
• Calibrating to an optimistic assumption that nobody can trace to a number. The tell: the productivity input exceeds your own observed range and is defended by opinion about team quality.
• Treating productivity as a judgment about people rather than a measured number. The tell: estimate meetings turn into arguments over whether 'my team is below average'.

• ▸Project name and completion date: one row per completed project.
• ▸Size and unit: final size counted after release (LOC or another countable unit).
• ▸Size counting rules: note how you treated reused, third-party, open source, test code, comments, blanks, data declarations, and split lines.
• ▸Effort (staff months): total effort, with a note on which activities and people are included.
• ▸Calendar time (months): start to release, with the start and end events defined.
• ▸Defects by severity: counts per severity class.
• ▸Productivity ratio: size divided by effort (e.g., LOC per staff month) for this project.
• ▸Range across projects: lowest and highest ratio observed.
• ▸Calibration assumption and rationale: the single value used in the estimate, and why it sits where it does in the range (e.g., 400, slightly optimistic but prudent).

1. 1Check the stage first. Per the chapter's summary table, decomposition by feature or task suits early-to-late on small projects and middle-to-late on medium and large ones. If you are still in the wide part of the Cone of Uncertainty, with tasks not yet identified or assigned, do not force a bottom-up estimate. Have an experienced estimator produce a coarse-grained one instead.
2. 2Choose the decomposition axis for what you are estimating. Break by feature or task for size, effort or features. Use an activity-based work breakdown structure (WBS) when you need effort or schedule. Pick one axis and keep the pieces non-overlapping.
3. 3Cut the item into pieces small enough that someone can picture the work. The chapter asks 'How small should the estimated pieces be?' and ties piece size to project progress: coarse-grain at the start, fine-grain near the end. Re-decompose more finely as the project advances.
4. 4Have the people who will do each task estimate it (Tip #43). Estimates from people not doing the work are less accurate, and separate estimators are more likely to underestimate. Do not substitute someone's general seniority. Experience in an activity does not by itself improve estimation accuracy (Jorgensen 2002).
5. 5Estimate each piece as an expected case, not a best case or worst case. The Law of Large Numbers works on expected-case errors: over- and underestimates on individual pieces tend to offset when you sum them. Sum these expected values to get the overall expected case.
6. 6If you also need an overall best case and worst case, do not add up each task's best cases and worst cases. The chapter lists this as a hazard under 'What went wrong?'. Use the standard-deviation approach it describes in 10.4: the simple formula for small numbers of tasks, the complex one for large numbers.
7. 7Check completeness before trusting the total. Walk the WBS against the full list of activities for the work. Missing pieces bias the sum low, and the Law of Large Numbers cannot repair an omission.
8. 8Record each piece's estimate and its actual result when the work finishes, and compare them. Feed the gap back into the next decomposition.

The source opens Chapter 10 with a weekly-team-meeting scene. You bet the group a pizza lunch that you can create a more accurate estimate for a new project than they can by gut feel. The chapter then builds the case for decomposition on the Law of Large Numbers: split the project, estimate each piece, and let individual errors offset in the sum. The excerpts supplied here do not include the scene's numbers, so the following is a labeled illustration, not source data. Suppose a feature is split into four tasks, each estimated by the developer who will build it, as expected-case effort: 3, 5, 2 and 6 days. The overall expected case is 16 days. One task will probably run over and another under. The sum absorbs part of that scatter, whereas a single 'about 16 days' guess has nothing to offset it. For a best-to-worst range, do not add four best cases and four worst cases. The chapter warns that this produces a range that is not meaningful, and says to use the standard-deviation formulas instead.

• If tasks are not yet identified or assigned to individuals (wide part of the Cone), then use an experienced estimator at coarse grain. Do not run a task-level bottom-up estimate.
• If the estimate is task-level, then the person who will do the work creates it. Separate estimators underestimate more often.
• If you need a range as well as an expected case, then compute aggregate best and worst cases with the standard-deviation formulas (simple for few tasks, complex for many). Never sum the individual best and worst cases.
• If the project is medium or large and early, then decompose only as far as the information supports. Move to finer pieces as the project moves into the middle and late stages.
• If you need schedule as well as effort, then use an activity-based WBS rather than a feature or task list alone.

• Summing every task's best case and worst case and presenting that as the overall range. Tell: the total range is implausibly wide or implausibly tight, and nobody can say how likely it is.
• Having a lead or outside estimator fill in the task numbers. Tell: the total comes in low and the people doing the work say they would have estimated higher.
• Dropping activities from the breakdown. Tell: pieces add up cleanly but the WBS lacks whole activity categories, so the total runs low however many pieces you estimate.
• Over-trusting an 'expert'. Tell: the estimator's confidence rests on technical experience, with no structured method or comparison to past actuals (Jorgensen 2002).
• Decomposing too early, at false precision. Tell: detailed task-level numbers on a project whose tasks are still unidentified, with the precision exceeding what the Cone of Uncertainty allows.

• ▸Item being estimated and what is measured (size, effort, features or schedule): state the unit once.
• ▸Project stage and Cone position: early, middle or late, and whether tasks are identified and assigned. If not, stop and use a coarse-grain expert estimate.
• ▸Decomposition axis: feature/task list or activity-based WBS, and why.
• ▸Piece list: one row per piece, with no overlaps.
• ▸Estimator per piece: the named person who will do the work.
• ▸Expected-case estimate per piece: one number each, not a best or worst case.
• ▸Overall expected case: the sum of the expected-case column.
• ▸Aggregate best and worst case: computed by the simple or complex standard-deviation formula, not by summing individual extremes. Note which formula and the task count.
• ▸Completeness check and later actuals: confirm every activity is covered, then record actual versus estimate per piece after completion.

1. 1Pick at least three methods that fail in different ways, so their errors are independent. The passages name the families: count/compute (function points, section 18.2), analogy, expert judgment (individual or group, e.g. Wideband Delphi), decomposition/recomposition, proxy-based estimates, and software estimation tools. Two methods that share an input, such as two size-driven models fed the same size guess, count as one.
2. 2Check each method's fit before running it. The Chapter 6 applicability tables map technique to project kind and project phase (Figure 16-4), so drop any method that doesn't suit your current phase. Run the rest in the same phase against the same scope statement.
3. 3Give each method its own inputs and its own estimator where possible. Calibrate the models and tools with your own historical data; the book's calibration chapter ties historical data to avoiding subjectivity and unfounded optimism.
4. 4Produce a range from every method, not a point. The book's test of a well-estimated project (Figure 16-5) is that single-point estimates may miss, but the ranges all include the eventual outcome. Record a low, expected, and high value per method.
5. 5Put all results on one chart, as in Figure 15-1 ("An example of multiple estimates for a software project"). Compare centers and widths: do the ranges overlap, and where?
6. 6Read convergence and spread. Overlapping ranges raise confidence, and you can commit to the overlapped band. A wide spread marks high uncertainty. Don't average it away.
7. 7Trace the spread to its cause. Check which input differs between methods: size, productivity assumption, team-factor adjustment (Cocomo II), or scope. Rerun the outlier with that input reconciled, or give the disagreement to a group review such as Wideband Delphi.
8. 8Carry the surviving range forward and re-run the whole set at each project phase. Because the cone of uncertainty narrows only through project decisions, narrower agreement is expected later, and persistent spread is a signal.

The passages give no numbers for Figure 15-1, so this example uses only figures that appear in the source and labels the rest as notation. Suppose you estimate a project three ways: a function-point count converted to effort, a Cocomo II run in a tool, and a Wideband Delphi group session. Cocomo II's own adjustment table shows how fragile one method is. If the team has very low Applications Experience, you multiply nominal effort by 1.22; if very high, by 0.81. For nominal effort N, that is a swing from 0.81N to 1.22N, about 1.5x, from one factor alone. That is why you do not trust a tool run on its own, and why a subjective team-rating argument is a likely cause of any gap. Say the function-point and Delphi ranges overlap but the tool's expected value sits outside both. You then check the tool's experience rating. If you had set it by optimism instead of history, you correct it and rerun. Next, a tool simulation of 1,000 outcomes (Figure 14-3 and 14-4 type output) can show whether your desired cost-and-schedule combination is realistic. In the book's example only 8 of 1,000 outcomes land in the target, so the target is a long shot even if the methods agree. You commit to the overlapped range, not to the target.

• If two or more independent methods' ranges overlap, then commit to the overlapped band and state it as a range, not the average of the centers.
• If the methods' ranges do not overlap, then do not average. Find the input that differs (size, productivity data, adjustment factors, scope) and fix or explain it before reporting.
• If one method's result is an outlier and it rests on subjective ratings (e.g., Cocomo II adjustment factors), then re-rate those from historical data first, since the book's reservations are about usage failure, not method failure.
• If spread persists after reconciling inputs, then treat it as real uncertainty, report the wide range, and schedule a re-estimate at the next phase instead of forcing agreement.
• If a group's initial estimates are poor, then use Wideband Delphi: in the book's data it improved results in 8 of 10 cases for terrible initial estimates. It also moved about one-third of groups outside their initial range, closer to the answer.

• Fake independence: all methods share one size estimate or one author, so they agree because they share an error. The tell: the methods all move together when you change a single input.
• Averaging the results: the average hides spread and gives false precision. The tell: a single number on the slide and no range.
• Picking the method whose answer matches the target or wish: this is the unfounded optimism the book warns about. The tell: you can't explain why you discarded the other results.
• Using methods outside their applicable project phase or kind (ignoring the technique applicability tables). The tell: a method's inputs are guessed because the data doesn't exist yet.
• Running the comparison once and never repeating it: the ranges narrow with project progress and the first spread goes stale. The tell: the original multi-method chart is still the 'current' estimate after requirements or size have changed.

• ▸Project and phase: name the project and its current phase, to check that each method is applicable at this phase.
• ▸Method (one row each, 3+ rows): analogy, function points, Cocomo-type tool, Wideband Delphi, decomposition, etc.
• ▸Independent inputs used: list the size source, productivity data, and who made the estimate, to confirm independence from the other rows.
• ▸Low / Expected / High effort: record a range for each method, never a point.
• ▸Calibration source: say whether it's your historical data, industry data, or a guess (and flag subjective ratings).
• ▸Overlap band: the range common to all or most methods; enter 'none' if the ranges don't overlap.
• ▸Spread diagnosis: if ranges diverge, name the input that differs and who will reconcile it.
• ▸Committed range and confidence: the band you report, plus what would change it.
• ▸Re-estimate trigger: the next phase or event at which you rerun every method.

1. 1Sort every number you hear into one of four buckets before you respond: estimate (a prediction of what will happen), target (a desirable business objective), commitment (a promise to deliver by a date or to a scope), or plan (the means of hitting the target). When a request arrives, ask which bucket it belongs to. The passages show that stakeholders blur these and sometimes call a target an "estimate," which gives it a halo of objectivity it doesn't deserve.
2. 2Translate the request into technical terms yourself. Most executives lack the background to separate estimates, targets, commitments, and plans, so that translation is the technical leader's job. Restate what you heard: "You have a 3-month target for the trade show. You're asking for a plan to hit it, not for an estimate."
3. 3Produce the estimate independently of the target. Work out size, effort, and schedule from the feature list and the current staff without letting the target set the answer. Then compare the two. The gap between estimate and target is the finding you report.
4. 4State the estimate as a range with a probability, never as a naked single number. A single-point estimate implies 100% probability that the actual outcome equals the planned outcome, which is unrealistic. Every single-point estimate carries a probability, explicitly or implicitly. "18 weeks" alone hides that it is only about 10% likely; "18 to 24 weeks" conveys the likely range of outcomes.
5. 5Name the confidence level of any single date you give. Use the cumulative probability picture: the chance of delivering on or before a date (or at or under a cost or effort). Say which point on that curve you are quoting, such as the 50/50 point, rather than leaving it implied.
6. 6Account for the asymmetry in the outcome shape. There is a limit to how well a project can go but no limit to how many problems can occur, so outcomes do not follow a symmetric bell curve. Skew the range's upper end accordingly instead of centering it on the single most likely number.
7. 7Convert the gap into options, not a verdict. When the estimate exceeds the target, keep the estimate fixed and discuss the variables you can change to move toward the target: features delivered, schedule, or staffing. Estimating features (how many can be delivered within schedule and budget constraints) is the right framing when time and budget are fixed.
8. 8Record what each number is called in writing. Label every figure in the plan or status report as estimate, target, or commitment, and attach the range and confidence to each estimate, so a later reader can't mistake one for another.

The source passage gives a typical miscommunication. An executive says: "How long do you think this project will take? We need this software ready in 3 months for a trade show. I can't give you any more team members." The project lead computes and returns: "We've estimated the project will take 5 months." The executive objects: "Didn't you hear me? I said 3 months." Each walks away thinking the other is irrational, because the executive wasn't really asking for an estimate; he was asking for a plan to hit a target. Applied here: the lead separates the buckets. The target is 3 months, set by the trade show. The estimate is 5 months, which should be given as a range with a confidence level instead of one number. The commitment is not yet made. The lead then says the current estimate does not meet the target and asks which lever the executive will move, since staff is fixed: reduce the feature list or move the date. That turns an argument about whose number is right into a decision about scope.

• If someone gives you a date and asks "how long will this take," then treat the date as a target, not a request for an estimate, and ask whether they want an estimate or a plan to hit the target.
• If you are about to say a single number, then attach a range and the probability it represents; if you can't state the probability, you don't yet have an estimate you can communicate.
• If the estimate exceeds the target, then do not shrink the estimate to fit; keep it and offer changes to features, schedule, or staffing.
• If a stakeholder calls a target an "estimate," then rename it explicitly as a target before it enters a plan, because the label gives it undeserved objectivity.
• If you are asked to commit, then commit only after the estimate's range and its probability of success have been compared to the target and the stakeholder has accepted the stated risk.

• Quoting a naked single-point number such as "18 weeks." The tell: no one asks about confidence, and the figure is later treated as a promise, though it carried only about 10% likelihood.
• Letting the target become the estimate. The tell: the "estimate" matches the business deadline exactly, and the lead "crunched numbers" only to arrive at the date already desired.
• Assuming a symmetric bell curve around the estimate. The tell: ranges are padded evenly above and below, though outcomes have a best-case limit and no worst-case limit, so overruns land outside the stated range.
• Treating a confrontation over a gap as a disagreement about facts. The tell: the lead concludes the executive is irrational and the executive concludes the lead doesn't get the business, with neither stating which concept they are discussing.
• Using ranges that are too narrow. The tell: the actual outcome falls outside every stated range, as in the poorly estimated project where estimates were uniformly low and the ranges too narrow to include the result.

• ▸Request as heard: paste the stakeholder's words verbatim.
• ▸Classification: mark each number in the request as estimate, target, commitment, or plan.
• ▸Target: state the business objective and its source (for example, a trade show date).
• ▸Estimate range: give low and high values for effort, schedule, or features, not a single point.
• ▸Confidence level: state the probability that the actual outcome falls at or under each value in the range.
• ▸Gap (estimate minus target): record the difference in the same unit as the target.
• ▸Levers offered: list the changes to features, schedule, or staffing that could close the gap.
• ▸Commitment status: write not committed / committed, with the date and the range the commitment is based on.
• ▸Stakeholder acknowledgment: record who accepted the range and confidence level, and when.

1. 1Test for stability before you estimate. The book's position is that you cannot accurately estimate an out-of-control process. Check three chaos sources named in the source: unstable requirements, poor technical practices, and high staff turnover. If any is active, say so in writing next to the estimate.
2. 2Separate estimate, target and commitment on the page. A commitment can equal the estimate, or be more aggressive or more conservative. If a target is being called an 'estimate', it has borrowed a halo of objectivity it hasn't earned. Relabel it before you do anything else.
3. 3Check whether the estimate is current with the requirements. List every requirement agreed since the baseline. The typical failure is that cost and schedule assumptions are never updated as requirements change, so the original estimate may have been accurate while the project is now unwinnable.
4. 4Choose the response by cause. For unstable requirements, the book says the more powerful responses are project control responses, not estimation responses. If you cannot stabilize requirements, consider short iterations, Scrum, Extreme Programming, DSDM or time-box development.
5. 5If you must estimate through volatility, put an explicit allowance for requirements growth, changes, or both into the estimate. The book's illustrative Cone (Figure 4-5) assumes about 50% growth over the project. Note that this Cone's data points are not backed by the same research as the original Cone.
6. 6Do not treat extra time as a fix for the Cone. Estimation accuracy depends on how refined the definition is, not on the effort spent estimating. The Cone does not narrow itself, so a request for 'another week to refine' is not deliverable. Widen the range to match the project's current stage.
7. 7Record every omitted activity and optimistic assumption as you go. Chaotic processes show up as the sources the book lists: omitted activities, unfounded optimism, subjectivity and bias, off-the-cuff estimates, and unwarranted precision. Review each one before you publish.
8. 8Re-baseline on every accepted change. Re-estimate when requirements change and tell stakeholders the original estimate no longer applies. Otherwise a feature set everyone agreed was a good idea gets reported as a late project.

The source describes the failure directly. A project's original estimate may have been accurate, but dozens of new requirements get piled on. They are agreed to but not accounted for, and the cost and schedule assumptions are never updated. The project then cannot meet its original estimate and is perceived as late, even though everyone agreed the additions were good ideas. Apply the book's illustrative Cone (about 50% growth) to a hypothetical baseline of 10 staff-months. The honest expectation becomes about 15 staff-months, so a 10-month commitment against an unmanaged flow of additions is a miss built in from the start. The estimation fix is to carry the growth allowance in the range. The stronger fix is control: freeze scope per iteration, or move to short iterations or Scrum so changes enter through planning rather than piling onto a fixed estimate. The source's own claim is that better estimation cannot by itself repair requirements instability.

• If requirements are changing and you can't stabilize them, then switch to a development approach built for volatility (short iterations, Scrum, XP, DSDM, time-box) in addition to estimating.
• If you must produce a fixed estimate under volatility, then add an explicit requirements-growth allowance (the book illustrates about 50%) and state that it is an assumption.
• If requirements have been added since the baseline and the estimate hasn't been revised, then treat the old estimate as void and re-estimate before judging the project late.
• If someone asks for more time to 'tighten' an early estimate, then explain that the Cone does not narrow by itself. Offer refined definition (requirements or design work) instead.
• If a number is being called an estimate but was set by a business goal, then relabel it a target and keep the analytical estimate separate.

• Defending a precise estimate on an unstable process. The tell: a single-point number with no growth allowance and no stated assumptions about requirements stability.
• Using estimation techniques to fix a control problem. The tell: repeated re-estimation while the requirements list keeps growing and nobody owns change control.
• Letting agreed additions go unaccounted. The tell: the project is called late although every added feature was approved.
• Letting targets pass as estimates. The tell: the 'estimate' matches the business date and no one can show the analytical derivation.
• Reading the Cone as something effort will shrink. The tell: the same wide range is expected to tighten in a week with no new definition work.

• ▸Project and estimate date: name the project and the milestone reached (e.g., Initial Concept, Requirements Complete).
• ▸Baseline estimate and what it covered: state the number and the requirements baseline it was built on.
• ▸Requirements added/changed since baseline: list each, with the date and who agreed to it.
• ▸Estimate updated for each change? (Y/N): if N, mark the estimate void and schedule a re-estimate.
• ▸Other chaos sources present: note poor technical practices or high staff turnover, with the evidence.
• ▸Growth allowance applied: give the % built into the range, and mark it as an assumption.
• ▸Estimate vs. target vs. commitment: record all three separately, and flag any target labeled as an estimate.
• ▸Control response chosen: stabilize requirements, or switch to short iterations, Scrum, XP, DSDM or time-box.
• ▸Stakeholder notice sent: note the date you told stakeholders the baseline changed and what was re-estimated.