By Anthony Soltero in career —

How to Get Out of Stakeholder Requests

Get them to say "no" for you

I got my Analytics team out of 2 stakeholder requests.

I didn't even say "no".

I let the stakeholders talk themselves out of it.

It was pretty easy and I felt no pressure.

This is how I did it.

The situation

A stakeholder submitted two requests to my team.

The requirements were well written and thorough. At face value, the requests felt valid, but then it came time to make two decisions:

  1. Who would work on the requests
  2. When would the work get prioritized

To make those decisions, we reviewed the requirements to understand the scope of the work.

That's when we started getting suspicious.

Review the request and requirements

You can't push back on a request if you don't know what's required.

When you don't review requirements before working, you get deep in the weeds before realizing that you shouldn't have started the work at all. We dodged that problem because we reviewed the request.

When my analyst reviewed the requirements, her spidey senses tingled. It seemed like we didn't need to create anything new. We had a hunch that functionality existed elsewhere.

Step 1: Review the request and requirements to determine if a solution already exists with available assets or if the stakeholder can self-serve in another way.

If you're suspicious, flag it.

Flag the request as suspect

In this situation, my analyst flagged the request as redundant.

Don't make this a complicated process. Whoever is reviewing the request needs to raise their hand and let the team know that the request is suspect. Then you decide who's going to discuss it with the stakeholder. In this case it was me.

Step 2: The reviewer "flags" the request as one that needs to be re-reviewed with the stakeholder.

Once we've flagged the request, it's time to bring the stakeholder in.

Meet with stakeholders

This is where we say "no" without saying "no".

We set up a meeting with the stakeholder and:

  • let it be known that we understood the request
  • demo'd the existing functionality
  • explained the new solution would require significant, additional work

After going through the details, our stakeholder told us:

"that actually gives us what we need...that complex solution isn't worth it."

We didn't have to say "no", the stakeholder came to these conclusions themselves.

Step 3: Meet with your stakeholder to review the request and make your case as to why it may not be needed. Likely, the stakeholder will rescind their request.

It doesn't always happen this way. The stakeholder doesn't always volunteer to redact their request.

In those situations, one question can cut through the noise.

A question as a dagger

If your stakeholder doesn't rescind their request, ask this one question:

"knowing the other functionality available, do you still need this?"

Then pause.

Wait.

Don't interject.

Don't say another word until they answer. Force them to ponder if they actually need what they asked for, considering all the new information they have.

People want to look smart and it's not smart to ask for something you already have.

So when you ask, "do you still need this?", the smart person will say, "no".

Your stakeholders want to be smart.

Step 4: Get the stakeholder to rescind their own request.

You didn't have to say "no" and you didn't have to be the bad guy.

You helped provide clarity and allowed your stakeholder to make the decision.

That's real leadership.