Project scheduling – Preventing erratic behaviour


Project has the reputation of having a mind of its own: tasks move around, dependencies don’t work, updates don’t reflect actual effort, etc. This apparently erratic behaviour can be prevented by setting the right parameters in the Calculations tab under the Options menu.

Basic Parameters

Calculation mode
This determines whether the effect of changes is immediately reflected, or you need to propagate changes manually by pressing the ‘Calculate Now’ button or Function Key 9. Default is Automatic

This controls whether changes are applied to all open projects. Default is active project only

Updating task status updates resource status
This flag determines whether changes to % complete also change % work complete. Default is on

Project uses the status date to update and reschedule tasks. This function is controlled by the following parameters. By default all these flags should be cleared so it is possible to enter dates manually.

  • Move end of completed parts after status date back to status date
  • And move start of remaining parts back to status date
  • Move start of remaining parts before status date forward to status date
  • And move end of completed parts forward to status date

Earned Value

The following parameters are used in conjunction with earned value.

Earned Value…
Allows you to select physical % complete to calculate BCWP.

Edits to total task % complete will be spread to the status date
Leave clear so % complete is distributed to the baseline end date instead of the status date.

Actual costs are always calculated by Microsoft Project
Edits to total actual cost will be spread to the status date. Leave both clear if you are planning to enter actual costs manually for accurate earned value calculations.

Default fixed costs accrual
Fixed costs can be applied at the beginning of the task, at the end or accrued in proportion to time. This is a default flag that can be changed for specific tasks as required.

Critical Path

The following parameters define the calculation of the critical path. It should be recalled that he critical path is the sequence of tasks with no slack that define the start and end dates of the project.

Inserted projects are calculated like summary tasks
If tasks in the sub-project are on the critical path then the sub-project becomes critical.

Calculate multiple critical paths
When this flag is set then a task with a constraint of ‘as late as possible’ will be shifted to the right of its own sub-group under the a summary task and not to the end of the project.

Tasks are critical if slack is less than or equal to
The critical path includes tasks with some slack days defined in this parameter. Normally set to zero.

OmniPlan is a simpler program with fewer parameters to watch. Perhaps the most important parameter is Granularity which can affect some calculations, especially levelling.


Before panicking when Project starts doing strange things and appears like a bug, take a moment to check and understand your chosen settings of the calculation parameters, and you will be surprised.