Consulting Questions to Ask Client
For the scoping conversation that happens after the problem is agreed and before the proposal goes out. Twenty questions on where the boundary of the work sits, which decisions stay with the client, what data and interview access you will actually get, how much of their team's time is committed, how sign-off and change control work, and who takes the work over when you leave.
The questions
Open any question for the note
What is in scope, and just as importantly, what should we leave alone?
Why ask it
Exclusions are the useful half and clients rarely volunteer them. Written down, "we are not reviewing the operating model" prevents the slow expansion that turns a six-week piece into four months at the same fee.
Which decisions do you want from us, and which will you make yourselves?
Why ask it
Ambiguity here is the most common source of disappointment on both sides. Some clients want a recommendation to approve, others want options with the trade-offs laid out. Delivering the wrong one reads as either presumption or fence-sitting.
What deliverable would you actually use: a report, a model, a trained team, a working process?
Why ask it
Ask what happened to the last document of each type. Clients often request a report because that is what consultants produce, when what they need is a working spreadsheet their own analyst can maintain after you have gone.
Who will read the output, and what do they need to be able to do with it?
Why ask it
A board paper, an implementation plan and a regulator's submission are different artefacts and cannot be the same document. Knowing the reader also tells you how much of the reasoning has to be visible and how much can sit in an appendix.
Which data will we need, who owns it, and how long does access usually take?
Why ask it
Access is the most reliable cause of slipped consulting timelines. Ask who grants it, whether a security review is involved, and whether the data has ever been pulled before. "It should be straightforward" from someone who does not own the system means nothing.
Who can we interview, and does the list need approving?
Why ask it
You are testing for filtering. A curated list of enthusiasts produces a comfortable, useless picture, and being told you may not speak to frontline staff tells you what the sponsor is worried about hearing. Both change how you design the work.
How much of your team's time are you committing, by name and by hours a week?
Why ask it
Get it written into the scope, not offered verbally. Every engagement design assumes some client effort; when that effort does not materialise, the work either stops or you absorb it, and the second is how consultancies lose money quietly.
What is happening in the next quarter that we should schedule around?
Why ask it
Year end, a system upgrade, an audit, peak trading, a reorganisation, school holidays for the key people. Any of these can make a perfectly reasonable timeline impossible, and the client rarely thinks to mention them unprompted.
How much disruption can the business absorb while this runs?
Why ask it
Sets whether you are designing a change people can adopt alongside their jobs or a programme that needs backfill. Answers about appetite for bold change should be checked against what the organization has actually survived recently.
What decisions have already been made that are not open for review?
Why ask it
There is usually a committed vendor, structure or announcement somewhere in the background. Learning it now lets you scope around it honestly; learning it in a steering meeting after you have recommended the opposite costs you credibility you cannot recover.
Which other projects touch this one, and who runs them?
Why ask it
Overlapping initiatives compete for the same people and can invalidate your recommendations mid-flight. Ask for names, then meet those leads early, because their cooperation is a dependency whether or not anyone writes it down.
What regulatory, security or contractual limits apply to how we work?
Why ask it
Covers personal data handling, where information may be stored, background checks, site access, and clauses in your client's own contracts with third parties. These change your staffing and your timeline, so they belong in the scope rather than in a later surprise.
Where do you want us working, and how often on site?
Why ask it
Presence has a price and a purpose. Being in the building buys you corridor conversations that no interview schedule replicates, but three days a week of travel changes your costs materially. Agree it explicitly rather than drifting into it.
How do you want progress reported, to whom, and how often?
Why ask it
Also ask what happens between reports if something is going wrong. A client who wants only monthly formal updates has no route to hear bad news early, and bad news that arrives late is what ends engagements.
Who signs off each phase, and what has to be true for them to sign?
Why ask it
Push for the acceptance test in plain words. "Sign-off when the sponsor is satisfied" is not a criterion, it is an open invitation to rework, and it is the clause most often argued about when the final invoice goes in.
If the diagnosis changes what we think you should do, how do we handle that?
Why ask it
Agreeing the mechanism before you need it is what keeps a genuine finding from becoming a contractual fight. You want a named route for a change of scope, a rough turnaround, and permission to raise it early rather than at the end of a phase.
How are we being paid: fixed fee, time, or phases, and against which milestones?
Why ask it
Ask what has to happen for an invoice to be approved and how long payment then takes. Fixed fees need tight scope and clear exclusions; time and materials needs a spending cap the client trusts. Mismatching the model to the uncertainty hurts one of you.
What are your contracting and procurement steps, and how long do they take?
Why ask it
Master agreements, supplier onboarding, insurance evidence, security questionnaires and purchase orders routinely add weeks between a yes and a start date. Find out now who owns each step, so the start date in your proposal is one you can meet.
Who owns the material we produce, and what may either of us say publicly afterwards?
Why ask it
Cover intellectual property in the deliverables, reuse of your own methods and templates, and whether you may name them as a client. Sorting this at scoping is straightforward; sorting it after a successful project rarely is.
Who takes this over when we leave, and what will they need from us?
Why ask it
Ask for the person, not the team. Handover designed at the start looks like documentation, shared working and shadowing along the way; handover arranged in the final week is a folder nobody opens, which is how good work stops being used within a quarter.
Turning a conversation into a scope
Practical guidance for the conversation itself
Writing the scope
- Define the work by its exclusions as well as its inclusions. A list of what you are not doing is the cheapest protection against expanding scope, and clients generally find it reassuring rather than defensive.
- Make the first phase small and its deliverable a decision. Diagnosis, then a go or no-go, lets both sides stop cleanly if the problem turns out to be different from the brief.
- Write the client's obligations in the same detail as your own: named people, hours, data by date, decisions by date. If their side of the scope is vague, every delay becomes your fault.
- State your assumptions explicitly, each with what happens if it proves wrong. Assumptions are how a fixed fee stays honest.
- Put a review point at roughly a third of the way through, with the explicit option to change direction. Most engagements learn something in the first weeks that should change the plan.
What the answers tell you
Access commitments are the real test
Enthusiasm is free. Agreeing to grant a data extract by a named date, or to release a named analyst for a day a week, costs something internally. A client who will not commit to access is telling you how much priority the work really has.
Listen for who is missing from the scoping conversation
If the people whose work will change are absent from scoping, they will hear about the project from a slide deck. Ask to include one of them, even briefly, and treat refusal as a risk to note rather than a detail.
Ask what the last engagement's scope got wrong
Clients can usually say precisely where a previous consulting scope was unrealistic: too many interviews, too little time for approvals, a report nobody had a slot to receive. It is free calibration and they are flattered to be asked.
Check the timeline against their own calendar
Take the milestones and lay them against the committee dates, the audit, year end and holidays. Most timelines that fail did so because approval could only happen on a date nobody checked.
Where scoping goes wrong
Fixed fee on an unfixed problem
If you cannot yet describe the deliverable in a sentence, a fixed price transfers all the uncertainty to you. Scope the diagnosis for a fixed fee and price the rest once you know what you are dealing with.
"Just a couple of extra interviews"
Additions arrive as small favours from people you want to keep happy. Log each one with its cost in days, even when you decide to absorb it, and show the accumulated list at the review point rather than at the end.
Designing around client effort that does not exist
Workshops, data pulls and co-authored outputs all assume availability. If the named counterpart has two hours a week, build something that works at two hours a week rather than something that needs eight.
Sign-off with no criteria
Acceptance defined as satisfaction gives an unhappy sponsor unlimited rework and gives a happy one no way to defend the invoice internally. Write down what the deliverable must contain and let that be the test.
Leaving handover to the end
A team that first sees the work in the closing presentation will not maintain it. If nobody can be named as the receiver, say so in the proposal and price a shorter, narrower piece rather than pretending the problem will be solved.
A workable sequence
From scoping call to signed scope
- 1Send a one-page summary within a day: problem, boundary, deliverable, what you need from them, and the assumptions. Ask for corrections in writing.
- 2Get the two or three access commitments confirmed by the people who actually control them, before the proposal is finalised. This is the step most often skipped and most often regretted.
- 3Write the proposal with phases, exclusions, client obligations and acceptance criteria, and put the change mechanism on the same page as the fee rather than in the terms at the back.
- 4Walk the sponsor through the assumptions and exclusions out loud before signature. If any of them make them uncomfortable, that discomfort is information you need now.
- 5At kickoff, restate the boundary and the review point to everyone who will be involved, including the people who were not in scoping.
If scoping keeps stalling
Repeated delays at this stage are rarely administrative. Usually a decision is unresolved somewhere above your sponsor. Ask directly what has to happen internally before this can be signed, and offer a smaller first phase that fits under whatever approval threshold is blocking it.