How to estimate task duration in a project plan

Every Gantt chart is built on one fragile thing: the duration you type next to each task. If those numbers are wrong, the bars, the dependencies and the final delivery date are wrong too, however neat the chart looks. Knowing how to estimate task duration is the skill that turns a pretty plan into a useful one.

The good news is that you do not need a special method or a spreadsheet full of formulas. You need a habit of breaking work down, thinking in ranges, writing down your assumptions and revising as you learn. This guide walks through that habit using one concrete example.

Effort, duration and elapsed time are not the same

Before estimating anything, separate three numbers that people often mix up:

• Effort is how much working time the task needs. Writing a landing page might take 12 hours of effort.
• Duration is how many working days the task spans on the calendar. Those 12 hours might spread over three days because the writer also has meetings and other work.
• Elapsed time includes waiting. If the draft goes to a client for review and they take four days to answer, the wait is part of the schedule even though nobody is working.

A Gantt chart shows duration. So when you estimate, ask "how many working days will this task occupy, given who does it and what else they are doing?" rather than "how many hours of pure work is this?". Model waiting as its own task or as a dependency, so it is visible instead of hidden inside an optimistic number.

Our example: a small website project

To keep things concrete, imagine a five-person team building a brochure website. The work looks like this: gather content, design the pages, build the templates, load the content, test, and launch. We will estimate it step by step.

Step 1: break work down until estimates feel easy

Large tasks are hard to estimate because they hide unknowns. "Build the website" could be two weeks or two months. "Build the contact page template" is something you can picture.

A useful rule is to split work until each task takes roughly one to five working days. Shorter than a day and the plan becomes noise to maintain. Longer than a week and the estimate is mostly guesswork.

In a Gantt chart, task groups and subtasks make this easy. Create a group called "Build" and put the individual templates inside it as subtasks: home page, service page, contact page, blog layout. The group's span then follows from the tasks inside it, so you only ever estimate small, concrete pieces.

Step 2: estimate with a range, then pick a number

Single-point guesses tend to be best-case scenarios in disguise. A simple and honest alternative is to give three numbers for each task:

• Optimistic: everything goes well.
• Likely: the normal case, with the usual small interruptions.
• Pessimistic: things go wrong in plausible ways, but not a disaster.

For the "contact page template" you might say 1, 2 and 4 days. The gap between optimistic and pessimistic tells you how uncertain the task is. A task with a range of 1 to 2 days is well understood. A task with a range of 2 to 10 days needs more thought: split it, run a small experiment, or ask someone who has done it before.

For the duration you put in the chart, use a number between likely and pessimistic for risky tasks, and the likely number for well-understood ones. The point is not mathematical precision. It is to stop yourself from always typing the happy path.

Step 3: use past work, not feelings

The most reliable source for an estimate is how long a similar task took last time. If the last three landing pages took four, five and four days, a new one will probably take four or five, no matter how simple it looks today.

Keep this lightweight. After each project, look at your plan and note which tasks ran over and by how much. Patterns show up quickly: maybe content always arrives late, or review rounds always take twice as long as planned. Next time, you adjust the estimate for that kind of task instead of repeating the same mistake.

If you have no history, ask the person who will actually do the work. An estimate from the doer is almost always better than one from a manager guessing from the outside.

Step 4: account for dependencies and waiting

Once you have durations, the dependencies decide when each task can start. In the website project, "Load content" cannot start until both "Build templates" and "Gather content" are done. If content collection is slow, the whole chain moves, even though building is on schedule.

This is why estimating and linking go together. If you want a refresher on how the links work, read Task dependencies in a Gantt chart: how they work. Two habits help here:

• Give every external wait its own task, such as "Client reviews design", with a realistic duration. Do not bury it inside the design task.
• Check which tasks have no slack. A delay in those tasks delays the whole project, so they deserve the most careful estimates.

Step 5: add buffer in the right place

Padding every task by 20% feels safe, but it hides the real risk and tends to get used up anyway. A cleaner approach is to add buffer deliberately and visibly:

1. Estimate each task honestly, without secret padding.
2. Add one explicit buffer task before an important deadline, for example "Contingency: 3 days" before launch.
3. Put a milestone after the buffer so the date everyone cares about stays protected.

Because the buffer is a visible task, the team can see when it is being consumed. If the buffer is half gone by the middle of the project, you learn that early, while you can still react. For more on choosing those deadline markers, see What is a milestone in a Gantt chart?.

Step 6: work out the whole schedule and sanity-check it

With durations, links and a buffer in place, look at the finished chart and ask a few blunt questions:

• Does the end date match what you would have guessed before estimating? If it is much later, your intuition was probably optimistic, and the chart is probably right.
• Is any person assigned to several tasks at the same time? Overlapping bars for one person mean the real duration is longer than shown.
• Which three tasks worry you most? Make sure each has a clear range and a named owner.

If you are starting from a blank page, the full process of building a schedule is covered in How to create a project schedule step by step.

Step 7: keep estimates alive during the project

An estimate is a prediction, and predictions should improve as information arrives. Once a task starts, update its progress honestly. When you discover that a task needs three more days, change the duration right away and let the dependent tasks move with it. Do this weekly rather than waiting for a crisis.

Never silently stretch a task to hide a delay: change the number and note why in the task description, so the next estimate benefits from it.

Letting an AI assistant help with estimates

If you work with an AI assistant, estimating is a good place to use it, with limits. An assistant can draft a first breakdown, suggest dependencies, check which tasks pile up on one person and move dependent tasks when a duration changes. ProGantt Flow includes an MCP connector for this: you connect Claude, Cursor or VS Code to your project and the assistant edits the same plan you see in the app. Its example prompts and setup steps are in the connector docs.

What it should not do is replace the person doing the work. An assistant does not know that your designer is on holiday next week or that the client always takes a week to answer. Treat its numbers as a draft to review, then correct them with what only your team knows.

A quick checklist

Before you call a plan ready, check that:

• Every task is small enough to picture, usually one to five days.
• Risky tasks have a range, and the chosen duration is not the best case.
• Waiting time has its own tasks.
• There is a visible buffer before the key deadline.
• The person doing each task has seen and agreed with its estimate.
• You have a date in your calendar to review the plan weekly.

Estimating well is less about being right the first time and more about being honest, visible and quick to correct. Build the plan in ProGantt Flow, adjust durations as you learn, and let the chart show you what the project really needs.