Engagement Scoping

Overview

Based on "Flawless Consulting" by Peter Block. The contracting phase is the most important and most skipped phase of a consulting engagement. Vague contracting creates resentment, scope creep, and failed engagements - not bad execution. A well-contracted engagement defines what success looks like, who does what, what happens when things go wrong, and what is explicitly not in scope. Do it in writing, at the start.

Workflow

Step 1: Clarify the Business Problem

Before scoping anything, confirm you are solving the right problem. Block warns against solving the presenting problem when the real problem is different.

Ask:

• "What is the specific business problem this engagement is solving?" (Not the symptom - the root cause)
• "What would we see differently in 6 months if this engagement succeeds?"
• "Who is most affected by this problem and how?"
• "What has already been tried?"

Document: a 2-3 sentence problem statement in business language. Share it with the client and confirm alignment before proceeding. If they revise it significantly, you were not scoping the right problem.

Step 2: Define Success Criteria

Success criteria must be specific and agreed-upon before the engagement starts, not after.

Template:

Success Criteria for [engagement name]

By [end date or milestone]:
- [Measurable outcome 1: e.g., "Leadership team agrees on 3-year strategic priorities"]
- [Measurable outcome 2: e.g., "Operating costs reduced by 15% in [department]"]
- [Measurable outcome 3: e.g., "New process documented and staff trained"]

Leading indicators (how we'll know we're on track mid-engagement):
- [Indicator 1]
- [Indicator 2]

Avoid success criteria that are activity-based ("workshops completed", "report delivered"). Activity-based criteria let a bad engagement end on time. Outcome-based criteria ensure you actually solved the problem.

Step 3: Define Scope - In and Out

Write two explicit lists: what is in scope and what is out of scope. Out-of-scope items are as important as in-scope items.

Template:

In Scope:
- [Specific deliverable or work stream 1]
- [Specific deliverable or work stream 2]
- [Geographic/organizational boundaries, e.g., "North America operations only"]

Out of Scope:
- [Excluded area 1 and why, e.g., "IT systems implementation - requires separate vendor"]
- [Excluded area 2]
- [Adjacent topics that may come up but are not part of this engagement]

Assumptions:
- [Client will provide X by Y date]
- [Access to Z team/data/systems will be available]
- [Engagement assumes no major org restructuring during the engagement period]

Out-of-scope items should address the top 3 things most likely to expand during the engagement based on the discovery conversations.

Step 4: Define Roles and Responsibilities

Consulting engagements fail when the client expects the consultant to do everything and the consultant expects the client to do everything.

Template:

Consultant responsibilities:
- [What you will produce, facilitate, or lead]
- [Decision-making authority you have]
- [Communication cadence you will drive]

Client responsibilities:
- [What they must provide: data, access, decisions, approvals]
- [Who the day-to-day point of contact is]
- [Executive sponsor: name, role, availability]
- [Time commitment expected from client team: e.g., "4 hours/week from project team"]

Shared responsibilities:
- [Joint activities, e.g., "Co-facilitate working sessions"]

Block's principle: the client must be a participant, not an audience. If the client will not commit to specific responsibilities, the engagement is at risk before it starts.

Step 5: Governance and Decision Rights

Define how decisions will be made and who can make them.

Template:

Decision authority:
- [Scope changes]: [Who approves - e.g., Executive Sponsor only]
- [Timeline changes]: [Who approves]
- [Budget changes]: [Who approves]

Escalation path:
- Day-to-day issues: [Primary contact]
- Engagement-level issues: [Project lead]
- Escalation: [Executive sponsor]

Change management:
- Any work outside agreed scope requires a signed change order before proceeding.
- Change orders will document: description of change, impact on timeline, impact on fee.

Never do out-of-scope work without a written change order, even a brief email confirmation. Verbal agreements on scope changes are how engagements become unprofitable.

Step 6: Boundaries and Ground Rules

Explicitly name the behaviors and boundaries that make the engagement work.

Template:

Communication:
- Status reports: [Weekly/biweekly, by whom, to whom]
- Escalation: [How and when issues get escalated]
- Client availability: [When the consultant can reach the client, response time expectations]

Confidentiality:
- [What data/information will be treated as confidential]
- [What can be referenced in anonymized form for other clients or publications]

Engagement health:
- If either party believes the engagement is off track, [mechanism - e.g., a brief
  "engagement health check" call will be scheduled within one week]

The engagement health check clause is one of the most valuable things in a scope document. It creates a safe mechanism to surface problems before they become crises.

Step 7: Document and Confirm

Produce a 1-2 page Engagement Scope Summary. Send it to the client before the kickoff meeting, not after. Ask them to confirm or correct it in writing.

The confirming email framing: "Attached is my summary of what we've agreed to. Please review and let me know if anything looks different from your understanding. I want to make sure we start aligned."

Anti-Patterns

1. Scoping by activity instead of outcome Bad: "We will deliver 5 workshops and a final report." Good: "We will deliver a documented process redesign that reduces [step X] from 3 days to 4 hours." Activity scopes create arguments about whether workshops were "good enough." Outcome scopes create alignment on what was actually accomplished.

2. Skipping the out-of-scope list Bad: Listing only what's in scope and leaving adjacent areas undefined. Good: Name the top 3 things most likely to expand the engagement and explicitly put them out of scope. Scope creep starts in the gaps. If it's not listed as in scope or out of scope, it's a negotiation waiting to happen.

3. Verbal-only contracting Bad: "We talked about it in the kickoff and everyone was aligned." Good: Written scope summary confirmed by the client in writing (even an email reply saying "looks right"). Memory is unreliable. Priorities change. Written agreements survive personnel changes.

4. No client responsibilities section Bad: Listing only what the consultant will do. Good: Explicitly naming what the client must provide, and when. When a client fails to provide agreed inputs (data, access, decisions), the engagement stalls. Written responsibilities give you a professional basis for addressing the delay.

5. No change order process Bad: Saying yes to client requests informally and absorbing scope creep. Good: A brief written change order process that both parties agreed to at kickoff. The change order process does not have to be bureaucratic. An email confirmation is enough. The goal is a written record.

Quality Checklist

• [ ] Problem statement written in business language and confirmed by client
• [ ] Success criteria are outcome-based, not activity-based
• [ ] In-scope list is specific (not "strategy work")
• [ ] Out-of-scope list addresses the most likely expansion areas
• [ ] Client responsibilities are named, not implied
• [ ] Executive sponsor is identified by name and role
• [ ] Decision rights defined for scope, timeline, and budget changes
• [ ] Change order process agreed upon
• [ ] Engagement health check mechanism included
• [ ] Scope summary sent to client before kickoff and confirmed in writing

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: qa-aman
• Source: qa-aman/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.