On most major projects, the monthly schedule cycle goes like this. The planner collects actual start and finish dates from the field. They load them into P6. They reschedule. They send the updated programme to the PM. The PM puts a Gantt chart in the monthly report. Done.

That is a schedule update. It is necessary. It is not sufficient.

The update tells you what happened. It does not tell you what it means. It does not tell you whether the critical path shifted. It does not tell you which activities consumed float and how much. It does not tell you whether the current trajectory will hit the completion date. It does not tell you what changed since last month and why.

The analysis does all of those things. The update is the input. The analysis is the output. The gap between them is where most project reporting fails.

What a schedule update includes

This is data entry and computation. P6 handles it. The planner's job is to make sure the data is accurate and the logic represents the current plan. This is important work but it is a process, not a product. The schedule update is not the deliverable. It is the raw material for the deliverable.

What a schedule analysis includes

This is interpretation. It requires someone who understands the schedule, the project context, and what the data means in the context of both. It is the part that takes 4-8 hours a month and is the reason PMs end up building slides the night before the steering committee.

Why the gap exists

Three reasons.

First, the tools do not help. P6 is a scheduling tool, not a reporting tool. It is excellent at computing the critical path. It does not produce a steering committee narrative explaining what the critical path means. The planner finishes the update and then switches to Excel and PowerPoint to build the story. The analysis happens in a different application from the data, which means manual extraction, manual formatting, and manual error.

Second, the planner is stretched. On most EPC projects, the planning team spends 70-80% of its time on the update cycle: collecting actuals, resolving exceptions, fixing logic, managing claim calendars, running look-aheads. The analysis that explains what the update means gets compressed into whatever time is left. On a bad month, the analysis does not happen at all. The update is the report.

Third, the deliverable is undefined. Most contracts specify that the contractor must submit a "monthly programme update." They do not specify that the update must include a critical path analysis, a float trend assessment, or a period-on-period comparison. The minimum contractual deliverable is the updated schedule file. Anything beyond that is discretionary. When time is short, discretionary work gets cut.

What this costs

The cost is not in the analysis that was not done. The cost is in the decisions that were made without it.

A steering committee that receives a Gantt chart without an analysis will ask "are we on track?" and receive an answer based on the PM's intuition rather than the data. The PM may be right. The PM may be wrong. Nobody in the room can tell the difference because the data has not been translated into a form that enables the question to be answered properly.

When the project overruns and the dispute begins, the absence of contemporaneous analysis becomes a specific problem. The delay expert needs to reconstruct what the project team knew, when they knew it, and what they did about it. If the monthly reports contain a Gantt chart and a paragraph of narrative but no float analysis, no critical path tracking, and no period-on-period comparison, the reconstruction takes months of expert time at $300-600 per hour. The analysis that would have taken one PM four hours a month now costs $50,000-100,000 to reconstruct after the fact.

The economics: Four hours a month of schedule analysis during the project, or six figures of forensic reconstruction after the dispute. The analysis pays for itself even if nobody ever looks at it, because the contemporaneous record exists.

What good looks like

A good monthly schedule analysis is five slides. Not twenty. Not fifty. Five.

  1. Where are we (forecast completion vs baseline)
  2. Are we late (float position and trend)
  3. Why (top drivers this period)
  4. What are we doing about it (recovery actions)
  5. What could go wrong (near-critical paths and emerging risks)

Each slide answers one question. Each answer traces to the schedule data with a data date. The analysis is dated, caveated, and reproducible. Run the same XER through the same method and you get the same answer.

This is the standard that most project controls professionals would agree with. It is also the standard that most projects do not meet, because the time to produce it is not budgeted and the tools to automate it did not exist until recently.

Closing the gap

The gap closes when the analysis is automated. Not the interpretation. Not the judgement about what matters. The extraction, the computation, the formatting, and the slide production. The PM's job is to look at the analysis and decide what to say about it. The PM's job should not be to spend four hours building the analysis from scratch every month.

This is what we built Allsignal to do. Upload the XER. The engines compute the critical path, the float trend, the baseline variance, the period drivers, the risk assessment. The PM reviews the output, adjusts the narrative, locks the slides, and exports. The four hours becomes twenty minutes. The analysis happens every month instead of when there is time.

But even without Allsignal, the principle holds. If your monthly report contains a schedule update but not a schedule analysis, you are delivering the raw material and skipping the product. The steering committee deserves better. So does the evidentiary record.