The problem with the definition of the project buffer presented in my previous post, the problem with most definitions of the project buffer, is that traditional schedules already have protection time. Some of that protection may be in the form of inflated task times or hidden safety time, but it’s there. Saying that “a project buffer is time placed at the end of a project to protect against variation” is correct, but so what? Everyone already protects their schedules as much as they can.

The problem with traditional schedules is, when the safety time is spread around in the nooks and crannies of schedules, when it’s hidden in task estimates, we use it up. It’s used, and used up, in protecting individual parts of the schedule. People rarely perceive value in delivering those individual parts early, which means safety time allocated to protect one area doesn’t help protect other areas.

The purpose of adding a project buffer isn’t just to protect against variation; we already do that. It’s to aggregate and manage that safety time, so we don’t waste it. In other words, the main purpose of the project buffer, the purpose that makes it unique, is to keep us from doing dumb things. It’s designed to influence our behaviors. Here’s an alternative definition of the project buffer that I would recommend:

It’s all about the behaviors. We schedule in order to influence behaviors. Our behaviors, in turn, are a result of what we value. In the previous post, I mentioned four common values:

• Responsiveness
• Getting things started
• Hitting deadlines
• Meeting individual goals

These are standard good-citizenship values. If you don’t value these things, you are not a good citizen. What problems do they lead to?

Responsiveness: By responding promptly to interruptions, including phone calls, emails, and instant messages, you are potentially delaying important work. Each interruption also requires some extra time to get back into whatever you were working on. Responsiveness conflicts with a need to work on your highest priority task.

Getting things started: If we start working on things as soon as they arrive in our “in” boxes, we have to stop working on something else; something that may be higher priority. Getting things started often conflicts with a need to get things finished.

Hitting deadlines: If you create deadlines that must be hit, you have to be sure to give people time to complete the work. Since there is variation in how long things take, that usually requires safety time. If I have something that takes two to four weeks to complete, I’ll ask for four. After some negotiation, I may get three. The problem is, if I’m successful in negotiating that safety time, on average I’ll have time for other things. If I’m good at what I do, people will ask for my help, and I’ll have time to accept. I’ll multitask. And multitasking conflicts with a need for speed.

Meeting individual goals: Should a project team work hard to hit an intermediate deadline, at the expense of delaying a product release that generates actual money for the company? Should I share information that may get me in trouble? Samuel Goldwyn reputedly said, “I want everybody to tell me the truth, even if it costs them their jobs.” When individual goals conflict with global goals, there’s no telling what choices people will make.

The problem is, we can’t get rid of these values. Good people are responsive. If I work hard to get you something to work on, I’m justified in expecting you to get going on it. Organizations communicate with deadlines. And meeting individual goals is a key part of almost all measurement systems; it’s hard to evaluate individual performance, without talking about individual goals.

What do we do? How should we resolve the dilemmas?

Here’s a clue: How can you have both? Under what circumstances can you both follow your priorities and be responsive?

Stay tuned for the answers in my next post.