Understanding Schedule Analysis

We define Schedule Management as all activities which directly involve and affect the project schedule. Within that spectrum we can break all Schedule Management activities into three facets: Analysis, Creation and Maintenance. Schedule Creation is the most intuitive concept to understand.

Schedule Managers create project schedules when none exist, or when new work must be added to an existing schedule.

Figure 1: Schedule Analysis’s three fundamental questions and vertices.

Schedule Maintenance encompasses repairs to the schedule logic or structure, compliance with industry standards and best practices, and ensuring that the schedule file accurately reflects the mutually agreed plan for how to proceed.

But what is Schedule Analysis? Schedule Analysis is the means by which project teams recognize progress, quantify time and resource constraints, and identify options for recovering lost time. More simply, Schedule Analysis answers the three questions in Figure 1. Though these questions are straightforward to ask, their answers are rarely obvious. This article will discuss Schedule Analysis’s primary objectives, and how Schedule Analysis fits into the larger role of project management.

Forecasting the Near Future to Eliminate Surprises

Knowing that a significant deadline has been missed is rarely helpful after the fact. However, any missed deadline can be avoided or mitigated given enough forewarning. Schedule Analysis’s first objective is to identify schedule variances and determine how those date shifts will impact future deadlines. Consider the scenario depicted in Figure 2. The Requirements and Design Phase is expected to finish nearly three weeks late. This is postponing the completion of Development and Unit Testing, and the start of Integration Testing. Why is the project team confident that they can recover from the three week slip to the start of Integration Testing? We have no way to determine this from Figure 2’s summary view of the project, however we can consider several questions which will help us see the big picture beneath the details.

Figure 2: Summary Gantt chart showing high level activities. The orange vertical line represents the project status date. The grey lines represent the baseline finish dates.
  • How compressible is the Integration Testing work? Can the Integration Testing Team add more testers or find other ways to make up for lost time? Are they planning to reduce the scope of their testing? 
  • How certain are the Design and Development teams that they can hit the Requirements and Design Complete target date of 10/20? How many Development work orders or tasks are left? How many of those tasks are dependent on the Requirements and Design wrapping up?  
  • How much remaining effort is left? How do we know that Integration Testing can really start the next business day as depicted above?

The summary Gantt in Figure 2 represents a schedule that is approximately 80 lines long. Reviewing the detailed schedule with the right task leads for the right section will allow us to quantifiably answer the questions above and help determine whether the December deployment date is still realistic. 

