What is project time estimation — and what it is not
Project time estimation is the process of forecasting how long each task, sub-task, and overall project will take to complete. It is the foundation of scheduling, resource planning, and deadline commitments. Without estimates, there is no plan — only a list of intentions.
But here is what most guides get wrong: the goal of estimating is not to perfectly predict the exact time a task will take. As Henning Christiansen writes in Project Management: The Red Pill, estimates rarely match actual time spent — and that is not even the point. The real purpose of a time estimate is to set a credible, behaviour-shaping expectation that the team can commit to, the project manager can track against, and the organisation can learn from over time.
This distinction matters enormously. A team that treats estimates as predictions will always be disappointed. A team that treats estimates as calibrated commitments — refined using real historical data — will produce better estimates with every passing project.
Parkinson's Law: the invisible force behind every estimate
Any serious treatment of project time estimation must start with Parkinson's Law. Formulated by C. Northcote Parkinson in 1955, it states:
In practical terms: when you assign a task a four-hour estimate, that task will take four hours — even if a skilled person could do it in two. The estimate becomes the de facto deadline, and most team members will pace their work to reach that deadline, not to beat it.
Christiansen identifies the structural reasons why finishing early is not rewarded: it is rarely acknowledged; the team member may fear looking like they underestimated; early completion can disrupt the manager's own schedule; and some people feel they would be "bothering" the manager by finishing ahead of plan. These are not laziness problems. They are rational responses to the incentive structures in most organisations.
The natural response is to artificially tighten estimates — hoping pressure will accelerate work. This almost always backfires. When estimates are consistently unrealistic, the team stops taking them seriously. Once estimates lose credibility, they lose all utility as planning tools. The goal is calibration, not pressure.
The effective estimation range: 100% to 200%
Christiansen gives a specific, practical target: actual time spent should typically fall between 50% and 100% of the estimate. In other words, the estimate should be between 100% and 200% of the realistic minimum time the task would take for a skilled person working without interruption.
This range does three things simultaneously. It accounts for the reality that workdays are rarely 100% efficient — most people achieve focused, productive work for less than half the day. It creates a buffer that prevents constant overruns without eliminating urgency. And it provides the project manager with a meaningful signal: if actual time consistently falls outside this range, the estimates need recalibration.
Christiansen recommends building a time percentage into every estimate that reflects the organisation's established standard — accounting for meetings, interruptions, context-switching, and the reality of imperfect workdays. This is not padding; it is honest accounting of what it actually costs to complete work in this organisation's environment.
The model-based approach: estimation from the project structure
The most distinctive aspect of Christiansen's approach is that time estimation is inseparable from the project model. You cannot produce reliable task-level estimates without first having a clear model of what the task is, what it depends on, and what it connects to.
For every model and sub-model in the project, four things must be documented before estimating begins:
- Which goal or objective does this model support? — if it cannot be connected to a goal, it probably does not belong in the project
- Which skills or expertise are required? — the skills matrix feeds directly into realistic estimation
- What is the time estimate for developing this model? — grounded in the specific task, not in the abstract
- When is the due date, if any? — connecting estimates to actual schedule constraints
This makes estimation concrete and honest. When the task is well-defined, when the estimator knows what skills are required and can reference the skills matrix, and when the dependency map shows what comes before and after — the estimate becomes dramatically more reliable than one produced in a planning session by people who have not yet thought through the actual work.
One of the most underestimated sources of estimation error is dependencies. A task that appears straightforward in isolation may carry hidden waiting time — for a decision from a stakeholder, for a module from another team, for a regulatory approval. Every dependency should be treated as a potential buffer requirement in the time estimate, estimated separately from the task's active work time.
The most effective approach: historical data
Christiansen is unambiguous: the most efficient and reliable method for time estimation is organisational experience — specifically, recorded historical data from previous similar tasks.
In many organisations, this data does not exist because past time data has never been systematically recorded. Time tracking is treated as an administrative burden rather than a strategic asset. This is a significant missed opportunity. Every project that completes without capturing actual vs. estimated time data is a project that contributed nothing to the organisation's future estimation capability.
The recommendation is to begin building this database immediately. The core requirement is simple: for every task, record the estimate and the actual time spent. Over time — even across two or three projects — this data becomes the most powerful input into future estimates.
Task description and model it belongs to · Skill level required · Initial time estimate · Actual time spent · Reason for variance (if over 20%) · Dependency delays experienced · Whether the estimate was set by the task owner, the PM, or collaboratively
Time estimation methods compared
The project management industry offers many estimation techniques. Here is how the most widely used methods compare — including Christiansen's direct assessment of techniques that appear structured but do not necessarily deliver better accuracy.
Best practices: what expert guidance adds
Involve the task owner in the estimate
The person who will do the work is almost always better positioned to estimate it than the person assigning it. Estimates imposed from above, without the task owner's input, are systematically optimistic — and systematically resisted. When the task owner contributes to the estimate, they take ownership of the commitment. The estimate becomes a mutual agreement, not a directive.
Separate estimation from scheduling pressure
One of the most common estimation distortions is backward planning — starting from a deadline and working backwards to produce estimates that make the timeline fit. This creates numbers that are not estimates at all: they are arithmetic that justifies a predetermined conclusion. Estimates should be produced from the work, then assembled into a schedule. If the schedule does not fit the deadline, scope or deadline — not the estimates — should be negotiated.
Distinguish effort from duration
Effort is the total work required (e.g., 20 person-hours). Duration is calendar time (e.g., 3 days). A task requiring 20 hours from one person at 50% availability takes 5 calendar days, not 2.5. Dependencies, holidays, review cycles, and parallel workstreams all affect duration independently of effort. Both must be estimated separately for an accurate project schedule.
Review and recalibrate estimates regularly
Christiansen makes an important point about the recalibration obligation. If estimates are consistently exceeded, the tasks must be reexamined — not just accepted as "running late". If estimates are consistently too generous, they should also be adjusted downward. An estimate that is never revised is a formality, not a management tool.
| Practice | Christiansen (Red Pill) | Industry best practice | Alignment |
|---|---|---|---|
| Primary estimation basis | Historical organisational data | Historical data + expert judgement | ✓ Aligned |
| Task definition before estimating | Model-based, precise scope | WBS, user story breakdown | ✓ Aligned |
| Planning Poker / T-shirt sizing | Does not improve accuracy | Useful for discussion, not prediction | ✓ Broadly aligned |
| Buffer strategy | Org-standard % per task | Task-level + project-level contingency | ✓ Aligned |
| Parkinson's Law | Central to the model | Acknowledged but underemphasised | ◎ Book stronger |
| Effort vs. duration | Implicit in model dependencies | Explicitly distinguished | ◎ Industry adds clarity |
| Estimate recalibration | Mandatory when pattern diverges | Recommended at retrospectives | ✓ Aligned |
The most common estimation mistakes
- Estimating without historical data: every estimate based purely on gut feel or group consensus is a guess with no error-correction mechanism. The only way to improve estimates over time is to record and review past data.
- Confusing "can be done" with "will be done": a task that could theoretically take 2 hours will take 4 if that is what is allocated, because of Parkinson's Law. The estimate must account for the real-world context.
- Letting deadlines drive estimates: backward planning produces estimates that are untethered from actual work. The resulting plan will fail on a schedule that was predetermined.
- Ignoring dependencies: tasks that appear short in isolation can carry multi-day waits for approvals, external inputs, or decisions. Every dependency is a potential buffer that must be estimated separately.
- Never recalibrating: an estimate set at the start of a project and never revisited is not a management tool. It is a historical artefact. Estimates must be reviewed when evidence suggests they are wrong.
- Treating all time as equal: a senior developer's estimate for a task is not the same as a junior's. Skill level must be part of the estimation input and should be captured in the skills matrix.
Time estimation in Proglar
Proglar's project management platform is built on the model-based discipline Christiansen describes. Time estimates are set at the task level, connected to the specific model or sub-model the task belongs to. As team members log actual time, the system captures estimated vs. actual data automatically — building the historical database that makes future estimates better.
Dependencies between tasks are modelled explicitly, making waiting time and cascading delays visible before they hit the schedule. When estimates consistently overrun or underrun, the variance is visible in the time tracking dashboard — giving the project manager the signal to recalibrate before the pattern becomes a problem.
Estimates as management tools, not predictions
Christiansen's Unicorn project manager treats time estimates the way a skilled pilot treats an instrument panel: not as the truth, but as the best available information — to be read critically, updated continuously, and acted on decisively when they diverge from reality.
- Estimates are set at task level, grounded in the project model, not in abstract categories
- Every estimate includes an organisational standard buffer — honest, not padded
- Actual time is recorded for every task, building the historical database
- Estimates are recalibrated when patterns diverge — not explained away
- Dependencies are estimated explicitly — waiting time is never hidden
- The team contributes to estimates; the project manager owns the commitment
Build estimates your team can commit to
Proglar connects task-level estimates to your project model, logs actual time automatically, and builds the historical database that makes your next project faster to plan. Try free for 30 days.