There are both art and science at play in the business of preparing effective and productive CPM construction schedule oversight reports. That is to say, that technical knowhow alone will not suffice for most clients’ needs. Reporting must be jargon free and accessible to the layman in order to meet this criteria. In this post I will discuss the primary components of robust and communicative construction schedule oversight reports that can meet their intended purpose.

The construction schedule oversight consultant shall be both a competent operator of the scheduling platform being deployed as well as a seasoned professional experienced in the means and methods of the projects they evaluate: at least some basic industry knowledge. If these skills are not present it will be plainly evident that there is a bandwidth shortfall in one or both of these (technical and practical) skill sets. Too often construction schedule oversight  is left to a project manager or functionary lacking the requisite experience. As expectations are typically low, there is little motivation to change the phenomenon. This is an impetus for project failure.

The chief premise to successful oversight is that a consistent and sound structure is the key to any successful report, whereas the lack thereof can spoil an otherwise viable report. For example, the report may be technically robust yet fail to impart context: a report may be full of data and technical points which alone cannot possibly inform the reader of circumstances on the ground in plain language. 

I like to keep my reporting structure simple, as complicated structures tend to bore people. I structure my construction schedule oversight reports with just three sections, beginning with an Executive Summary. As the term implies, a summary cannot be generated before all of the statistics are in and observations made, or after all data has been reviewed, analyzed, and processed. Even though it appears at the top of the report, it is the last section to be completed.

The Executive Report Summary begins with some basic information at a high level that you will return to and elucidate further upon as the report develops.

The order of my recommended structure for construction oversight report is as follows:

Section I: 

Executive Summary

Narrative of the longest path

Milestone discussion

Overall calculation of the longest path

Calculations of secondary paths

Reporting period progress update narrative

Narrative of secondary paths

Brief discussion of potential or realized risk and delays and any recovery or mitigation efforts

Don’t worry, the  executive summarydiscussion will refer to tables and graphs in subsequent sections.

Section II: 

Observations 

Technical deficiencies

Project logic errors

Although there are two components to Section II, it is often the longest.

Section III: 

Appendices: Tables and statistics 

Previous month’s progress (discussed in Executive Summary)

Overall schedule with actual and planned (forward pass) dates 

Baseline vs. update comparison

Update vs. previous month comparisons

Milestone Table (discussed in Executive Summary)

Longest Path table filter

Float Paths

Six-week look-ahead (also see below)

The Executive Summary is an abbreviated section of a construction schedule oversight report that cuts right to the chase or bottom-line. It is useful as a means of achieving clarity, as well as a tool to provide a synopsis of schedule status for those who lack the time or attention span to slog through a lot of technical data points that only impart the what, and not the why.

The Executive Summary is a distillation of data extracted from the technical reports, and any key project logic insights that need to be addressed. It is informed by the production team and boots on the ground. A minimum of tables and graphs should be represented in the Executive Summary. 

An example of an Executive Summary might read:

“The project kept pace with the baseline projected performance – as well as recovering x days of project total float for a remainder of y days project total float. The S curve graph of planned vs. actual work is consistent with previous month’s projection, and the project baseline. The projected milestone dates are now represented in Section III, Table z.“ Portions of the schedule are compromised due to technical and project logic errors that preclude accurate calculation. These have impacted the integrity of the data and should be corrected in order to gain clarity in the forward pass.”

Subsequently, in Section II, a high-level discussion of technical issues follows. The technical discussion is indicated before a discussion of project logic. The technical discussion is unique in that one needn’t have any construction experience to conduct it: several analysis tools are available on the market that calculate and analyze various errors in a given schedule predicated on various families of metrics – most notably DCMA-14 (2005.) The DCMA metric system is built-in to the Primavera platform, and in nineteen years has not changed. One need only press the F9 key to access output into a Wordpad document that lists a list of basic technical errors sans metrics.

For example, if you wanted to know the percentage of critical paths vs. non-critical paths, or constrained activities you would have to perform your own calculations. Other theories of scheduling, such as critical path drag, overuse of lag, or Lean methodology, are also a separate exercise. Since standards (PMI, AACE) include certain thresholds, it’s necessary to know what they are and how to find them.

