How to time a monthly schedule update package before counting time saved

Ask how long the monthly schedule update package takes on most jobs and the answer is an estimate, and every claim about time saved on schedule reporting gets measured against that estimate. Before you trial anything on the update, time the package you already produce, step by step, for a few cycles. The trial then has something real to be measured against, and the steps it does not touch stay in the total.

Write down the package

Start with what actually goes out each month. On a typical job that is the updated XER file, a few printed layouts, a set of standard reports and a narrative. Name each one as it exists on your project: the longest path Gantt layout you print for the owner meeting, the baseline variance layout, the report group you run through Batch Reports, and the narrative format the contract asks for. If the specification lists the submission contents, copy that list.

That list is the deliverable you are timing. A trial that produces a shorter narrative or drops a layout has produced a different package, and its hours do not compare with this one.

Log the steps as they happen

Time each step during the cycle, not from memory afterward. A monthly schedule update usually breaks down along these lines.

Keep hours worked and calendar days apart. For example, two hours of work spread over three days because a superintendent has not confirmed an actual finish is two hours of effort and three days to issue, and a new tool can change one without moving the other.

Note what made each month hard as well: how many activities were statused, how many relationships changed, whether an actual date was disputed. A small update with one contested actual start can take longer than a large routine one, so a single month is not a baseline.

Count the whole package

When the trial runs, time the same steps on the same package. If the trial only touches the compare and narrative rows, the collection, entry and review hours still go into its total. A saving quoted on the drafting step alone leaves out the review that makes the narrative issuable, and a fast draft that needs heavy correction has moved hours from drafting into review rather than removed them.

Give setup and learning time its own line in the first cycle. It will not recur every month, but it belongs in the decision.

Agree when the narrative is issuable

Before the trial, agree with the reviewer what makes the narrative issuable. Every milestone that moved is explained against last month's update, each explanation points to a record, and anything unconfirmed is marked as unconfirmed. Count the corrections the reviewer makes and log what kind each one was. A wrong date in a table and a slip explained by the wrong cause each count as one correction, but they are different problems, and averaging them together hides the second one.

For the narrative format itself, see how to structure an owner schedule narrative.

Time two packages in the 60-Day Pilot

Pathizer works in the compare and narrative rows of the table above, and the executive narrative is drafted for the scheduler to review. After each analysis its Report Generator also prints the Float Path, Contractor, Owner and 4-Week Look-Ahead reports on 11x17 sheets. If one of those replaces a layout you print today, log that as a change to the package before you compare the hours. Sixty days is two monthly packages, enough to time both against the baseline you logged, and the pilot needs no card. The price after it is published starts at $249 a month for up to 2,500 activities, as listed on the pricing page, so the hours you measure can be set against a known cost. Start at pathizer.com/pilot.