How to Make Things Happen « Scott Berkun - The Diigo Meta page

• 01 May 12
  

  Mike Schoultz
• 23 Apr 12
  

  Kenji Rikitake

  productivity innovation creativity

• 17 Apr 12
  

  Colin Brosnan

  projectmanagement do doing todo

• 

  Todd Suomela

  project-management projects management business gtd

  • Master the many ways to say no

     

    Sometimes, you will need to say no in direct response to a feature request. Other times, you’ll need to interject yourself into a conversation or meeting, identify the conflict with priorities you’ve overheard, and effectively say no to whatever was being discussed. To prepare yourself for this, you need to know all of the different flavors that the word no comes in:

     
     
    • No, this doesn’t fit our priorities. If it is early in the project, you should make the argument for why the current priorities are good, but hear people out on why other priorities might make more sense. They might have good ideas or need clarity on the goals. But do force the discussion to be relative to the project priorities, and not the abstract value of a feature or bug fix request. If it is late in the project, you can tell them they missed the boat. Even if the priorities suck, they’re not going to change on the basis of one feature idea. The later you are, the more severe the strategy failure needs to be to justify goal adjustments.
     
    • No, only if we have time. If you keep your priorities lean, 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, but that no one should bet the farm assuming it will happen.
     
    • No, only if you make <insert impossible thing here> happen. Sometimes, you can redirect a request back onto 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.” However, this can backfire. (What if he does convince Sally? Or worse, realizes you’re sending him on a wild goose chase?)
     
    • No. Next release. Assuming you are working on a web site or software project that will have more updates, 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 has to 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. The web site search engine will never support the Esperanto language. Never. Ever.”

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.