Re-running Update Forecast with an Earlier Forecast Date
Scenario
A project task is actively being worked on and actual effort is being reported over time. The project manager uses Update Forecast to keep future planning aligned with execution.
First Update Forecast Run
At the end of the month, the project manager:
-
Runs Update Forecast on the task with a Forecast Date of March 31
At this point:
-
Actual effort reported up to March 31 is applied
-
Task assignments between the task Start Date and March 31 are locked as manually set
-
Future task assignments are recalculated starting after March 31
The forecast now reflects the most up-to-date plan while preserving historical data.
Second Update Forecast Run (Earlier Forecast Date)
Later, the project manager realizes that:
-
Some actual effort should have been finalized earlier
-
The forecast needs to be recalculated using a Forecast Date of March 15 instead of March 31
The project manager runs Update Forecast again, this time selecting March 15 as the Forecast Date.
AdaptiveWork Behavior
When Update Forecast is run a second time with an earlier Forecast Date:
-
Task assignments previously created as manually set between March 15 and March 31 are evaluated
-
If Keep manually set effort values is selected:
-
Existing manually set assignments are preserved
-
Only future assignments beyond March 15 are recalculated
-
-
If Keep manually set effort values is not selected:
-
Manually set assignments created by the first Update Forecast run are reset
-
Assignments are recalculated starting from March 15
-
Result
-
The forecast reflects the correct historical cutoff date
-
Future planning is recalculated based on the newly selected Forecast Date
-
Project managers retain control over whether previously locked assignments are preserved or recalculated
Why This Is Useful
This scenario is common when:
-
Month locking is adjusted retroactively
-
Actual effort is corrected after an initial forecast
-
A project needs to be preplanned using a more accurate historical cutoff