Factors that affect rescheduling
The result of a reschedule varies depending on the features you have implemented in your project. For example, start and finish flags override link logic, calendars determine when a task can start and finish, and a task's ASAP/ALAP position can affect where it is positioned.
The following factors can affect the result of a reschedule:

Tasks are rescheduled relative to the imposed start date or imposed finish date that is set on the Properties dialog. You cannot set both an imposed project start date and an imposed project finish date.
If you set an imposed project finish date, the project is rescheduled beginning from the task at the end of the project's link logic; this task is set to finish on the project finish date and all predecessor tasks are positioned relative to this task. Rescheduling from a finish date is sometimes referred to as 'backwards rescheduling'. Note that this only applies when you reschedule the entire project (ie if you reschedule the chart that represents the programme or if you reschedule a branch with the reschedule scope set to All): if you only reschedule a branch of the project, any imposed project finish date is ignored.
If you position a task to begin before the imposed project start date or end after the imposed project finish date, such tasks will be moved by the reschedule so that they start or finish within the imposed project start or finish date.

A task cannot start or finish on a non-working period as defined by the task calendar. When you draw or move a task, it snaps so that its start and finish dates fall in working periods on the task calendar. Similarly, during a reschedule tasks are positioned so that they start and finish in working periods on their calendar.
You can see in the illustration below that tasks snap to start and finish in working periods on their calendar both before and after rescheduling:
|
|
Before rescheduling |
After rescheduling |
When a task has a modelled resource allocation, the resource's calendar can affect the position and duration of the task.
A milestone is positioned at the end of a working period or at the start of the following working period, depending on whether it is a finish milestone or a start milestone. For example, if a milestone falls at the end of a working day, a finish milestone will be positioned at 17:30 that day, whereas a start milestone will be positioned at 09:00 the following morning.

You can choose whether or not to straighten the progress line to the report date of a selected progress period when you perform a reschedule. If you choose to straighten the progress line, any uncompleted tasks that fall before the report date are moved forward in line with the report date so that they lie in the future (indicating that they are still to be carried out).
If you straighten the progress line, you can choose whether you also want to move any completed tasks that lie after the report date backwards to before the report date (indicating that they have been carried out and are in the past). If you choose to move completed tasks that fall beyond the report date, the progress line will be completely straight following the reschedule, but the dates of some completed tasks will have changed. If you choose not to move completed tasks that fall beyond the report date, the progress line will not be completely straight - the reschedule will only push uncompleted tasks forward.
Moving uncompleted tasks forward may affect the project finish date. You might not want to do this if you intend to edit these tasks to ensure that they do not affect the project finish date.

Any uncompleted tasks with start flag or finish flag constraints are rescheduled to comply with their constraint. Start flags and finish flags override link logic that might allow a task to start or finish at times other than the specified date.
You can relax finish flags so that tasks with finish flag constraints can be rescheduled beyond their finish flag date, using the Reschedule dialog.
If you set a start flag on a summary task or expanded task, then all tasks within the summary group or subchart are rescheduled beginning from that start flag date. Similarly, if you set a finish flag on a summary task or expanded task, all tasks within the summary group or subchart are rescheduled from that finish flag date.
You can use a Work Between constraint to impose both a start date and a finish date on a task. If the Work Between constraint is on a task which increases in duration or which contains subordinate tasks that extend the duration of the parent task, then the way in which the task is rescheduled depends on the Finish on or before flags are soft setting on the Reschedule dialog:
- When this check box is selected, the start date is preserved but the finish date is invalidated.
- When this check box is cleared, the finish date is preserved but the start date is invalidated.
If you apply a Holding Pin constraint to a task and the task is moved in a reschedule as a result of other constraints such as links, the Holding Pin flag itself is moved with the task. If there are no other constraints on a task to which a Holding Pin has been applied other than the Holding Pin itself, the task will not be moved backwards by the reschedule; it will be pinned to its current date.

