Share via

How Finish variance is calculated in case Task Duration is entered in eDays and the Task Type is Duration based

Anonymous
2016-06-17T11:41:26+00:00

In Microsoft Project it is possible to define task in terms of ‘elapsed’ days. Elapsed days are used when a task’s duration needs to disregard any ‘nonworking time’ or resource constraints.

I have defined the task with Duration as 10e days.  The task was baseline. They task was delayed by 4 days. I expect the Finish variance to be difference between Actual Finish date and Baseline finish date ( 30th June - 26th June)  i.e 4 days, however I see the finish variance as 13 days.

The duration variance is correct as 4 edays then why is Finish Variance showing as 13 days. This is leading to confusion in Task Tracking View to user as they interprete it as difference between  Actual Finish date and Baseline Finish date.

In project options , one day is 8 hours and standard calendar with 5 working days in a month and no other holidays or exceptions defined in calendar.

Here is example to try out and check in Project Professional

Task Mode Task Name Duration Start Finish Baseline Finish Actual Finish Finish Variance Duration Variance Predecessors Resource Names Work
Auto Scheduled Task1 14.35 edays Jun 16 '16 Jun 30 '16 Jun 26 '16 Jun 30 '16 13.25 days 4.35 edays R1 344.5 hrs
Auto Scheduled Task2 11 days Jun 16 '16 Jun 30 '16 Jun 29 '16 Jun 30 '16 1 day 1 day R2 88 hrs
Microsoft 365 and Office | Access | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

4 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2016-06-20T17:05:54+00:00

    I agree with Trevor – not a bug, just how Project works.

    Some fundamental issues:

    1. Project stores all durations (including finish variance) in minutes.  Displaying any other intervals (hours, days, weeks, months) is the result of converting minutes using the conversion factors in the Project options.
    2. Under default conditions 1 elapsed day equals 3 (8-hour work) days.  That is, 1 eday = 24 hrs * (60min/hr) = 1440 minutes.  This is converted to (work) days as 1440 minutes / (8 hrs/day * 60 min/hr) = 3 days.
    3. Specifying “elapsed” durations does a few things to the task, in effect:
      • Implicitly applies a 24h x 7d weekly calendar;
      • Implicitly ignores Resource Calendars in scheduling the work;
      • Automatically displays all other duration fields for the task (including slack and duration variance) in “elapsed” time;
      • Introduces complications to the critical path calculation – just like other variable calendars do.
    4. Unfortunately, Finish Variance seems to always be displayed in the default duration-entry units for the project – i.e. minutes, hours, days, weeks, or months – none of these are “elapsed.”  (Not sure why this is; there’s no obvious reason why duration variance can be converted but not this one.)

    For these and other reasons I avoid elapsed durations with very few exceptions.  An 8h x 7d calendar with no holidays typically suffices for many purposes.

    Was this answer helpful?

    4 people found this answer helpful.
    0 comments
  2. Anonymous
    2016-06-20T00:52:40+00:00

    Greema,

    You haven't really provided enough information for us to replicate your scenario exactly.

    Also, you need to choose a date/time format which displays the time as well as the date. File, options, general.

    Also, how can the task have an actual finish on 30 June when right now it is only 20 June?

    Actuals are things which have happened in the past.

    Even so, I made a new file with a start on 16 June 08:00, with one task and 10 ed duration, baselined it, and then typed in the actual finish date 30 June in the tracking table.

    MSP filled in the actual start as 16 June 08:00.

    Also, because I did not specify the time, MSP adopts the default finish time which is 17:00.

    I get this result, similar to yours. I think if you work out how many 8 hour periods there are between 30/06/16 17:00 and 26/06/16 08:00, you will find that it comes to 13.13. The ".13" (0.125 actually) is 1 hour of an 8 hour day.

    Like this:

    26/06/2016 08:00 - 16:00

    26/06/2016 16:00 - 24:0027/06/2016 00:00 - 08:0027/06/2016 08:00 - 16:0027/06/2016 16:00 - 24:0028/06/2016 00:00 - 08:0028/06/2016 08:00 - 16:0028/06/2016 16:00 - 24:0029/06/2016 00:00 - 08:0029/06/2016 08:00 - 16:0029/06/2016 16:00 - 24:00

    30/06/2016 00:00 - 08:0030/06/2016 08:00 - 16:00

    30/06/2016 16:00 - 17:00

    Task Name Duration Start Finish Baseline Finish Finish Variance Duration Variance
    Task1 14.38 edays 16/06/16 08:00 30/06/16 17:00 26/06/16 08:00 13.13 days 4.38 edays

    Not a bug. Just how it works.

    Any help?

    Was this answer helpful?

    0 comments
  3. Anonymous
    2016-06-19T05:39:57+00:00

    Hi Rod,

    I am using Project Professional 2013. I have a view created in Project Online where we have  Status indicators based on value in Finish variance days i.e. if <30d then it is shown as Green and so on. These indicators  are showing unexpected results where task duration is defined in edays.

    Which version do you suggest to use. Was this a known issue and resolved  in 2016 ?

    Thanks

    Regards,

    Greema

    Was this answer helpful?

    0 comments
  4. Anonymous
    2016-06-19T02:05:52+00:00

    What version of Project is this? Have you updated to latest update? If not, do so, and try to recreate again (progress=0%, then 100%).

    Was this answer helpful?

    0 comments