The power of "no" in project management

Today I want to talk about the allure of yes, the illusion of yes, the discipline of no, the need for standards, a useful compromise, and why you need a no man.

The allure of “yes.”
* “Yes” is the pleasure of possibility. It can be exhilarating. It opens up new opportunities.
* People who say yes are regarded as “team players,” which looks good on a review.
* People like to hear yes, because it affirms them.
* Yes counteracts the fear of missing out.
* When you say yes you put yourself in a position to learn and do new things.

The illusion of “yes.”
* Accommodating requests seems like progress. Lots of things may be getting done.
* Saying yes is easy, but doing what you promised may be heard. I saw a funny quote on LinkedIn that’s relevant. “We do not do these things because they are easy, but because we thought they would be easy.”
* Saying yes may imply a competency or ability you don’t really have.

The discipline of “no.”

Think about that for a minute. Who likes “discipline”? Discipline is sweat, cold showers, and boring food. Discipline is something imposed on me that limits me. It’s not fun.

But “no” does some good things.
* Keeps you on focus.
* Limits mission creep.
* Keeps resources under control.
* Keeps things predictable, like workflow.
* Sets boundaries.
* Allows you to stick to your principles.
* Is better for timelines.
* Eliminates short-term variations.
* Allows experts to make decisions, because you have to have some credibility to say no.
* It weeds out bad ideas (which are most ideas). It’s better for your co-worker to say no than your customer.

“Yes” and “no” require standards.

Saying yes to one thing means saying no to something else, and vice versa. Yes and no decisions have to be made in the context of a general project or business framework. You have to have a mission, goals, timelines, etc. “No” helps you stick to those principles.

“Yes, and” is good for creativity, as I explained in a previous episode. “No” is a tool for focus.

“No, but” can be a useful compromise.

Sometimes I say there are two kinds of programmers. “Yes” programmers and “no” programmers.

The “yes” programmer wants to please, but then he finds out it’s not that easy. The “no” programmer wants to keep things within the limited parameters that he can be sure of – that he knows will work.

“No, but” can be a good path forward. Explain why you can’t say yes, based on appeals to the project framework, or timelines, or resource limitations, but listen to the underlying vision and try to find something like it that does fit.

You need a no man.

Many job descriptions highlight the need for a “team player,” but as we’ve seen, that can mean a “yes man” who will happily hop down every rabbit trail and you’ll end up doing lots of stuff that doesn’t contribute to your goals.

You need some skeptics on your staff. You need the difficult person who calls things back to reality – who remembers budgets and timelines. You need somebody who will say “no.”