Questions to Ask Stakeholders for a Project
Questions for a project manager, analyst or lead running kickoff and discovery conversations, covering what the project is for, how success will be judged, what is genuinely fixed, who decides what, dependencies you do not control, and how people want to hear about problems. Take six or eight into any one conversation rather than working through all twenty.
20 questions, each with the reason to ask it · includes a conversation guide
The questions
Open any question to see why it works.
- 1
In one sentence, what does this project need to do?
Ask everyone this and compare the sentences later. Divergence between two stakeholders in week one is cheap to resolve and expensive to discover at delivery. If someone cannot answer in a sentence, the project probably has more than one purpose bundled together.
- 2
Why now?
Every project has a trigger: a contract renewal, a regulation, an outage, a new executive, a competitor. The trigger tells you which deadline is real and which parts of the scope exist to satisfy the trigger rather than the stated goal.
- 3
What happens if we do nothing?
The strongest test of priority available in a first meeting. If the honest answer is that things continue roughly as they are, you are on a project that will lose people and budget to anything more urgent, and you should plan for that rather than be surprised by it.
- 4
How will you personally judge whether this succeeded?
The word personally matters. The official success criteria are in the business case; what this individual will actually be judged on, or will remember in a year, is often something else, and it is what drives their behaviour in every later disagreement.
- 5
Which number should move, and what is it today?
Asking for the current value is the real question. If nobody can tell you the baseline, either the measurement does not exist, in which case building it is part of the project, or the target was chosen without reference to reality.
- 6
Has this been attempted before, and what happened?
Most projects that feel new are the second or third try. Find the previous attempt, the person who ran it, and why it stopped. That history is the best available predictor of what will go wrong this time, and it never appears in the brief.
- 7
Who else has a stake in this that I have not spoken to?
Ask at the end of every interview and keep pulling the thread until names stop being new. The teams nobody mentions are usually the ones with no advocate and the most exposure: support, operations, whoever maintains the thing after handover.
- 8
Who is likely to be against this, and why?
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.
- 9
Of date, budget and scope, which is genuinely fixed?
Everything is described as fixed until you make people rank them. Ask for the order rather than a yes or no, and write the answer down with the date, because the ranking will be denied later by whoever ends up on the losing end of it.
- 10
If we had to cut something, what goes first?
Better asked now than in the week you have to do it. A stakeholder who cannot name anything cuttable is telling you the scope has not been prioritised at all, and the cut will eventually be made by whoever runs out of time first.
- 11
What cannot change, whatever we decide?
Constraints and preferences arrive in the same tone of voice, and only constraints are actually non-negotiable. Regulation, contracts, a system nobody can modify, a union agreement and an executive commitment already announced are the usual real ones. Tag each item as you hear it.
- 12
Who signs off on requirements, and who can overrule that?
These are two different people more often than anyone admits. Knowing the second name saves you the version where a sign-off is obtained, work proceeds for six weeks, and someone senior reopens the whole question.
- 13
When two of you disagree, who decides?
Ask it out loud, in the kickoff, while it is hypothetical and cheap. The answer may be a person, a forum, or an uncomfortable silence, and the silence is the most useful outcome because it identifies a decision you now need to get made in advance.
- 14
How much of your team's time can I actually have, and when?
Get names, hours per week, and their other commitments. Stakeholders routinely promise subject matter experts who are already fully allocated elsewhere, and the shortfall shows up as slipped dates that get attributed to the project team instead.
- 15
What are we depending on that we do not control?
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.
- 16
What has to be true for this to work that we are currently assuming?
Asks for assumptions directly, which experienced stakeholders can usually produce and which no status report ever contains. Answers like the data is clean, the customers will switch, or the other team will be finished by March are the ones that later become the reason a project failed.
- 17
What are you quietly worried about?
Ask one to one and after the formal questions are finished. The concern that comes out here is often specific and political, about a person or a prior commitment, and it is the item least likely to survive translation into a risk register but most likely to determine the outcome.
- 18
Who has to change how they work for this to pay off, and do they know yet?
Most projects deliver something technically and fail to deliver the benefit, because the benefit depended on people working differently and nobody owned that. If the answer to do they know is no, you have just found the largest piece of missing scope.
- 19
What does the day after go-live look like?
Ask who answers the phone, who fixes defects, who trains the next intake, and whose budget pays for it. Support and ownership after handover are routinely unassigned at kickoff and then negotiated in a hurry during the final fortnight.
- 20
How do you want to hear about problems, and how early?
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.
Running discovery conversations
Practical guidance for the conversation itself.
Setting up the interviews
Setting up the interviews
- One person at a time wherever you can. In a group, the most senior person's version of the goal becomes everyone's version within five minutes, and the quiet objection is never raised.
- Read what already exists first: the business case, the previous attempt, last year's support tickets. Your questions should test the written story rather than ask people to recite it.
- Say at the start how long you need and who will see the notes. People are far more specific about problems once they know whether their name is attached.
- Bring six to eight questions, not twenty. The value is in following up on the answers, and a fixed script prevents that.
- Interview downwards as well as upwards. The people who do the work daily will describe the current process accurately, and the people who own it will describe the version in the procedure document.
Getting past the rehearsed answer
Getting past the rehearsed answer
Ask for the last time, not the usual case
How often does that happen invites an estimate. When did it last happen, and what did you do, produces a story with a date, a name and a workaround in it. Switch to the specific version whenever an answer starts sounding like policy.
Listen for the passive voice
When someone says a decision was made or the approach was agreed, an actor is being hidden, usually because they disagreed with it or genuinely do not know who decided. Ask who, mildly, and note both the answer and the hesitation.
Separate wants from constraints as you write
Tag every note as one or the other in the moment, because you will not be able to reconstruct it afterwards. Later scope negotiations are entirely about the wants, and this saves relitigating things that were never optional.
Keep going past the quotable answer
The first statement of the goal is the version rehearsed for a steering committee. The real objective usually appears twenty minutes later, attached to a specific frustration with a specific system or person.
After the interviews
After the interviews
- Send each person a short written summary of what you heard and ask them to correct it. Corrections cost minutes now and weeks later.
- Put the one-sentence goals side by side. Where they conflict, get the conflict resolved by a named decision maker before anything is planned, and record who resolved it.
- Turn every assumption you were given into either a check you will run or a risk with an owner. An assumption that is only written down is not managed.
- Track who you have not yet interviewed and keep it visible. A stakeholder discovered in month three arrives with requirements and no budget for them.
- Re-ask the fixed-versus-flexible question at each major milestone. The ranking of date, budget and scope changes quietly as the organisation's priorities move, and nobody will tell you it has.