How to calculate project completion time with suitable example

Estimating project duration is like building a life plan. You know where you want to get, you know something will likely go wrong, but you still need to establish a timeline to reach your goals.

If there is one thing to know about estimating project duration, it will have to be this: there are lots of traps to look out for.

But with proper preparation you can make this into an easy experience.

Here is where you start.

What is duration in project management?

Project duration is the total amount of time it takes to finish a project, which you measure in business days, hours, weeks, or months. The duration can be seen at the timeline for project delivery, whether it is five days or five years. Project duration usually depends on your resource availability.

The difference between effort, duration, and elapsed time

In simple terms, effort is focused on highlighting the work units (hours) you need to complete a task or a project, while duration is focused on the time you need to take to complete it. The duration is usually longer than the estimated hours in effort because your team doesn't work non-stop.

Elapsed time is more about the progress — it looks at how long it took from the moment you assigned someone to a project to the moment they completed it. Eventually, it will also show how effectively you're working — are you going to meet the promised deadlines?

How is project duration calculated?

Top-down estimating

PMBOK explains top down estimating, also known as analogous estimating as “a technique for estimating duration or cost of an activity or a project using historical data from a similar activity or a project.”

In other words, here you need to look at your historical data and compare the new project to something similar that has already been completed, assuming that the new project will take approximately as much time and resources to complete.

How to calculate project completion time with suitable example

Bottom up estimating

With bottom-up estimating, you go from detailed to general look — from task to project. The rule is simple — if you cannot make an accurate estimation of a project, dissect it to the units which you can estimate properly, like milestones or even individual tasks.

Parametric estimating

Parametric estimating is basically taking analogous estimating to another level. You also look at historical data only get more accurate when it comes to numbers, introducing something of a "statistical relationships".

That is to say that you need to find a comparable project in your historical data and then customize calculations based on the numerical parameters of your new project.

Three-point estimating

PMBOK explains three-point estimating as “A technique used to estimate cost or duration by applying an average or weighted average of optimistic, pessimistic, and most likely estimates when there is uncertainty with the individual activity estimates.” 

Here you get to reduce your risks by accounting for several scenarios your project could end up following.

Project duration best practices

Suppose you need to build a website and you have estimated that it will take about 40 hours of work (the effort). However, the website will not be ready in 40 hours for a number of reasons: you might have other projects running, you cannot devote all of your time to building a website, you need to take some days off in the middle of the project, etc.

As a result, the effort will be 40 hours, but the duration will be longer. For example, if you decide to devote 5 hours a day to the project it will take you 8 days to complete it (your duration), but if your colleague comes to help and takes half of the workload off your shoulders, the project will take only 4 days.

But whether you will be working alone or with reinforcements, here are some things you could do to get more efficient.

1. Create a resource schedule

When a project involves more than one person working on it, you need to create a resource schedule for transparency and visibility.

Here you will be able to see when your resources are free, full, or overbooked and by how much. This is your best bet to juggle resources and follow the "less is more" concept.

With Runn's resource scheduling, all you need to do is click, drag, and drop workload when you need to allocate it to someone specific. You can extend, shorten, transfer, and split work among your resources to accommodate everyone involved.

How to calculate project completion time with suitable example

2. Include time off

With a resource schedule, it's wise to account not only for the time when someone is available to work but also when they are not. People take vacations, days off, sick leave, etc. — all of which can delay your project delivery if you don't account for them when estimating project duration. But by adding that time off right into the schedule you can avoid surprises and unneeded headaches.

3. Add a contingency reserve

No project is perfect. There will be risks which may or may not happen, delays that may or may not stall the project, additional costs that may or may not make you go over the budget.

