How Microsoft Project Calculates Task Duration

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.

Image Source

Next Webinar

Projects in the Fast Lane: Getting High Performance from a Cross-Cultural Team

Written by Daryl Deffler
Daryl Deffler is currently employed by a large insurance company where he provides project management, project scheduling tool, process, and standards consulting for an enterprise project management office comprised of about 200 project managers. He has over 25 years in the IT project management field with experience managing small projects to large programs. During this time he has also developed and taught classes in both project management and scheduling tools such as Microsoft Project 2013, Primavera and ABT Workbench. He has been employed in the IT industry since 1979 in additional roles, including software development, technical support and management across mainframe, midrange and PC platforms.
Share This Post
Have your say!
00
10 Comments
  1. Great article!

  2. Bravo, sir!

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

  4. 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

  5. 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.

  6. 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.

  7. My comments to your response as follows:
    1) It is a common phenomenon that a Project that is sizable often runs into delay, requiring a recovery by pumping in more manpower on shift work such as working the D/S workers late (say, 6pm to 9pm) and more substantially, adding N/S resources
    2) For a Project that is already underway, to make modifications to the Task List midstream as you’ve suggested (by breaking the tasks to suit the various shift patterns) will not be too feasible. The Original Project Schedule is already carved on stone, so to speak, and Baselined.
    3) Making use of Task Calendars will render the D/S Work inoperable. By that I mean Tasks that are carried out in D/S and continue to Shift work will have no “Placeholder” for MSP to spread the Work.
    MSP has a queer way of calculating Duration. Observing the Task Usage View, it appears that the following take place:
    a) First, the WORK is proportioned out according to the Head Counts of each Shift (D/S, 6pm-9pm, NS)
    b) The apportioned Work is distributed to the time segments according to the defined time segmentation (15mins, 2hr, etc), filling-up the working time of each Calendar (D/S, 6pm-9pm, NS). For example for 15min segmentation, 10D/S men will have a value of 10×15/60=2.5hrs of work assigned to the segment.
    As a corollary to a) & b), the number of time segments with Assignments will be the same for each Work Pattern ((D/S, 6pm-9pm, NS)
    c)The count of segments with assignment are totaled, divided by the number of defined hours per day, to obtain the Duration. For the case of Standard Calendar, the defined hrs per day will be 8hrs.
    d) The beginning and the end assignments of the combined Shifts will rolled-up to the Summary to define Another Duration Value.
    A point to note is that the Calculated Values of c) & d) may differ in some cases. This is rather confusing but understandable from the point of view that the bases of calculation differ.
    This bring me to the conclusion that MSP is NOT SUITED for cases when there is a combination of Shift Work. To accelerate Project Completion, a natural thing to do is to increase resources in Shift Work. In applying these Shift manning, unexpected results will occur. Adding resources results in INCREASED DURATION!!!
    In order to obviate this shortcoming of MSP, I make use of a workaround.
    i) Shift Work Resources will be aligned with the Project Calendar, meaning 6pm-9pm shift will adopt the D/S Calendar. Same for NS.
    ii) Manpower assignment for respective Shift will be adjusted for their availability. As such, a 10 men, 6pm-9pm assignment will take the value of 10×3/8=3.75 men when we assign to the Task concern. 8 being the 8hrs day of Standard Calendar. For the case of NS (6pm to 6am; 11 hrs of work), the equivalence will be 10×11/8=13.75 men.
    The result of MSP Duration Calculation perfectly reflect the expected reduced Duration of [Total WORK/Sum of Available Work hrs].
    A caveat is the PEAK Manpower obtained from MSP will have to be reversed to Normal level by the above Availability Multipliers.
    My apology for the verbose commentary.
    Plse offer me your thoughts on this matter.
    Thank you again.

  8. yl
    I agree with your over all assessment. MS Project seems to work fine in most of the more straight forward scenarios. But I’ve also noticed that as the project scenarios become more complex with things like multiple shift work, overlapping shift work, and team members in different time zones/countries, it becomes an increasingly more complex and difficult task to create a realistic/tight schedule and maintain it. And this becomes exponentially more complex in a manufacturing environment where the PM is trying to reflect the fact that part of a product assembly is started on first shift and then finished on the second shift.

    I wish I could point you to some resource that would detail how to handle your scenario, but I don’t know of any. As a result, the only thing I’ve found that works consistently is to identify (sometimes creative) ways to simplify the scenario so that we can push the schedule (so to speak) back into the range where Project does work well.
    For example, rather than complicating the issue with the fact that the project team is in New York, Denver, and India, set up the schedule as if the entire team is in one location. After all, when you think about it, the fact that one resource works 8 hours on Monday during East Coast time and another work 8 hours on Monday on India time, both resources are working 8 hours in the same day.
    When doing shift work, you might try setting up the project calendar to cover the longest number of hours per day and every possible work day. Then use resource calendars to define specific hours/days for each resource. Since Project schedules work based on the intersection of the calendars, every resources normal working hours should therefore intersect the project calendar 100% and therefore resources should schedule as expected. Meaning, if the longest shift is 11 hours and some team members work M-Th for 11hours and others work Wed-Sat but only for 8 hours, set up the project calendar for M-Sat 11 hours per day.

    I know this doesn’t provide specifics, but I think what you’re doing is falling right in line with how I would approach the situation. Identify where the problems are appearing, try to find ways to simplify (as needed), experiment with work arounds, and go with what works.

    Based on your response dates, it appears you’ve been working with this issue for quite some time. I wish you the best of luck.
    And since most learnings and deeper understandings of the inner workings of Project come from experimentation, you might want to consider publishing your approaches/findings in a future MPUG article.

    • Thank you for your very prompt response. Yes, it has taken me quite a while to figure out how MSP works and to circumvent the algorithm with a Workaround. The exigencies of our Project work demands a solution to the discrepancies MSP give rise to. My sincere thanks to you for validating my approach. I’ll certainly share it with our community in due course. Thank you again.

  9. yl
    I had another thought/suggestion on your question.
    I’ve talked to multiple PMs who’ve had issues with Project when they try to make Project perform as a work scheduling tool. Not the people side of it, but the product manufacturing side of it. For example, their company makes widgets and they’re try to use Project to create a schedule that will manage the manufacturing work schedule where creation of a widget can be started on first shift, finished on second shift, finished in the same shift, and any combination.
    Project doesn’t handle this well. When a PM tries to configure this scenario in Project, it ends up exponentially increasing the project schedule complexity as well as the work required to maintain the schedule.
    In these scenarios, I’ve recommended simplifying the schedule by tracking the individual widget production schedule outside of MS Project, much like you might do with Agile story points. Identify the total widgets, estimate the work, calculate the estimated duration for the manufacturing work, and plug those estimates into Project. For example, there are 237 widgets to manufacture, it should take both 1st and 2nd shifts 4 weeks to complete the required widget production. Create 4 week tasks in Project and attach the shift resources accordingly. Then track widget production in an external tool (could be Excel) to identify not started, in production, and completed. When reporting you can then compare widget production Project hours % complete to total widget % complete to verify if you’re on track.
    This approach generally works for the following reasons.
    * As a PM, our role is to identify total project duration and cost. When will it be done and how much will it cost?
    * It significantly reduces schedule complexity which allows Project to schedule better
    * It significantly reduces our efforts as a PM to manage the schedule on a day to day basis
    * It removes our (PM) involvement in widget scheduling changes…we don’t care what sequence widgets get completed and which shift started or finished them.
    Note that you will need someone on the manufacturing side to own and manage the widget production. But that’s where their expertise is. Give them ownership and manage them as a sub-team.
    * It supports on going sponsor reporting

    Again, I don’t know your specific project details, but maybe some flavor of this general approach might help.
    Think outside the box. Utilize Project for what it’s good at. Utilize other tools/approaches where needed.

    Hope this helps.
    Good luck!

Leave a Reply