On Tuesdays I write about the top voted question on Ask Berkun (see the lovely archive). This week’s question came from Sam K. [via email]:

I lead a team in a very political organization. It’s hard to make things stick. I want to focus my team but I struggle with how to defend priorities as my boss and her peers often change their minds and commit to more things than we can possibly do. Any advice?

If you can’t say no, you can’t truly say yes either. The reason for this is if you’re always saying yes you’re giving away the limited resources you have to tasks that are not the most important things to do. This is like like having a savings account for retirement where you are always making withdrawals to buy what tempting things you happen to see: it’s not really a savings account anymore. And it follows that a project that says yes to fun, but low priority requests, isn’t really a project anymore: it’s just a collection of random bits of work. Without the authority to say no, it’s nearly impossible to do well at any kind of project.

Sadly some people in management positions struggle with this basic notion (and I fear for the state of their retirement accounts). They want to please everyone, and in trying to please everyone they likely end up failing everyone, as the project work that truly needs to be done never gets completed.

Master the many ways to say no

The reason why every project needs clear priorities is it provides a tool for everyone about what to spend resources on. It tells you what kinds of ideas or requests what to say yes and no to. While it can be hard work to get all the leaders to agree to one list of priorities, it’s essential to getting you the leverage needed to say no (and to manage a project well). Once the agreed priorities are in place, that priority list becomes a kind of contract. And you should confirm with the leaders that your job is to defend the priorities, even against requests they might have in the future.

This means when a new idea or request comes in, you simply check the priorities list: if it fits, you can consider it. If it doesn’t you need to say No. There are many different ways to say no and you should master them. You can say it with an explanation, a smile, an argument, a counterproposal, an offering of a glass a wine, or a reminder that you are not just saying no to them, but that you are defending the very priorities that they agreed to previously.

To prepare yourself for this, you need to know all of the different flavors that the word no comes in:

• No, unless this fits our priorities (which it probably doesn’t). This is the most common flavor of no that wise leaders use. It re-establishes that the priorities drive decisions. Early on in a project this often leads to a rehashing of why the priorities are the priorities, but that’s a healthy discussion. They may suggest a way to refine or clarify how the priorities are written. But the later you are into a healthy project, the firmer you should stand.
• No, only if we have time. If you keep your priorities lean, as you should, there will always be many very good ideas that didn’t make the cut. Express this as a relative decision: the idea in question might be good, but not good enough relative to the other work and the project priorities. If the item is on the priority 2 list, convey that it’s possible it will be done if there is extra time, but that no one should assume it will happen.
• No, only if you make <insert impossible thing here> happen. Sometimes, you can redirect a request back on to the person who made it. If your VP asks you to add support for a new feature, tell him you can do it only if he cuts one of his other current priority 1 requests. This shifts the point of contention away from you, and toward a tangible, though probably unattainable, situation. This can also be done for political or approval issues: “If you can convince Sally that this is a good idea, I’ll consider it.” As you may know that Sally is unlikely to say yes, which sends the requester towards a dead end: but it’s a dead end that leads away from you.
• No. Next release. Assuming you are working on a project with more updates (e.g. a website or software project) or sprints, offer to reconsider the request for the next release. This should probably happen anyway for all priority 2 items. This is often called postponement or punting.
• No. Never. Ever. Really. Some requests are so fundamentally out of line with the long-term goals that the hammer should come down. Cut the cord now and save yourself the time of answering the same request again later. Sometimes it’s worth the effort to explain why (so that they’ll be more informed next time). Example: “No, Fred. Our mobile app will never support the Esperanto language. Never. Ever. Because no one uses it and never will.”
• Another approach that Zac Cohn suggests is using customer validation. “Very cool idea. Once you talk to some customers who express a need for that, come back and we can explore the next steps in validating that idea. Once it’s fully validated, we can determine the appropriate place in the roadmap.”

On the day you are assigned a project, you should clarify with your boss that you need their support in saying no to people. It needs to be established across the organization that in most cases they’ll get the same answer from your boss, as they get from you. You can also familiarize your coworkers with this list of ways  you are likely to say no, perhaps even keeping it up on your whiteboard, prepping them for the likely conversations you will have in the future.

---

This is based on an excerpt from the bestselling project management book,  Making Things Happen. Other classic chapters include:

• The truth about schedules
• How to figure out what to do
• What to do when things go wrong
• How not to annoy people
• Making things happen (the titular chapter)
• Power and politics
• Buy the bestselling book here