Ever wondered why a task starting on 1/2/17 and ending on 1/30/17 displays a duration value of three days while a task starting on 1/2/17 and ending on 1/6/17 displays a duration value of five days? Or why an allocation of three hours on one day is a duration value of 0.75 days, while an allocation of eight minutes on another day may show as 0.33-day’s duration? This article explores how Microsoft Project calculates duration and allocates work. I also try to demystify why these seeming inconsistencies are actually accurate.

**Microsoft Project isn’t Human**

The first thing to do is to forget about thinking like a human. As humans, our instinct when allocating a resource four hours of work on a day is to allocate the work from 8:00 a.m. to 12:00 p.m., noon to 4:00 p.m. or some other contiguous block of time.

Unfortunately, Project doesn’t “think” that way. Microsoft’s project management application distributes work allocation based on mathematical algorithms. As a result, it does things that make sense from an algorithm perspective, but not from a human perspective. And that’s what we humans need to understand.

Project defines Duration as the “Total span of working time for a task.”

Based on that definition, one would think that calculating a task duration would be rather simple: the number of business days between the task Start date and the task Finish date (inclusive).

But let’s consider the following examples. Tasks 1 through 5 and Task 8 are all eight-hour tasks with one assigned resource allocated at 50 percent. Looking at the Duration column values, the task Durations for those tasks range from two days to 10 days. Tasks 6 and 7 are three and four Work hours with 0.75 day and one-day durations, respectively.

There are a lot of inconsistencies. So just how does Project really calculate Duration?

Project uses two duration calculation formulas, one for Fixed Duration tasks and another for Fixed Units and Fixed Work tasks. Let’s explore each.

**Fixed Duration Tasks**

Fixed Duration tasks are the easiest, directly aligning with most people’s initial concept for how duration should be calculated. It’s simply the number of business days between the task Start date and the task Finish date (inclusive).

Looking at Tasks 1 and 2 above, both are Fixed Duration with a project manager-entered duration value of 10 days. Task 1 is a Flat work contour (default value) which simply means Work value is equally distributed across the entire Duration. In this example, the timescale data confirms this, showing there are 0.8 hours of work planned for each of the 10 days.

Task2 is slightly different. While it is also Fixed Duration with eight hours of work, the Work Contour field contains a value of “Contoured,” meaning the project manager manually entered planned work values directly into the timescale data cells. In this case, the PM decided that the eight hours of work would be done by working four hours on day four and the final four hours on day eight. Note that all other days show zero planned hours and the final two days show no value whatsoever.

In both these Fixed Duration examples, the Duration is 10 days simply because the PM entered that value. Both tasks start on 1/2/17 and finish on 1/13/17. How the work is distributed across those 10 days is irrelevant.

**Fixed Units or Fixed Work**

Fixed Units or Fixed Work duration calculations are more complex and less intuitive.

Starting simply, duration only includes any day on which work is planned. Restated from another perspective, duration does NOT include any day on which planned work is zero.

Task 8 below illustrates this concept. Despite the task Start date of 1/2/17 and a Finish date of 1/11/17, the task Duration is three days (not eight) because work only occurs on the three highlighted days.

So far, easy, right? Just wait. It gets more complicated.

**Daily Work Distribution**

The first step in understanding work distribution is to understand how Project divides the work across the days. Assignment Units, Work Contour and Work fields all play a part in this determination.

Again, starting simply, Task 5 below has eight hours of planned work, the resource is allocated with an Assignment Units value of 50 percent, and the Work Contour value is “Flat,” meaning the work is spread equally. Project determines the maximum hours per day to be four (50% x 8 hours per day) and then proceeds to spread the eight hours of work at four hours per day. In this case, the result is a two-day duration.

Task 4 follows the same work distribution process, albeit slightly more circuitously. In this example, the Work Contour value is “Front Loaded.” As with Task 5, the Assignment Units value of 50 percent determines that work distribution cannot exceed four hours per day, but the Work Contour (Front Loaded) algorithm determines the number of days and how the work will be allocated on each day. The result is a four-day load pattern highlighted below.

But wait! That doesn’t really explain why each task’s partial daily allocation (compared to an eight-hour day) is considered a full day. The key to understanding this aspect rests within how Project physically distributes the time.

**Time Segment Allocation**

The second step to understanding work distribution is being aware of how Project divides the work day. Each day is 24 hours. Each hour is comprised of 60 one-minute segments. This is a basic but important concept in understanding Project. Let’s go through it in more detail. The following screenshot shows a daily timescale segmented into hours 12 a.m. through 11 a.m. and then 12 p.m. through 11 p.m.