With a contingency reserve, you can be prepared for whatever happens and still keep your project going according to plan (even if it's not the most optimistic one).

4. Don't underestimate

People have a natural tendency to be overoptimistic. In project management, this can lead to project failure.

Have you ever moved houses? It never takes the time you expect it to take — there is always a something causing one delay after another and you end up sleeping on a mattress for two weeks.

In a way, projects can be the same. This is why leaving space for some wiggle room, scope creep, ad hoc requests, and the like can help you realistically estimate project duration.

Start a free trial of Runn to see how you can optimize and simplify your project planning and estimation in a matter of a few clicks!

Getting a large project completed on schedule requires advanced planning and attention to detail. Diagramming the project workflow and determining the critical path gives you the expected length that everything will take from inception to completion. For that to be accurate, you need to do a thorough job estimating how long each task will take.

To determine the critical path, divide each project into smaller tasks and note dependencies between them. List the related tasks in the order they must take place and note the earliest date they can start and finish without causing the next activity to be delayed. You’ll find that most projects have multiple paths, since some required activities can be run in parallel. For example, if you’re opening a restaurant, you can be negotiating with produce suppliers at the same time the electricians are wiring your dining area, so those would fall under separate paths. Write out the relationships between tasks as a network diagram, and find the path with the longest duration. That’s the critical path, since any delay in that path will delay the completion of the project.

To estimate how long it will take to complete a task, you need an estimate of the available resources. Determine how many workers you’ll have, whether they will be employees or contractors, and what their level of expertise is. If this is a project where equipment plays a key role, get that firmed up as well. You don’t want to base your scheduling for a construction project on the assumption of having two cranes only to find out you’re only getting one. Also note any schedule constraints, like whether a holiday will interrupt the work week, or whether a competing project threatens to siphon off some of your staff by a certain date.

Getting an accurate completion time ideally involves the input of the workers in charge of performing the tasks. Balance that feedback against historical data and lessons learned from your past projects, as well as industry averages. This serves as a check against schedule padding, in which someone might offer an overestimation of the required time to provide some wriggle room. Also take into account external factors that could alter the schedule. Besides resource allocation questions, this might include environmental factors, or cultural and information systems differences if you’re working with another company.

Once you’ve gathered the opinions of those on the task and compiled the data, it’s your job to provide the final estimates. There are a number of techniques for doing so. In one-point estimating, you simply provide one time estimate for how long an activity will take. Analogous estimating takes into account prior history and uses that as a predictor of present task length. Parametric estimating relies on the relationship between activity variables to come up with a time, while heuristics simply estimates everything by using a rule of thumb, such as setting up the site always takes up 20 percent of the project time.

The most comprehensive way of estimating completion times is by using the Program Evaluation and Review Technique. PERT uses risk management techniques to account for the possibility that a project may be completed ahead of schedule or suffer unanticipated delays. You come up with three different time lengths: the realistic amount of time it is most likely to take, an optimistic assessment, and a pessimistic assessment. Multiply the realistic time by four, add the positive and negative time scenarios, and divide the result by six. That's the time you'd use for estimating task length when compiling the activities to determine the critical path.


Page 2

Inserting cushion times into a project schedule during project planning can improve your project management, but only if you follow some basic procedures. You have to decide whether and how to insert cushion times for the best result. Some ways of including cushion time don't delay the scheduled finish of the project, and you have to avoid causing unnecessary delays by inserting too much cushion time.

The schedule of your project plan shows different activities, their start dates and projected completion dates. The activities are made up of tasks with estimated durations. When you're not sure whether a task can be completed in the allocated time, you can add an extra cushion and lengthen the total duration. The extra task duration delays the completion date of the activity and may delay the project finish date, but you are now more certain that the task in question can be completed in the estimated time.

When you schedule your tasks, you usually find that some tasks can't start because they depend on other tasks to finish. This results in time cushions between tasks. For example, you may want to schedule laying sod right after the spreading of topsoil but can't because the sprinkler system isn't connected and the plumber's schedule is full until the following week. The time cushion in the schedule before you can start to lay sod is called slack time, and you can use it to optimize the project schedule. You can reduce work on the tasks that have slack time and assign more workers to the task that is holding you up. In this case, you may be able to take one of the workers spreading topsoil to help the plumber finish earlier.

Task contingencies are specific time cushions you assign to risky tasks. The process differs from increasing the duration of a task with a cushion, because the contingency amounts remain separate from the tasks. If you don't know how long a task might take, you can assign a time cushion as a contingency to make sure you can complete the task by the projected finish date. If you later get new information that lets you estimate the duration of the task accurately, you can reduce or remove the contingency. Since the contingency time cushion remains a separate amount, it is a more flexible approach than increasing task duration.

If you are uncertain how long an activity will take overall, you can insert time cushions as buffers between the tasks of the activity. Buffers remain explicit time cushions separate from individual tasks and disappear when the task following the buffer starts. The start date of the task reflects the actual start, and the buffer assigned before that date becomes meaningless. You may have used some of the allocated buffer time to start the task earlier than originally scheduled, and you may be able to reassign additional buffer time later in the project if risks there have increased.