Long-duration projects and the fixed-rolling schedule
by Adrian Abramovici, PMP
While not diminishing the importance of the baseline schedule and the CPI/SPI parameters, here's a caution against their potential misuse.
ONE OF THE FIRST THINGS we are taught to do when starting a project is come up with a project baseline. This baseline includes the schedule, manpower needs definition (hopefully, loaded with the schedule), and an apportioned budget (again, across the scheduled tasks). Once all this has been completed to our, and our various customers' (internal and external) satisfaction, the schedule and budget allocation and spread are frozen, and become our project management baseline (PMB). The measurements for cost performance (CPI) and schedule performance (SPI) kick in, our performance and raises get pegged to them, and our middle name is “Mud” or “God” depending on whether those indices are below or above 1! Better yet, in some cases, the baseline becomes the contractual project baseline, against which our customer measures the project performance, and against which progress payments and fee are awarded. Oops!
Why Oops? Surely I should not object to the fact that the project needs a baseline and that the project performance should be measured against it! Surely I can't object to using CPI and SPI as monitoring indices, allowing early action to be taken to correct project problems? No, I don't! It's only when the baseline and the associated CPI and SPI are misused and misinterpreted that I have a problem.
Nailing Everything Down Early. Let's consider the case of the fearless project manager, “Mr. Knownut,” who believes that the best way to manage a project is to nail everything down early, and force everyone to work to the early plan. He therefore proceeds to require his team to create a fully detailed schedule for the whole length of the project. This “complete schedule” then gets “frozen” as PMB. However, things on a long-term project being as fluid as they usually are, there is a high probability of details in the original plan being wrong midway through the project. Various problems arise and are dealt with by reprioritizing tasks and workarounds, and risks are identified and mitigated. Addressing problems inevitably leads to rearranging, adding or deleting tasks, redirecting resources, and so forth. This then creates variations against the original PMB that will express themselves in the CPI and SPI, more so in the per-month values but also in the cumulative. Now, if the project performance is judged against the PMB performance in such a setup, Mr. Knownut will have a hard time explaining his variances and will expend a lot of effort in trying to “correct” things that are just a reflection of basic, inherent project management mechanics. The irony is that if the project successfully manages its problems and risks, the mid-term variations will disappear and the final cumulative CPI and SPI will settle back onto 1, but usually the credit will go to “Mr. Goldenboy,” the replacement project manager.
Adrian Abramovici, PMP, is director of product assurance for MD Robotics (ex Spar Aerospace) in Brampton, ON, Canada, manufacturers of space robotic systems such as the Shuttle's Canadarm and the new robotic systems for the International Space Station. He has over 16 years of project and program management experience at increasing levels of responsibility in the aeronautical and aerospace Industry.
Original project estimates are just that—educated estimates based on accumulated experience made at a time when the program is more an idea than a well defined piece of work. They are by necessity accurate when looking at the grand picture, but surely not in their low-level detailed forecast years into the future. For lack of a crystal ball, it is ridiculous to expect scheduling accuracy beyond the first six months, possibly the first year, of a multiyear program in the form of a PMB at the time of proposal or immediately after program start.
Keeping a Rolling Schedule Window. The period following this initial high-resolution phase should be treated as planning packages with planning schedules, with adequately spaced milestones to constrain the overall program. As we progress through the project, we should keep a rolling schedule window of some six months in which we provide detailed task scheduling, and resource and budget load the tasks within that window.
Now we know all this, but sometimes the rolling window approach makes some project managers very unhappy, as they feel they lose control and have no visibility into the long-range future of the project. They fear that a rolling window will be manipulated to mask poor performance. So they demand complete schedules and fully spread budgets at the start of the project, and then they nail those down as the PMB. The problem is compounded by the natural association of the word “re-baselining” with the words “screw-up recovery,” an association that seems to pop up automatically in the mind of everyone (senior management, customers, and let's face it, you and I). So in most cases internally driven rebaselining is seen as a very bad sign! Therefore anytime the PMB gets really out of whack with reality and needs to be rebase-lined, this is seen as a cardinal sin, for which the manager and project team are penalized.
Losing PMB Credibility and More. Let's review the worst-case scenario: a longduration project with baselined detailed schedules, team, and management performance pegged to the CPI and SPI performance, and a company philosophy that abhors any rebaselining. I would venture that the following effects will be seen on such a project:
■ PMB credibility. If the real-life schedule starts to deviate from the crystal-ball-based PMB, the PMB loses credibility, and the term “baseline” no longer carries the clout it should with the team members. The CPI and SPI reported are not used, as they carry no real meaning. Workarounds implemented “to recapture the baseline” are seen as a waste of time, adding to the team demoralization.
■ Loss of motivation, distraction from the real work. In most of these cases, the project management and the staff are spending inordinate amounts of time “managing the management and the customer,” that is, explaining the cost and schedule variations, to the obvious detriment of their working the issues and recovering from any problems. Morale suffers, as does the team's performance.
■ Disincentive to creativity. As a project progresses, new ideas and approaches might surface that could positively impact the overall performance of the project. For example, overrunning the initial budget allocation in the early stages of work and by that pulling back the schedule can pay off afterward, when one reaches the manufacturing and test phase. Adding one more set of test and support equipment might help when you need to parallel up testing at the back. But why should we spend or initiate these actions if this will certainly cause a problem with our CPI and SPI? Much easier to just stick to the initial plan.
■ Encouraging narrow-minded decisions. If a group wants to improve their CPI, they might make some narrow-minded decisions where one area will save a few bucks and disregard the potential downstream impact the decision and the “saving” might have on other team members.
Clearly this is a worst-case scenario, but it does happen sometimes. What then is the right approach to scheduling and baselining long-duration projects?
The Fixed-Rolling Schedule. For long-duration projects, the project management baseline schedule should be a high-level, roll-up schedule summary that defines the major project activities and establishes the major project milestones and deliverables, but not the whole detailed network of tasks. An initial budget allocation should be performed at this level, as part of the PMB.
The detailed schedule should then progress with the “rolling window” technique, detailing the six months ahead, but this detailed schedule should not be “frozen” at any point in time. Not only should project managers have the right to modify the detailed schedule, they should be mandated to re-evaluate the project as required and at set intervals (for example, every major project milestone). The re-evaluation must consider scope changes, better understanding of the product later in the lifecycle, better understanding of the external constraints under which the project functions (for example, manpower availability), better understanding of internal constraints (slips or early deliveries), and so forth. The re-evaluation can, and should, go both ways—either requiring an increase or a decrease in the planned budget and schedule for the various tasks. Based on this re-evaluation the project manager should have full authority to change the detailed schedule and juggle priorities, as long as the established project milestones captured in the PMB are maintained and within the allocated budget.
CPI and SPI should be measured based on the roll-up level (forward outside the six-month window) combined with actuals for the past and the detailed spread for the rolling window. The same level of scrutiny and analysis of project performance remains available at this level.
The budget allocated at the start to the roll-up PMB tasks should be reallocated in more detail with the rolling window. A formal rebaselining exercise might be initiated whenever the lower-level changes force movement in the PMB roll-up schedule and milestones or require budget reallocation between the roll-up major activities.
A FIXED ROLL-UP baseline summary combined with a flexible detailed project schedule removes the shackles from project managers and allows them freedom to manage the project. It can be argued that some of the control the project manager, the customer, and senior management might have in a detailed PMB environment is lost when going this route, but the flexibility the project manager gains is more than worth it. Project managers are paid to manage projects—let them! ■
PM Network December 2000