Schedule Analysis Techniques

The week is over, and it was a long one. You added two new subprojects to the schedule baseline, reviewed the schedule with half a dozen managers, sent monthly metrics to the Finance and Earned Value Team, and published the weekly “Schedule SITREP” report that gets shared with new hires and client leadership alike. Along the way, you caught a looming deadline that would have postponed the next release, helped one manager smooth her employees’ 60-hour/week workloads, and warned another manager that his team would have nothing to do after the winter holiday – unless they finally get Procurement to purchase the badly needed custom hardware.

Your Schedule Management Office deserves real credit for keeping things running behind the scenes. But a problem is surfacing which, if left unchecked, could derail everything. The responsible team might have a chance to diffuse the situation. But no one knows where the trouble is brewing, not even you. 

So continues the Schedule Manager’s endless waltz. What if every week is this frenetic? How can the Schedule Manager keep pace with a large ever-changing project without burning out? The difference between an insurmountable workload and routine chores is not the size of the task list, or the wellbeing of the project. It’s the preparedness of the Schedule Manager. A well-equipped Schedule Manager will execute the worst week of the project with the same poise and stamina as their most boring week. 

Schedule Analysis Principles explained why the process of statusing, reviewing and reporting a schedule must occur with comprehensive regularity to be useful. This article will discuss how to make Schedule Analysis’s basic tenants practical and repeatable. It will then overview some of the technical data and methods a Schedule Manager can use to quickly detect and call out consequential schedule variances.

Learning What Matters

Every substantial project has work which does not go according to plan. Much of the time, the delay or hastening of an activity has no significant impact on the overall schedule. Sometimes, a schedule variance will impact subsequent activities or create a resource bottleneck. This happens either when an affected task is on the critical path, or the resources (team members) must postpone seemingly unconnected work until their schedule clears.1For example, a shopping website’s search page and secure customer checkout page do not depend on each other to function, but the system architect won’t have time to design the search page until they have finished designing the checkout page.

Remedying schedule variances can be difficult, and sometimes time consuming. The art of Schedule Analysis starts with knowing which schedule variances should be fixed, and which delays aren’t worth the trouble. 

When problems arise, Project Managers and Team Leads have several remedies at their disposal. But corrective action can’t be considered if they don’t realize the threat. Finding those threats and warning the team is the Schedule Manager’s responsibility, and the most valuable role they play on the project. Schedule Managers have two sources of knowledge for understanding which schedule variances matter. The first is the hard data contained within the schedule: task durations, dependency logic, and resource loading. The second source is institutional knowledge. 

Schedule logic (when done properly) tells project stakeholders what is on or close to the project’s critical paths.2Project schedules often have a critical path which runs the length of the project. Large projects may have one or more local critical paths which affect a release, or other significant event. Schedule Managers should perform the same critical path analysis on local critical paths that they perform on the larger critical path. Variances when compared to activities’ total remaining slack can guide the Schedule Manager’s decisions about where to spend time reviewing the schedule in depth. For example, consider Figure 1, where the Test Team is running two weeks behind writing all of their test cases. It may be of future interest to understand what caused the Test Team’s work to slide. However, since Software Development is the task driving the start of Software Testing, rushing to finish writing the test cases is of little benefit to the project. In fact, diverting resources to rescue test case writing may delay Software Development by taking available resources. 

Figure 1: Although, Write Test Cases is taking longer than planned, there is no impact to the overall project schedule. The Schedule Manager’s and Project Manager’s attention is best spent ensuring that Software Development completes on time.

Other knowledge about which delays matter are tied to understanding the client and the project itself. Some clients are amenable to postponing a major release in order to launch with all necessary functionality. Some projects have unchangeable deadlines that connect to major events outside the project. Other projects may have valuable resources who are only available at a certain time. These institutional factors will help Schedule Managers and Project Managers make informed decisions about how to achieve the most successful (or least terrible) project outcomes given the circumstances. 

So how does a Schedule Manager look at a several thousand-line project schedule and spot which few lines require decisive action? The answer is quickly. 


Since projects are inherently fluid, any single schedule analysis will have a short shelf life. Over the course of a busy workweek, Schedule Managers have only hours to glean a comprehensive picture of where the schedule has shifted and how consequential variances can be corrected. The most important thing a Schedule Manager can do is find what they’re looking for with haste. Fortunately, even the largest schedules can be analyzed rapidly, if the Schedule Manager knows where to look and what to look for.

