Question about how Replan Dates handle the current week

Hi, I have a question about how Process Dashboard calculates Replan Dates.

The documentation says that the dashboard uses simple linear extrapolation into the current calendar period, and that replan dates may fall on weekends or holidays. This suggests the calculation uses calendar time, not working time.

What I need to clarify is:
1) When calculating how much of the current week is left, does the dashboard assume a full Monday–Sunday calendar week?
2) Does it ignore working hours completely (e.g., Mon–Fri schedules)?
3) In other words: Is the Replan Date always based purely on calendar-time proportions, never on working-time availability?

Just trying to confirm how the current week is interpreted in the replan calculation. Thanks!

Different people have different work schedules: which days they work, and which hours. The Team Member List in the WBS Editor does not have a way to record those nuances; and the dashboard has no way to respect nuances that it knows nothing about. So the Replan and Forecast dates are based purely on calendar-time proportions: 24 hours a day and 7 days a week.

Thanks a lot, David.

I have one more question to understand how Replan treats tasks that are currently “in progress.”
When calculating the remaining effort for such a task, does the dashboard effectively use something like:

remaining = max(0, planned_time − actual_time)?

In other words, if a task has already taken more time than originally planned, is the remaining time considered to be zero (rather than negative) for the purposes of the Replan and EV logic?

Thanks again for your time and your explanations!

It's quite a bit more complex than a simple max(0, xxx) calculation.

As you've stated: when computing the Replan date for in-progress tasks, the dashboard will subtract actual time from planned time to produce remaining time. Remaining time is then used as the "weight" for a new earned value calculation, as described here, to produce a set of replan dates. The Forecast calculation is similar, except it divides planned time by CPI before subtracting the actual time.

If some of the in-progress tasks are overspent, this creates a problem (negative numbers) for the calculation above. The dashboard will attempt to resolve this problem by:

1. Making a list of all the overspent tasks, and all the underspent/not started tasks
2. Attempting to "borrow" a small fraction of planned time from the underspent/not started tasks, and reallocating it to the overspent tasks.
3. It will attempt to borrow enough time to cover the overspent amounts, plus an additional 10%.

Why does it do this? Well, the stated goal of the replan calculation is, "you're slightly ahead/behind where you planned to be, but we assume the original plan was essentially correct." And the stated goal of forecast is, "your original estimates had some bias. We'll correct the remaining work to remove that bias and recalculate."

In the replan calculation, the engineering assumption that "the original plan was essentially correct" implies that "the original total planned time (summed for all tasks) was correct." Another way of saying this is, "some of the tasks might be over their estimates, and some might be under, but these cancel each other out so the total cost of remaining work is unchanged from the original plan." If some in-progress tasks are overspent, we expect other tasks will be underspent by a similar amount. The "borrowing" step above is just an algorithmic way of calculating that.

Similarly, the forecast is built on an engineering assumption that the remaining work will have the same CPI as the completed tasks. Time borrowing is used to cover overspent tasks so the total forecast time for remaining work meets that state invariant.

The extra 10% (mentioned in step 3 above) helps to produce more realistic replan and forecast dates. If we just borrowed enough time to bring the negative numbers up to 0, those zero-remaining-time in-progress tasks would all be replanned to finish instantaneously. That's not realistic or helpful. So we instead presume the overspent in-progress tasks are "90% done," and borrow enough time for them to have a little effort still remaining.

As you can imagine, all of this cleverness can still break down. If my original plan had 10 total hours worth of work and I have a task that's overspent by 20 hours, no amount of borrowing can dig me out of that hole. In that case the borrowing logic gives up and falls back to a max(0, xxx) calculation. The replanned total time will grow as a result.