The sample below shows an hour within a day segmented into 10 six-minute segments starting at 0, 6, 12, 18, etc. minutes past the hour. Without grouping, each hour would show 60 one-minute segments.

After the day’s work allocation is calculated, Project distributes the day’s total planned work across the time segments within each day. When the workday is displayed as one-hour segments, the timescale data below reveals what Project is really doing.

If you recall, our Task 5 example showed that Project calculated four hours per day. Looking at Task 5 below, rather than allocating four hours from eight to 12, as a person might do, Project spreads the four hours across all of the day’s time segments. The result, as highlighted below, is that each hour segment contains 0.5 hours of work. Each of the eight one-hour time segments contains planned work. And because each of the daily time segments contains work, Project sees this as a full day of Duration. As a result, the four hours of work counts as a full day of Duration.

Looking back to our Task 4 example, the Work Contour (Front Loaded) algorithm calculated a four-day task duration with daily work allocations as shown below.

The following screenshots show how each day’s planned work distributed across each of the eight one-hour segments. On Monday, the four hours of work spread out as shown below.

On Tuesday, the 2.67 hours of work was distributed as follows:

And on Wednesday, the 1.2 hours of work was allocated as shown below.

Looking at the first three days of Task 4, it’s now understandable why Project considers these small allocations to be full days. Remember, it’s the fact that each of the day’s time segments contain an allocation, regardless of how large or small.

But how is Project calculating the last or partial days?

**Partial Day Allocations**

Partial day allocations occur on the first or final day of work allocation when the remaining work is less than the calculated maximum. Continuing our Task 4 example, the sample below shows how the remaining 0.13 hour (0.13 x 60 min = 8 minutes) of work is distributed across the final day.

To understand how the final day duration of 0.33 is derived, we need to look at the day’s work distribution from a smaller timescale perspective.

Here, I’ve changed the Options to show both Date/Time and the timescale data by hour, grouped into 20-minute segments in order to display how Project distributes the final day of work. If you look at the sample below, you’ll see that Project allocated about 1.2 minutes of work (0.02h x 60 minutes) in each 20-minute segment until all of the day’s total planned work was distributed. This starts at 8:00 a.m. and concludes after eight allocated segments at 10:40 a.m., which also happens to be the task’s Finish time. To arrive at the final day’s allocation of 0.33, divide the eight 20-minute segments containing planned work by the total number of 20-minute segments available in the full work day (3 per hr. x 8 hr. = 24) and you get 0.33 (8 / 24).

In this case, the percentage of the full day is determined by the number of allocated segments compared to the total number of segments within the day.

**What to Remember about Task Duration**

To summarize, Project calculates task Duration in two ways:

- The Duration for Fixed Duration tasks is simply the fixed duration value, regardless of when planned work is or is not distributed within that duration.
- The Duration for Fixed Units or Fixed Work tasks requires a deeper understanding of the algorithms. Duration includes any business day with planned work. Business days with zero planned work are NOT included in Duration. However, to really understand what Project considers a full day of Duration and how it calculates partial days of Duration takes an understanding of how Project distributes planned work.

Planned work is distributed using the following logic:

- Daily work allocation is calculated based on the Work, Assignment Units and Work Contour value. This determines the maximum hour allocation per day, the number of days across which work is allocated and the hour allocation for each day.
- For all days where the day’s work allocation matches the maximum work allocation per day, the day’s work allocation is simply spread equally across the total work segments within the day.
- For the first or last day’s allocations when the allocated work is less than the maximum allocation per day, Project spreads the day’s allocation across the work segments until all the day’s allocation is distributed.

With that logic in mind, Project determines the Fixed Units or Fixed Work full/partial days based on these simple rules:

- If all work segments across the day contain work, regardless of how much or how little, it is considered a full day.
- If the last day’s work allocation doesn’t fill all work segments, it’s a partial day. The percentage of the full day is calculated based on how many of the work segments contain work compared to the total number of available work segments in the full day.

Perhaps now you’ll better understand how eight hours of work can result in a one-day, three-day or five-day duration; and with partial durations, why three hours is considered a 0.75-day duration or how eight minutes can be seen as 0.33-day duration.

## 11 Comments

Very detailed and informative article which cleared a lot of things for me.

However, I could not understand why project would allocate 1.2 minutes work in 20 minutes segment for Partial Day Allocations. Is there some logic to this?

Thanks

Unfortunately, I haven’t been able to find any documentation or logic that explains how project determines the number of time segments across which it will spread a partial day allocation.

Great article!

Bravo, sir!

