Planning and Estimation (PLA)

A date is a promise made to others; an estimate is a judgment under uncertainty. The greatest damage is not a wrong estimate (they all are, to some extent), but a wrong estimate…

Guide≈ 5 min readCheckedReading

On this page

Why this topic
What this topic measures
The five levels
Milestones by level
Detailed reading by level
Partial achievement and rating
Move to the next level
See also

Level: 🟢→🔴 · Code: PLA · Matrix: PI

Why this topic#

A date is a promise made to others; an estimate is a judgment under uncertainty. The greatest damage is not a wrong estimate (they all are, to some extent), but an estimate that is wrong and presented as certain: it triggers cascading commitments (user training, customer communication, resource freezes) that collapse together. A mature schedule does not predict perfectly; it states how reliably it predicts, and readjusts without drama.

What this topic measures#

Axis: from imposed date to calibrated probabilistic forecasting.
Key indicator: forecast reliability (share of commitments met on date, average gap between estimate and actual).
Unit: % of commitments met; relative workload gap (± %); width of the announced range.

The five levels#

Level	Short name	Promise	Typical indicator (orders of magnitude)
1	Imposed date	We know when we are asked to deliver; we discover along the way whether it is feasible.	Commitments met: < 30 to 40%
2	Milestone plan	A plan with milestones and owners exists; deviations are visible when they occur.	Commitments met: 40 to 60%
3	Shared estimation	The team estimates itself, with explicit margin and assumptions; the announced date is a range.	Met: 60 to 75%; workload gap ± 30%
4	Measured forecasting	Forecast reliability is measured on historical data and used to announce dates.	Met: 75 to 90%; workload gap ± 15 to 20%
5	Probabilistic forecasting	Dates are announced with a confidence level (“85% before the 15th”); the plan adjusts without surprises with each new piece of information.	Calibration: announced 85% ≈ observed 80–90%

Milestones by level#

ID	Milestone	Verifiable evidence
PI-PLA-1.1	A target deadline exists for each project.	Date present in the project sheet.
PI-PLA-1.2	Main tasks are listed.	List of work packages/deliverables.
PI-PLA-1.3	Delay is identified (even late) and stated.	A past delay appears in meeting notes.
PI-PLA-2.1	Plan with milestones, main dependencies, and owners.	Up-to-date planning diagram or table.
PI-PLA-2.2	The plan is updated at least at each milestone.	Plan version history.
PI-PLA-2.3	Known vacations and unavailability are integrated.	Plan cross-checked with the team calendar.
PI-PLA-3.1	Estimates are made by those doing the work (poker, Delphi, decomposition).	Estimation workshop notes.
PI-PLA-3.2	Each estimate includes its assumptions and a range or margin.	“Assumptions” and “min/max” fields completed.
PI-PLA-3.3	External dependencies (other team, data, vendor) are planned with margin.	Dependencies listed with needed-by date and contact.
PI-PLA-3.4	Actual capacity (excluding meetings, support, incidents) is used, not theoretical time.	Availability factor documented (for example 60 to 70%).
PI-PLA-4.1	Estimated/actual gap is measured for each completed item.	Estimated/actual history over ≥ 20 items.
PI-PLA-4.2	A throughput indicator (velocity, cycle time) feeds forecasts.	Throughput curve, cycle time (percentiles).
PI-PLA-4.3	Announced dates are based on history, with a calculated range.	Dates with explained interval.
PI-PLA-4.4	Rebaselines are counted and analyzed.	Number of replans tracked per project.
PI-PLA-5.1	Probabilistic forecasts (Monte Carlo simulation on history or equivalent) are used.	Report with percentiles (50/85/95%).
PI-PLA-5.2	Calibration is verified: announced 85% hits about 85 times out of 100.	Calibration table over ≥ 20 forecasts.
PI-PLA-5.3	Decision-makers reason with ranges and not a single date.	Meeting notes citing ranges.
PI-PLA-5.4	Each new piece of information (incident, departure) updates the forecast in under 2 days.	Update date vs event date.

Detailed reading by level#

Level 1. Signs: the date comes from the sponsor or an external event; the team compensates with late nights. Benefit: alignment on a real deadline. Does not guarantee: feasibility or quality. Difficulty: 1/5. Effort: 1/5.

Level 2. Signs: milestone plan, updates before reviews. Benefit: shared view of the sequence. Does not guarantee: that the plan holds against unexpected events; estimation remains a wish. Difficulty: 2/5. Effort: 2/5.

Level 3. Signs: the team explains its estimates; the range is accepted as normal. Benefit: more honest commitments; less end-of-project stress. Does not guarantee accuracy. Difficulty: 3/5. Effort: 2/5.

Level 4. Signs: you know your error rate; you say “based on our history, 80% chance before end of March.” Benefit: credibility with sponsors. Does not guarantee stability if context changes (new tech, refreshed team). Difficulty: 4/5. Effort: 3/5.

Level 5. Signs: forecasts recalculated automatically, calibration verified, decisions based on percentiles. Benefit: informed portfolio decisions. Does not guarantee absence of black swans. Difficulty: 5/5. Effort: 4/5.

Partial achievement and rating#

Common rule: see README.

0.5: estimate made by the team but without written assumptions; history exists but is not used.
1: evidence can be reviewed without oral explanation.
A partial 5: forecasts based on actual throughput (4.x acquired), simulation on one or two projects, calibration not yet measured (5.2 = 0). Score: about 4.2.

🧪 Example

Datamart team, kit delivery every two months. History: 12 kits, median cycle time 18 days, 85th percentile 31 days. Announcement: “the fix will be delivered in the December kit, with 85% confidence before the 20th.” The department manager knows what to tell their teams.

⚠️ Pitfall

Estimate turned into commitment. Symptom: the team systematically pads estimates. Cause: the estimate was used as a contract, and overrun was penalized. Remedy: separate estimate (judgment), target (wish), and commitment (decision), and write them separately.

⚠️ Pitfall

Goodhart: if velocity is a target, it inflates (point inflation). Velocity is for team forecasting, never for comparing teams.

💡 Expert tip

Estimates in person-days are biased by optimism (planning fallacy); the proven countermeasure is to estimate by analogy on comparable completed items (reference class forecasting) rather than by decomposition alone.

Move to the next level#

Possible means (optional)

1 → 2: a milestone plan in a shared tool; see planning tools.
2 → 3: collective estimation (poker, three-point), assumptions log; see Scrum in Practice and predictive methods.
3 → 4: collect estimated/actual, cycle time, percentiles; see metrics and reporting.
4 → 5: Monte Carlo simulation on history, calibration table, automatic recalculation.

🤖 AI

AI can suggest a breakdown, flag forgotten tasks, and compare with similar items; it does not have access to your team's real context and its estimates are often too confident: treat it as one more opinion to calibrate against history. See AI for Project Management (General, Then Data).