Source: CMS Management of the Federal Marketplace, A Case Study1Levionson, Daniel R., “CMS Management of the Federal Marketplace, A Case Study”. U.S. Department of Health and Human Services, Office of the Inspector General. (https://oig.hhs.gov/oei/reports/oei-06-14-00350.asp) February, 2016.

Establishing Trends to Predict the Distant Future

The inherent unpredictability of projects and project environments, makes long range forecasting difficult. A thorough analysis of an accurate and detailed schedule may reliably predict project performance six weeks out. That doesn’t help much when trying to forecast a finish date which is eighteen months in the future. However, even if there is not a single critical path spanning the eighteen months, a Schedule Manager can offer critical insight into whether that plan is likely to be achieved. Consider Figure 3 which depicts an integrated hardware and software project with multiple Requirements, Design, Development/Construction, and Testing phases. The Schedule Manager has tracked progress against the baseline weekly for the last nine months. The first two hardware phases took longer than expected, however construction is expected to complete on time. Now that the hardware design is complete, the experienced contractor can proceed at a predictable pace. Furthermore, construction started on time and there is considerable slack between the end of the hardware construction phase and the start of the combined system testing. There is good reason to believe that past delays to construction will not materially impact this project’s completion.

Figure 3: Notional high-level schedule for a project that is partially complete. Three phases completed late. Two phases are forecast to finish late. Two phases are forecast to finish on time. The last phase is months away from starting.

Developing the system software does not offer similar confidence. Delays during the initial requirements phase postponed the start of the design phase. The second requirements phase and the design phase are expected to finish late. The software development team’s claim that they will finish on time is highly suspect. Consider the following questions: 

  • What are the dependencies between requirements, design and software development? 
  • Are the new finish dates for the second requirements phase and the software design phase guaranteed? Will they slip further? 
  • What steps has the software development team taken to mitigate the date slips above?
  • What enabled software development to begin before the software design phase? How much measurable progress did the development team make before software design started? 
  • What is the software development team doing to mitigate the requirements and design delays? 

Though the high-level schedule suggests that the project will get back on track by the time system testing begins, an experienced Schedule Manager would see cause for doubt. The burden of proof rests with the project manager and the software team leads to convince all stakeholders that the schedule is recoverable in the long term. Whether the prediction is six weeks out, or sixteen months out, the Schedule Manager’s line of inquiry remains the same. Are you on schedule? How do you know? What are you doing about it? An honest recognition of a problem halfway through a long project gives managers a long time to remedy the problem. The more time that is available for remedy, the more options the project team will have to self-rescue. 

Facilitating Communication

Ask a veteran manager “What is a project schedule?”, and they may offer one of several institutional answers.

  • A project schedule is a tool for tracking a project’s progress. 
  • A project schedule is a resource loaded, time phased listing of project activities that shows scheduled task completions and task dependencies.
  • A project schedule is an output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources2Project Management Institute, A Guide to the Project Management Body of Knowledge.Sixth Edition, 2017.
  • A project schedule is a document that integrates the planned work, and the resources necessary to accomplish that work, which should be the focal point of program management.3US Government Accountability Office, GAO Schedule Assessment Guide. https://www.gao.gov/products/GAO-16-89G, December 2015

All of these answers are true and valid. But above all else, a project schedule is a communication tool. It allows teams to convey information with each other and amongst themselves. 

Supporting Team Leads

Schedule Analysis’s end goal is to provide intel and knowledge to managers which allows them to control the trajectory of their work. That process begins by making them aware of their blind spots. Ask a team lead whether they are on schedule, they will usually say yes. When asked how they know they are on schedule, their answer may be unconvincing. This is not necessarily because the team lead is out of touch with the work or because they are trying to cover their tracks. Team leads often do not have the time to take notice of problems which do not have a bright red flag. Unfortunately for team leads, most schedule delays aren’t recoverable by the time they become an emergency. 

A Schedule Manager’s primary responsibility is to help other managers spot threats to the schedule before they become an emergency. Once identified, schedule managers can help team leads answer Schedule Analysis’s third question, “What are you doing about it?”. 

Inter-team Communication

Of equal importance, Schedule Analysis facilitates inter-team communication. The Schedule Manager is responsible for understanding every team’s progress. If every project manager must report to the Schedule Manager and vice versa, the Schedule Manager becomes a communication hub for the project. This allows schedule mangers to convey every team’s responsibility’s and needs to other relevant teams, and gives team leads at least one resource to consult for project knowledge. The more productive communication that is available to project stakeholders, the lower the odds that a project team gets left in the dark or caught by surprise.

Figure 4: Schedule Management as a communication hub for all project teams with formal and informal inter-team lines of communication drawn on the outside.

In Figure 4, suppose the Oracle Development Team is running irrevocably late. This will impact the Quality Assurance Team, the Testing Team and SAP Development Team schedules. But with early enough warning, the SAP team can halt work on their SAP to Oracle interface and shift their focus tasks which they can knock out now. The Testing team, now aware that they won’t get the complete package on time can reorganize their testing strategy to tackle integrated system testing last. The Quality Assurance team will be able to make similar adjustments. The Oracle Team’s delays will still be partially felt. However, comprehensive schedule analysis and reporting can make the difference between finding options in time to mitigate some delays and having no recourse beyond apologies and blame. 

Suppose spreading word of the delay was left to the Oracle team lead, who owns the schedule impact. Project team leads often have tunnel vision with respect to their team and the larger project as a whole. The Oracle Project Manager probably has limited awareness how their own delays will affect other teams’ workflows. Even if the Oracle manager is willing to admit their team’s delay, the effort they would spend spreading the word is time spent distracting them from getting their team back on track. 

Informed Decision Making

During the course of any project, leadership will be expected to respond to unforeseen circumstances. Having clear information about where the project is today, and where it will be tomorrow is a significant advantage when trying to determine the correct course of action. 

Should we hire more resources? Will mandatory overtime fix our short term critical issues? Do we need to postpone the next deployment? Must we postpone or cancel work on one feature to complete work on others? A thorough schedule analysis can give executive leadership the answers to these questions and allow leadership to consider several “what if” scenarios before settling on a course of action.