Questions to Ask Stakeholders
Twenty questions for interviewing a stakeholder early in a project: what they want, how they are measured, who signs off, and where they expect trouble. Written for project managers, consultants and product leads running discovery conversations.
The questions
Open any question for the note
How would you describe this project in your own words?
Why ask it
Opening here catches the most expensive problem early: a gap between the brief you were handed and what this person thinks they are getting. Listen for whether they describe an outcome or a deliverable. Someone who can only name the artifact, a new dashboard, a new portal, usually has not decided yet what it is for.
What made this a priority now rather than a year ago?
Why ask it
Projects rarely become urgent on their own. The answer is usually a specific event: an audit, a lost account, a new executive, a competitor's release. That event is what will still define success in six months. If the only answer is that leadership asked for it, nobody is feeling pain yet, and sponsorship will be thin when the work gets hard.
What will you be able to do once this is done that you cannot do today?
Why ask it
Pushes past feature lists toward capability, which is the level at which stakeholders actually disagree with each other. It also hands you a sentence in their own words that you can reuse in status updates and scope arguments for the rest of the project.
Who else on your side will feel the effects of this, and how?
Why ask it
Stakeholders routinely speak on behalf of people they have never asked. If they cannot name the affected teams or describe the effect in concrete terms, you have located a group who will first hear about the project at rollout, which is where resistance comes from.
How will you personally be judged on whether this went well?
Why ask it
Stated goals and personal incentives are not always the same thing. A stakeholder whose review rides on a launch date will trade scope for time; one who owns an error rate or a compliance metric will do the reverse. Once you know which, you can predict most of their future decisions.
Walk me through how this works today when it goes smoothly.
Why ask it
Asking for the good version first gets you a clean baseline and signals that you are not there to hunt for failures. Watch the hesitation: a sponsor who cannot narrate their own process step by step is describing the process they believe exists rather than the one their staff runs.
And what does a bad day look like?
Why ask it
Requirements live in the bad day: the private spreadsheet, the manual re-entry, the call someone makes to a friend in another department to unblock things. None of it appears in a written brief, because everyone involved stopped noticing it years ago.
What has already been tried here, and why did it stop?
Why ask it
Prior attempts are the cheapest research available to you. The part that matters is the reason it stopped: budget, a departure, a technical wall, or quiet refusal by the people meant to use it. If that reason has not changed, your project will meet it too.
If we could only deliver one part of this, which part?
Why ask it
Forces a ranking they have probably been avoiding. Refusal to choose is itself useful information, because it means the trade-off will get made later by you, under time pressure, without them. Worth saying that out loud while the room is still calm.
What change here would count as a step backwards, even if everything else improved?
Why ask it
Inverting the goals question surfaces constraints nobody thought to write down: a report a regulator expects in a fixed format, a screen the night shift depends on, an approval step that exists for a legal reason. Far cheaper to hear now than during acceptance testing.
Which numbers do you already report upward, and will any of them move because of this?
Why ask it
The metrics someone already reports to their own boss are the ones they will genuinely be held to. Look for the gap: if nothing on their existing report will visibly change, either the value of this work is invisible to the people funding it or you are measuring the wrong thing.
Who has to sign off before this is real, and what do they need to see?
Why ask it
Separates opinion from authority. Plenty of stakeholders present themselves as the decision maker because it is simpler than explaining the committee. Asking what the approver needs to see also tells you the format of the document you will eventually have to produce.
Realistically, how much of your own time can you give this in a normal week?
Why ask it
An honest small number is worth more than enthusiasm. Under an hour a week means you should plan for written decisions and asynchronous approvals rather than workshops, and it means agreeing now on what happens to the schedule when a decision has to wait.
When something needs a decision within a day, how do I reach you?
Why ask it
The useful part of this answer is the fallback: who can decide while they are travelling or on leave. Push for a name rather than a reassurance. Projects lose weeks in the gap between a question being asked and anyone feeling entitled to answer it.
When your team and another department disagree about scope, how does that usually get settled?
Why ask it
Cross-department disagreement is the most common way scope grows without anyone deciding to grow it. If they name a person or forum, you have found the real arbiter. If the answer is that people work it out between themselves, expect to be the one doing the working out.
What are people on your team saying about this project when you are not in the room?
Why ask it
Shifts altitude from their view to their staff's. Discomfort here often means the project was announced rather than discussed, which predicts a rollout where users treat the change as something being done to them. Their guess is also a reasonable proxy for adoption risk.
Is there a date behind the date, something that genuinely cannot move?
Why ask it
Most stated deadlines have padding, and a few are anchored to something immovable: a fiscal close, a contract expiry, a regulatory filing, a conference where someone has promised a demo. Knowing which kind you have tells you whether time or scope is the variable you get to negotiate.
What would make you want to stop this halfway through?
Why ask it
Asks for their abandonment conditions before there is any reason to panic. The answer puts numbers on their tolerance for delay and overspend, and a stakeholder who has never once considered stopping has not thought seriously about risk at all.
Where do you think we are most likely to get this wrong?
Why ask it
Invites criticism of the plan rather than of you, and people volunteer doubts about plans far more readily. Whatever they name belongs in your risk log whether or not you agree with it, because you will hear it again the first time something slips.
What have I not asked about that you expected me to?
Why ask it
Hands them the agenda at the end, when they have the full shape of your thinking. The answers tend to be small and concrete: a person you should have met, a system nobody mentioned, a past incident that still colours how their team reacts. Omissions are easy to point out once the pattern of your questions is visible.
Running a stakeholder interview
Practical guidance for the conversation itself
Before you sit down
- Interview one stakeholder at a time where you can. In a group, the most senior person's version of the goal becomes everyone's version within about five minutes.
- Say up front how long you need and what happens to their answers. People are more candid about problems when they know whether the notes go in a shared document.
- Read what already exists first, the business case, last year's attempt, the support tickets, so your questions test the written story rather than repeating it back.
- Bring no more than eight questions to the room. Twenty is a list to choose from, not a script, and the value comes from following up rather than getting through it.
Reading the answers
Ask for the last time, not the usual case
"How often does that happen?" invites a guess. "When did it last happen, and what did you do?" produces a story with dates, names and workarounds in it. Use the specific version whenever an answer starts sounding like policy.
Watch for the passive voice
When someone says a decision was made or the requirement was agreed, they are hiding an actor, usually because they disagreed with it or do not know who decided. Ask who, gently, and note the answer.
Separate wants from constraints
Almost everything a stakeholder says is one or the other, and only constraints are non-negotiable. Tag each note as you write it. Your scope conversations later will be about the wants, and it saves relitigating what was never optional.
Notice who they never mention
Across several interviews, the teams nobody names are the ones with no advocate: often operations, support, or whoever maintains the thing after handover. Their absence from the conversation is a finding in itself.
Common pitfalls
Taking the first stated goal as the goal
The opening answer is usually the version rehearsed for a steering committee. The real objective tends to appear twenty minutes later, attached to a specific frustration. Keep going after you have something that sounds quotable.
Letting the interview become a demo
If you spend the time explaining your approach, you learn nothing and they feel sold to. Hold your solution until you have their problem in their words, even when they ask what you are planning.
Confirming rather than testing
Leading questions get agreement, not information. "So reporting is the main pain point?" will be answered yes by most people in most meetings. Ask what the main pain point is and let them fill it in.
Skipping the boring stakeholders
The person with no strong opinion and no budget is often the one who can quietly block go-live, because they run the process the change lands on. Interview them anyway, and early.
After the conversation
Send back what you heard, not what you concluded
Within a day, send a short summary in their language: goals, constraints, decisions they own, and anything you promised to find out. Corrections arrive fast when someone reads their own words slightly wrong, and almost never when they read your analysis.
Log the disagreements rather than smoothing them
Where two stakeholders want incompatible things, write both positions down with names attached and take the conflict to whoever can settle it. Averaging the two into a vague requirement hides the problem until build.
Record the quotes you will need later
Keep the exact sentence where someone described the priority, the immovable date, or the thing they would consider a step backwards. When scope is contested six months on, a direct quote ends the argument faster than a summary does.