Saying "No": A Tutorial for Project Managers

Saying "No" can be painful — so painful that we sometimes avoid it just to avoid short-term pain, only to find later that the long-term pain is even worse. For example, when I've been asked to commit to deliver a product within a time period that was clearly too short, I have sometimes agreed to the request, even though I knew better. My own guess is that at one time or another, most of us have avoided saying "no" by saying "yes." We do this in spite of our experience that the price we pay for agreeing to do something we don't believe in is often far too high.

There are many people who would like to say "no," but I've decided to focus on project managers. Even for project managers, there are occasions to say "no" that I won't deal with here. But if you're a manager, an executive, or an engineer, you can take what's here and modify it to suit your own needs.

A bit of shorthand just for this essay. Typing these quotes around the "no" and "yes" is only slightly less annoying than reading them, so I'll be using these constructions:

What can go wrong when we say-yes

Here's an example. You're a project manager of a large project. Of course, the project is late (see, for example, "Why Complex Technology Projects Are Usually 'Late'"). You're sitting at one of those long conference tables with about 16 other people, including eight of your team leads, four people from Marketing, two sales reps whose accounts are key customers, and two VPs (Marketing and Engineering). You've just gone through the critical issues list and you gave a pretty good justification for your estimated completion date. Apparently the justification isn't good enough, though — five people in the room are now pressing you to commit to a date four months earlier than you believe you can meet. You can probably guess which five. Everyone is looking in your direction. You feel alone. You feel as if nobody is backing you up. You'd rather be interrogated by Kenneth Starr.

What are your choices? This isn't really very complicated — there are only two basic options. You can agree to a shorter date, or you can try to persuade others that what they want isn't realistic. Let's suppose that you agree to a short date, and then examine the consequences.

• Assuming that you knew what you were doing when you made the estimates, the project team won't make the short date — no way.
• By agreeing to the short date, you will have immediately undermined your own credibility with the team — on this project, and in the future. After all, did you not believe in those estimates you so carefully drew up? If not, then they might ask "What else have you said that you yourself don't really believe?"
• More damage will come to your credibility later, when the project comes in "late;" that is, past the date you just agreed to. Then some people might ask why you agreed to the short date, when even Ratbert could tell it was impossible.
• Get ready for some serious déjà vu. When the news that the project is late hits the wire, when it's obvious to everyone some months from now that you won't make the short date, most of the same players, including yourself, will reconvene in this same room, with maybe even the CEO sitting in, and you'll be in the same hot seat. It might even be a little hotter then. Did I say déjà vu? In some organizations, it's more like the movie "Ground Hog Day" [Ramis 1993] — it happens again and again.
• At that point, the members of the project team will be even more tired and cynical than they are now, because they will have been burning the candle at both ends for all the months between the time you agreed to the short date, and the time it became unavoidably clear to everyone that the short date was a fantasy.
• The quality of the work everyone has been doing will be in decline. Errors and omissions could cost you even more time.
• Problems might have multiplied because of shortcuts taken and risks that went unmitigated in the hope that things would fall the right way. And you know: things rarely fall the right way.
• It might even happen that the sane date, the one you originally wanted, could become impossible because of all the compounded problems caused by rushing to the short, improbable date.

Trying to achieve an improbable date is like trying to cross an urban Interstate at rush hour. You might make it, yes, if you can move as fast as the Roadrunner. But chances are you won't survive. If a date is improbable, it's just improbable.

Why saying-yes doesn't "buy time"

Perhaps you believe that saying-yes — agreeing to an improbable date — is a bad idea because it just postpones the day of reckoning. Ah, if only it were that good! Agreeing to an improbable date is actually far worse than a simple postponement. While it's true that saying-yes introduces a delay, the delay itself actually makes the problem worse. Time passes, resources are spent, and opportunities for alternative strategies disappear. The project becomes more tightly constrained as time goes by. Your options narrow. Agreeing to an improbable date makes that improbable date even less probable than it was when you agreed to it.

The idea that we can "buy some time" by agreeing to try to do magic is actually backwards. You aren't buying time — you're transferring it. When you agree to try to go for a date that you know you can't make, you're taking from the project the time you need to address the underlying issues that are plaguing the project. In exchange, you receive a postponement of the confrontations. Confrontations plural? There are actually two: the confrontation you're now having with the people who are demanding an early completion date, and the confrontation they must soon have with Reality.

