What to include in a construction schedule handover package

When a scheduler hands over a job, the incoming scheduler usually gets the current XER and a transmittal. Their first real question tends to be one the XER cannot answer, such as which revision last month's owner report was built from, or why a remaining duration on the testing sequence was cut. A handover is finished when the recipient can answer questions like that from the package alone, and the check near the end of this article tests exactly that.

Fit the package to the recipient. A scheduler taking over the schedule model needs the scheduling options and the open findings, while an owner's representative reading the monthly report needs the revision, the basis note and the decisions due. Where the contract specifies submission content, it governs, and this method sits on top of it.

Write down what the recipient does next

Put the purpose at the top of the transmittal. The recipient might be continuing the monthly update, reviewing a recovery option or covering the schedule while the regular scheduler is on leave, and each case calls for a different package. Include the reporting period, sender, recipient and the response expected.

If the package contains a proposed revision still under review, say so on the first page, because transmitting a file does not make it accepted and the recipient should not have to guess. Keep the issued package separate from the working folder, so nobody has to choose between exports with similar names.

List the files and their basis

Make a short manifest. For each file give the name, revision, purpose and how it relates to the others, covering the current XER or native file, the previous update used for comparison and any baseline the report measures against.

Record the project IDs, data dates, the software version and the scheduling options needed to reproduce the dates, such as Retained Logic or Progress Override and how total float is calculated. If the recipient runs a different version or a different tool, agree a check before relying on the import. Rescheduling the imported file and comparing the finish date and total float on the contract milestones is a reasonable one.

Confirm that every report in the package was produced from the transmitted revision. If the model was corrected after the narrative was written, regenerate the affected outputs or state the mismatch before issuing.

Explain the forecast as it stands

A basis note covers the assumptions the next update depends on, such as the calendar used on a key handoff, the source of a remaining-duration forecast, an access date waiting on confirmation or a planned sequence that has not been agreed. Mark which statements are recorded progress and which are forecast assumptions, and say where the backup is filed, so the previous scheduler's working assumption does not harden into fact under a new name.

Point the recipient at the activities behind any material date change, since a list of finish dates gives nobody a way to check the reasoning.

Hand over the open findings

Unresolved findings go in the package with their IDs, the questions asked, respondents and due dates. Keep the respondent's explanation separate from the reviewer's decision, since an answer received by email may still need checking against the model.

Use the same IDs in the review log and the narrative, and keep them in a traceable findings log the recipient can open. If an activity was renamed or replaced, include the confirmed mapping so the next reviewer does not open a duplicate question because the original reference is hard to find.

Test it with one real question

Take a hypothetical transfer between two schedulers. The outgoing scheduler sends the current export and a report describing a later testing milestone. The incoming scheduler opens both and finds the report cites a revision that is not in the package.

They check the manifest and find that a corrected export was issued after the report was written. The sender supplies the matching revision and points to the open testing-sequence question in the review log. The incoming scheduler then finds the referenced activities, reads the basis note and identifies who owes the missing confirmation.

Run the same check on your own package with one material question. Ask the recipient to find the source, state its review status and name the next action. Anything they cannot find becomes a specific correction to the handover.

Record what was sent, to whom and at which revision. Close the handover once the recipient has opened the files under their own project permissions and confirmed they have the open questions, since a delivery receipt only proves the email arrived.

Keep each update's reports with the update

In the example, the report and the export it was built from had come apart. After each analysis, Pathizer files that update's reports with the update itself, beside the executive narrative written from the same analysis, so whoever picks up the job opens the reports with the update they describe. Try it across your own projects for 60 days with no card, and hand the next scheduler a package built that way. Start at pathizer.com/pilot.