Separate effort, duration and capacity
Effort is the amount of work required, for example in hours or person-days. Duration is the calendar time between start and finish. Capacity is the amount of time people can actually dedicate to the project.
Confusing these concepts creates overly optimistic plans. Five days of effort does not mean delivery in five days if the resource is available only 40% of the time.
A simple calculation
Theoretical duration = effort / available capacity, then add dependencies, approvals and sensible buffers. This does not replace judgement, but avoids a common initial mistake.
Break work down before estimating
The larger the task, the less reliable its estimate. Break the project into deliverables and then into activities that are homogeneous enough to reason about.
Estimate with the people who will do or understand the work. They often know operational details that are invisible in a purely high-level plan.
Write down assumptions
An estimate only makes sense when its assumptions are visible.
- Expected quality level.
- Availability of data and content.
- Number of review cycles.
- Stakeholder availability.
- Supplier or technical dependencies.
Use ranges instead of false precision
Early in a project, uncertainty is high. A range such as “8 to 12 days” is often more honest than an arbitrary 9.5-day number.
Use optimistic, most likely and pessimistic values when useful. The gap forces the team to identify the risks behind uncertainty.
Refine progressively
Estimates should become more precise as scope is clarified, technical choices are confirmed and dependencies become known.
Include coordination, approvals and uncertainty
Production work is only part of the effort. Useful meetings, reviews, testing, corrections, documentation, release preparation and coordination should be included.
Add buffers according to uncertainty rather than applying the same percentage everywhere. New areas or third-party dependencies deserve more reserve.
Do not plan 100% of capacity
A team planned at full capacity has no room for incidents, questions, urgent work or normal coordination. Slightly lower planned utilisation often makes delivery more reliable.
Compare estimated and actual effort
At the end of a work package or project, compare estimates with actual effort. The purpose is not to punish variance but to improve the estimation model.
Look for causes: unclear need, missed dependency, underestimated quality level, approval time, scope change or unfamiliar skills.
Build a reference base
Keep lightweight history: task type, estimate, actual effort, context and variance cause. Over time, this evidence is often more useful than a complex theoretical method.
Implementation checklist
Before considering the topic under control, check these points in your project.
- Work broken down.
- Assumptions written.
- Real capacity known.
- Buffers adapted.
- Review planned.
Continue with related project management guides
Conclusion
This method becomes truly useful when it is applied consistently and adapted to the project context. The goal is not to create more documentation, but to make decisions, responsibilities and trade-offs more explicit.