How to close schedule review findings without losing the evidence

Take an example activity, M-240, whose remaining duration goes from 12 to 18 working days between two updates. The reviewer asks why, a reply arrives by email before the due date, and the row is marked closed. At the next update the 18 days are still unexplained, the reply sits in one person's inbox, and the same question gets raised as a new finding.

A finding should close when the reviewer has checked the answer against a record or verified the model correction. A short action log does that job if it keeps the observation, the question asked, the response, the evidence and the reviewer's decision on one row, and carries any open row into the next update under the same ID.

Ask a question someone can answer

Each row starts with one observed change and one requested response. "Check schedule" gives the recipient nothing to do. "Explain why the remaining duration for activity M-240 changed from 12 to 18 working days between the selected updates" names the activity, the field and the two files, so the person answering knows exactly what to look up.

Write the question without your theory in it. If you suspect the crew size changed, ask for the basis of the forecast and let the answer confirm or rule it out. When one row has drifted into separate questions about progress, delivery and access, split it into linked rows so each can close on its own evidence.

Agree the respondent and the due date before the row goes out. The person who supplies the answer is often different from the person who reviews it and from the person who can authorize a schedule change, so name the respondent in its own column and record the reviewer and any approver in the closure record, instead of a single "owner".

Keep the record small

A spreadsheet filed with the update in the project's document control system is enough for most monthly updates. The test is whether someone picking it up six months later can reconstruct the question and how it was resolved.

"Ready for review" should mean a response has arrived from the subcontractor or coordinator and the reviewer has not yet accepted it, so the update meeting can tell it apart from a row still waiting on the field.

One finding from open to closed

Here is a hypothetical. An update comparison shows that a testing activity's remaining duration went up. The finding gets reference SR-014, the reviewer records both file revisions, and the testing coordinator is asked for the basis of the new forecast.

The coordinator replies that a new inspection sequence was added. That is a useful answer, but the sequence document is not attached, so SR-014 moves to awaiting evidence and the reply is logged under the original question without overwriting it.

When the sequence document arrives, the scheduler checks it against the model and finds the duration was keyed wrong. The model is corrected in a new revision and the comparison is rerun. The reviewer then closes SR-014 with the correction, the document reference, the revised comparison and the date. That closes this one question, and the corrected date remains a forecast that the next update will test.

Close on evidence

Before closing a row, check that the response addresses the observation and that its references actually open. If the answer required a change to the model or the report, confirm the change was made.

If the explanation is accepted with no change to the model, record that decision and the reason. If a correction was needed, keep the original observation and point to the corrected revision, because replacing the old value with the new one erases what was reviewed. A closed row records that one question was answered, and the contract's own notice requirements still apply alongside the log.

Some questions will still be open when the report is due. Say so in the report and carry the finding forward under the same ID, so the owner sees an open item and the team is not pushed into presenting an unfinished review as complete.

Carry open findings into the next update

At the next review, work through the open findings before adding new rows. Confirm the source activities still exist and the observation still holds, then check whether new evidence has changed the question.

An activity missing from the new export has not resolved anything by disappearing. Find out whether the ID changed, the scope moved to another activity or the wrong project was exported, and record any confirmed mapping to the new ID.

Reopen a closed finding when new evidence undercuts the decision. Record why it was reopened and leave the earlier closure visible, which tells the next reader far more than a fresh duplicate row would.

Run the update meeting off the log

Pull up overdue responses, findings ready for review and the decisions that affect the next submission. A count of closed rows rewards easy closures while the M-240 question stays open, so do not report it as progress on its own. Once the findings are sorted they feed a short owner schedule narrative, with the log holding the trail and the narrative explaining what the owner needs to decide.

Get the first rows from your own update

Every row in this log starts as a difference between two updates, and the comparison basis column needs the files it came from. Pathizer's free Update Compare lists what changed between two .XER schedule updates, from activities and relationships added and deleted to start, finish, duration and total float changes, so each row you open from it can cite the two files. Drop last month's and this month's files at pathizer.com/xer-update-compare, with no sign-in, and open your first rows from what it lists. The files are read in your browser and are never uploaded to Pathizer.