Schedule Reporting Principles

One of technology’s most unsung Schedule Reporting tools is the car GPS. It tells the driver at a glance where they are, what they should be doing next, and two measurements of when they will finish the trip. If things go wrong, or there is an obstacle, the GPS helps identify ways to get back on course, and estimates the new arrival time.

A good schedule status report conveys similar information. Understanding Schedule Reporting summarized some common schedule reports and their shared characteristics.

This article will discuss the prerequisites a project schedule must satisfy before it is fit for reporting, determining whether a given report will be useful, and the Schedule Managers’ imperative to reflect reality, especially when the news is bad. 

Figure 1: Screenshot of a smartphone GPS. (Google, Inc)1Image screen captured from Google Maps – GPS Navigation, Google Inc. (2018) https://itunes.apple.com/ca/app/google-maps-gps-navigation/id585027354

First Assumptions

Regardless what form a schedule report takes, the report’s sole source of data is the schedule file. Explanations, justifications and other discussion topics may be appended for context. However, the schedule file must be the sole source of truth for dates, progress, remaining effort, and the schedule’s baseline. Said another way, transparency and consistency dictate that all reported data be traceable directly back to the schedule file.

For the sake of accurate reporting, it is vital that the schedule be properly maintained. In all disciplines, reports are only as accurate as the data they come from. Inaccurate schedules which contain out of date tasks, future actuals2A future actual is a completed task with a finish date that is still in the future. For example, if today’s date is June 13th and a task has an actual finish date of June 27th, it calls into question all other dates in the project file., logic errors, missing dependencies or baseline errors can permanently damage both the report’s and the Schedule Manager’s credibility. 

What Not to Know

Schedule reports are useful decision-making tools if they are accurate, consistent, easy to understand and easy to produce.  Reporting too much information threatens all four of these characteristics by making reports cumbersome, and distracting stakeholders with trivia. 

Consider the GPS interface depicted in Figure 1. Nearly all automotive navigation systems visualize driving directions in a similar fashion. There are also several data points which, importantly, GPS devices do not show.

  • Original ETA
  • Departure time
  • Total distance traveled
  • Percent of trip complete
  • Number of route changes
  • Cumulative average speed

Why are these easily collected metrics not shared? The simple answer is that the extra information has proven worthless to drivers. They do not help the driver arrive at their destination faster, more safely, or with fewer mistakes. Presenting the extra data would only steal the driver’s focus and complicate their next decision. Schedule Reporting faces a similar risk of producing extraneous information. Unlike drivers, managers sometimes imagine extra data will help them, especially if they are under duress. When a critical part of a project runs late, managers look for some shred of control that will rescue the situation, or intel which absolves their responsibility. Usually, this additional data only distracts managers from their most serious problems and Justifies useless precautions.

Remember that reporting is a function of Schedule Analysis. Schedule Analysis’s purpose before all else is answering the Big Three questions: 

  • Are you on schedule? 
  • How do you know?
  • What are you doing about it?

If a schedule report does not answer at least one of these three questions, its value to the project is negligible. 

Examples of Spurious Information Requests

Figure 2 depicts a few examples of reports whose perceived and actual value to the project are not aligned. Each of these reports is both “down in the weeds”, and very broad in scope. Studying volumes of schedule data is not necessarily a bad use of a manager’s time. However, such in-depth analyses are usually the responsibility of a dedicated Schedule Manager who knows what to look for, and how to interpret what they’ve found. Deep-dive reports do not provide much benefit as a decision-making tool unless the data and the investigation are highly focused. 

Figure 2: None of these example reports are of value for answering Schedule Analysis’s Big Three questions.

Responding to Spurious Information Requests

Schedule Managers have an obligation to honor all analysis and reporting requests. However, Schedule Managers who receive requests for schedule data which appears to not be useful or relevant should identify why the request is being made. It is often the case that managers will ask for seemingly unhelpful information because they do not understand how to get what they need. Using interview techniques such as “five whys” may assist in understanding the requestor’s chief concerns. 

Often the best ways to quell spurious information requests is to produce the requested report. Stakeholders will quickly lose interest in reports that do not help them make decisions. The Schedule Manager may also find that an existing report may answer the stakeholders’ real concerns.

Exposing Bad News

