A steering group wants a migration completed in twelve weeks. The project plan can be drawn to fit twelve weeks, but the closest completed projects took sixteen to twenty-four weeks and all had fewer dependencies.
Decision situation
Project estimation
Estimate time and effort with an outside view instead of relying only on the current plan.
Deep decision guide · reviewed 2026-09-10
A target date is not a forecast wearing a tie.
How do we estimate a project when the business already has a date in mind?
A target is useful for planning, but it becomes dangerous when it quietly turns into the starting estimate. Detailed plans then explain how the date could work while comparable completed work, rework and ordinary delays stay outside the frame.
The outside view is not an excuse to ignore project details. It is a second source of evidence. A useful estimate keeps the target, the forecast and the assumptions separate so the team can see whether it is committing to a date or predicting one.
A better review
Run the decision in five moves.
- 1. Make an independent first estimate or range before discussing the target date in detail.
- 2. Choose a reference class of genuinely comparable completed work and record the observed range.
- 3. List the few assumptions that would move the current project toward the fast or slow end of that range.
- 4. Show the business target and the forecast as two separate numbers instead of averaging them into one comfortable answer.
- 5. Define the evidence or milestone that should trigger an estimate update and keep the previous forecast for calibration.
Worked example
The twelve-week migration
The team adds a small buffer to the twelve-week target and calls the result conservative.
The team starts with the comparable-project range, explains which current differences could justify moving within that range and reports the twelve-week date separately as a business target that would require explicit scope, capacity or risk changes.
Decision record
Write down the parts that are easiest to rewrite later.
- Business target and reason for it.
- Independent forecast range.
- Reference class and why it is comparable.
- Assumptions that drive the fast and slow cases.
- Update trigger and previous forecast for later calibration.
Practice the decision
Try the reasoning before the stakes are real.
A sponsor says the migration should finish in twelve weeks. The delivery team then estimates each work package while that date remains visible.
Try the scenario →A team has a detailed task plan for a data migration. It predicts 40 days, but nobody has checked how long similar migrations actually took.
Try the scenario →The previous project missed its date by six months. Managers now double every estimate, even though most comparable projects had much smaller delays.
Try the scenario →Reviewed research notes
Go deeper where the evidence needs more context.
Research supports a recurring pattern of optimistic completion-time estimates. The useful response is to compare the plan with similar completed work and keep uncertainty visible, not to multiply every estimate by one fixed number.
Read the synthesis →Evidence boundary
Useful lens, not a diagnosis.
Planning fallacy, anchoring and availability are plausible lenses for the reasoning process. Real delivery also depends on scope, skills, dependencies, incentives and technical constraints, so a late project is not proof of a cognitive bias.
The guide reuses the project's reviewed planning-fallacy synthesis and anchoring evidence. Reference-class forecasting is a practical procedure, not a universal correction formula.
Signals to notice
Reasons to slow down and check.
- The estimate starts from one target date.
- Comparable completed work is not being used.
- The plan assumes dependencies will behave normally.
Questions before action
Make the missing evidence visible.
- What happened in comparable completed work?
- What range is supported by the reference class?
- Which assumptions would move the estimate toward either end?
Relevant lenses
Concepts that may help you test the reasoning.
Use this concept as a question to test the decision, not as a label for a person.
Open →Use this concept as a question to test the decision, not as a label for a person.
Open →Use this concept as a question to test the decision, not as a label for a person.
Open →Practical moves
Do something different, not only notice a label.
Use outcomes from comparable completed cases before refining an inside-view plan.
Open →Create a reference point before seeing a strong external number or recommendation.
Open →Preserve what was known, expected and uncertain before the outcome changes memory.
Open →Skill to develop
Forecasting
You can produce forecasts that are easier to challenge, compare and learn from later.
Practice this situation
Choose a useful first move.
A sponsor says the migration should finish in twelve weeks. The delivery team then estimates each work package while that date remains visible.
Skill: ForecastingOpen scenario →A team has a detailed task plan for a data migration. It predicts 40 days, but nobody has checked how long similar migrations actually took.
Skill: ForecastingOpen scenario →The previous project missed its date by six months. Managers now double every estimate, even though most comparable projects had much smaller delays.
Skill: ForecastingOpen scenario →