Most people who have worked on a project know that the Schedule Manager updates and studies the schedule looking for delayed work to get back on track. However, reviewing the schedule is only a piece of the whole and it is not a solitary activity. So, what is Schedule Analysis?
Schedule Analysis is the means by which project teams recognize progress, quantify date 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 imperative to provide decision quality information, 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 three weeks late. This is postponing the completion of Development and Unit Testing, and the start of Integration Testing. But Integration Testing is still expected to finish on time. What makes the project team think they can recover from the delay? The summary project view in Figure 2 doesn’t offer enough information for us to know the answer, however we can consider several questions which will help us see the big picture beneath the details.
- 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 new Requirements and Design finish date of 10/20? How many Development 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 “tomorrow” 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 Team 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.
Establishing Trends to Predict the Distant Future
The inherent unpredictability of projects and project environments, makes long range forecasting difficult. Thoroughly analyzing a detailed schedule may predict the project’s future six weeks from now. That doesn’t help much when trying to forecast a finish date eighteen months away. 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.
Figure 3 depicts an eighteen-month 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 hardware delays past or future will not materially impact this project’s completion.
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 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 likely to hold? 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 forecasts that the project will get back on track by the time system testing begins, an experienced Schedule Manager would test their suspicions. The burden of proof rests with the Project Manager and the Software Team Leads to convince all stakeholders that the schedule really is recoverable.
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.
Ask a veteran manager “What is a project schedule?”, and they may offer one of the following well known answers.
- A project schedule is a tool for tracking a project’s progress.
- A project schedule is an output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.
Project 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.
US 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 amongst one another about how their work is going, and when it will complete.
Supporting Team Leads
Schedule Analysis’s end goal is to provide intel and knowledge to project teams 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, and they will usually say “yes”. When asked how they know they are on schedule, they may answer unconvincingly. This is not necessarily because the Team Lead is out of touch, or because they are trying to cover their tracks. Team Leads are busy. They often do not have the time to take notice of problems which do not have a bright red flag. Unfortunately, most schedule delays don’t raise a red flag until they are an unavoidable emergency.
A Schedule Manager’s primary responsibility is to help other managers spot threats to the schedule before the red flag goes up. Once identified, Schedule Managers can help Team Leads answer Schedule Analysis’s third question, “What are you doing about it?”.
Of equal importance, Schedule Analysis facilitates inter-team communication. The Schedule Manager is responsible for understanding every team’s progress. If every Team Lead 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 responsibilities and needs to other relevant teams, and gives Team Leads a reliable knowledge source about the entire project. The more lines of productive communication that are available to project stakeholders, the lower the odds that a project team gets left in the dark or caught by surprise.
In Figure 4, suppose the Oracle Development Team is running irrevocably late. This will impact the Quality Assurance, Testing, and SAP Development Teams’ schedules. But with early enough warning, the SAP Team can halt work on their SAP-to-Oracle interface, and shift focus to tasks they were planning to work later, but can be completed now. The Testing Team, now aware that they won’t get the completed system on time, can reorganize their testing strategy to tackle integrated system testing last. The Quality Assurance Team may make similar adjustments. The Oracle Team’s delays will still impact the project. However, comprehensive schedule analysis and reporting can make the difference between finding ways to press forward, and having no recourse beyond apologies and blame.
Now suppose that spreading word of the delay was left to the Oracle Team Lead. Leading a project team often creates tunnel vision. The Oracle Project Manager probably has limited awareness how their own delays will affect other teams’ workflows. That becomes even more true when working through a crisis. Even if the Oracle manager is aware of and willing to admit their team’s delay, the effort they would spend spreading the word distracts the manager from getting their team back on track. Furthermore, they may not even convey the right information to their peers, because they do not know what intel is most valuable to other teams. The Schedule Manager, with their broader and more targeted view of the project, can supply a far more candid and comprehensive assessment to affected project teams.
Reporting to Inform Decision Making
The culmination of every Schedule Analysis cycle is the verbal or written reports which result from statusing and reviewing the project schedule. The knowledge conveyed by these reports will allow project leadership to respond to unplanned circumstances which arise on any project. Consider the following questions which face project managers routinely.
- Should the project hire more resources?
- Will mandatory overtime fix short term schedule slip?
- Does the client need to postpone the next deployment?
- Must the developers postpone one feature to complete work on others?
Schedule Reporting gives project leaders at all levels the answers to these questions and enables managers to consider several “what if” scenarios and options before settling on a course of action. Having clear information about where the project is today, and where it will be tomorrow significantly elevates a manager’s confidence that their decision is an informed one.
The same high-confidence schedule information allows project stakeholders at all levels to make informed choices about how to focus their effort to achieve the project’s immediate and long-term objectives.
This article has overviewed how the small and large scale schedule analysis can provide stakeholders and project teams with critical information which allows them to steer the course of their work. Schedule Analysis Principles will outline why the recurring steps of Schedule Analysis are essential for ensuring a project’s timely success.