When project teams need to make a critical decision, it helps if the decision is an informed one. Schedule status reports are the artifacts which leaders rely on to inform and justify their time management decisions. Schedule reports also document a project’s history and trends over time. These historical trends aid managers in seeing what lessons should be learned and how to adjust their planning for the next project.
This article will overview some of the common schedule status reports, their audience, and the basic tenants to follow when reporting on the project schedule.
The Need to Know
Standards compliant project schedules contain a wealth of data about the projects they model. At a minimum, each Task in a resource loaded, baselined schedule file contains a minimum of seventeen variables not including custom fields, timescale data,[mfn]Timescale data is a breakdown of the number of hours a Resource is assigned to a Task for a given day, week or month.[/mfn] and quasi-dependent variables such as Percent Complete.[mfn]The typical formula for calculating Percent Complete is Actual Duration ÷ Projected Duration (i.e. Actual + Remaining). Actual and Remaining Duration are two of the seventeen variables listed above.[/mfn] Like a sports reporter covering a baseball season, the large supply of data produces volumes of metrics. Which statistics are noise? What information can be converted into useful, actionable knowledge for the stakeholders?
Producing useful knowledge for schedule stakeholders requires the Schedule Manager to understand what stakeholders need to do with the information they have. A good schedule status report will tell its audience exactly what they need to know, and avoid burdening them with data which is spurious or distracting. Figure 2summarizes some common schedule status reports and their use.
It is common for stakeholders to want to see more schedule intel than simply the elements which are directly tied to their role on the project. Team members want to see the milestone Gantt’s big picture. Senior leadership may want to understand portions of the critical path or other operational metrics. Auditors want to see everything. Sharing extra information is rarely detrimental to the project. The only time schedule reports should not be shared is when the report contains sensitive information. This is one of the reasons why a schedule file should not be burdened with sensitive content such as financial data.
When sharing reports with new audiences, the Schedule Manager should ensure the reports come with proper context to guard against unnecessary panic. For example, suppose a project’s Schedule Performance Index (SPI) is 0.83[mfn]SPI is the financial value of work performed to date over the value of the work planned to date. (SPI = EV ÷ PV) An SPI of 0.9 indicates that 10 percent of the work planned to date is behind schedule. An SPI between 0.85 and 0.9 commonly triggers executive leadership to take corrective action.[/mfn], and Senior Executives request an extract of all project tasks which are running late. Without context, this report becomes a list of accusations against some luckless team. The Schedule Manager must also provide context regarding which delayed tasks are consequential to the project at large. Despite the low SPI, the project may be running smoothly, and the key project deadlines may not be impacted. The Schedule Manager must be able to distinguish to all stakeholders the difference between delays that are trivial and delays that matter.
Consistency and Simplicity
It is important to remember that schedule status reports are a means to an end. Reports should convey knowledge quickly and succinctly. Regardless of content, any high-quality schedule status report has four common characteristics:
- Easy to understand
- Easy to produce
These characteristics provide reliability to both the schedule and the Schedule Management process so that the reader can comprehend, then act on the schedule report as quickly as possible.
Accuracy is paramount when producing a schedule status report. The reader’s trust hinges on two assumptions. The first assumption is that the report exactly reflects the data in the schedule file. An errant date, a task incorrectly marked complete or incomplete, or miscalculated metrics such as SPI cause distrust of the report and the process significantly out of proportion with the size of the mistake.
Second, the report must not contradict information from other managers and team members. This can be tricky when managers in denial insist that the sky is green. In preparing the schedule for reporting each cycle, the Schedule Manager must reach consensus with managers and team members responsible for delivery about when upcoming work will complete, to guarantee that everyone is on the same page.
When a manager and Schedule Manager cannot resolve conflicting perspectives, it constitutes a schedule risk which should be documented and tracked like any other project risk. Schedule risks usually reach quick resolution and form a basis for settling future conflicts in favor of the manager or the Schedule Manager.
Once a schedule status reports and their cadence have been established, it must be produced with the same look and feel. Reports should have the same content. Charts and tables should use the same format each time. A consistent picture makes it easier to compare reports from one cycle to the next and identify trends that are of interest to stakeholders.
This does not preclude the Schedule Manager and schedule stakeholders from agreeing to change a report to suit evolving needs. However, frequent changes to report formats results in more work for the Schedule Manager as well as making trends difficult to spot.
Easy to Understand
What is the point of the report? What intel should the reader take away from its contents? Schedule status reports are operational documents. They may be contractually required, but schedule reports never rise to the significance of project deliverable such as a system design document. The time required to review and digest the knowledge in a report should be minimal.
The easiest to comprehend metrics are those which track trends over time and forecast what is coming next. Like a patient’s blood pressure and respiratory readings, a single SPI measurement or critical path report may be interesting. But the trend over time is what tells the reader the true health of the project.
Easy to Produce
The difficult step in producing a schedule status report should be preparing the schedule file for reporting. A Schedule Manager may spend days chasing down answers, troubleshooting delays, and cleaning up the schedule file. But the production of weekly or monthly reports should take very little time. Proactive Schedule Managers will be regularly looking for ways to automate and streamline the reporting process to save time and reduce human errors.
When deciding which schedule reports to produce, the Schedule Manager should also decide the reporting cadence. Earned Value reporting follows a monthly reporting cycle. Some reports may be required on a bi-weekly basis. Audits occur infrequently. However, it is common to produce some schedule reporting artifact for every schedule statusing cycle.
Since the vast majority of schedules can be statused and reviewed on a weekly basis, schedule status reports are typically produced weekly, even if the report’s audience is small. Assuming schedule status reports meet all of the characteristics above, this should not cause the Schedule Manager or the project teams undue burden. To the contrary, weekly Schedule Reporting can drive project efficiency by setting the drumbeat for the project. Every week, project teams know they must:
- Provide progress updates for all tasks underway
- Review the schedule with the Schedule Manager
- Decide how to resolve any delays or shifts in priority
A consistent reporting process ensures that even a project’s worst week is executed with the same process stability as the project’s easiest week. Whether the project gets ahead or falls behind, every week that the project team can answer the Big Three questions in Figure 1is a week that the project team has prevented the schedule from drifting into uncertainly.
Note that it does not make sense to provide schedule reports more frequently than the statusing and analysis cadence since the report would be based off of identical progress data. If stakeholders expect reports weekly then the schedule must be statused weekly. Agile and related development methodologies have daily reporting requirements. However, since Agile development assumes a fixed schedule, daily Agile reporting is a function of scope (i.e. backlog) management rather than Schedule Management.
Regular project schedule reporting is as essential to the project as the schedule itself. If reports do not convey accurate information about the progress and likely completion of the project, then both the schedule and the reports provide no tangible value to the project. Starting with some basic assumptions about the fitness of the project schedule, Schedule Reporting Principles makes the case for ensuring that schedule reports are traceable directly to the schedule itself, and for providing full transparency and context to all project stakeholders.