Glossary
Project duration accounts for calendar time, parallelization, dependencies, and rework. Learn to forecast realistic timelines for software projects.
Across three companies — Shiksha Infotech, UshaOm, and Salesken — I've seen the same engineering challenges repeat. The details change but the patterns don't.
Project duration is the total time from when a project starts until it's complete. It includes all the phases: planning, development, testing, deployment, and sometimes post-launch monitoring.
Project duration is not the same as development time. Development might be 4 weeks. But if there's 2 weeks of planning, 1 week of testing, and 1 week of deployment, project duration is 8 weeks. Many PMs conflate these and under-estimate.
Accurate project duration estimates enable credible commitments. "We can ship this feature in 8 weeks" is very different from "we can ship this feature in 4 weeks." One is credible planning. The other is wishful thinking.
Underestimating project duration leads to:
Estimating project duration accurately is one of the highest-leverage things a PM can do.
They're often conflated but different:
Development time: Hours spent actively building. Usually 60% of project duration.
Project duration: All the time from start to finish. Includes: planning, design review, code review, testing, deployment, and often buffer for unexpected issues.
Example project timeline:
Development time (the time engineers spend actively coding) is 4 weeks. Project duration is 8 weeks.
When a PM says "this should take 4 weeks," they often mean development time. When they commit to leadership "this ships in 4 weeks," leadership hears project duration. This mismatch creates missed commitments.
1. Estimate development time. How long will active development take? This is the core work.
2. Add 20-30% for planning and design. Before development, there's work: clarifying requirements, designing the solution, getting alignment.
3. Add 20-30% for testing and review. After development, code review takes time, QA finds issues, fixes are made.
4. Add 10-20% for deployment and stabilization. Getting code to production, monitoring for issues, fixing production bugs.
5. Add 10-20% buffer for unknowns. Things take longer than expected. Unexpected blockers arise. Dependencies delay.
So if development time is 4 weeks:
Total project duration: 8 weeks for something that required 4 weeks of active development.
"Development time = project duration." It doesn't. Development is only part of the project.
"Code review takes no time." Good code review takes time. If you're not accounting for review time, your estimates are optimistic.
"We should eliminate the buffer." Buffers aren't waste. They're insurance against unknowns. Eliminating buffers guarantees you'll miss dates.
"We can parallelize everything." Some things run in parallel (design while planning). Others are sequential (testing after development). Assuming maximum parallelization leads to optimistic estimates.
"Testing should take 10% of time." Depends on risk tolerance. Security-critical projects: 20-30% of time in testing. Standard projects: 15-20%. Quick features: 10%. But never zero.
Project duration directly affects how many projects fit in a quarter:
If your team has 13 weeks of capacity and project duration is 8 weeks, you can fit 1 major project. If project duration is 4 weeks, you can fit 3 projects.
Underestimating project duration by 2 weeks per project means you'll commit to 3 projects and deliver 1.5.
This is why accurate project duration estimation is a lever for organizational credibility.
Waterfall: Estimate the entire project upfront. Project duration = sum of all phases.
Agile: Break the project into sprints. Estimate each sprint. Project duration = sprints needed × sprint length.
Both work if estimates are honest. The difference: Agile lets you discover information incrementally and adjust. Waterfall commits upfront and is harder to adjust.
For uncertain projects (especially those involving new technology or unknowns), Agile is usually better because you can adjust as you learn.
"Experienced teams are faster, so we can reduce estimates." Experienced teams often estimate better (more accurate) but not necessarily faster (estimate = actual time). Don't assume experience = speed.
"We can compress any project by 20%." False. Some projects have critical paths that can't be compressed. Adding people often makes it slower (communication overhead). Compression sometimes works, but assuming it's possible for every project leads to missed dates.
"Project duration is determined by code complexity." Code complexity is one factor. But project duration is also determined by: requirements clarity, team knowledge, testing needs, and deployment complexity. A simple feature in an unfamiliar system can take longer than complex feature in a familiar system.
Q: How do we estimate if we've never built something like this before?
A: Reference class forecasting. Find the closest thing you have built. If you haven't built something like this, find the closest analogy. "This project is like X, but bigger/smaller/more complex/less complex. X took 8 weeks. This should take 10-12 weeks." Acknowledge uncertainty: "We have limited reference data, so estimate has high uncertainty."
Q: Should project duration include post-launch work?
A: Depends on how you define "complete." If complete means "shipped," then no. If complete means "shipped and stable," then yes. Be clear about the definition when estimating.
Q: How much of the buffer should actually be used?
A: If you're using buffers wisely, you'll use 0-30% of them. More than that suggests your estimates were too optimistic. Less than that suggests your buffers are too large. Aim for using 15-20% on average.
Keep reading
Related resources
