Schedule Analysis Techniques discussed how to analyze the schedule to understand which resource and date shifts matter. It also overviewed the where and the what of problem hunting. Schedule Reviewing Fundamentals covered how Schedule Managers should use their individual review to prepare themselves and the schedule file for manager reviews, and how to conduct manager review meetings.
This article will detail some of the most useful tricks for homing in on the source of a problem and drawing stakeholders’ attention to those areas quickly and effectively. We will also use a simple construction example to walk through the schedule analysis done before and during a manager review meeting.
Knowing Your Tools
How does a Schedule Manager find all the issues they need to fix in a large schedule file? Quickly. This does not mean attempting to speed read the entire schedule. It means looking at the fewest possible lines with the fewest possible steps (and mouse clicks) to learn everything you need to know. The only way to do that is to know the capabilities of the tools you are using. Schedule Management tools have many options for flagging, filtering, grouping, and highlighting both the rows and the metrics most important to you. Detailing the features of specific schedule management applications is outside the scope of this writing. But knowing the full capabilities of the tools you use can save hours of busywork every week.
For example, in Schedule Reviewing Fundamentals we discussed how Schedule Managers should make an initial pass through a schedule to check key milestones and summary activities for changes. This first pass doesn’t require Schedule Managers to look at every line of the schedule. So don’t do that. If the schedule’s key events have been flagged with a filter key, or assigned to a dedicated view, all the needles can be effortlessly pulled from the proverbial haystack. Let your tools do the work for you. Figure 32 depicts a sample collection of filters which a Schedule Manager could build to quickly find relevant information. Such filters once built, stick with the schedule forever.
Another trick for improving manager reviews is to create a “Requires Review” custom flag. During the individual review, mark every line which team leads need to look at. Then the Schedule Manager can filter (or conditionally highlight) the schedule based on the Requires Review flag to cover the highlights with the team lead or use the flag to double-check that nothing important was missed.
Logic Hierarchy
Over the life of a project, logic driven schedules can develop enormous complexity resulting in numerous unintended consequences. In fact, one of schedule analysis’s more frustrating time sinks is troubleshooting part of a schedule file which is not behaving as expected. Remember that schedule files are governed by a hierarchy of rules. Any line in a schedule that is not following an expected rule, is likely getting its start or finish date superseded by a less obvious rule. For example, a Must Start On constraint trumps every other logic rule. But if a single resource records a single hour against the task, that assigned resource’s Actual Start date will trump the hard constraint.
When troubleshooting schedule logic, it is often helpful to build a logic tree for diagnosing a schedule’s trouble spots. Figure 33 lists some the common issues worth checking to untangle logic knots.
Remember, never work without a safety net! Before any analysis, always save a backup copy of the schedule. Sometimes starting over is the easiest or the only way to undo a mistake.
Example: How to Fix Variances
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 tip the balance in the project team’s favor.
Figure 34 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 shortens a task’s duration by adding more resources to the task, making people work overtime, or thinking wishfully. Crashing the schedule attempts to complete as many tasks as possible in parallel which were originally expected to happen sequentially.
Understanding the Problem
Figure 34 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 compress the Shingle Roof task by hiring more roofers. This is a sensible step worth considering, but does that fix the real problem?
Construction of the shed is being delayed by two activities: the late start in Erect Frame and Assemble Rafters and Beams’ late finish. Of these two activities, only Assemble Rafters and Beams is not executing as planned. The Gantt bars in Figure 34 show that Erect Frame has roughly the original planned duration. This begs for the question, what is going wrong with Assemble Rafters and Beams? Until someone discovers and resolves the source of the delay, there is no reason to believe that the projected finish dates will hold.
Triage
All managers have scarce resources with which they can troubleshoot problems. Problem solving on a project necessitates figuring out where the available resources can do the most good. With the little we know about the project above, here are the triage steps a Schedule Manager should walk through with the team lead.
Step One: Stop the bleeding. Assemble Rafters and Beams needs to arrest – and if possible, reduce – its schedule slip before meaningful recovery can be planned. This is a reactive, as opposed to a proactive step, but it is the project manager’s immediate critical path problem.
Step Two: Investigate compressing Erect Frame. The project manager should spend a little time considering options, but not much. Trying to compress in-progress tasks generally yields low results for the time spent. Since Erect Frameis nearly half complete, there isn’t much remaining duration left to compress. In this case, the task’s delay has more to do with the late start than slow progress on the task itself. Finally, Erect Frame’s other successor task, Hang Siding, has no subsequent tasks. It has plenty of slack to complete in parallel with the critical path tasks. This step is also reactive, but subsequent analysis will help the manager get ahead of the project delays.
Step Three: Triage Attach Rafters to Frame. Since this task 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 likely to also encounter delays. This is also the longest remaining task, which gives it the most potential compressibility. Step three is where the team lead should spend most of their available time remedying the schedule variances.
Step Four: Compress Shingle Roof, if resources remain. Hiring more roofers is a sensible proactive step. The task is far enough in the future that the project manager may even be able to find more people without undue emergency. But if this is the first or only step a project manager takes to remedy the schedule, they are taking a gamble. Timely completion of the project still depends on all preceding tasks completing without further delay. Many managers make the mistake of treating the last tasks of a project, usually testing and documentation, as available slack to burn. It’s alluring to hope things will get better later instead of fixing real problems now.
Step Five: Crash the schedule. Sometimes crashing the schedule will be the first good option. Other times it will be the last. The shed project is not a great candidate for crashing activities, but it may be possible. For example, once the frame is erected, any rafters which have been built could be added to the shed, even if not all the rafters are built. Once some of the rafters and beams are installed on the shed, roofers may be able to begin roofing part of the shed. But this is a risk laden tradeoff. Paralleling too many tasks, especially in the confines of a construction zone, will risk resources stopping and starting because not everything is assembled, extra idle time while others occupy the same workspace, and/or increase the hazardousness of the work environment. Project managers must make a level headed decision whether crashing the schedule is worth the added risk.
Summary
This example seems simple because it only contains six lines, and because there are no resource constraints, external dependencies, or competing project priorities to consider. But whether a schedule is six lines or six thousand lines, the same principles and techniques apply. Identify a problem in the schedule, relate it to the real-world issue, and work with team leads to find a solution. Mastery comes with practice.
When a schedule’s size or a problem’s complexity seems overwhelming, remember it is always possible to analyze a schedule one relevant line at a time. Also, remember that schedule analysis is a team effort. The Schedule Manager leads the process, but never works truly alone.
Next Steps
Mitigating a schedule’s delays is an outcome of statusing and reviewing the schedule, but it is not the end goal. Schedule analysis’s real purpose is establishing and communicating a peer reviewed snapshot of the project schedule at the current moment of time. Schedule reporting capstones the process.