fruit vegetable isolated on white

The trick is you don’t say no! At least, you don’t shut them down right away – remember you need to maintain a good relationship with these people to ensure your project is successful. In this post I’ll first describe the situation and explore what could go wrong, then describe a simple 4 step process for saying no, while at the same time building a better, more trusting relationship with your stakeholders.

The scenario

You’re an inexperienced Project Manager and your team of BAs has just finished up on their requirements for Project X phase 1 and are in the process of validating those requirements. They’re almost done, when the Chief of Marketing says she needs Feature Z to be part of the solution. Now, feature Z immediately jumps out as something requiring a lot of additional work that wasn’t part of your plan – analysis and design work, engaging more delivery teams, extra build work, additional testing, etc. Basically, building Feature Z would result in no chance of on-time project delivery and would detract from the main business objectives.

But the Chief of Marketing insists on Feature Z. It’s a must have! This would break your project but you can’t say no right away because you need the chief to be on board. So, you could try explaining the impacts on project scope, timeline, budget, etc. This might work if you already have a great relationship with a lot of experience working together but if that’s not the case, here are a few steps that will help build that relationship and also achieve the best outcome for your project.

Step 1 – Do your research

Understand and clarify the problem – talk to your team, other people you know in the business and any BAU support teams who may have information. There may be another group within the organisation who is tackling the same problem. There may even be an existing solution that can be utilised to solve your stakeholder’s problem.

Do some preliminary investigation into the effort required to implement Feature Z – you need to know what you’re talking about before you engage the stakeholder for steps 2, 3 and 4 below. Otherwise you could run into issues if they press you for details or they may turn out to be more technical that you think and already have some understanding of what’s required.

Identify an alternative and perform some deeper investigation into how this will work and that it will meet the needs of you stakeholder. This alternative may be a non-IT solution such as a change in business process or standard operating procedure. The alternative may be a solution with less IT build, or a tactical solution that will address the immediate need until project ABC-Next comes to implement the strategic solution to the problem.

This information will prepare you for steps 2, 3 and 4.

Step 2 – Make them feel heard and understood

The most important part is to make sure your stakeholder feels that their voice has been heard and the request understood. Often this will be received as well, if not better, than actually giving them what they’ve asked for. Start off by saying that you hear their request, understand the challenges they face and you’ve been investigating solutions.

Step 3 – Say, we could do something even better (your alternative)

If your stakeholder has asked for a Zebra and you offer them an Apple… well that won’t go down very well at all. Your stakeholder will think you haven’t been listening at all! So you can’t offer something completely different. However, say your stakeholder asked for a Red Delicious apple and you have a Gala apple, this is where you promote all the benefits of your Gala apple instead of talking about the Red Delicious that they wanted.

So, your stakeholder is now feeling happy that they have been listened to and that you want to help them meet their challenges; you are ready to propose your alternative. Start by saying that you could build Feature Y into the solution. The benefits of building Feature Y are that:

  • It would help your stakeholders meet their challenges; and,
  • It could be implemented in a much shorter timeframe, or even delivered ahead of the main project go-live date; and,
  • It would be much less costly to build and maintain; and,
  • It would provide the must have functionality of Feature Z without the extras that won’t be used; also
  • It would be a better use of the organisation’s resources in-line with the organisational strategy and technology roadmap.

Step 4 – If the alternative is rejected, prioritise in the bigger picture

If your stakeholder has accepted your alternative then off you go! However if they’ve rejected the alternative and are insisting on the original request without much compromise, then it’s time to help them understand how it fits into the big picture context. Explain that the team is currently working on high priority items that tie back to the business objectives of the project and you’ll need to put the new request in the pipeline to be worked on during phase 2 or when the team has capacity.

If your stakeholder wants a bit more detail describe the main features in scope for the project, how they trace back to the business objectives of the project and the business benefits they provide. Describe your team’s capacity for the short-medium term. Help your stakeholder understand that the new request isn’t directly related to the business objectives, or will not be used often in practice (statistics may be helpful to know in this case). Therefore it needs to be prioritised further down the list so that it doesn’t un-necessarily detract from meeting the main business objectives of the project.

Whether your stakeholder has accepted or rejected the alternative, they’ve seen the reasoning behind your recommendations, know that you are considering their point of view and that you are working to help them meet their challenges – this helps you build a solid reputation and accrue trust with your stakeholder.

Notice that you never outright shut down the requests of your major stakeholders

I’m reminded of the TV series The Goodwife there is a scene where the campaign adviser says “you never say no! You say ‘all possibilities are open to me and I’ll decide within 48 hours’. Then you do whatever you want to do”.

While we can’t really “do whatever you want to do” in the project world, we do need to control scope for our projects to ensure successful implementation and deliver on the business objectives. We also need to maintain a good relationship with our stakeholders. To do this, we need to make the stakeholders feel heard, offer an alternative and promote the positives of the alternative, and if the alternative is rejected, prioritise the request in the bigger picture context.

What are your most productive ways of saying ‘no’?