Saying "No": A Tutorial for Project Managers
by Rick Brenner
Have you ever thought "Why did I ever agree to do that?"? Have you ever wished that you
knew better how to say no — or even how to avoid volunteering to do something — without
suffering undue consequences? Giving a firm and clear No can feel good if it comes from a
place of high self-esteem.
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:
||This means "to agree to do something when
you know in your heart that it's a long-shot at best, and probably
||This means "to decline to do something,
and to tell it that way, because you know in your heart that
it's a long-shot at best, and probably impossible anyway."
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 VP's (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
- 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
- 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 93] — it happens again and
- 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
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
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
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
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
- 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
- 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.
Adm. Leighton Smith and President Clinton. One example of applying
one of these formulas is a story told
by Adm. Leighton Smith, Jr. (ret.)
in the documentary Give War a Chance
]. When Adm. Smith was commander of IFOR in Bosnia, President
Clinton visited — with Secretary of State Madeleine Albright
and a Congressional delegation. Smith was a "minimalist"
in the debate about the role of NATO military elements in Bosnia,
opposing policies that called for widening IFOR's mission there.
Pressures from the "maximalists," who sought a wider
role for IFOR, had been building, and at one point in the visit,
the President asked the Admiral, in front of the Secretary and
the members of Congress, if IFOR could guard the mass grave sites
in Bosnia. Such a responsibility would have widened IFOR's role
considerably, and Adm. Smith thought it was a dangerous idea.
He replied, "Mr. President, we can do anything you ask of
us, but there's a price to pay, and, in this case, it means a
lot more forces." Later, the President privately thanked
the Admiral for his answer, calling it "perfect," and
saying, "they needed to hear that from you." Photo courtesy Frontline.
As you practice, you'll find your own ways to say-no. But here are a few to get you
- 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
- 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
- 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
- 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.
- McLendon 96
- McLendon, Jean and Gerald M. Weinberg, "Beyond Blaming: Congruence in Large Systems
Development Projects," IEEE Software, July 1996, pp.33-42.
- Ramis 93
- Ramis, Harold, director. Ground Hog Day. Columbia/Tristar Pictures, 1993.
Order from Amazon.com
- Satir 91
- 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.
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 rbrenner@ChacoCanyon.com or by telephone at (617) 491-6289, or toll-free at (866) 378-5470 in the continental US.
Reprinting this article
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 words in your inbox in one hour. License any article from this Web site. More info