The brevity and compass of DCMA-14 restricts and limits its use as a comprehensive tool to evaluate a schedule in any profound way. On the other hand, Primavera’s Report module is robust, if not underused by schedule oversight managers, most of whom seem to be unaware of its existence outside the predecessor/successor report. The reports are output in tabular form, and most can be shown as columns in the GANTT chart. All have customizable fields. These can be added to your technical report as needed.

Forensic and analysis platforms – such as Deltek Acumen Fuse, have hundreds of metrics that provide in depth vision into every aspect of the schedule data set that DCMA-14 and Primavera can’t begin to imagine. Most glaring is Primavera’s limitation of three database comparisons: two baselines and one update. Fuse has no limitations on the number of databases it can compare. This is a consideration when modeling trends or trend-analysis on a project. To reiterate, Fuse forensics and analysis is leaps and bounds above peer platforms.

In of itself, a technical report offers little insight except to the seasoned oversight manager, and would not be useful without the accompaniment of an analysis of project logic. Otherwise, it is simply raw data without context. For that reason, many oversight consultants become over-reliant on their technical sections of their reports, most of which never see the light of day.

Of far greater import is the generation of a project logic analysis section. Understand that a project can be devoid of technical issues, and still fail to give an accurate representation. Even a modest schedule of 400-500 activities can necessitate dozens of pages of project logic comments. 

For example, if there is no lag or curing activity between a concrete pour and the removal of shores, Primavera will not flag the sequence as erroneous project logic – the obvious omission of time for the concrete to set/cure, and the oversight may be completely missed. Another common project logic error is trade-crashing, or the concurrency of several trades in an area too small to allow proper and safe access in order to truncate overall duration. A schedule may simply state ‘MEP rough ins,’ as if all worked together in the same place at the same time, whereas MEP trades must be broken down into areas and sequences, with mechanical beginning, followed by plumbing and electrical.

Assuming total float is 0-days, I like to track near-critical float-paths up to one month or 22 work-days within the period, such that they can’t become critical before the next monthly update. Other tables and graphs may include: % of commitments (projected start and finish dates) met or S Curve cost projections. These also are not self explanatory, and require their own narratives. To re-emphasize the above points, it is a mistake to merely issue tables and graphs without narratives to explain them, as few people will have the patience to interpret them as raw data.

I like to provide comparisons of both the baseline and previous month to current month in separate charts, though you may show them in Primavera in one GANTT chart, assigning two baselines. I like to compare both because schedules tend to change and morph – often to the extent that they obfuscate the baseline, or in many cases – the revised baseline. It’s a mistake to only compare the previous month’s update and not the baseline or revised baseline with the current update.

One overlooked aspect of the report pertains to the look-ahead schedule – typically a six-week timeframe. Invariably, as reports are constructed and published, data becomes dated, and obsolete, or no longer relevant at the time of report issuance. Most schedulers merely filter the GANTT chart to yield a six-week window without consulting the superintendent. That is a mistake. The superintendent has more accurate and timely data at his disposal, which is why he should be involved in the lookahead discussion.

For example, conditions on the ground often change without notice, creating a variation with the schedule. Activities may be pushed back or moved up to accommodate the project’s needs. A scheduler must be apprised of these changes so that he can represent them in his narrative, if not in the GANTT chart, as well. 

That is why I prefer not to prepare and issue six-week look-ahead schedules until as late as possible, and in a separate publication: schedule reviews may be monthly, and look-aheads weekly, for example. In this way, they are less likely to be compared and conflated with data from the monthly update, which invariably does not match up. Other than milestones and early-finish dates, on the ground and progress update projections generally are not intended to be in lockstep.

Only a seasoned construction professional/scheduler has the tools to create a construction schedule oversight report, yet even with basic skill sets, they may fail to produce coherent reports merely for a lack of clarity and concise structure, and over-reliance on technical aspects and jargon. Some companies have templates for their reporting, yet just as often the consultants are given more latitude in structuring their own reports for lack of standardization, which is typically elusive.

Lastly, there are also elements of construction schedule oversight that don’t belong in the monthly oversight review. These would include reflection, mitigation, and recovery schedules, which are published in their own distinct report formats separate from the monthly. Once a critical path  impact is noted in a progress update, a recovery schedule request is certain to follow.

A lack of standardization is quite common owing to a shortfall of construction schedule oversight consultants, and the limited number of these roles at distinct companies. Simplifying the process by introducing more concise structure and clarity could put a stop to the endless gobbledygook that is offered up as schedule analysis. More information on this topic can be found with the PMI and AACE.