Rethinking PERT, Introducing Wagn Project Tracker
Software estimation is a constant challenge. We've all been there – trying to predict the future with limited information, often leading to stressful deadlines and missed expectations. One common technique discussed is PERT, which aims to manage this by using three point estimation: Optimistic (O), Pessimistic (P), and Most Likely (M). It's an attempt to embrace uncertainty.
My Experiments and Why I Think Standard PERT is Flawed
I've spent a good amount of time working with PERT and similar three-point estimation systems, both in corporate settings and personal projects. While the intent is good, I've consistently run into what I see as fundamental flaws:
Correlated Risk & Systemic Errors: The biggest issue is that O, P, and M are often not independent variables. If there's a systemic problem – poorly understood requirements, an unfamiliar technology, unstable dependencies, a bottleneck in the review process – it doesn't just affect one estimate; it taints all three. If your core understanding is flawed, your 'best case', 'worst case', and 'most likely' are all likely skewed in the same direction by the same root cause. It creates a false sense of security through multiple data points, but they're all susceptible to the same underlying failure mode.
Lack of Confidence Indication: The OPM spread tells you the range of perceived outcomes, but it doesn't tell you how confident the estimator is in that assessment. An expert facing a genuinely volatile task might give a wide OPM range with high confidence in that range. A novice tackling something new might give the exact same OPM range simply because they're guessing and lack confidence in their own estimate. The raw OPM numbers don't distinguish between inherent task volatility and estimator uncertainty.
These limitations mean that while PERT looks more sophisticated, its outputs can still be wildly inaccurate if the underlying assumptions are wrong, and it doesn't fully capture the estimator's own confidence level.
My Modified Approach: Expected Estimate + Certainty
This led me to experiment with a different approach. Instead of asking for three time estimates, I focus on capturing two key pieces of information directly:
The Most Probable Estimate (E): What's the single best guess for the realistic duration under normal circumstances? This aligns with the intent of PERT's calculated 'E' (Expected Duration).
Certainty Level: How confident is the engineer in that specific estimate? Is this something they've done countless times (High Certainty), or is it full of unknowns (Low Certainty)?
This "Certainty" factor addresses the missing context from standard OPM. I find simple T-shirt sizes (Low, Medium, High) work well enough for practical purposes. You can also use a numeric scale. That might look like: "How confident are you in this estimate?" (25%, 50%, 75%, 90%, 99%)
Deriving OPM from Certainty: Modeling Reality
With 'E' and 'Certainty', we can then derive the O, P, and M values algorithmically. The key here is to model the asymmetric reality of software development: delays are far more common and can be much larger in magnitude than unexpected speed-ups. Tasks rarely finish in half the expected time, but doubling or tripling the expected time? That happens.
My derived OPM system uses the Certainty level to apply different multipliers to the Expected estimate (E). As uncertainty increases, the multiplier for the Pessimistic (P) estimate grows significantly faster than the Optimistic (O) estimate shrinks.
Here are the multipliers I've baked into @wagn/project-tracker:
| Certainty Level | Optimistic | Most Likely | Pessimistic |
|---|---|---|---|
| High | 1 | 1.5 | 2.5 |
| Medium | 0.75 | 1 | 2 |
| Low | 0.5 | 1 | 1.25 |
This 2.5x multiplier for 'Low Certainty' is designed to account for those common scenarios where complexity snowballs, turning a seemingly simple task into a much larger effort. If actuals consistently exceed even this pessimistic buffer, it strongly signals a need to investigate deeper systemic issues (requirements, process, architecture) rather than just padding estimates further.
I've also written about these principles for clear requirements in more detail:
Principles Driving the Approach (and the Tool)
This thinking is grounded in a few core principles for effective estimation:
Decompose Relentlessly: Break large features into small, manageable tasks using a hierarchical WBS system. If a task feels like it'll take more than 1-2 days, it's almost always too big and needs further decomposition. You may change this minimum threshold based on your team's process.
Be Deliverable-Oriented: Frame tasks around outcomes ("Implement X API endpoint," "Add Y component") not just activities ("Code the service"). Connect work to tangible results.
Include the 'Hidden' Work: Remember to account for testing (unit, integration, manual), documentation, code reviews, deployment, etc. These are real work and need to be part of the estimate.
Introducing: Wagn Project Tracker
To make this approach practical for my own use, I built a simple tool: Wagn Project Tracker.
It's an offline-first web app (React, Zustand, Tailwind) that embodies this estimation philosophy:
Hierarchy: Organizes Tasks within Sections.
Task Estimation: Uses simple Fibonacci-like values (1h, 2h, 3h, 5h, 1d, 2d, 3d, 1w).
Section Certainty: Assign Certainty (Low, Medium, High) at the Section level.
Derived PERT: Calculates overall Optimistic, Expected, and Pessimistic project estimates based on task efforts and section certainties, using the asymmetric multipliers.
Utility: Task completion tracking, Markdown import/export, copy-to-clipboard, data saved locally in the browser.
It's straightforward by design. It helps me break down work, apply my certainty-based estimation, and get a more nuanced forecast than traditional methods often provide.
If you've also found standard PERT or OPM estimation lacking, or you're just looking for a simple, opinionated tool to structure your planning and estimation process, give Wagn Project Tracker a look. It’s the system I’m currently using, refined through trial and error.