Flags that move tasks forward (On or After flags and Holding Pins) take lower priority than flags that fix tasks to specific dates (On flags). For example, if a task with a Start On or After flag precedes a task with a Start On flag that conflicts with the flag of the predecessor task, then the reschedule may move the predecessor task to an earlier start date, irrespective of its Start On or After flag. This is illustrated below, where the first task is moved to an earlier date during the reschedule despite its Start On or After flag, as it is overridden by the second task's Start On flag:
|
|
Before rescheduling |
After rescheduling |
Flags that move tasks backward (On or Before flags) take priority over flags that move tasks forwards (On or After flags and Holding Pins). For example, if a task with a Start On or After flag precedes a task with a Finish On or Before flag that conflicts with the flag on the predecessor task, the reschedule may move the predecessor task to an earlier start date, irrespective of its constraint. This is illustrated below, where the first task is moved to an earlier date during the reschedule despite its Start On or After flag, as it is overridden by the second task's Finish On or Before flag:
|
|
Before rescheduling |
After rescheduling |
Any uncompleted tasks that have been constrained to start on a new day are rescheduled so that they start at the beginning of the next day even if they could start earlier during the previous day. What constitutes the start of a new day is determined by the calendar that has been applied to a task. If a task has no calendar applied to it, the start of a new day is deemed to be midnight.
Any uncompleted tasks that have been constrained to complete within a single time period, shift or work pattern are rescheduled so that they are moved forward into the first time period, shift or work pattern in which there is enough time for the task to be completed.

Tasks can be positioned to start as soon as possible (ASAP) or as late as possible (ALAP) on their bar, using the Placement field in the Constraints section of the Task tab of the Bar and Task Properties dialog.
When tasks are positioned to start ASAP they start as soon as links and flag constraints allow. Any free float period is shown after the task finish date:
When tasks are positioned to start ALAP, any free float period is consumed and the task is positioned at the latest date possible without affecting any other tasks. The free float period is shown before the task start date, indicating that it has been consumed:
You can also position tasks to start ASAP Force Critical, which positions them to start as soon as possible but with no free float so that they become critical:
By default, tasks that are configured to be ASAP Force Critical appear identical to critical tasks. This can make it difficult to differentiate between critical tasks and ASAP Force Critical tasks. You can specify an override colour for tasks that are configured to be ASAP Force Critical, using the ASAP force critical override colour field on the View tab of the Options dialog.
If you specify an override colour in this field, all tasks that are configured to be ASAP Force Critical are given a critical appearance using the specified colour rather than the standard critical marking following a reschedule. This is illustrated below, where green has been specified as the ASAP Force Critical override colour:

Links affect when tasks can be carried out, but start and finish flag constraints override link logic. Links only affect uncompleted tasks; completed tasks are unaffected by link logic because they lie in the past.
When progress occurs out of sequence, you can specify the way in which part-completed links are affected by the reschedule, using the Reschedule dialog.
Normally, if you link tasks, rescheduling the project will rearrange the tasks so that the gaps between them are as prescribed by the logic of the links - and by any other constraints. This is illustrated below:
|
|
Linked tasks, prior to reschedule |
Linked tasks, post-reschedule |
If you were to then move one or more of the tasks above manually to change the gap between them, rescheduling the project subsequently would normally rearrange the tasks again to reimpose the link logic, removing the offsets that you created by moving the tasks manually:
|
|
The middle task moved manually |
Post-reschedule, link logic is reimposed |
In some circumstances, you may want to ensure that the offsets between tasks that are created when you move the tasks are maintained, and that they are not overridden when a project is rescheduled. You can do this using a special kind of link. This may be useful in a number of circumstances, for example where you have a bar that contains overlapping tasks. Tasks on such bars are not constrained by any implicit links to predecessor tasks on the same bar as they would be on a standard bar on which task overlaps are not allowed. Once you have drawn a series of overlapping tasks, you can maintain the offsets between them and prevent the tasks from being moved when the project is rescheduled using a 'maintain offsets' link.

Float on tasks within expanded tasks can be truncated to the finish of the expanded task, instead of extending up to the project finish date. This is useful if, for example, an expanded task contains a sub-project and you are only interested in seeing the float within that sub-project. You choose whether to truncate float in subcharts by using the Reschedule dialog.
When float is truncated and you have set unlinked tasks to Move if at project or chart bounds or Move to ASAP/ALAP position, any unlinked tasks within subcharts will move within the bounds of the subchart, not within the project's bounds.
Expanded tasks have their float and early start/late finish dates determined by their subordinate tasks.