Understanding reschedule reports

This section of the report details the following:

• The long and short name of the project.
• The file name and location of the project - or, in the case of Asta Enterprise projects, the project ID, data source ID and server name.
• The date and time at which the report was produced.
• The user name of the user that produced the report.
• The reschedule number - a number that identifies the reschedule. The reschedule number is increased by one each time you reschedule all or part of a project. Reschedule numbers are stored for each user, so in an Asta Enterprise project your own reschedule number is only increased when you reschedule a project.

This section of the report details the following:

• The number of tasks within the scope of the reschedule - whether or not they were changed by the reschedule.
• The number of milestones within the scope of the reschedule - whether or not they were changed by the reschedule.
• The number of links between tasks within the scope of the reschedule - whether or not they were changed by the reschedule.
• The number of tasks and milestones within the scope of the reschedule that (i) have not been started, (ii) are currently in progress and (iii) have been completed.
• The number of tasks and milestones within the scope of the reschedule that have been changed by the reschedule - ie the number of tasks and milestones that have either been moved or that now have a different amount of float.
• The highest logical precedence, which indicates the number of links in the longest dependency path through the portion of the project network that was within the scope of the reschedule.
  
  Logical precedence is the position of a task in relation to its predecessor tasks (those that link to it). The logical precedence is set when you reschedule a project. For example, if Task B is linked to Task A, and Task A is the first task in the link chain, Task A will have a logical precedence of 1 and Task B will have a logical precedence of 2.
• The amount of time that the reschedule took from start to completion.

This section of the report details the following:

• The area of the current project that has been rescheduled - either All, Branch (with the name of the branch), View (with the name of the view) or Selection. Note that if only part of a project has been rescheduled, the reschedule report only includes details of data that falls within the scope of the reschedule.
• The configuration settings that were in place for the reschedule, as set using the Reschedule dialog or the Reschedule tab of the Options dialog.

This section of the report details the following:

• The imposed start or imposed finish date of the project, as defined on the Properties tab of the Properties dialog.
• The data date - ie the report date of the progress period to which the progress line was straightened during the reschedule.
• The project's prevailing contract date for completion - ie an alternative date that is used for the calculation of float - if one has been specified.
• The calculated earliest actual start - ie the date on which the portion of the project network that was within the scope of the reschedule was actually started.
• The calculated earliest early start - ie the start date of the portion of the project network that was within the scope of the reschedule.
• The calculated latest early finish - ie the finish date of the portion of the project network that was within the scope of the reschedule.

This section of the report details the following:

• Any tasks within the scope of the reschedule that are involved in a link loop.
• Any tasks within the scope of the reschedule that end after a deadline that has been applied to them; both the deadline date and the scheduled finish date are detailed.
• Any tasks within the scope of the reschedule that have conflicting constraints - ie any tasks that have negative float.
• Any buffer tasks within the scope of the reschedule that are completely consumed.

This section of the report details the following:

• The number of tasks within the scope of the reschedule that have only incoming links or predecessor tasks on the same bar.
• The number of tasks within the scope of the reschedule that have only outgoing links or successor tasks on the same bar.
• The number of tasks within the scope of the reschedule that have both incoming links (or predecessor tasks on the same bar) and outgoing links (or successor tasks on the same bar).
• The number of tasks within the scope of the reschedule that have neither incoming links (or predecessor tasks on the same bar) or outgoing links (or successor tasks on the same bar).

Any tasks that have no incoming links or no outgoing links are detailed.

Critical path theory demands that only one task in a project network should have no predecessors and that only one task should have no successors; all other tasks should have logic links that control their position. In the following illustration, milestone 'Start' would be shown as having no incoming links and milestone 'Finish' would be shown as having no outgoing links:

This section of the report details any tasks within the scope of the reschedule that have a constraint flag applied to them, together with the type of flag, the constraining date and the gap between the constraining date and the scheduled date.

This section of the report details any tasks within the scope of the reschedule that have a deadline flag applied to them, together with the deadline date and the gap between the deadline date and the scheduled date. Note that even though project buffer tasks have deadline flags applied to them, they are not detailed in this section of the report.

If you have configured the reschedule to use delivery dates where they have been specified against projects as a deadline, details of the delivery dates that have been specified within the scope of the reschedule are given in this section of the report.

This section of the report details any milestones within the scope of the reschedule, together with their dates prior to the reschedule and their dates following the reschedule.

You can configure this section of the report using the Key milestones section group on the Reschedule dialog or the Reschedule tab of the Options dialog:

• If you clear the Milestone report check box, this section of the report is omitted entirely.
• If you click the List all milestones radio button, this section of the report details all of the milestones within the scope of the reschedule, regardless of whether or not they have been changed by the reschedule.
• If you click the Changed only radio button, this section of the report details only those milestones within the scope of the reschedule that have been changed by the reschedule - ie those milestones that have either been moved or that now have a different amount of float.
• If you select the Restrict to check box and select a code library entry, this section of the report details only those milestones within the scope of the reschedule to which the selected code library entry has been applied.

This section of the report details any buffer tasks within the scope of the reschedule, together with their duration, original duration and buffer consumption.

This section of the report details any interruptible tasks within the scope of the reschedule, together with their duration and original duration.

This section of the report details any fully or partially completed predecessor tasks within the scope of the reschedule that are succeeded by a fully or partially completed successor task, whether the predecessor task is linked to the successor task by a logic link, or appears to the left of it on the same bar. For each instance of out-of-sequence progress, details of the predecessor and successor tasks are given, with the amount of lead/lag on the link in question and a description of the problem.

In cases where a link starts on an incomplete task and ends on the completed portion of a part-completed task, this section of the report is affected by whether or not the Move part completed links check box is selected on the Reschedule dialog or the Reschedule tab of the Options dialog: if you select this check box, the reschedule will resolve any out of sequence progress in this case automatically, so it will not be detailed in this section of the report.

This section of the report details the following:

• Any tasks within the scope of the reschedule that have a 'Start On or After' constraint flag applied to them, whose logical links cause the task to start later than the date of the constraint flag.
• Any tasks within the scope of the reschedule that have a 'Start On' or 'Start On or After' constraint flag applied to them, whose logical links are not driving links - ie where the logical links would allow the task to start on an earlier date had the constraint flag not been applied to it.

The link from the first task is a driving link, as it has the steepest slope and sets the position of the task at the link end; the link from the third task is a non-driving link, as it does not have the steepest slope of all the links entering the second task:

If a task or milestone is constrained by both a start flag and one or more incoming links, it is likely that the dates that are computed for these different constraints will differ. This section of the report enables you to identify such tasks.

This section of the report details the following:

• Any critical tasks within the scope of the reschedule - ie those tasks that have zero total float.
• If the reschedule is configured to check the integrity of the critical path, any critical tasks within the scope of the reschedule that break the integrity of the critical path.

This section of the report lists any tasks within the scope of the reschedule that are on the longest path through the project network. The list is sorted by logical precedence so that the sequence of tasks reads from top to bottom.

A task is computed to be on the longest path if one or more of the following is true:

• Its finish date is equal to the latest finish date of the network.
• It has an outgoing link that is driving and that ends on a task that is on the longest path.
• It has an immediate successor on the same bar line that is on the longest path.

If a summary task contains tasks that are on the longest path and the summary task has an incoming driving link, the summary itself is also on the longest path.