Scoping the engagement: the problem statement and the proposal

The Meadowlark team's first meeting with the client takes place in a boardroom above the co-op's largest grocery store. Colin Baptiste, the chief executive, is joined by Sunita Grewal, vice-president of grocery, and Doug Pankratz, the chief financial officer. Within ten minutes it is clear that the three of them see the problem differently. Sunita believes the stores are losing to discount chains in the larger towns and need lower prices. Doug believes costs have grown faster than sales for a decade and that some stores should close. Colin believes the co-op has lost touch with younger members, who see it as their grandparents' store. Each wants the team to confirm his or her view.

Dr. Mehta had predicted this. The first job of a consulting team, she told them, is to agree with the client on what problem you are solving. Most failed engagements fail here, not in the analysis. A team that starts analysing before the problem is agreed will find that its answer satisfies nobody, because each executive was waiting for the answer to a different question.

From symptoms to a problem statement

Clients usually describe symptoms: falling margins, unhappy members, losing stores. A problem statement turns those symptoms into a question precise enough to answer and important enough to matter. Barbara Minto, who developed the pyramid principle at McKinsey in the 1960s and 1970s, suggested building it from three parts: the situation, which describes the stable background the audience already accepts; the complication, which explains what has changed or gone wrong; and the question, which the complication raises and the engagement must answer. Writing the situation first forces the team to state facts everyone agrees on, which builds common ground before the disagreements.

A good problem statement has several qualities, often summarized with the acronym SMART: it is specific, measurable, action-oriented, relevant and time-bound. The team's draft question meets each test. It is specific to grocery rather than the whole co-op; it measures success by margin, patronage refund and younger members; it asks what the co-op must do, not merely why things went wrong; it addresses the board's real concern; and it sets a three-year horizon. It also states two constraints that came from the board: the refund target of 7.0 million dollars and a limit of two store closures, because each store is often the only grocery in its town.

Daniel points out that the constraint on closures shapes the whole engagement. Without it, the obvious answer might be to close every losing store; with it, the team must find other ways to improve them. Constraints are not obstacles to work around but part of the problem. A team that ignores them will produce an answer the client cannot use. At the same time, a team should ask where each constraint came from, because some are firm, such as a legal requirement, and others are assumptions that could be tested. Colin explains that the limit on closures reflects a promise the board made at the last annual meeting after members protested the closure of a store in a small town. It is firm.

Who decides, who influences, who carries out

The team next maps the people who matter to the engagement. A stakeholder map places each person or group according to their influence over the decision and their interest in the outcome. At Meadowlark the board decides; the chief executive sponsors; the vice-presidents of grocery, finance and member relations shape the analysis and will run any changes; store managers and staff carry out the work; members, through their votes at the annual meeting and their shopping, judge the result. The union that represents staff in eight of the stores must be consulted on any change in scheduling. The co-op's wholesaler, a larger co-operative owned by retail co-ops across the region, supplies most of what the stores sell and sets many of the promotion programs.

The map shows that the team cannot please every stakeholder, but it must understand each one's view. Sunita, whose division is under scrutiny, has the most to lose and the most knowledge. Dr. Mehta advises the team to spend extra time with her early, to ask about her hypotheses, and to make sure she sees the analysis before anyone else does. Never let a vice-president learn about a problem in her own division for the first time in a steering meeting, she says. It turns an ally into an opponent.

The engagement proposal

The team turns its agreed problem statement into a written proposal, which becomes the engagement letter once the sponsor signs it. Professional firms write proposals to win work; a student team writes one to make sure both sides understand what will and will not be done. Dr. Mehta lists the elements every proposal should contain.

• Background and objectives: the situation and complication in a few sentences, and the question the engagement will answer.
• Scope: what is included and, as important, what is excluded. The team includes all 22 grocery stores and the member program as it affects grocery. It excludes the fuel and farm supply businesses, except where a grocery store shares a site with them.
• Approach: how the team will work, including interviews, a member survey, analysis of store and sales data, benchmarking and workshops with managers.
• Deliverables: an interim findings presentation at the second steering meeting, a final report and presentation to the board, and the analysis files the co-op can update.
• Timeline: twelve weeks with steering meetings in weeks 3, 7 and 10.
• Team and governance: who is on the team, who the sponsor is, how often they will meet and who resolves disagreements.
• Client responsibilities: the data the co-op will provide and by when, access to stores and staff, and the managers' time required.
• Confidentiality, data handling and conflicts of interest, including the safeguards agreed for Grace.