When we say-yes, there's a transaction involving time, which we can understand using an analogy from accounting. In this analogy, there are two time accounts. One is for your career within the organization. The other is for the project you're managing. When you say-no, you let the time stay in the project account, and take whatever consequence comes as a charge to your career account. When you say-yes, you take time from the project account, and transfer it to your career account. You intentionally plan to use the time in your career account to postpone the confrontation that you're about to have with the people who are arguing for the short date. This might be a good idea, if it weren't so much like embezzling. Using project resources for personal gain is a questionable practice. When you say-yes, you aren't buying time — you're embezzling it.

How saying-yes prevents group problem solving

When I say-no to people who desperately want to hear "yes," they must finally face the problem, or even better, we'll face it together. When I say-yes, I deprive the organization of a real chance to face the issue. And I do it without letting anyone in on what I'm doing — perhaps not even myself. A fundamental requirement for successful group problem solving is a shared agreement that a problem exists. When you say-yes, you get shared agreement — that there is no problem. This halts group problem solving.

Let's go back to the hot seat in that conference room for a minute. As soon as you say-yes, you mollify the five advocates of the short date. Your stomach might go into knots, but at least these five people are off your back. And they're relieved of all responsibility for figuring out what to do about the problem. Chances are, this problem wasn't their only problem. So they're more than happy to move on to something else. The meeting ends shortly after you say-yes, and you walk out of there under the burden of a very significant action item: to do the impossible. But their minds are now elsewhere, and this is how group problem solving comes to an end. The problem is now all yours. That's fine, if you actually have what you need to solve the problem. But since we're assuming here that you don't, the problem is still there, but by group agreement, it remains unseen.

