0

My project started in Jan 2020 and as of Jun 2020, we have spent a total of 80 working days ( minus weekends and public holiday). However, the actual duration given by the MS Project is over 90 working days. This doesn't make sense as how could the actual duration in MS Project be more than the actual duration of the entire project. Can anyone please advice.

The project is scheduled to end in July 2020, where we have a total of 100 scheduled working days. The scheduled working days matches if calculated manually.

2
  • Have you defined weekends and public holidays as "not working" ?
    – Solar Mike
    Commented Jun 30, 2020 at 13:00
  • Hi yes. Weekend and public holidays have been defined
    – Jetstream
    Commented Jul 1, 2020 at 14:03

2 Answers 2

1

I think the simple answer is that you have a mismatch between the calendar you are using to manually calculate duration and the standard calendar MSProject is using to calculate it. You need to build a calendar in MSProject to match what you are using offline. Or, just simply use MSProject's definition of the calendar and its duration outcome.

2
  • It can’t be since the scheduled duration calculated manually and from the MSP matches. However the actual duration doesn’t match. Plus the manual calendar is based on the calendar in the MSP
    – Jetstream
    Commented Jul 1, 2020 at 14:05
  • So both the planned duration of your calendar and MSP match but actuals differ? I misread that in the OP. Sorry about that. And both the baseline start and finish dates match actual start and finish, i.e., there is no finish variance?? If so, then I'm at a loss. Commented Jul 1, 2020 at 14:11
1

The “Actual Duration” of an in-progress summary task (including a project summary task) in MSP is NOT the same as – nor even closely related to – the elapsed work days from the start of the summary to the Status Date. Rather, the actual duration of the summary is the product of its duration and its %complete, where the latter is computed as a duration-weighted average of the %completes of its sub-tasks.

That is, for a summary task,

  1. Duration = ProjDateDiff ([Start],[Finish]) (The difference between the rolled-up start and finish dates, using the applicable calendar)
  2. %Complete = Σ[Subtask Actual Durations] / Σ[Subtask Durations]
  3. Actual Duration = Duration * %Complete
  4. Remaining Duration = Duration - Actual Duration

The summary task’s rate of progress (as timewise increase in %complete or Actual Duration) is highest when many of its subtasks are being executed concurrently and lowest when only one or two subtasks can be executed at a time. Consequently, for a typical complex project that is running exactly according to plan, the indicated progress of the project summary task (as Actual Duration) will start out trailing the Status Date during the initial ramp-up period but will lead the Status Date substantially by the end of the main execution period (prior to ramp-down). Thus, your indicated Actual Duration of ~90+ days at a Status Date that is 80 days into a 100-day project seems unremarkable. That said, it is not a valid substitute for critical path analysis, earned valued analysis, or other suitable forecasting methods.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.