The proposal also states what the team will not do. It will not recommend specific staff reductions by name, negotiate with the union, or give legal advice on leases. These exclusions protect the client as well as the team. Dr. Mehta notes that a written scope is the team's best protection against the most common problem in consulting, scope creep.

Scope creep

Scope creep is the gradual expansion of an engagement beyond what was agreed, usually through a series of reasonable-sounding requests. It is common because clients see a capable team and want help with other problems, and because consultants want to please. It is dangerous because time is fixed: every hour spent on a new question is an hour taken from the original one.

The Meadowlark team meets this problem in its second week. After reading the draft proposal, two directors ask whether the team could also review the fuel business, where volumes are falling as more members drive electric and hybrid vehicles, and check whether farm supply prices are competitive. Both are good questions. Daniel builds a simple capacity check before the team responds.

# Does the proposed scope fit the team's capacity? (hours over twelve weeks)
team, weeks, hours_per_week = 3, 12, 20
capacity = team * weeks * hours_per_week
workstreams = {
    "Scoping, proposal and kickoff": 70,
    "Interviews (38) and coding": 110,
    "Member survey design and analysis": 90,
    "Store and category data analysis": 140,
    "Benchmarks and secondary research": 50,
    "Options, business case and roadmap": 100,
    "Storyline, slides and rehearsal": 60,
    "Project management and client meetings": 50,
}
need = sum(workstreams.values())
print(f"Capacity {capacity} h, planned {need} h, buffer {capacity - need} h ({(capacity - need) / capacity:.0%})")
# The board's first request added a fuel-site strategy and a farm-supply pricing review.
extra = {"Fuel and convenience strategy": 160, "Farm supply pricing review": 80}
total = need + sum(extra.values())
print(f"With the added requests: {total} h, over capacity by {total - capacity} h")
for k, v in sorted(workstreams.items(), key=lambda kv: -kv[1])[:3]:
    print(f"  largest: {k:42s}{v:4d} h")

Capacity 720 h, planned 670 h, buffer 50 h (7%)
With the added requests: 910 h, over capacity by 190 h
  largest: Store and category data analysis           140 h
  largest: Interviews (38) and coding                 110 h
  largest: Options, business case and roadmap         100 h

Three students working about twenty hours a week for twelve weeks have 720 hours. The original plan needs 670, leaving a buffer of 50 hours, or about 7 per cent, which Dr. Mehta considers thin but workable. Adding the two requests would require 910 hours, nearly 200 more than the team has. The team cannot do all three pieces of work well; doing them all would mean doing all of them badly.

The team takes the numbers to Colin with three choices: keep the original scope; swap part of the grocery work for one of the new questions; or keep grocery as the focus and include fuel only where it touches grocery, such as stores that share a site with a fuel station. They recommend the third, and suggest the fuel strategy as a separate project for a future student team. Colin agrees and explains the decision to the directors, who are satisfied that their question has been heard. The episode teaches a general rule: when a client asks for more, show the trade-off in time and quality and let the client choose, rather than silently absorbing the work or flatly refusing.

Success criteria and data

The proposal ends with how success will be judged. Dr. Mehta encourages teams to agree on criteria with the sponsor at the start, so that the final evaluation is not a matter of taste. The Meadowlark team and Colin agree on four: the board can make a decision on grocery at its spring meeting; the recommendation is supported by Meadowlark's own data, not only national statistics; the managers who must carry it out have seen and challenged it; and the analysis can be updated by Doug's team after the students leave.

The last practical step is the data request. The team asks for three years of sales, gross margin, wage hours and shrink by store and department; store-level occupancy costs; promotion records; membership data showing age band and spending, stripped of names; the results of any past member surveys; and the wholesaler's benchmark survey of similar co-ops. Each item has an owner and a due date. Personal information about members must be handled under the Personal Information Protection and Electronic Documents Act and the co-op's own privacy policy, so the team asks for anonymized extracts and agrees to keep them on the co-op's systems.

Leo and Owen face a different scoping problem at Cedarline. The chief executive's request, to turn many plans into one transformation, is too broad to answer in twelve weeks. After two meetings they narrow it to a single question: in what order should Cedarline carry out its supply chain, people, digital and international plans, and how should it govern them, given limits on cash, management time and the new union agreement? Owen says the narrowing felt like losing ambition at first, but he now sees that a question they can answer is worth more than one they cannot.