Framing the mandate and claim boundaries
7 min read
Lesson objectives
- Analyze defining the client decision, users, and jurisdictional limits before collecting data and justify a reviewable recommendation.
Mandate design begins with a practical question: which decision should the client improve, who owns it, and what does the client expect from the consultant? “We want ESG compliance” identifies no standard, user, jurisdiction, or assurance level. The consultant converts it into decision choices: a disclosure gap assessment, an impact-prioritization exercise, or an operational roadmap. Each requires different evidence. The engagement letter names entities, period, users, and exclusions, and states that neither the program nor the report creates a universal ESG compliance badge.
Four boundaries are fixed before interviews. The topic boundary names included issues; the organizational boundary names companies, sites, and relationships; the time boundary defines baseline and comparison periods; and the authority boundary shows who decides, reviews, and supplies data. If a sponsor says all subsidiaries are included while the system covers two of five, the mismatch is a scope defect. The consultant asks management to expand collection, narrow the claim, or disclose missing coverage. Ambiguity is not permission to assume the easiest boundary.
A mandate register records the requested claim, purpose, user, framework, jurisdiction, verification level, available evidence, and limitations. It distinguishes voluntary use of a standard to organize work from a legal obligation requiring a current local source. It also separates advice from independent assurance: helping management construct a metric does not make the adviser its assurer. Where roles overlap, the team records the independence threat or conflict, arranges separate review, or narrows public language rather than concealing the relationship.
Test mandate quality with an acceptance matrix. For every output ask whether it has a named user, spatial and temporal boundaries, collectible evidence, language no broader than that evidence, and an authorized decision owner. An output failing two questions does not enter the work plan. The matrix is not a marketing score; it prevents expensive collection that answers no decision. Record every unresolved question, its owner, and decision date because deferred ambiguity usually returns as a dispute at delivery.
After scope approval, maintain a change register. Any added entity, period, or standard records its effect on time, cost, and comparability. A sponsor cannot add a new question at the end and label its absence a delivery failure. Equally, a consultant should not hide behind the letter when evidence reveals a material issue directly connected to the purpose; escalate it as a scope decision. This discipline protects the relationship and prevents uncontrolled expansion or a false statement of completeness.
The delivery memorandum uses three confidence levels: established through primary records or reperformance; partially supported and requiring verification; and unverified, therefore unsuitable for an external claim. Each level has matching language. “The register shows” is stronger than “an interview suggests,” while “data were unavailable” is more accurate than “no impact exists.” The memorandum also identifies management dependencies and limitations that could alter the result. This does not weaken the report; it stops readers assigning precision the engagement did not produce.
Close the mandate review with a counter-reader test: would a user absent from the engagement understand the report boundary from its title and opening page? The data owner checks figures, the process owner delivery, the risk owner exceptions, and the decision owner alternatives. Their sign-off is not external assurance, but it shows role-specific review. Success is measured by resolved scope questions, evidence completeness for agreed outputs, and public language that stays inside the boundary. A material gap becomes a pre-publication condition, not a vague future action.
Mandate lab: before accepting the engagement, the consultant builds a decision register rather than relying on a broad proposal. Each row names the decision expected, its owner and deadline, the information needed, the party able to provide it, and the permitted level of reliance. A decision to approve a disclosure plan is kept separate from an investment decision or a promise of improved performance. A named audience distinguishes a board paper from a data-team workbook, while an assurance column distinguishes a limited review from reasonable assurance. The register is reconciled with the engagement letter and kick-off minutes; an output without a user, or a decision without an owner, remains an open question.
Three drift tests make the boundary operational. If marketing asks for the phrase “ESG compliant” without naming a criterion, the request enters the claims register as unqualified and cannot appear in the deliverable. If a subsidiary is added after fieldwork starts, a change request records consequences for evidence, timing, fees, and sampling instead of silently widening coverage. If a severe harm appears outside the disclosure topic, the consultant invokes the escalation protocol rather than hiding behind scope. The closing package contains a one-page mandate memo, a boundary matrix, and a numbered assumptions log. It is reviewed by the executive sponsor, the data owner, and legal counsel where appropriate. The completion test is practical: a person absent from kick-off must be able to state what question will be answered, what is excluded, which evidence is acceptable, who approves changes, and which limitations travel with the conclusion. If that cannot be done, the mandate is not ready, however polished the proposal looks.
Lesson summary
This lesson connects defining the client decision, users, and jurisdictional limits before collecting data to alternatives, criteria, evidence, and a review trigger.