Well done explanation! The screenshots were very helpful to visualize your descriptions.

Excellent, SIR

The sample below shows an hour within a day segmented into six 20-minute segments starting at 0, 6, 12, 18, etc. minutes past the hour. Without grouping, each hour would show 60 one-minute segments. I am confused by six 20 minute segments, shouldn’t if be 6 10 minute segments or 3 twenty minute segments. Otherwise this has been easy to follow and thankyou.

Adriana;

Excellent catch, thank you. That just goes to prove that no matter how many times you proof read something, it’s still possible for an error to slip by. It should actually say 10 six minute segments. I’ll see if I can get that changed for the benefit of future readers. Again, thank you.

As to the Partial Day Allocations, why 20-minute segment is used but not 15-minute segment or 30-minute, 40-minute segment are used within each hour? Is it because the 0.02h value? Is there any algorithm logic or rules on segment options?

Cheers

Dear Dale,

I agree that Calendars and the definition thereof has a huge effect on MSP calculation of Duration.

Delay in the execution of a Project caused the Schedule to slip.

For crashing of a Project, I’ll have to add Night Shift work to bring the schedule back to to plan.

MSP Hours per day Setting is 9 hrs.

Day Shift Schedule is 7:30 AM to 5:30 PM with an hour Break at Noon, making a 9hrs workday.

Night Shift is 6:00 PM to 6:00 AM with an hour Break at 12:00 AM, making a 11hrs workday.

For a Task of X_days duration, assignment of additional Night Shift Workers (Base Calendar following the Night Shift) causes MSP’s to Increase Duration, rather than to decrease it!!!

The way MSP calculates Duration is well illustrated by your article “How Microsoft Project Calculates Task Duration” https://www.mpug.com/articles/how-microsoft-project-calculates-task-duration/.

In this consideration, I’m led to believe that MSP is NOT SUITABLE for Project Scheduling when Multiple distinct Resource Calendars are involved.

Please enlighten me or point me to the forums/reviews that discuss on this issue.

Thank you in advance.

Yl;

Adding shifts of differing duration (from resource or project calendars) adds an additional level of complexity. Most projects have a simple configuration where the Project calendar = resource calendars. When these calendars are out of sync, Project assigns resources based on the intersection of the calendars. For example, if the Project calendar is Monday-Friday 8-5 and a Resource calendar is configured as Friday-Sunday at 10 hours/day, project will only assign that specific resource to work on Friday for 8 hours because unless otherwise told by the PM, project tasks follow the Project calendar and Friday 8-5 is the intersection of the Project and Resource calendars.

To help address this, Project added Task calendars and the ability for the PM to indicate that project should ignore the resource calendar and only use the Task calendar.

To address your 11 hour shift scenario, try this. Set up a second shift calendar with 11 hour work days. Add that calendar (as the Task Calendar) to tasks that occur on the second shift and check the box indicating that project will ignore the Resource calendar. This should allow resources with an 8 hour resource calendar to work 11 hours on second shift tasks.

Keep in mind that checking the ignore resource calendars box will cause project to ignore the resource calendars on EVERY assigned resource.

Unfortunately, this is about as flexible as project gets.

In addition, if you have the 8-5 resource also assigned to tasks FOLLOWING the resource calendar that could execute at the same time as the second shift tasks OVERRIDING their normal work calendar, you might end up with significantly over allocated resources assigned work during both first and second shifts in the same day. It can get complicated very quickly.

As a guideline, try to keep the schedule as simple as possible by;

* Keeping second shift resources segregated (in project) from other shift resources. Meaning for example, Bob will only work first shift.

* Keep task work segregated by shift. For ex; Task 5 will only be executed during second shift and by second shift resources

* If possible use dependency relationships to isolate task work that crosses shifts, uses task calendars and ignores resource calendars. For ex; the Install task starts Wednesday 8 am and runs for 24 hours using resource from all shifts. Try to ensure that project dependencies don’t allow other tasks to run in parallel

* Break tasks (if possible) to utilize shift resources more simply. For example, a Parts Development task that might take a full week of all shifts to complete could be broken into two tasks, Parts Development Shift 1 and Parts Development Shift 2, both running in parallel with only appropriate shift resources assigned.

Bottom line, keep the schedule as simple as possible and try to identify ways you can avoid overly complex scenarios. It may mean more work for you the PM, but it will result in a schedule that is much simpler to maintain.

Hope this helps.

By submitting a comment you grant MPUG a perpetual license to reproduce your words and name/web site in attribution. Inappropriate and irrelevant comments will be removed at an admin’s discretion. Your email is used for verification purposes only, it will never be shared.