Accelerate Before You Slip

It seems counter intuitive. To make a project go faster when you don’t have to, because you are already on schedule. That is the point.

Fast teams we’ve studied consciously accelerate the schedule when they are on or ahead of schedule. They know that the time saved today can be lost tomorrow when the unexpected happens. They call it “time banking.” They deposit time into their account and expect time withdrawals in the future. This is expected when developing advanced technology, where there are more unknowns than knowns. The only certainly is that the schedule will slip.

The fast teams are continually pulling-in the schedule. They work to the “early schedule” rather than letting things slip to the latest time they can start (i.e. working to the late schedule). They know that they have to pull harder than the force of the schedule moving/pushing out to the right. Schedule “pull-in” is distinctly different from “pulling-back” the schedule after it has slipped. Once a schedule is late or slipping badly, a team is in damage control, just trying to keep their heads above water. The idea is to stay out of the water in the first place.

The psychology of the fast team is very different. They accelerate before it slips. This skill is not developed “overnight." It also can’t be “trained” into a group of people. It is as much a mindset as a set of actions or behavior. It can take teams months to develop the ability to accelerate a schedule. Some never get there. They tend to be happy simply updating schedule performance in order to know where they are and where they are going. For most, this is a worthy goal.

The process maturity steps are sequential. Teams have to master each step before they move to the next. Starting with the most basic “update performance.” They meet every week in the Refresh Planning meeting to report what tasks have started, what have finished, what have not started, and which tasks are still in progress, and what time is remaining. Getting this rhythm “down” is very hard.

It requires disciplined meeting attendance and each task owner to know the correct status of each task. It also requires experience to estimate time remaining for the in-progress tasks, based on the content and risks associated with the task. Forecasting is hard. The more experience a team has, they better they are at it. All future process maturity steps are predicated on having an accurately updated schedule, so this is a critical step to master, which can take months.

The next step is to “pull-back” after time has been lost/something has slipped. Most projects spend their lifetime pulling-back, since they start late, are under-resourced, were forced into overly aggressive estimates, and are always later than their aggressive target dates. So there is the “pull-back” from day-one and there is “pull-back” throughout the project when something slips. Slip just compounds in these conditions.

However, most teams are very happy to achieve this level of planning excellence - just being able to pull-back when something slips. It is a good goal for every team using FTTM Planning to reach this step within 2 months of starting the planning process.

There is a big chasm between Pull-back and Pull-in. Pull-in means that you are already on schedule and you are trying to make something go faster; to finish faster than the predicted completion. This is a state reserved for advanced FTTM Teams. They look at the critical path every week and peel back multiple layers to expose the next long path behind the longest one. They work hard to reduce each of these long paths through mitigation actions or by changing the way the work is done to make it go faster and making decisions. In this world, they value every single day of acceleration and are aware of every day lost.

When it slips a day it is BAD, and everyone works to recover it. They know that it is easier to pull-in than to pull-back, so they spend a lot of time trying to make it go faster (i.e. pulling-in to bank time).

Pull-back and Pull-in are often mixed up. They are different and can be used to measure the “process maturity” of a team. Both are good… Pulling-back after you slip is important in order to be on time. But pulling-in a schedule before it slips will greatly improve the chances of hitting a target date on time, because the unexpected will happen to force the project back off schedule. It is a constant battle to keep a project on schedule; a war between deposits and withdrawals.

The final step is to “take action.” Again, another obvious statement, but rare to see teams that are good at planning and then executing that plan. These things usually fail in that gap between plan and execute. So the advanced team will use the schedule to model a pull-in, and then they will take the actions on the project to make that pull-in a reality by making decisions, gaining support, moving resources, changing direction, changing flow, and so on. They “do” versus talking about doing something. The point is that they not only model the problem, they actually use the model to direct their actions.