The Long Pole

The long pole in the tent holds the tent up. It determines the height of the tent. The long pole in a project is the critical path. It is the longest contiguous path, from start to end, that forms the overall project duration. The long pole in the project tent drives the end date.

Our goal is to accelerate projects; to make them go faster, to finish on time or early.

A core best practice of fast teamswe’ve studied is to consciously work to the early schedule. They do it early, rather than waiting until the last minute. How do you get teams to behave this way given it runs contrary to human nature?

They assumed that long pole would get shorter, not slip and become longer. This is another counter-intuitive notion, that a project would actually accelerate rather than decelerate. Once they figured out how to reduce the duration of the longest continuous path of activities, they would attack the next longest path, since they knew that this would be the next driver.

The long pole in the tent determines the height of the tent. Lets assume we had other poles in my tent. If we figured out how to reduce the duration of the longest pole, what would be the next one?

Lets stay we can get Team A to reduce Long Pole #1, and simultaneously ask Team B to reduce Long Pole #2 based on the assumption that Team A will be successful. We do this with teams every week during Refresh Planning, tracking back each long pole (or critical path) until we have five teams working on acceleration. This is all predicated on the belief that each team will succeed. In a normal project environment, teams tend to assume the opposite; that the other guy will fail, and that they will have more time… not less. Fast teams don’t do this.


We call this “peeling the onion.” It is like taking each layer off of an onion to expose the next one underneath. Conversely, this next layer is also the one that can bite you, since this path could also slip, and if it did, it would become the new critical path. May times these second and third critical paths are within 10 days of float from the critical path and have to be taken as seriously as the critical path. Peeling-the-onion generates before-the-fact thinking and early schedule behavior. It is a process that assumes the other teams on the project will succeed.

Let’s look at this implemented on a schedule. This is more fun with a real project, but this example will illustrate the concept.

The red activities are the long-pole or critical path that sets the end date for the project. I have five other paths here that also could drive the end date. Lets peel the onion and see each level of critical path.

I have this set to show the main critical path, then the next critical path.

So this is the first and second critical path. Notice that the second path (in blue) is 10 days behind the main critical path. If this were real, we’d ask the team on the second path what they could do to make their project go faster, assuming we could accelerate the first path.

I’ll jump back to the longest poll, the one with zero float. Now here is the second one, it has 10 days of float.

Assuming that Team 2 got faster, who’s next? This is the third potential critical path—it’s 20 days from the main critical path. That teal colored line on #18 is the float path.

This is the fifth path. Its 33 days off the critical path.

I’ll reset back to the first critical path. Change the setting to show only a single critical path and walk back through each successive critical path.

I’ll reset again and change the setting to show “all critical paths” and continue the walk-back simulation. These are all the paths displayed. Again, this is a simple example, it gets much more exciting on large schedules—we’re doing this now with a major complex program with thousands of activities.

What tends to happen on most late projects is that the longest pole just gets longer. In fact, everyone is counting on it. The longer it gets, the more room they have, and less pressure they feel. Of course in this situation they all fail, but at least the can blame the poor guy on that long pole!

The longer that long pole gets, the longer the other ones get behind it. The notion that the long pole guy will accelerate is not even considered. We call this the “late schedule” mentality. There is no sense thinking of ways to pull-in, since the total project keeps pushing out.

Fast teams assume success, not failure. They create a culture with reasonable risk is encouraged—where they assume the other guy is going to succeed and they help him while trying to figure out how to get their own team to move faster. They peel-the-onion every week until they have at least five teams on the critical path.


As Louis Pasteursaid, “Chance does favor the prepared mind.”