本文へ移動
cccskills
無料GitHub で公開

engagement-scoping

Define the scope, success criteria, roles, and boundaries for a consulting engagement. Use when a consultant says "help me scope this engagement", "I need to define what's in and out", "the client keeps adding things", "scope is getting fuzzy", "we need a contracting conversation", "I'm not sure what we actually agreed to", "help me set boundaries with a client", or "what should be in a kickoff". Also trigger when describing an engagement that feels like it is expanding without agreement, or when starting a new client relationship and preparing the initial contract or SOW.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md8.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

Design clean and consistent APIs. Use when the user says "design an API", "API design review", "design these endpoints", "REST API for X", "GraphQL schema", "API contract", "how should this endpoint work", "review my API design", or wants to create or improve an API interface - even if they don't explicitly say "API design".

日本語の概要は準備中です。原文の説明を表示しています。

qa-aman/claude-skills202026年9月10日 更新

qa-aman のスキルをすべて見る

このスキルの問題を報告する