Accelerate... Finish On Time
/You have to accelerate the schedule in order to be on time.
In other words, you need to pull-in the schedule just to be able to meet the committed target date. This is called "time banking." You accelerate to gain time now, since you know unexpected things will happen in the future, where you will need to use that banked time. What is certain, is uncertainty! Only a fool assumes a plan will materialize as planned!
When we say, "Accelerate the schedule," we are really just trying to hit the committed target date "on time." You need to “pull-in” all the time, just to be on time. The minute you let go of the force pulling to the left, your schedule will slip to the right. The larger discussion though is, "Should the committed target dates be accelerated?" I’ll discuss this in a bit. This thinking is characteristic of the best practiced-fast teams. We’ve observed them always looking for ways to accelerate, even when they were not yet late, since they knew that they would need that “banked” time to deal with unexpected events in the future.
1. Pull-in
Lets assume we are on schedule. In order words, our schedule fits within the time available to deliver the project’s completion. Fast-teams will attempt to accelerate their schedule in order to “bank” time for the future. They do this using a variety of practices that look at the critical path and re-engineer it to remove inefficiencies. So the acceleration is based on specific actions by team members to implement the accelerated schedule. This “before-the-fact” behavior generates anticipatory thinking and action. This is also called, “Working to the early schedule.”
2. Pull-back
The second condition, which is more typical, is where a schedule slips and then a team needs to recover that lost time to get back on schedule. This is called, “Pull-back.” It’s an “after-the-fact” behavior pattern that many teams find themselves in--continuously throughout the project. The cause of this is either poor planning on the front side, or unrealistic expectations about the committed target dates, i.e., the team was late before they started and could never recover.
3. Fast-Time-To-Market -- Pulling-in from aggressive targets!
This third condition describes the fast-teams we’ve worked with who apply best-practice thinking to managing their projects. For many reasons, target dates are accelerated. Usually this is driven by external factors such as market conditions, competitive factors, or anticipated capacity constraints or demands. The team figures out a way to do the project faster using the classic re-engineering techniques of Optimization Modeling. The key to this working, is that the team believes that the project can be accelerated and demonstrates, through the schedule modeling process, that it can be done, considering the calculated risks. In this case, fast-teams continually pull-in the accelerated schedule through the Refresh Planning process (i.e., update, breakdown, pull-in near-term). They continue the before-the-fact practice and bank time, even on the FTTM accelerated time-line, since they know they will need it in the future.
Process Maturity
There are degrees of “process maturity” with this scheduling practice. There are really two groups of behavior; “before” and “after-the-fact” thinking. The most effective teams are in the “before-the-fact” space, but this is very hard to do.
Lets start with “no updating” of the schedule. The lack of current status of where a project is at a given point in time makes pull-in almost impossible.
Next comes regular updating of the schedule, where actual performance is recorded against the baseline schedule. This stage is more than most teams do, and if it is done regularly and accurately it can provide valuable information about where you are at a given point in time. Knowing where you are is half the battle. Most project teams we see, don’t.
The most advanced form of this after-the-fact behavior is to pull-back the schedule to recover lost time. This is actually an advanced form of the practice.
As we move into the FTTM space we see teams using the schedule to identify before-the-fact actions to accelerate the schedule before it slips. It is one thing to model schedule acceleration, it is yet another thing to actually implement the acceleration on the project itself. Fast-teams use pull-in action logs to make sure that the “modeled pull-in” gets implemented in the field.