Calculate a schedule
Calculation uses the activity network, working calendars, durations, constraints, and actual progress to forecast remaining work and calculate float. Use it after a planning or progress change when you want the forecast to reflect that change.
Before calculating
Confirm that you are in the intended editable schedule. Save a version if you need to preserve the existing forecast, especially before recalculating an imported submission.
Check the schedule’s status date and the activity calendars. Historical actual dates should describe what happened; remaining durations should describe work still to do. Changing the status date alone does not record progress for the team.
Run Calculate
In Edit mode, use Calculate in the editing toolbar, or F9 when the schedule has focus. Open the calculation options to review the status date, mode, and Schedule Automatically setting.
When Schedule Automatically is enabled, supported scheduling edits trigger calculation as you work. With it disabled, edit the inputs and run Calculate when you are ready to update the forecast. A changed input and an unchanged bar can therefore be a sign that calculation is pending.
Review any error before continuing. Contradictory relationships or invalid input need correction; a failed calculation is not a new accepted forecast.
Choose the status date
The status date divides historical reporting from remaining work. Set it to the date and time through which the schedule’s actual progress is known.
For a monthly update, first gather actuals through the agreed cutoff and review remaining durations. Then move the status date and calculate according to your reporting process. Do not move the date forward and assume that activities planned before it happened automatically.
In a managed Progress cycle, Move status date to cutoff and Recalculate schedule are separate choices when applying updates. See Run a progress update.
Choose a calculation mode
The mode matters most when activities have started out of sequence or when remaining work must be separated from actual work.
| Mode | Practical purpose |
|---|---|
| Retained Logic | Keep the remaining-work forecast subject to the applicable predecessor logic, including work that started out of sequence |
| Progress Override | Relax applicable predecessor restrictions on already-started work so its remaining work can proceed under this mode’s rules |
| Actual Dates | Use actual-date-based relationship behavior for progressed activities |
| Retained Duration | Keep actual and remaining duration distinct and schedule the next continuous remaining-work block using those quantities |
Choose a mode that matches the team’s scheduling practice, then keep it consistent across reporting periods unless a deliberate change is needed. The names are a useful guide, but they are not a promise that every P6 or Microsoft Project option is reproduced. The CPM reference explains the exact rules and exceptions.
Microsoft Project imports use Retained Duration. P6 imports use the supported scheduling option recorded in the XER; Retained Duration can be chosen in Syncify but has no exact P6 scheduling-option encoding on export.
Understand the inputs that matter
- Remaining duration is the amount of working time still to schedule. Physical percent does not automatically calculate it.
- Actual start/finish are historical facts. Ordinary recalculation preserves them.
- Calendar determines the working periods available to each activity.
- Relationships and lag determine dependency timing.
- Constraints represent date restrictions; mandatory constraints are hard overrides.
- Must Finish By, when set in the schedule options, affects the finish target used for late dates and float.
Level of Effort and WBS Summary activities are calculated differently from ordinary network activities. Structural WBS rows roll up their children. Resource quantities and availability do not level or drive the schedule.
Why dates move
Work through the cause in this order:
- Status date: is remaining work now being forecast from a later reporting boundary?
- Actuals and remaining duration: did progress or the remaining estimate change?
- Calendar: is there a weekend, holiday, changed shift, or different calendar assignment?
- Logic: did a predecessor, relationship type, or lag change?
- Constraints: did a direct date edit create or modify a date restriction?
- Calculation mode: is out-of-sequence progress being treated differently?
- Import differences: did the source rely on unsupported options, resource leveling, or omitted external relationships?
Select the affected activity, inspect Details, and trace its Driving Path. Compare against a saved pre-calculation version when you need to see what changed. Do not repeatedly type the expected date over a calculated result without understanding the cause.
Interpret float
Total float expresses available movement relative to the late-date calculation; negative values indicate the plan exceeds an applicable target. Free float concerns movement without delaying the relevant successor timing. Their values depend on logic, calendars, constraints, and the calculation rules.
The Critical display uses a configurable total-float threshold. A red or highlighted row is a prompt to investigate, not proof that this single activity is causing the project’s finish.
Check the result
Review the project finish, key milestones, newly negative float, and any activities whose dates moved substantially. Open Quality and inspect relevant warnings. Preserve the reviewed result as a version or publish it through the Progress cycle when appropriate.