Checking the integrity of the critical path when rescheduling

The integrity of the critical path is checked as follows:

• The project is rescheduled.
• After the reschedule, Asta Powerproject temporarily increases the duration of each incomplete task on the critical path in turn to 600d, and checks that the finish date of the project moves into the future by the same amount, give or take 1d, or any other amount of leeway that you allow.
• If the finish date of the project moves into the future by the same amount when the duration of a task is temporarily increased (give or take 1d, or any other amount of leeway that you allow), the task is considered to be correctly linked; it does not break the integrity of the critical path.
• If the finish date of the project does not move into the future by the same amount when the duration of a task is temporarily increased (give or take 1d, or any other amount of leeway that you allow), the task is considered to be incorrectly linked; it breaks the integrity of the critical path.

In the following illustration, Task 4 has a 'work between' constraint that makes it critical. However, this task is not linked in to the critical path that runs from the start to the finish of the project, which includes Task 1, Task 2 and Task 3. Increasing the duration of Task 4 to 600d would not cause the finish date of the project to move into the future by the same amount. Task 4 therefore breaks the integrity of the critical path:

In the following illustration, there are two critical paths: one that runs from Task 1 to Task 3, and another that runs from Task 4 to Task 6. The 'start on' constraint that has been applied to Task 5 means that increasing the duration of Task 4 to 600d would not cause the finish date of the project to move into the future by the same amount. Task 4 therefore breaks the integrity of the critical path:

In the following illustration, Task 2 is included on the critical path, but has an incoming Finish-to-Finish link and an outgoing Start-to-Start link, which means that the end of the task is not tied to the end of the project. Increasing the duration of Task 2 to 600d would not cause the finish date of the project to move into the future by the same amount. Task 2 therefore breaks the integrity of the critical path:

In the following illustration, Task 1 is included on the critical path, but has an outgoing Start-to-Start link midway along the task that ends at Task 2, which means that the end of Task 1 does not currently affect the end of the project. Increasing the duration of Task 1 to 600d would not cause the finish date of the project to move into the future by the same amount. Task 1 therefore breaks the integrity of the critical path:

To check the integrity of the critical path when rescheduling, select the Critical path integrity check box, on either the Reschedule tab of the Options dialog (used to set default reschedule options) or the Reschedule dialog (used to set options at the time of a reschedule).

If a task on the critical path has an outgoing Start-to-Start or Start-to-Finish link and has no other outgoing driving link, the task will break the integrity of the critical path, as increasing the duration of the task to 600d will not move the finish date of the project forward into the future by the same amount, give or take 1d. If you have built tasks like this into your schedule deliberately, this is undesirable. The fourth example in the above section gives an illustration of this type of situation.

One way of resolving this issue is by identifying and eliminating all Start-to-Start and Start-to-Finish links from a project. If you do not want to do this - it may be necessary to have one or more links of this type in a project - you can resolve the issue by increasing the amount of leeway that each task is allowed before it is deemed to break the critical path integrity. For example, if you specify 10d leeway, a task is allowed to increase in duration by up to 10d before it is deemed to break the critical path integrity.

Enter the amount of leeway you want to allow each task in the Days leeway field. Asta Powerproject defaults to allowing each task one day's leeway - and this is the minimum amount of leeway allowable - to allow for tasks that are configured to start on a new day. If more than one calendar is used in a project, you should increase the amount of leeway to the length of a weekend, eg 2 days, especially if tasks are configured to start on a new day and/or if the length of weekends differs in the various calendars.

If you choose to check the integrity of the critical path, it will take longer to reschedule a project; for this reason, critical path integrity is not checked whenever Risk Analysis or the resource leveller reschedules the project.

After you have rescheduled a project with the Critical path integrity check box selected, you can identify which tasks - if any - break the integrity of the critical path in the following ways:

• Display the 'Breaks critical path integrity' field in the spreadsheet. This field displays a check box which is selected for any tasks that break the integrity of the critical path.
• Examine the Breaks critical path integrity field, in the 'Float' group of fields, on the Task tab of either the Bar and Task Properties dialog or the properties view. This field is selected for any tasks that break the integrity of the critical path.
• Execute a schedule quality check that includes the 'Critical path test' quality metric.

If you do not configure Asta Powerproject to check the integrity of the critical path when rescheduling, no tasks are identified as breaking the critical path integrity.

If a task is identified as breaking the integrity of the critical path, you should examine its links and any constraints that have been applied either to the task or to other tasks on the same critical path to determine what the problem is. For example:

• If a task has an incoming Finish-to-Start link and an outgoing Start-to-Finish or Start-to-Start link, the end of the task will not be tied to the end of the project. It will therefore break the integrity of the critical path.
• If a constraint flag is restricting the movement of a task in such a way that increasing the duration of the task to 600d would not cause the finish date of the project to move into the future by the same amount, this task - or others on the same critical path - will break the integrity of the critical path.

Once you have identified the problem tasks, use one or more of the following techniques to resolve the problems, then reschedule the project again to check that your solution has worked:

• Check any constraint flags on the failing tasks and remove any constraints that are restricting the movement of tasks unnecessarily.
• If a failing task does not have any constraints, check any constraint flags on other tasks that are on the same critical path as the problemfailing task, and remove any constraints that are restricting the movement of tasks unnecessarily.
• Check the failing tasks' incoming and outgoing links to ensure that tasks are linked correctly into the critical path, and amend the links if necessary.
• Increase the amount of leeway that each task is allowed before it is deemed to break the critical path integrity, using the Days leeway field, on either the Reschedule tab of the Options dialog or the Reschedule dialog.
  
  If a task breaks the critical path and this is not caused by its links or constraints, it is likely that the cause is multiple calendars being used in the project - especially if tasks are configured to start on a new day and/or if the length of weekends differs in the various calendars. In this case, you should increase the amount of leeway to the length of a weekend, eg 2 days.