Now let's think about what happens when you say-no. Suddenly, everyone in the room now knows that there's a problem. And most likely, people go to problem-solving mode immediately. In some groups, personal attacks and blame can result, as some people identify you as the problem (you aren't). And you might find yourself under attack. In other groups, those with more effective problem-solving practices, the group can now move to a collective exploration of the problem and possible resolutions and options. You probably know which kind of organization yours is.

The best route to a constructive resolution is through saying-no. It isn't a guarantee of an outcome you want, but saying-yes makes such an outcome a lot less likely by preventing group problem solving.

Why it can be difficult to say-no

Probably the main reason we say-yes when we want to say-no is to avoid playing the blame game. Back to that conference room. My experience in such situations suggests that if I say-no, the short-date folks in the room first try to persuade me that I must be mistaken. Failing that, they try to invent miraculous ways to cut work from the schedule. "We can save two weeks in testing," or "What if we remove these other features?" These conversations are inevitably unproductive, but for some reason, they occur with regularity. It's frustrating to engage in these debates, particularly if your partner in debate takes a position such as "Let's not be so technical about this," when the subject matter is inherently technical.

Why is this so difficult? The short date folks want something that's simply impossible. It should be so easy to say "I'm sorry, I don't know how to get all the remaining work done in the time we have left." What makes such a simple statement so hard to say? Fear.

In my own case, I fear losing my job, or I fear being passed over for promotion, or being downgraded on a performance review. These are real fears of real consequences. And these consequences really happen to people. Some of them have happened to me. So to avoid these consequences, we say-yes.

But the fear stays with us, even after we say-yes, and it's compounded by the knowledge that we agreed to try to do what we know is truly impossible. The next time there's a crunch, we face the same dilemma, and we make the same choice. Impossible goal is piled on impossible goal, until we're carrying a heavy burden of guilt and obligation to meet impossible commitments. Is this a life you want for yourself? Wouldn't it be better to say-no? It never seems so, until after you say-yes. Next time you feel the urge to say-yes, remember that.

Why it's destructive to play the blame game

Often we confuse the responsibility for addressing a problem with the responsibility for creating it in the first place. In the confusion, we can sometimes come to believe that the people who created the problem are responsible for resolving it. If we do that, we can get into even deeper trouble, because it just isn't always true that the best people to resolve problems are the people who create them.

For example, let's suppose that I'm a project manager, and that I've made some inaccurate estimates that were used to compute a delivery date that we now understand we can't make. And let's suppose that Sales has committed to delivering the item to a key account. What now?

One possibility is that we can work 16-hour days, hoping to make the date. Another is that we can tell the customer that we made a mistake and that the product won't be ready on time. In the former approach, the project staff takes responsibility for solving the problem; in the latter, Sales takes some responsibility. Which approach is "right?"

There is no right. It depends. We can choose between two high-risk strategies. If we work long days, we could lose important people from the project team, and we could risk product quality, corporate liability, and harm to the customers. If we explain things to the customer, we could lose a customer. Tough call. But we make the decision on the basis of our assessment of the risks and benefits of each strategy, rather than on the basis of who is "to blame for this mess."

When an organization finds itself in a blame cycle, some people feel pressure to take responsibility for addressing a shared problem. When I agree to accept responsibility for resolving a shared problem, even when I feel that I contributed to creating the problem, I might be depriving the organization of better options for addressing the problem. Even though the other people involved might feel a sense of justice and relief when I say-yes, the organization might be making a significant error.

When I say-no to people who desperately want to hear "yes," they must join me in facing the problem that we have. It might be that the problem isn't one of our own making; it might even be that I helped make the problem. But it's important for everyone to understand something about problems — the owner of the problem owns the problem. The owner of a problem is responsible for addressing it, even if the problem's creator is somebody else. And in organizations, the owner is usually us.

Traps and pitfalls when we say-no

One reason we avoid saying-no might be that we've had some bad experiences with it. As with most things we try to do, we can learn to do them better. So let's look at some of the traps and pitfalls that you might encounter as a no-sayer.

The cavalier "no"

Perhaps the most destructive way to say-no is to simply deliver the "no" without regard to its effect on your partners in the discussion. To appear not to care about the consequences of your "no" — or worse, to actually not care — almost certainly alerts your partners to a threat and could motivate them to attack, blame, or engage in other destructive tactics.

To avoid this, as you deliver your "no," take care to communicate that you do care about the consequences, that you're still on the team, and that you're highly motivated to find another way. Communicate clearly that your "no" merely means that you can't find a way to do what you've been asked to do, and that it's very likely impossible. Communicate clearly that you believe another way can be found, and that you're ready to help find it.

I told you so

When you've predicted the current problem, it's very tempting to remind your discussion partner of that fact. For example, you might feel the urge to say, "I don't believe we have the resources to make that date now, any more than I believed we had the resources to make the original date six months ago."

Avoid this temptation. Even though it seems to you to be a strong argument that buttresses your credibility, it usually forces your partner in conflict to dig in, heightening the conflict, and making it more personal. Reminding people of your past successful predictions, or their past unsuccessful ones, almost always deepens divisions. Stick to the here and now.

Putting the punch line last

A great formula for jokes, but exactly the wrong thing for saying-no. When you say-no, put the "no" up front. Compare these two nos:

• I really would like to help out, but we don't have the resources we would need, and there probably isn't enough time, so I'm afraid we can't help with that approach.
• I can't help with that approach and I'd like to explain the problems I see. We can't commit the resources it needs, because we just don't have them. Even if we did have the resources, I don't think we have enough time.

When you put the punch line last, everything leading up to it sounds evasive and defensive. While the listeners wait for the punch line, they're working on responses to your excuses. They might not even hear your punch line if they're too distracted with constructing their own replies.

When you put the punch line first, you increase the probability that people will hear it. And when you follow it with an immediate offer of an explanation of your problem, you have a good chance of moving the discussion away from confrontation and toward problem-solving.

I'm not to blame — they are

If you've convinced yourself to say-no, but you still feel some fear, you might be tempted to make it easier on yourself by adding a blame statement as self-protection. For example, you might say "I don't believe Release 2.0 can make that date anymore. Perhaps we could have done it if the firmware team weren't still working on the problems in Release 1.0, but as things are, it's just not possible."

Playing the blame game rarely works. Even if you succeed in distracting people from the real problem — the thing you're saying-no about — they're distracted. They can't focus on the real problem because you've distracted them. To address the problem, everyone must focus on it, and blaming prevents that.

A better approach: be more direct, stick to the facts. You might say "I don't believe Release 2.0 can make that date anymore. We just don't have enough firmware folks to get the job done in time." When people ask why there aren't enough, you (or someone else) can explain what they're all doing. This approach sticks to the facts and avoids blame. It leads the group into solving a resource allocation problem.

Some honest ways to say-no directly

Saying-no well, and feeling good about it, starts from the inside. To feel good about the no, start by feeling good about yourself. Then adding the no is a small step. You're saying-no with the knowledge that you can deal with what comes. You're just stating the truth as you see it. To help you focus on this centered approach, use "I" (or possibly "we" if you're speaking for a team) statements as you say-no.

As you practice, you'll find your own ways to say-no. But here are a few to get you started.

I don't know how to do that.

If someone has asked you to do something, and you honestly don't see how you can get it done, say so. It's better to let them know now than it is to have them discover it later, after you led them to believe that you could do it. If everyone knows your limitations, you can get the help you need to get the job done. Remember, your limitations aren't just yours. If you don't know how to get something done, there's an excellent chance that nobody does.

I don't know how to do that within the constraints we have now. Could you help me find a way to adjust the constraints?

This is a general formula that's probably more useful as a formula than an actual way of saying-no. It's easy to generate more specific examples of this formula:

I can't do that by the time we need it. Could you help me adjust some priorities?

This one is especially handy if you have to say-no because you're overbooked. Another way to say this one is, "Sure, I can do that, but it would have to be instead of something else that's less important." Now the two of you can begin some joint problem solving about priorities. That's a very good place to be.

I don't know how to meet that date with the schedule we've already accepted from our supplier. Can you think of a way to get those components from them any earlier?

Now you've moved the discussion towards team problem solving of a critical-path schedule issue. Perhaps someone in the room can work this issue better than you can.

I don't know how we can meet that date. What would happen if we were a week late?

In this example, you're moving the discussion to a question of the target date. In most cases, a one-week delay is OK, so this is actually an exploration of the boundary of "OK."

I don't know how to stay within schedule and budget if we change the requirements at this late date. If we were to add this capability in a later revision, what could we do to keep the customer satisfied in the meantime?

Typically, the real issue for many in Sales/Marketing is customer satisfaction. You're more likely to be successful in problem solving if you can move the team to problem solving of the real issue.

We could do that. It would require more resources, and it would take longer, but we could do it.

This approach is "can-do." The risk, of course, is that the response might be "well, then do it, but we can't spare any more time or resources." But if you trust your audience to take you at your word, to understand that you really do need more time or resources, then this is a good option.

It's unlikely that we could get it done. It's possible, but I'd estimate that the probability is under 10%.

Project management is inherently uncertain. This is especially true of complex projects. Even if you're certain that you cannot make a date, or that you cannot include a feature and still make the date, you can't be 100% certain. Use this. When you deliver your "no," deliver it as a probability — a low probability. This approach is actually more correct than simply saying "We can't do it," because it gives your estimate of the chances of success.

There's a problem with this approach — you might be dealing with someone who won't accept probability estimates. Some people might say, "Don't give me those probabilities — can you do it or can't you?" If that happens, then you know that you're dealing with someone who isn't plugged into Reality. Anyone who expects a manager of a large, complex project to know anything for certain — 100% certain — is in Fantasy Land. You might have to avoid this approach, at least until they retire, or the project ends, or you can transfer or find another job.

Where to go from here

Observe the people around you

The people around you face many of the same situations you do. Once in a while, you'll have a chance to watch someone choose between saying-yes and saying-no. When it happens, enter it in your say-no journal. You might learn a new way to say-no, or find an example of saying-yes. Track the example over the months to see how well it works out.

Observe yourself

You might surprise yourself. It might happen that you find a new way to say-no just by getting through life. When you find a new way to say-no, don't let it get away. Add it to your say-no tool kit.

Form a say-no circle

You might know other project managers who face these same issues. Perhaps they work at your company, but perhaps they work somewhere else. Through email or telephone, keep in touch — exchange saying-no and saying-yes stories. Learn from the experiences of everyone in your say-no circle.

Are you a project sponsor? Recognize those who say-no.

If you're a sponsor for a project, and any of your project managers says-no, recognize them: "I'm really grateful for your honesty. I don't know how we could have gotten through this if we didn't know about the problem." Say this publicly. The most important raw material for sane project management is Truth. If you want more Truth, honor those who deliver Truth.

Make copies of this essay

You've read this far, so I'm guessing you found this essay useful. If you know of others who could benefit from reading it, send them the URL, or make printed copies and give them away. If you're expecting a confrontation on a project soon, and you think you'll want to say-no, let the others who will be in that conference room with you read this first.

  Top

References

McLendon 1996

McLendon, Jean and Gerald M. Weinberg, "Beyond Blaming: Congruence in Large Systems Development Projects," IEEE Software, July 1996, pp.33-42.

Ramis 1993

Ramis, Harold, director. Groundhog Day. Columbia/Tristar Pictures, 1993. Order from Amazon.com

Satir 1991

Satir, Virginia, John Banmen, Jane Gerber, and Maria Gomori. The Satir Model, Family Therapy and Beyond. Palo Alto, CA: Science & Behavior Books, 1991. Order from Amazon.com

WGBH/Frontline 1999

Give War a Chance. WGBH Frontline, 1999.

Contact me

Do you sense that people in your organization might be saying-yes when they really want to say-no? I can do a one day workshop (or a 90-minute interactive talk and demonstration) on the problems of saying-yes and the advantages of saying-no.

Contact me to discuss your specific situation, by email at rbrenIyeJIiAfnGdKlUXrner@ChacsxirZwZlENmHUNHioCanyon.com or by telephone at (650) 787-6475, or toll-free at (866) 378-5470 in the continental US.

Are you a writer, editor or publisher on deadline? Are you looking for an article that will get people talking and get compliments flying your way? You can have 500-1000 words in your inbox in one hour. License any article from this Web site. More info