Questions to Ask Stakeholders
65 questions to ask stakeholders at the start of a project, grouped by what you are trying to find out: what they want, how the work runs today, what the result has to do and what is fixed, who decides and how they want to work with you, and where they expect trouble. Written for project managers, consultants and product leads running discovery conversations, and for anyone after business analyst questions to ask during requirements gathering: the Requirements group goes through steps, rules, exceptions, data and how each need will be tested. The last group is for the other chair: questions to ask as a stakeholder when a project team wants your time.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Goals
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 problem are we solving, and who has it today?
Why ask it
A problem with an owner can be visited: you can sit beside that person and watch it happen. If the answer goes straight to the solution, such as we need a new system, ask what goes wrong without one and who is on the receiving end.
What does success look like to you once this is finished?
Why ask it
Ask every stakeholder this and lay the answers side by side. The differences between them are your real scope risk, and they are far easier to settle in the first month than in the last. If the picture stays vague, ask what they would show a colleague to prove it had worked.
What made this a priority now rather than a year ago?
Why ask it
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 the pain yet, and sponsorship may be thin when the work gets hard.
What happens if we do nothing?
Why ask it
If the honest answer is that things carry on much as they are, expect to lose people and budget to whatever is more urgent, and plan for that now. A concrete cost, such as a contract that lapses or a backlog that keeps growing, is worth writing down as they say it. It is the argument you will need the day someone proposes pausing the work.
What will you be able to do once this is done that you cannot do today?
Why ask it
The answer moves the conversation from a feature list to a capability, which is the level where stakeholders tend to disagree with each other. Write the sentence down the way they say it. You can reuse it in status updates and scope arguments for the rest of the project.
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.
How will we measure whether this worked, and is that a number you already report?
Why ask it
A measure someone already reports to their own boss is one they will be held to. If the measure is new, ask who will collect it and who will read it, because a number with no reader tends to stop being collected once the project team has gone. If nothing they report today would move at all, the value of the work may be invisible to the people paying for it.
Where does this rank among everything your area has committed to this year?
Why ask it
A rank of fourth or fifth is still worth hearing, since it tells you how hard you can press for their attention. Ask which company goal the work is counted under as well. A project tied to a named goal tends to keep its people when budgets tighten, and one tied to nothing is easy to raid.
Have you seen this done somewhere else, well or badly, that I should look at?
Why ask it
Reference points save a lot of description, and the bad example is often the sharper one. Ask what specifically they admired. A stakeholder who says make it like theirs usually means one detail, the speed or the single screen, and not the whole thing.
Today
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.
What does a bad day with this process 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.
Who will use this every day, and when did you last watch one of them at work?
Why ask it
The second half separates knowledge from assumption without accusing anyone. If it has been a year or more, treat what they tell you about users as a hypothesis and ask for an introduction to someone who does the job.
What do you hear most often from customers or staff about the way this works now?
Why ask it
Complaints that reach a senior person have already been filtered, so you are hearing the ones loud enough to travel. Ask where they come in, whether a support queue, a survey or a corridor, and whether you can read the raw version yourself.
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.
Which systems, reports or teams does this touch that I will not find in any document?
Why ask it
Listen for the export someone runs by hand each month and the team that quietly depends on it. Your stakeholder may know only one or two of these, so ask who would know the rest and add that person to your interview list.
Where does the information you rely on for this come from, and how far do you trust it?
Why ask it
Distrust of the data explains a lot of odd behaviour: duplicate records kept on the side, figures rechecked by phone before they go into a report. If they do not trust the source now, a new tool built on that source will inherit the doubt.
Requirements
What does someone need to be able to do with this, from the first step to the last?
Why ask it
A requirement stated as a task, such as approve a refund without leaving the customer's record, can be built and tested. One stated as a feature, such as a refunds module, cannot. When the answer comes as a list of features, pick one and ask who uses it and what they are trying to finish.
Where a person makes a judgement call in this process, what rule are they applying?
Why ask it
Business rules mostly live in people's heads: the amount above which a second signature is needed, the customer type that skips a step. Ask where each rule is written down, and if it is nowhere, put the question to two people separately. Different answers mean the rule has to be decided before it can be built.
Which cases do not follow the normal path, and how often does each come up?
Why ask it
The exception that turns up twice a year is the one nobody mentions, and it tends to surface against a deadline. Ask for the last real example of each instead of a description. Then decide together which are worth designing for and which can stay a manual step with a named owner.
Is that how it has to work, or how it has always worked?
Why ask it
Many requirements are a description of the old system with the word must in front. Asking where a step came from sorts the ones backed by a contract, a regulator or a customer promise from the ones backed by habit. Ask it with curiosity, because the person in front of you may have designed the step.
What information has to be recorded at each step, and who uses it afterwards?
Why ask it
Every field should have a reader. Going through the current form line by line tends to turn up a few that nobody downstream looks at, and one that somebody in another team cannot work without. That second kind is easy to drop by accident when a form is tidied up.
Which reports or figures do you need to get out of this, and what decision does each one feed?
Why ask it
Reporting needs are often left until the end, by which point the data to support them was never captured. Tie each report to a decision and a person. One that nobody can connect to a decision is a candidate for cutting, and saying so now is kinder than building it.
How many of these do you handle in an ordinary week, and how many in the busiest one?
Why ask it
Peaks, not averages, are what a process or a system has to survive. Ask where the figure comes from, since a number recalled from memory and a number pulled from a log can be far apart. If nobody knows, counting is a small job worth doing before any design starts.
How quickly does this have to respond, and how long could you manage if it were down?
Why ask it
Speed and availability are requirements too, and they are costly to add late. "Fast" and "always" cannot be built to, so ask in terms of their day: a customer waiting on the phone, a shift that starts at six. Then ask what the fallback is when it fails, because someone will have to run it.
How would we check, together, that this requirement has been met?
Why ask it
If nobody can describe the check, the requirement is not finished yet. Write the test in the stakeholder's own words beside the need it belongs to. It becomes the acceptance criterion, and it settles in advance most of what would otherwise be argued at sign-off.
What must be there on day one, and what would only be nice to have?
Why ask it
Expect the first pass to put nearly everything in the must column. Test each item by asking what they would do on day one without it: if there is a tolerable answer, it is a want.
If we could only deliver one part of this, which part?
Why ask it
This asks for a ranking they have probably been avoiding. A refusal to choose is useful too: it means the trade-off will be made later by you, under time pressure, without them. Say that out loud while the room is still calm.
What is definitely not part of this project?
Why ask it
Exclusions are rarely written down, because nobody likes saying no at the start, and an unwritten one is where a later argument begins. Offer two or three candidates yourself, the mobile version or the second region, and see which ones they defend.
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.
Of date, budget and scope, which one is truly fixed?
Why ask it
Everything is described as fixed until you ask people to rank the three. Ask for the order, not a yes or no, and write it down with the date of the meeting, because whoever ends up on the losing side may remember it differently.
When do you need this by, and what is driving that date?
Why ask it
Some deadlines have padding in them and some are anchored to something that cannot move: 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 thing you get to negotiate.
What budget has actually been approved, and who would have to agree to more?
Why ask it
The figure in the business case and the figure somebody has signed are often different. If your stakeholder does not hold the money, find out who does and how long a request for more usually takes, since that wait belongs in your plan.
Which rules do we have to work inside, such as legal, security, accessibility or procurement, and who checks each one?
Why ask it
What applies varies by country, industry and employer, so ask how it works here and do not rely on your last project. The name of the reviewer matters as much as the rule: ten minutes with them early is cheaper than a failed review in the final month.
Once the scope is agreed, how should a new request be handled?
Why ask it
New requests are certain, so the only open question is the route they take. Agree who can say yes, what gets traded out to make room, and where it is recorded. Without that, changes arrive as favours asked in corridors and nobody can say later when the scope grew.
People
What is your own role in this project, and what do you expect to be asked for?
Why ask it
Titles tell you little here. One sponsor expects to approve every screen while another wants a note once a month, and neither will say so unless asked. If the role they describe differs from the one on your stakeholder list, fix the list the same day.
Who has to sign off before this is real, and what do they need to see?
Why ask it
Opinion and authority are easy to confuse in a first meeting, and some stakeholders present themselves as the decision maker because it is simpler than explaining the committee. What the approver needs to see also tells you the format of the document you will eventually have to produce.
Who else should I talk to before I form a view?
Why ask it
The names show who this person respects and who they think holds the detail. Ask for an introduction and not only a name, because a cold request from a project team is easy to ignore. Note whether anyone junior, or anyone outside their own department, makes the list.
Who is likely to be against this, and why?
Why ask it
Opposition is rarely irrational. It is usually someone whose work gets harder, whose headcount is implicated, or who was overruled earlier. Asking a supporter to explain the opposing case gets you a fairer version than waiting to meet it in a steering meeting.
When your team and another department disagree about scope, how does that usually get settled?
Why ask it
Disagreement between departments is a common way for scope to grow without anyone deciding to grow it. If they name a person or a 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 do you think your team says about this project among themselves?
Why ask it
You are asking for a guess, and the guess is a fair early read on how the rollout will land. Discomfort here often means the project was announced and never discussed, and people who were only told tend to treat a change as something done to them. Ask whether you can hear it from one or two of them directly.
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.
How much of your team's time can I actually have, and when?
Why ask it
Get names, hours per week and what else those people are committed to. An expert who is promised to you but already fully booked elsewhere turns up later as a slipped date, and the slip gets blamed on the project team.
What do you need from me and my team that you have not always had from project teams?
Why ask it
Many stakeholders carry a grievance from an earlier project: surprises at the steering meeting, jargon, a team that vanished after launch. Hearing it shows you which habit will earn their trust, and it is usually a small thing to do differently.
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.
How often do you want an update, and in what form?
Why ask it
Match the format to how they read: a two-line message, a dashboard, ten minutes on a call. Someone who asks for a weekly report and never opens it should be moved to something shorter, so agree to look at the arrangement again after a month.
How do you want to hear about problems, and how early?
Why ask it
Preferences vary widely and are worth knowing before there is a problem: some want a call the day you suspect something, some want issues brought only with an option attached. Agree the threshold now so that raising a risk later is not itself treated as an escalation.
Risks
What worries you most about this project?
Why ask it
Leave a pause after asking. The first answer is usually the respectable worry, the timeline or the budget, and the second is the one they think about on the way home. Thank them for it and resist reassuring them straight away, or they will keep the next one to themselves.
Suppose it is a year from now and this has failed. What went wrong?
Why ask it
Treating the failure as already over makes it easier to criticise the plan, and the answer tends to come out as a story with a cause in it. Put whatever they name in your risk log whether or not you agree. You will hear it again the first time something slips.
What are we depending on that we do not control?
Why ask it
Vendors, another team's release, a data feed, a procurement cycle, an external approval. External dependencies fail differently from internal ones because you cannot escalate your way out of them, so each one needs a named owner and a date you have confirmed yourself.
What has to be true for this to work that we are currently assuming?
Why ask it
Assumptions never appear in a status report, yet an experienced stakeholder can usually list them when asked. The data is clean, the customers will switch, the other team will be finished by March: write each one down with the name of someone who can check it.
What would make you want to stop this halfway through?
Why ask it
Better asked now, while nobody has a reason to panic. The answer puts rough numbers on how much delay and overspend they will tolerate. If they have never thought about stopping, agree together what the warning signs would be, so the question is not new on the day it matters.
Whose daily work has to change for this to pay off, and have they been told?
Why ask it
The benefits in a business case often rest on somebody doing their job differently: entering data sooner, giving up a spreadsheet, trusting a number they did not produce. If your stakeholder cannot name those people, you have found the group who will first hear about the project at rollout. Telling them is a task, and it needs an owner.
What else is landing on the same people over the same months?
Why ask it
A reorganisation, a year-end close, another rollout or a busy season can sink a sound plan simply by using up the attention it needed. Ask for dates and put them on your timeline beside your own milestones.
What does the day after go-live look like?
Why ask it
Ask who answers the phone, who fixes defects, who trains the next intake, and whose budget pays for it. Support after handover is often still unassigned at kickoff, and it then gets negotiated in a hurry in the last weeks.
What have I not asked about that you expected me to?
Why ask it
Save this for the end, when they have seen the shape of your thinking and can spot what is missing from it. 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.
As a stakeholder
What is this meant to fix, and how will you know it has?
Why ask it
For the other chair: you are the stakeholder, and a project team has asked for your time. Start with the purpose in their words. A team that can name both the problem and the measure has given you something to judge every later request against, and one that cannot has shown you what to settle before any dates.
What exactly do you need from me, and by when?
Why ask it
A clear answer, such as three decisions and a named expert for two hours a week, lets you say yes or no honestly. A vague one, such as your support, tends to turn into unplanned requests later, so ask them to come back with a list.
Which decisions are mine to make, and which am I only being told about?
Why ask it
Teams often say consult when they mean inform. Settle it decision by decision, because finding out late that your view was a courtesy is how a stakeholder becomes an opponent. If the team cannot say yet, your asking has done them a favour.
What will change for my team, and on what date?
Why ask it
Ask for the change in terms of an ordinary working day: which screen, which form, which handover. If the team can only describe benefits, they have not looked closely at your area yet, and you should lend them someone who can walk them through it.
What are you assuming about my area that I should check?
Why ask it
Plans are built on guesses about volumes, staffing and how clean your records are, and you are the person who can test them cheaply. Correcting an assumption now takes a conversation. Correcting it after the build takes a change request.
What is most likely to make this late, and what is being done about it now?
Why ask it
A team that answers quickly and specifically has a live risk list. One that says nothing is likely to slip has not looked. You are not asking for a guarantee, only for evidence that someone is watching.
What was left out to make this plan fit?
Why ask it
Most plans have a cut list, written down or not, and the items on it show what the team judged less important than you might have. If something of yours is on it, this is the cheapest moment to argue for it, or to accept the loss knowingly.
How will I find out this is going off track before it shows in a status report?
Why ask it
Status reports have a habit of staying green until the week they turn red. Ask which early sign the team itself watches, a slipping test date or a decision left unanswered, and ask to be told when it moves.
Who looks after this once the project team has moved on?
Why ask it
If the answer is your team, you need to hear it now, along with the budget and training that go with it. Ask to see where support is written into the plan. An owner nobody has named is usually an owner who has not been asked.
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 tends to become everyone's version before the meeting is over.
- 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 ten questions to the room. The full list is there to choose from, not to read out, and the value comes from following up rather than getting through it.
Choosing from a long list
Ten questions for a first meeting
If you get one meeting, the most important questions for an analyst to ask are the ones no document will answer later. Take the first three from Goals (the project in their words, the problem, what success looks like), the walk-through of how it works today from Today, two from Requirements (what must be there on day one, and which of date, budget and scope is fixed), two from People (who signs off, and who else to talk to), and two from Risks (what worries them most, and what you have not asked). That covers purpose, limits, authority and doubt, and leaves room to follow up.
Pick by what you do not yet know
Before each interview, write down the two or three things you could not answer if your own manager asked. Choose the group that covers them and skip the groups you can already fill in from documents. A finance lead and a team supervisor should not get the same ten questions.
In a requirements gathering session
Much of business analysis is the slower pass that follows discovery: not why the work exists but what, exactly, it has to do. For that pass, take one process at a time and work down the Requirements group in order: the steps, the rules, the exceptions, the data, then how each need will be tested. Put the same questions to the person who does the job and to the person who sponsors it. Where their answers differ, you have found a business requirement that nobody has agreed yet.
When you are the stakeholder
The last group turns the table. If a project team has asked for your time, those are the questions to ask them before you agree to anything: what the work is for, what they need from you, which decisions are yours, what changes for your people, and who owns the result afterwards. If you are on the project team, read the same group as the questions stakeholders ask, and have your answers ready before the meeting.
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 later in the conversation, 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?" is easy to say yes to whether or not it is true. 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.