Schedule Reporting Principles – Proactive Schedule Management

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 complete their 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.

Schedule Reporting Fundamentals 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, how to determine whether a given report will be useful, and the Schedule Managers’ imperative to reflect reality, especially when the news is bad.

First Assumptions

Regardless of 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 baseline. Said another way, transparency and consistency dictate that all report information be traceable directly back to data in the schedule file.

Figure 38: Screenshot of a smartphone GPS. (Google, Inc)

It is vital that the schedule be accurately maintained. Reports are only as reliable as the data they come from. Schedules which contain out of date tasks, future actuals¹, logic errors, missing dependencies or baseline errors can permanently damage both the report’s and the Schedule Manager’s credibility.

What Not to Know

Reporting too much information risks distracting stakeholders with trivialities. Consider the GPS interface depicted in Figure 38.² 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. These extras 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 key 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 schedule analysis’s imperative is to answer 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 questions, its value is negligible.

Examples of Spurious Information Requests

Figure 39 depicts a few examples of reports whose perceived and actual value to the project are not aligned. Sometimes a manager must study volumes of schedule data to understand a critical component of the project. When taking the time to do an in-depth analysis, make sure that the data being analyzed answers the question being asked. Information is not valuable merely because it is difficult to obtain. Conversely, information should not be reported simply because it is easy to provide. Only information which improves a project team’s decision-making ability is worth reporting.

Figure 39: None of these example reports are of value for answering schedule analysis’s “Big Three” questions.

Special Analyses and Spurious Information Requests

Sometimes, schedule stakeholders will want or need to know something out of the ordinary. How much slack is distributed throughout the schedule? What are our resource load projections for the next three years? How many date shifts have we rebaselined? These questions off the beaten path often require in-depth research or generous assumptions. (e.g., “What will our schedule look like if we need to ramp up development 30% over the next 18 months?”) On large projects it’s not uncommon for Schedule Managers to answer one or two such questions every month. Some of these special analyses can be invaluable to a project. Other requests are much less useful.

Schedule Managers are obliged 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. Managers will often 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 real concerns.

Sometimes the best ways to quell spurious information requests is to produce the requested report.

For example, consider the scenario where a Schedule Manager is asked to provide a weekly summary of all schedule changes. The project manager is likely making the request because they don’t understand why or how the project schedule is slipping. Such forensics may help identify what happened in one circumstance. But constantly looking over one’s shoulder is a poor way to prepare for what’s ahead. Project managers will eventually stop asking for reports which they realize aren’t helping them. Perhaps the best way to curtail spurious reporting requests is to get ahead of stakeholders with the information they actually need. The manager above, searching the weeds for what went wrong, likely still has a project in jeopardy. The Schedule Manager can help them refocus on what’s important and restore control with the right actionable information.

Confronting Bad News

Schedule status reports benefit a project most when they identify problems far enough ahead 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, or not believed.

Schedule reports must walk a fine line when identifying delays. Reports must not indulge fear mongering, nor can they postpone consequential news. Providing the right forewarning with proper context is essential for managers and team leads to value and trust schedule reports.

Schedule Managers may often find their reports are loathed because they call attention when projects are not going well. 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. Hiding schedule delays is unacceptable. All stakeholders have the right and the obligation to know how work is progressing compared to the plan.

Consider the schedule depicted in Figure 40. 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 rationalization which managers use to suppress reporting runs something like this. “We don’t know yet that the activity will be late.” In addition to being a logical fallacy³, this passive project management argument withers when confronted with schedule analysis’s fundamental questions.

Figure 40: 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 System 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 lead, the Test team may only realize that their start date has been delayed when the deadline passes everyone by.

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 39 prove 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 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. Understand the difference between trivial setbacks and delays that matter.

One of the benefits of reviewing the schedule with team leads is that it allows team leads not only to peer review the schedule data but also begin implementing recovery plans in conjunction with the report. This small step allows schedule variances to be reported in proactive rather than reactive terms. Figure 41’s report notes a project which is struggling. In the last week of September, the project team recognized that Requirements Analysis is running late, a lack of developers will extend Software Development’s duration, and the construction firm won’t finish the new offices when promised.

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 the picture of a team that is taking charge.

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

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.

Timeliness of Information and Report History

Since reports are inherently static and projects are inherently fluid, the value of a schedule report diminishes over time. Even on slow predictable projects, a report can lose half its value every 1 – 2 weeks. Up to date reports must be produced regularly to keep schedule stakeholders informed.

Figure 42: The value of a schedule status report diminishes quickly over time.

Next Steps

While project managers may not understand the essentials which make a high-quality schedule report, they often understand the valuable intel which allows 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.