What problem does this system address?
Traditional estimation produces single-point numbers that hide uncertainty, leading stakeholders to treat guesses as commitments and engineers to pad estimates defensively.
I analyzed project outcomes at an organization running 12-15 projects per quarter. 67% of projects exceeded their original estimates by more than 20%. The root cause was not poor estimation skill. It was information destruction: engineers produced ranges (“this will take 3 to 6 weeks”), managers converted ranges to points (“so it will take 4 weeks”), and executives converted points to commitments (“it launches on March 15th”). Each conversion destroyed information about uncertainty. As I discussed in estimation as epistemology, an estimate is a statement about what you know and do not know, not a promise about the future.
How is the system structured?
The system provides 3 methods (reference class forecasting, lightweight Monte Carlo, and pre-mortem adjustment), each appropriate for different project types and decision needs.
Step 1: Reference class forecasting for recurring project types
For projects similar to past work (feature development, infrastructure migrations, integrations), use historical data. I built a simple database tracking actual duration versus estimated duration for 48 completed projects, categorized by type. When estimating a new feature project, I pull the distribution of past feature projects: median was 1.4 times the initial estimate, 80th percentile was 2.1 times. The estimate becomes: “Based on 23 similar projects, most likely 7 weeks, 80% confidence it completes within 10 weeks.” This method takes 30 minutes per project and outperformed expert judgment by 35%. Reference class forecasting was developed by Daniel Kahneman and Amos Tversky precisely to counteract the optimism bias in individual estimation.
Step 2: Lightweight Monte Carlo for complex projects
For projects with multiple uncertain components, decompose into 5-15 sub-tasks. For each sub-task, estimate a best case, most likely case, and worst case duration. Run 1,000 simulations sampling from these ranges (a spreadsheet template handles this in seconds). The output is a probability distribution: “50% chance of completing by April 15, 80% chance by May 3, 95% chance by May 20.” I found that stakeholders presented with probability distributions made meaningfully different planning decisions than those given point estimates. They chose the 80% date for external commitments and the 50% date for internal targets. This method takes 2 hours per project.
Step 3: Pre-mortem adjustment for novel projects
For projects with no historical comparison, standard estimation methods produce false precision. Instead, produce a rough estimate through decomposition, then run a 45-minute pre-mortem: imagine the project has taken twice as long as estimated. What went wrong? I facilitated 11 pre-mortem sessions. Each identified an average of 4 risks that were not in the original estimate. Incorporating those risks into the estimate increased initial estimates by an average of 40%, which, based on actual outcomes, improved accuracy from 31% within-budget to 72% within-budget. This method is described further in my piece on the pre-mortem as standard operating procedure.
How do you validate it works?
Validate by tracking the percentage of projects that complete within the stated confidence interval, targeting 80% of projects finishing within the 80% confidence bound.
After 4 quarters, 72% of projects completed within the 80% confidence interval (target: 80%, so there is room for improvement). Schedule overruns exceeding 20% dropped from 67% to 28%. Stakeholder satisfaction with project predictability, measured by quarterly survey, increased from 3.1 to 4.2 on a 5-point scale. The critical shift was cultural: stakeholders stopped asking “when will it be done?” and started asking “what is the confidence level for that date?” That question change represents a fundamental improvement in how the organization reasons about uncertainty.