Saying “no” is hard for everyone.
“If I say “no”, they will think I’m not a team player.”
“If I say “no”, they will think I’m not committed to the product’s (company’s) success.”
“If I say “no”, they will blame me for the other project’s failure (because I wouldn’t let my resource spend some time helping it).”
“If I say “no”, they will be disappointed in me.”
“If I say “no”, they will say that I’m inflexible.”
“If I say “no”, they will say that my team isn’t willing to work hard.”
“If I say “no”, they will be mad at me.”
And no one likes people to be mad at them.
However, it’s critical for a Project Manager to understand when and how to say “no”.
Laying the groundwork for saying “no”, and the way you say “no” can help minimize or eliminate any bad feelings that follow.
All projects should begin with a Vision and Scope statement. The purpose of the “Vision” part is to describe the consensus on the purpose and goals of the project, its operating environment, and any assumptions made by stakeholders. The “Scope” part is usually a list of features, pre-requirements spec, along with expected phasing of features if everything isn’t to be delivered or developed all at once.
“Stakeholders” include you, the Project Manager, and it is here, in the Vision part, that you can document your assumptions regarding project schedule and resources. And likewise, the Scope should include a list of features that will not be developed or delivered (without getting too picky, but making sure that everyone understands).
Treat this as a contract between you and the project sponsor. Don’t let it get out of date. When the scope feature list evolves into the requirements document, update anything that contradicts your original agreement or assumptions, even if it’s just a note to replace the feature list with the one in the requirements document. Don’t let contradictions stand: otherwise the original agreement becomes useless and confusing. If you end up getting more resources or schedule to develop some of those features that were originally on your “not” list, update that list, along with the resources and schedule assumptions. The updates don’t have to be complicated: after all, the Vision and Scope statement isn’t that large.
It is this agreement, the Vision and Scope statement, along with the requirements document, which will back you up later when you need to say “no”. It will give you a way to say it nicely, professionally, and firmly. You can describe all the work and discussion that went into it, why it says what it says, and explain that your planning relied on the word of all its stakeholders. And that while you’d like to be a team player, and don’t want to be seen as a roadblock, there would have to be a discussion on your original assumptions (or on your constraints) in order to accommodate this change/addition/loss of resource, etc.
Your team will be relieved that you’re saying “no” on their behalf (because everyone hates to say “no”) Your sponsor will understand that there’s a right way and a wrong way to go about making changes to the plan (after all, change is inevitable). Don’t worry about saying “no” to the wrong thing, to something really, really important. If it’s truly critical, your project sponsor will figure out a way to work with you to allow it to happen through feature reprioritization, increased resources, or a longer schedule.
And you will have the respect of everyone.
Anita Wotiz
www.duckpondsoftware.com (see the Consulting tab)
Instructor, UCSC Extension, SEQ Program
Software Requirements Engineering and Management (next class starts Aug 5 2008)
Software Project Planning, Monitoring, and Management (next class Oct/Nov 2008)