Where to Look

Suppose you are asked to investigate a large project schedule that is running two months behind. Each line of a resource loaded schedule contains fourteen schedule data fields.3Start, Finish, Duration, Work, Resources, Dependencies (possibly with lag), Constraint Dates, Baseline Data and Actuals. In a 15,000-line schedule, that equates to 210,000 data points collectively determining the project’s end date. Somewhere buried in that mountain of information are a hundred tasks requiring scrutiny. And scattered across those hundred tasks are perhaps a dozen data points which are the real culprits driving the project’s delay.  

Analyzing every line item would be a daunting undertaking. But since comparatively few tasks can be postponing the project’s finish, large swaths of the schedule file can be ruled out of the analysis. In fact, without even tracing a critical path, the Schedule Manager can cut their initial analysis down to tasks which are currently being worked, overdue milestones, and tasks that have just completed. 

Newly completed tasks can be analyzed rapidly. Their only relevant variables are the finish date and successor tasks (including lag). Most of the time, they require only a cursory review because it is extremely rare for completed work to be a schedule file’s source of trouble. Overdue milestones, if they are impacting the schedule, will almost always be on the critical path. Occasionally, a schedule file will have resource constraints which are impacted by a shifting milestone. 

But the majority of schedule delays can be found in the tasks which are currently being worked. Even on a large heavily delayed schedule, only a fraction of the tasks are likely to contain information that is directly relevant to understanding why major events have been impacted.4Suppose a project schedule contains 15,000 lines and 250 team members. Even if each resource is been assigned four tasks on a given work week, the total number of tasks worked is no more than 1,000 tasks, or 0.07% of the schedule.

Here, a Schedule Manager realizes a key benefit to building a detailed project schedule. Tasks that are small, are more likely to be either complete or not started, instead of partially complete. Consider the work to build a red-eye reduction filter for photographs in Figure 2. If all five software development tasks were merged into a single large task, it is not obvious what component of the software development process has delayed the overall work, or whether a remedy even exists. Instead, the increased level of detail allows the Schedule Manager to focus all of their efforts on remedying the User Interface task, while also providing a warning to the Test Team that they may have to start testing late, or concentrate their initial testing efforts on software functionality, instead of user interface testing. 

Figure 2: Work described by five small tasks vs one large task.

What to Look For

As with baseball, scores of metrics can be calculated to measure schedule performance, but it is very easy to produce a useless analysis simply by looking at the wrong metrics. Which metrics will provide the most beneficial information to the project team? Remember that Schedule Analysis’s imperative is to provide Project Managers and Team Leads with decision quality information. This inherently forward-looking activity requires forward looking knowledge. 

Figure 3: Qualitative chart ranking the utility of several project schedule metrics for forward looking Schedule Analysis.

For example, consider Schedule Performance Index (SPI) which is shown in the middle-left of Figure 3. SPI is an appealing metric, especially in Earned Value Management. It distills an entire project into a single number which tells executives whether a project is ahead of schedule or behind schedule. Tracking at regular intervals tells leadership which direction projects or programs are trending. Though properly calculated in conjunction with Cost Performance Index (CPI) as a ratio of dollar estimates, SPI is robust enough to be reasonably estimated using billable hours or even task progress. 

But what decision quality information does SPI offer project leadership? A low SPI score may indicate to a manager that their planning process is underestimating the work, or that the project does not have enough resources.5It is worth mentioning here, and discussing more thoroughly elsewhere that adding new resources to a project in a short-term attempt to crash the schedule often has the opposite effect. However, a Project Manager may have other sustainable and unsustainable options at their disposal to remedy resource bottlenecks. But if more resources and better planning aren’t the answer, SPI only tells the project manager how quickly they’re drowning. Consider instead, the much more targeted metric Finish Variance, which compares a task’s projected finish date to the baseline finish date. Both Finish Variance and SPI are a means of comparing progress (or lack thereof) to the original plan. However, Finish Variance is much more useful to managers in the trenches because it can tell them what activities and teams need most attention. 

Figure 4: Table comparing the utility of Schedule Performance Index and Finish Variance for answering schedule analysis questions.

In essence, the contrast of small and large schedules in Figure 2, mirrors the strategic and tactical value of SPI and Finish Variance. Both metrics have merit, however the quality and purpose of the information they provide varies significantly. Even though Figure 4 shows that both metrics can be used for forecasting, the type of forecasting that each metric offers will differ. 