Schedule status reports benefit a project most when they identify delays far enough in advance that managers and team members have time to take corrective action. Well-built schedule files can accurately detect specific delays weeks in advance, and forecast trends looking a year ahead. However, this intel is wasted if it is not heard, not believed, or not acted on. Schedule reports must walk a fine line when identifying delays. They must not indulge fear mongering, nor can they postpone consequential news. Striking the right balance with proper context is essential if managers and team leaders are to value schedule reports.

Schedule status reports are often loathed because they call attention when projects are not going well. This can lead to scrutiny and oversight which most managers do not welcome. Managers may try to bury bad news either to delay scrutiny until they can remedy the problem, or to hide that they have lost control of the project. Regardless of personal excuses, hiding schedule delays is unacceptable. All stakeholders have the right and the obligation to know how work is progressing compared to the plan, and why. 

Consider the scenario depicted in Figure 3. A six-week (30 business day) Software Development activity was supposed to start two weeks ago and finish by the end of the month. Delays in completing the predecessor activities have pushed the start of Software Development by two weeks. The Development team lead does not believe they have the bandwidth to make up the time. When should the schedule status report announce the delay?

One common justification which managers make to suppress reporting an upcoming delay runs something like this. “We don’t know yet that the activity will be late.” In addition to being a logical fallacy3Argument from Ignorance: The assertion that a proposition is false because it has not yet been proven true. “Although the schedule dependencies, estimated work and available resources suggest that Software Development will run late, we are not yet late. Therefore, we can report that we are still on track.”, this passive project management argument withers when confronted with Schedule Analysis’s fundamental questions.

Figure 3: Answering Schedule Analysis’s Big Three questions (grey) when trying to suppress news of the delay vs. proactively reporting and confronting the delay.

Obfuscating or not acknowledging the delay puts the project on precarious footing. First, the project team is setting report readers up for surprise when the delay hits. Second, the delay to Testing now becomes the sole responsibility of the Software Development team. The Development team lead is compelled to try to compress their schedule, strike bargains with the Testing team, and face the client’s wrath alone. If the Software Development team lead isn’t in contact with the Test team, the Test team may only realize that their start date has been delayed when the end of month deadline comes to pass.

Identifying Remedies to the Delays that Matter

Schedule Managers are not auditors. They are part of the project team and have as much responsibility to remedy schedule impacts as they do to identify them. The reports in Figure 2prove unsatisfactory because they raise alarm but do not offer adequate context from which readers can take corrective action. The Schedule Manager must work with managers and team leads to make sure reported delays and resource constraints are properly understood within the full context of events. Reporting bad news is necessary, but it is only productive if it is also presented with a path forward. 

Schedule reports should also not dwell upon delays which have negligible impact on the project. So long as late tasks contain sufficient slack, the responsible team lead has a plan to complete the work, and the schedule change is not bottlenecking other activities, there is little benefit in distracting readers from the big picture. Schedule Managers must understand the difference between trivial setbacks and delays that matter. 

Aided by schedule reviews with team leads and other decision-making stakeholders, schedule status reports should be backed up not just by evidence corroborating the delay, but also viable plans to recover from delays. The details of the remedies may not appear in the reports themselves. However, every delay which impacts the project should have remedies identified which will correct the issue. One of the benefits of reviewing the schedule with team leads before producing a schedule report is that it allows team leads to implement recovery plans in conjunction with the report. This small step allows schedule variances to be reported in proactive rather than reactive terms. Figure4depicts a project which is suffering a very bad end of the month. The last week in September, the project team recognized that Requirements Analysis is running late, a lack of developers will extend Software Development time, and the construction firm won’t finish the new offices when promised.

Figure 4: Example of how three typical project delays can be reported with factual context and options for resolution.

It is very easy to write a narrative that the project team has lost control of their project. Instead, if the Schedule Manager works with team leads and project managers to find viable roads to recovery, the project team can paint a very different picture. Timing is critical. Note that the end of September report is forecasting delays which would impact schedule weeks and months from now. When the Schedule Manager and schedule reports are trusted sources of decision-making intelligence, they can shape customer perceptions as well as the project outcome by spotting delays when they are still on the horizon, rather than an imminent, unavoidable hazard. 

Next Steps

While project managers may not understand the essential value of good Schedule Reporting, they often understand the value of reports which identify problems early enough for them to act. Schedule Reporting Techniques offers guidance for streamlining the reporting process, and communicating with stakeholders where they should dedicate their focus, based on what is known today.