The big idea: Your first consulting job is to turn the client’s business problem into a design challenge your team can move in one year: a specific group of people, a moment, a change you want for them, and a clear map of who has a stake and what cannot change.
In 60 seconds
- Scoping turns a client’s business problem into a design challenge your team can move in one year.
- A well-scoped challenge names a specific group of people, a moment and the change you want for them, not a product.
- Map every stakeholder, sort constraints into firm and assumed, name what is out of scope, and get your client’s yes.
Do this: write one approved How Might We challenge with a stakeholder and constraint list, and use it in your briefs and technical report.
How scoping works
Your client will describe a business problem: costs are up, people leave, lines are long, a program is not used. Scoping turns that problem into a design challenge your team can actually move in one year. A well-scoped challenge names the people, the moment and the change you want for them, and it is honest about who has a stake and what cannot change.
Hear the problem
Write down the client’s problem in their own words. Ask what prompted it now and what they already tried.
Example: “We lose too many new hires in their first 90 days.”
Find the people and the moment
Whose experience sits under the numbers, and when does it go wrong?
Example: new line workers, in their first two weeks on the floor.
Map stakes and limits
List the stakeholders and the constraints. Mark which constraints are confirmed and which are guesses.
Example: training must happen in paid shifts.
Write the challenge
One How Might We question with a person, a moment and a change, plus what is out of scope.
Example: “How might we help new line workers feel confident and part of the crew in their first two weeks?”
What clients say
- A symptom. “Our discharge process is a mess.” (a hospital)
- A metric. “Permit approvals take too long.” (a city office)
- A solution they already picked. “We need an app for dining hall orders.” (campus dining)
- A goal with no person in it. “We want more engagement.” (a nonprofit)
What you turn it into
- A person. Patients going home after heart surgery, and their caregivers.
- A moment. First-time food truck owners, from the first form to opening day.
- A change, not a product. Students get a hot meal between classes without missing the start of the next one.
- A reason it matters. Volunteers who stay past their first month, because the work feels useful.
You learned this in London
In IB 407 you wrote How Might We questions from a point of view and checked them for scope: not so broad that nobody knows where to start, not so narrow that the answer is already inside. The same test applies here. The difference is that a real client now owns the problem, the budget and the final say.
Scope is a deal, not a guess
Your challenge is an agreement with your client about what your team will and will not work on this year. Write it down, read it back to them and get a yes. Revisit it when your research shows something new.
Map your stakeholdersSix roles to look for before you write the challenge
A stakeholder is anyone who uses, decides, runs, pays for, blocks or lives with the result. Most client challenges touch at least four groups.
Users
The people whose experience you are designing for.
Watch out: there is often more than one group of users (patients and caregivers, students and staff).
Decision maker
The person who approves money, policy or space.
Watch out: this is often not your day-to-day contact.
Client contact
Your sponsor. Opens doors, answers questions, reads your briefs.
Watch out: their view of the problem is one view, not the whole picture.
Frontline doers
Staff who would run any solution every day.
Watch out: skip them and your prototype dies in week one.
Affected, not at the table
People who live with the result but never join the meeting: families, other shifts, neighbors, the team downstream.
Watch out: they often explain why past fixes failed.
Gatekeepers and partners
IT, legal, compliance, unions, vendors, city offices, funders.
Watch out: a late “no” from a gatekeeper can stop a finished idea.
Constraints: firm, assumed and out of scopeName the walls before you design
Firm constraints
Confirmed limits: budget, deadlines, laws and safety rules, policies, union agreements, data you cannot access.
Use it: design inside them. They are part of a feasible answer.
Assumed constraints
Limits you heard secondhand or guessed: “IT will never approve that,” “staff have no time.”
Use it: check each one with your client contact. Some are real. Some are habits.
Out of scope
Related problems your team agrees not to tackle this year, such as pay rates or a building renovation.
Use it: write one or two down. It protects the team from scope creep in spring.
Questions for your first scoping conversationWhat to ask the client before you write a word
- What prompted this now? What changed?
- What have you already tried, and what happened?
- Who experiences this problem most? Who else feels it?
- Who decides whether a solution moves forward? Who could block it?
- If this went well, what would be different in a year? How would you know?
- What cannot change: budget, rules, systems, timelines?
- What data, places and people can our team get access to?
- What is off the table for this project?
Treat the answers as a starting point. Your Inspiration research will confirm some and challenge others. Follow the interview ethics you learned in BUAD 317 for every conversation.
Try it: Challenge Scope Builder
Tool · BUAD 497
Challenge Scope Builder
Turn a client’s problem into a design challenge your team can actually move.
- 1Fill in
- 2Check
- 3Share
Your design challenge
All checks
Put it to work: your challenge in your briefs and your report
Your scoped challenge is the first thing your client agrees to and the thread that runs through the whole capstone. It anchors your first Weekly Consulting Briefs, your Summer Prototype Update and the opening pages of your HCD Technical Report, where the checklist asks for the design challenge, why it is happening, and the objectives and scope of the report.
Capture the client’s problem
Write it in their words, with what prompted it and what they already tried.
Your deliverable: a two-sentence problem statement in your Weekly Consulting Brief.
Map stakeholders and constraints
Fill all six stakeholder roles you can. Sort constraints into firm and assumed, and plan how to check the assumed ones.
Your deliverable: a stakeholder and constraint list your team keeps updating.
Write and test the challenge
Run it through the Challenge Scope Builder, then read it to your client contact and ask if answering it would matter to them.
Your deliverable: one approved How Might We challenge plus an out-of-scope line.
Report the scope
Use the approved challenge in your Summer Prototype Update and your report’s Executive Summary and Introduction.
Your deliverable: the primary design challenge, why it is happening, and the objectives and scope section of your HCD Technical Report.
Flag scope changes
When research shifts your focus, say so in the next brief, explain the evidence and confirm the new scope with the client.
Your deliverable: a scope note in the Risks section of your Weekly Consulting Brief.
Example: from client problem to challengeA small manufacturer’s onboarding
| Part | Example |
|---|---|
| Client problem | “We lose too many new hires in their first 90 days.” |
| People and moment | New production line workers, in their first two weeks on the floor. |
| Stakeholders | New workers, plant manager, HR coordinator, shift leads, families of new hires. |
| Constraints | Training happens in paid shifts (firm). Safety procedures cannot change (firm). Shift leads have no time to mentor (assumed, check it). |
| Challenge | How might we help new line workers feel confident, safe and part of the crew in their first two weeks? |
| Out of scope | Pay rates and hiring ads. |
This example is invented for practice.
Before you submitCheck your scope
- [ ] The client’s problem is written in their words.
- [ ] The challenge names a specific group of people and a moment.
- [ ] The change is an outcome for people, not a product.
- [ ] Users, a decision maker and at least one affected voice are on the stakeholder list.
- [ ] Assumed constraints are marked, with a plan to check each one.
- [ ] One or two things are listed as out of scope.
- [ ] Your client contact has agreed to the challenge.
Go deeper
Back to all BUAD 497 topics · Next: Who You Learned From: Your Interviewee Log and Sample
In-class team activity · 25 min
Scope Squeeze
By the end: A scoped design challenge for your client project with a stakeholder map, constraints marked firm or assumed, and one out-of-scope line, tested by another team. Your instructor will give you the password in class.
Part of the Smith GLS human-centered leadership sequence: IB 407, BUAD 317 and BUAD 497, toward the Human Centered Consulting Certificate.
Frequently asked questions
What is scoping a client challenge?
Scoping turns a client's business problem into a design challenge a team can move in one year. A well-scoped challenge names the people, the moment and the change you want for them, and it is clear about who has a stake and what cannot change. It is written as one How Might We question plus what is out of scope.
How do you turn a client problem into a design challenge?
Use four steps: hear the problem in the client's words, find the people and the moment, map stakeholders and constraints, then write the challenge. For example, "We lose too many new hires in their first 90 days" becomes "How might we help new line workers feel confident and part of the crew in their first two weeks?"
What is the difference between firm and assumed constraints?
Firm constraints are confirmed limits such as budget, deadlines, laws, safety rules, policies and union agreements, and you design inside them. Assumed constraints are limits heard secondhand or guessed, like "IT will never approve that." Check each assumed constraint with your client contact, because some are real and some are habits.
What are common mistakes when scoping a consulting project?
Common mistakes include accepting the client's solution as the challenge, such as "build an app," and naming "everyone" or "the community" as the user. Other traps are big verbs with no detail, like improve or optimize, a stakeholder list with only the people in the meeting, and quietly changing scope in spring without telling the client.
Which stakeholders should a consulting team map?
Look for six roles: users, the decision maker, the client contact, frontline doers, people affected but not at the table, and gatekeepers and partners. Most client challenges touch at least four groups. Affected people such as families or other shifts often explain why past fixes failed, and a late no from a gatekeeper can stop a finished idea.