The utility of Finish Variance and SPI is fairly universal across most types of projects. However, it is difficult to generalize about all schedule metrics because the nature of projects varies so greatly. Some metrics will be more useful in certain situations than others. The key for the Schedule Manager is to know which metrics will provide managers and project teams with the best knowledge to make informed decisions. 

How to Fix It

Difficult choices are par for the course on all projects. Project leaders rarely get to face project management dilemmas with a simple yes/no decision, or even the foresight that their choice will work. The Schedule Manager, equipped with a high-quality project schedule, can help tip the balance in the project team’s favor. 

Figure 5 depicts a simple construction project which is trending late. Without corrective action, the shed will not be finished on time. Basic project management courses offer two general solutions: compress the schedule, or crash the schedule. Schedule compression theoretically shortens a task’s duration by adding more resources to the task, or making people work overtime. Crashing the schedule attempts to complete as many tasks in parallel that were originally expected to happen sequentially. 

Figure 5: Gantt chart showing construction of a shed is behind schedule. The best tasks to analyze for recovering lost time are those closest to today. (Baseline duration in grey.)

Understanding the Problem

Figure 5 does not depict enough information to know what options are viable, but we can still see choices available to the project team. For example, the project manager could plan to hire more roofers. In this scenario, that management decision is a sensible proactive step. Bringing more people onto a project takes time. The project manager will need time to find and hire extra roofers while the rest of the shed is built. But does that fix the problem at hand? 

Construction of the shed is being delayed by two events, the late start in erecting the frame, and rafter and beam assembly. But of these two events, only rafter and beam assembly is not executing as planned. Despite a late finish date, the time bars in Figure5 show that erecting the frame has roughly the same expected duration as was originally planned. This begs for the question, what is going wrong with rafter and beam assembly? There is no guarantee that the projected finish date will hold. In fact, until someone discovers and resolves the source of the delay, further schedule slip is likely. 


All project managers have scarce resources with which they can troubleshoot problems. Problem solving on a project necessitates figuring out where the limited resources available can do the most good. With the little we know about the project above, here are the triage steps a Schedule Manager should recommend. 

Step One: Stop the bleeding. The project manager should direct their focus on preventing further delays to rafter and beam assembly or recovering time if possible. Note however that this is a reactive step. The project manager is catching up to the facts on the ground. 

Step Two: Weigh the tradeoffs of compressing frame erection and attaching rafters to the frame. By a narrow margin, erecting the frame is the driving task which is postponing the rest of the schedule. But frame erection’s other successor, hanging siding, has no subsequent tasks. Thus, hanging siding has plenty of slack in the schedule to be completed in parallel with the critical path. Minimal time should be spent on this step because it is also reactive. 

Step Three: Triage attaching the rafters to the frame. Since attaching the rafters to the frame has not started, this is the first proactive step that the project team can take. Assembling the rafters has already impacted the schedule, a follow-up task involving the same product or the same personnel is the most likely task to experience delays. This is also the longest remaining task, which means it is most likely to benefit from schedule compression. The steps the project manager takes to hasten this task are going to provide the most potential benefit to the project schedule.   

Step Four: Compress roof shingling, if resources remain. Again, hiring more roofers is a proactive step. But if that is the first or only step a project manager takes, they will hinge timely delivery of the project on all of the previous tasks proceeding as forecast. That is a risky gamble when the project already hasn’t gone as planned. In practice, project managers routinely make the mistake of treating the last tasks of a project, usually testing and documentation, as available slack to burn because that is easier to contemplate than resolving the nearest term problems. 


This simple example is merely an introduction to advanced concepts of Schedule Analysis. More complex project schedules require Schedule Managers to contend with resource constraints, external dependencies, changing scope and stakeholder prioritization. Yet the same principles and techniques still apply. To chart the best possible way forward, the Schedule Manager must know where to look, what to look for, and how to fix what’s wrong. 

Next Steps

Understanding Schedule Analysis overviewed the Schedule Manager’s role in project management to provide stakeholders with decision quality information. Schedule Analysis Principles established schedule statusing, reviewing and reporting as a repeatable process which acts as the drumbeat for consistent, reliable project management. Having now overviewed the techniques which make schedule analysis sustainable and repeatable even for large project, subsequent articles will explore what Schedule Managers must know about each process step to execute their essential role with game changing results.