How to estimate project timelines realistically

Every project manager has watched a carefully constructed timeline collapse in the first week. The tasks were reasonable, the team was capable, and somehow everything still took twice as long as planned. This isn’t a failure of willpower or competence - it’s a failure of estimation method.

The problem isn’t that we’re bad at predicting how long tasks take. The problem is that we’re estimating the wrong thing entirely.

Most timeline estimates focus on effort - how many hours of actual work something requires. A developer might accurately say a feature needs 16 hours of coding. But that estimate ignores everything that happens between starting and finishing: waiting for design assets, clarifying requirements mid-build, three days of radio silence from the client, the “quick sync” that devours Tuesday afternoon. The work takes 16 hours. The calendar takes three weeks.

This gap between effort and duration is where most schedules die.

What emergency departments figured out decades ago

Emergency rooms solved a version of this problem long before software existed. A patient assessment might require 20 minutes of a doctor’s direct attention. But the patient’s total time in the department - what hospitals call ‘door to disposition’ - runs four to six hours. Tests get ordered, results come back, specialists get paged, beds get found.

ED administrators learned that speeding up individual tasks barely moves overall throughput. What matters is managing the spaces between tasks: handoffs, waiting, dependencies, bottlenecks. They track ‘time to first physician’ not because the greeting matters, but because a 30-minute delay at triage cascades into a two-hour delay at discharge.

Project timelines work identically. A two-hour task that sits waiting for three days is a three-day task for scheduling purposes. Your timeline needs to reflect the calendar, not the timesheet.

Estimate in calendar time, not work hours

Here’s how to build timelines that don’t lie to you:

Start with dependencies, not tasks. Before estimating anything, map what blocks what. Which tasks can’t start until something else finishes? Where are the external dependencies - client approvals, third-party API access, legal sign-off, decisions from people who don’t reply to email? These constraints shape your timeline more than individual task estimates ever will. I’ve seen two-week projects stretch to eight weeks because nobody mapped the approval chain upfront.

Schedule the handoffs explicitly. When work moves from one person or team to another, that gap isn’t zero. Design to development takes two days minimum - the developer needs to review, ask questions, get answers. Review cycles take a week when the reviewer has their own priorities. Put these in your timeline as actual line items, not invisible assumptions.

Use ranges, not points. “Between two and five days” is honest. “Three days” is a guess pretending to be a fact. The narrower your range, the better you understand the work. If you can’t narrow it below a 3x spread, you don’t understand the work yet.

Account for the utilisation lie. Nobody works eight productive hours on your project every day. A senior developer I worked with tracked his time for a month: 23 hours per week of actual focused work, the rest eaten by meetings, Slack, context-switching, and “quick questions.” That’s 58% utilisation, and he was protective of his time. A “five-day effort” from someone at 50% utilisation is ten calendar days. Plan for this or be surprised by it.

Buffer at milestones, not tasks. Padding every task estimate triggers Parkinson’s Law - work expands to fill available time. Keep individual estimates honest and add explicit buffer at phase transitions. A 20% buffer at each milestone creates slack where you need it without hiding it in inflated line items.

The three-point method (use sparingly)

When you genuinely don’t know how long something will take - new technology, unclear requirements, first time doing this type of work - use three estimates: optimistic (everything goes right), pessimistic (reasonable problems occur), and most likely (typical conditions).

The formula: (Optimistic + 4×Most Likely + Pessimistic) / 6

For a task you’d optimistically finish in 2 days, realistically 4, pessimistically 8: the weighted estimate is 4.3 days.

Don’t use this for routine work. If you’ve built login systems before, you know how long login systems take. The three-point method is for genuine uncertainty, not false precision on familiar tasks.

Historical data beats your optimism

The single best predictor of how long something will take is how long similar things have taken before. Full stop.

If your last three website redesigns took 14, 18, and 16 weeks, your next one will take 14-18 weeks. Not 8 weeks. Not 10 weeks. I don’t care how energised everyone is at the kickoff meeting or how much “we’ve learned from past mistakes.” The base rate is 14-18 weeks.

This requires tracking project durations, which most teams refuse to do because the numbers are embarrassing. Track them anyway. When scope creep hits and your boss asks why you’re behind, you’ll want data showing that the last project crept by 40% too.

No historical data? Borrow it. Ask peers at other companies. Find published post-mortems. Check industry surveys. A SaaS integration “typically takes 6-12 weeks” according to vendors who want to close deals - so plan for 12-16. Imperfect external data beats confident internal fiction.

When you’re wrong (and you will be)

Estimation is probabilistic. You’re not predicting the future; you’re defining a probability distribution. The goal isn’t perfection - it’s useful accuracy that improves over time.

Track your variance obsessively. When projects finish, compare estimates to actuals. Were you consistently 30% short? Did integration tasks always blow up? Did client review cycles take triple what you planned? This feedback loop is how you get better. Without it, you’ll make the same mistakes forever.

Communicate uncertainty in ranges, not dates. “Mid-March” sounds precise but means nothing. “Between March 10 and March 28, most likely around March 18” lets stakeholders plan appropriately. They can schedule the launch event for late March instead of March 15th and then scrambling when you’re not ready.

Re-estimate as you learn. Day 1 of a project is when you know least about it. By Day 30, you’ve discovered the hidden complexity, the integration nightmare, the stakeholder who changes requirements weekly. Update your timeline. This isn’t failure - it’s incorporating reality. Clinging to your Day 1 estimate when everything has changed isn’t integrity; it’s delusion.

Timelines are communication tools, not blood oaths. Build them honestly, update them when reality demands, and track what actually happens. The project manager who’s 20% off with good communication beats the one who’s 50% off with false confidence every time.

---

Quick reference

Door to disposition: Hospital metric measuring total time from a patient’s arrival to their final outcome (admission, discharge, or transfer).

Throughput: The amount of work or number of items completed within a specific time period.

Utilisation: The percentage of available work time actually spent on productive project work versus meetings, interruptions, and other activities.

Parkinson’s Law: The principle that work expands to fill the time available for its completion.

Three-point estimating: A forecasting method using optimistic, pessimistic, and most likely estimates to calculate a weighted average duration.

Scope creep: Uncontrolled expansion of project requirements beyond what was originally planned and agreed upon.

Variance: The difference between estimated project duration or cost and actual results.