# Delivery Methodology --- # Lección: Use case identification and qualification LESSON 1 OF 7 · DELIVERY METHODOLOGY ## Not every use case earns a pilot. By the end of this lesson, you'll be able to qualify any use cases that are worth scoping and identify which three engagement patterns consistently produce a defensible ROI story at Day 30. The Qualification Filter ## Two types of gain. One of them survives a CIO readout. Before scoping a pilot, you need to know whether the use case produces structural change or marginal improvement. The distinction determines whether your ROI case holds at Day 30. Marginal Gain Does the same work faster The unit of work doesn’t change. Claude speeds up an existing task, reduces friction, or cuts time on something repetitive. Productivity gains are real but diffuse, and hard to isolate from other factors in a 30-day window. Examples: autocomplete, boilerplate generation, inline documentation. Good for adoption momentum. Difficult to anchor a CIO-level business case to. Structural Gain Changes what work is possible The unit of work itself shifts. A task that required a team of four and six weeks now requires two developers and two weeks. The ROI case is measurable before Day 30 and defensible at the readout. Examples: legacy migration at scale, new feature loops with full Claude participation, framework-level modernization. Anchors a renewal conversation. Engagement Mode ## Two activation modes. One changes the data you get. The scope decision happens at engagement entry. Mode 1 is a training-only activation. Mode 2 wraps it in a 30–45 day program. Mode 1 2-day training activation Code 101 and admin setup delivered as a standalone training event. Fast to deploy, minimal setup. Produces adoption signals but not ROI data: there’s no measurement period, no use case owner, and no baselined metrics to close the loop against. Mode 2 30-45 day program Training plus a structured activation: pre-kickoff setup, use case definition, a midpoint check at Day 20–25, and a closeout readout with champion-presented results. ROI data is available because the measurement infrastructure was built before Day 1. Where Claude Code Wins ## Three engagement patterns that consistently produce structural gains 01 Code modernization Migrate legacy stacks, translate languages, upgrade dependencies across a large codebase. Claude handles the volume; developers handle judgment calls on architecture. The ratio of Claude-assisted commits to total commits is directly measurable. 02 New feature build Accelerate net-new development through the full feature loop: scaffolding, implementation, tests, review prep. PR cycle time before and after is the core metric. Works best when the feature scope is clear and CLAUDE.md is well-invested. 03 Code migration Move between frameworks, cloud providers, or architectural patterns. Well-scoped, high-volume, low-ambiguity tasks ideal for agentic delegation. Velocity gain is visible within the first two weeks. Does This Use Case Qualify? ## Four criteria that separate a pilot-worthy use case from a wishlist item Not every use case that sounds promising passes qualification. Run each candidate through these four criteria before committing to a pilot scope. A weak score on any one is a signal to reframe the use case or deprioritize it. Volume means the task recurs frequently enough to generate meaningful data in 30 days. A one-off project doesn’t qualify regardless of complexity. Complexity means Claude adds real leverage, not just speed. If a junior developer could do the task in an afternoon, Claude’s contribution is marginal. If it takes a senior engineer three weeks, there’s structural gain available. Measurability means you can capture a baseline before Day 1. If you can’t measure it before the pilot starts, you can’t close the ROI loop at Day 30. This is non-negotiable. Developer readiness means the team is willing to change their workflow, not just try a tool. A pilot where developers use Claude occasionally around their existing habits produces flat metrics. Adoption has to be designed in. Qualification Rule A use case that scores well on complexity but fails on measurability is not a pilot candidate. It is a risk. Simulation · Make the Call ## The Arvana Technologies Qualification Arvana Technologies is a mid-market software firm with a 60-developer engineering team. Their CTO wants a Claude Code pilot. Three decisions, up to 6 points. Live Scenario The Arvana Technologies Qualification 3 decisions · 6 pts max Score  0/6 1 Decision 1 · Use case selection Arvana’s engineering lead proposes two use cases. Option A: using Claude Code to add unit tests to a codebase that already has 82% coverage. Option B: a Java-to-Spring Boot migration the team has been scoping for eight months. Which use case qualifies for the pilot? Choose one A Unit test generation 82% coverage is already high. Claude adds speed, not structural change. No meaningful baseline gap to close. Select B Java-to-Spring Boot migration High volume, pre-scoped, clear structural change. All four qualification criteria met. Select C Both, run in parallel The test case dilutes the ROI signal. Mixing structural and marginal use cases in one pilot makes attribution harder at the Day 30 readout. Select 2 Decision 2 · Baseline capture The team chooses the migration. Now determine which metric to baseline before Day 1. Which baseline metric gives you the most defensible ROI story at Day 30? Choose one A PR cycle time from ticket-to-merge for migration tasks Directly measurable before the pilot starts, captures the full Claude-assisted loop, and is visible in existing tooling. Select B Developer hours logged per migration task Useful but self-reported. Harder to audit and more susceptible to estimation bias than PR data. Select C Lines of code migrated per week A vanity metric. Claude produces more lines faster, but the line count doesn’t measure quality or completeness of migration work. Select 3 Decision 3 · Cohort composition You’re designing the pilot cohort. Arvana has 60 developers. Migration is the work. Which cohort design produces the most signal by Day 30? Choose one A 8–10 developers who own the migration backlog Deep signal from the people doing the real work. Metrics are traceable to actual tasks. Select B 20 developers across four different teams Broader signal but thinner depth. Mixed use cases and varying task types make the ROI story harder to attribute. Select C All 60 developers, starting with awareness training Too broad for a Day 30 readout. No use case ownership, no scoped tasks, no measurable starting point. Select Qualification Complete 0/6 Your decision trail Run the scenario again Course artifact · Lesson 1 contribution Delivery Plan Pack Delivery Plan Pack: Qualification section By the end of this course you’ll have a complete Delivery Plan Pack covering qualification, pilot design, ROI scorecard, and champion plan. This lesson contributes the qualification section. 1. Name the use case in one sentence. State what Claude Code will do in the context of a specific codebase or workflow. 2. Label it structural or marginal and explain why in two sentences. Reference the unit of work that changes (or doesn’t). 3. Score it on the four criteria: volume, complexity, measurability, developer readiness. Flag any criterion that is weak and note whether it can be addressed before the pilot starts. LESSON 1 OF 7 COMPLETE ## You can qualify a use case. Now design the pilot. The structural vs. marginal distinction is the first decision in every Claude Code engagement. Structural gains produce defensible ROI. Your qualification section is started. Up next · Lesson 2 Pilot design: cohort, scope, duration, and success criteria With a qualified use case in hand, the next decision is how to structure a pilot that produces a defensible answer at Day 30, not just a good feeling. --- # Lección: Pilot design LESSON 2 OF 7 · DELIVERY METHODOLOGY ## A pilot that can't be evaluated is not a pilot. By the end of this lesson, you'll be able to design a pilot that produces a defensible answer at Day 30 with the right cohort, a scoped use case, and success criteria locked before the work starts. Who’s in the Pilot? ## The cohort you choose determines the data you get. Cohort selection is a design decision, not an availability decision. The profile of your pilot developers directly shapes what the Day 30 readout can claim. Wrong cohort Willing participants Early adopters and enthusiasts generate high usage data and positive qualitative feedback. But they don’t represent the typical developer. Engagement metrics from this group won’t extrapolate to the broader team, and won’t hold up to scrutiny in a CIO readout. Right cohort Use case owners Developers who already own the work the use case targets. They have active tickets, familiar patterns, and a realistic starting baseline. Their before-and-after data is attributable and defensible. The metric story writes itself. Scoping the Pilot ## Scope and duration are design decisions, not defaults. The default “run it for a month and see what happens” produces inconclusive data. Explicit scope and duration produce a closing argument. 1 Define the target use case precisely Not “code modernization” but “Java-to-Spring Boot migration of the auth service module.” The more specific the scope, the cleaner the ROI attribution. 2 Choose the cohort based on ownership, not availability The developers actively working on the scoped use case, not those with the most calendar space. 3 Set the duration based on task cycle time Long enough for at least two complete task cycles (ticket-to-merge) per developer. For most migration work, 25–30 days is enough. 4 Lock the scope before Day 1 Scope creep during a pilot dilutes the ROI story. If a new use case emerges, log it for Phase 2 and protect the original scope. Before Day 1 ## Success criteria must exist before the pilot starts. If you don’t know what success looks like at Day 30, you can’t design the pilot to prove it. 01 Baseline metric The metric you’re trying to move, measured before Day 1. PR cycle time, task hours, migration velocity. Without a baseline, there’s no before/after story. 02 Target threshold The number that constitutes a win. “25% reduction in PR cycle time” is a claim. “PR cycle time improved” is not. Thresholds are what get quoted in renewal conversations. 03 Measurement method How you will capture the data. Existing tooling (git, JIRA, PR analytics) is preferable to self-reporting. Objective data survives scrutiny. 04 Target date The specific date you’ll assess. Day 30 is a milestone, not a deadline. Name it before the pilot starts so everyone knows what’s being measured when. Design Rule A success criterion you can’t measure before Day 1 is a hypothesis, not a commitment. Set the baseline before the kickoff meeting. Simulation · Make the Call ## The Kellner Industries Pilot Design Kellner Industries runs a 45-developer engineering team building enterprise infrastructure software. The CTO has approved a Claude Code pilot. Three decisions, up to 6 points. Live Scenario The Kellner Industries Pilot Design 3 decisions · 6 pts max Score  0/6 1 Decision 1 · Cohort selection Kellner has approved a pilot for their C++-to-Rust migration project. You’re selecting the cohort. The migration team has 8 developers. The broader engineering org has expressed interest. Which cohort design produces the most defensible Day 30 result? Choose one A The 8 developers who own the C++-to-Rust migration backlog Direct use case ownership. PR data is attributable, baselines are clean, and the Day 30 story is focused. Select B 15 developers across migration and two other teams More breadth, but mixed use cases make ROI attribution harder. The migration data will be diluted by unrelated work. Select C All 45 developers in an initial awareness cohort Generates adoption data, not ROI data. No use case ownership, no scoped baselines, nothing to present at Day 30. Select 2 Decision 2 · Success criterion The 8-developer migration cohort is confirmed. Now define the primary success criterion. Which success criterion gives you the most defensible story at Day 30? Choose one A Developer satisfaction score at Day 30 Useful qualitative signal but not a business case. CIOs want productivity data, not NPS scores. Select B PR cycle time from ticket-to-merge, with Day 1 baseline captured Clean, auditable, and directly tied to the use case. The Day 30 comparison is clean. Select C Lines of Rust code produced per developer per week Vanity metric. More code produced faster doesn’t mean better code or faster completion of migration milestones. Select 3 Decision 3 · Scope management By Week 2, two of the developers are excited about using Claude for a separate documentation project and want to expand the scope. What do you do? Choose one A Log documentation for Phase 2 and protect the migration scope Scope expansion mid-pilot dilutes the ROI story. One strong use case story beats two weak ones. Select B Let the two developers split their time, but track separately Manageable, but creates reporting complexity. The migration data will be thinner and the documentation data won’t have a baseline. Select C Expand the pilot to include documentation The Day 30 readout will have two mixed stories, neither with clean before/after data. Expansion decisions belong in Phase 2. Select Pilot Design Complete 0/6 Your decision trail Run the scenario again Course artifact · Lesson 2 contribution Delivery Plan Pack Delivery Plan Pack: Pilot design section By the end of this course you’ll have a complete Delivery Plan Pack. This lesson contributes the pilot design section. 1. Name your cohort: how many developers, which team, and why they are the right owners for the use case. 2. Write your primary success criterion in the format: “[Metric] will [improve/decrease] by [threshold] compared to the Day 1 baseline by [date].” 3. State how the baseline will be captured and from which system. 4. Define scope protection: what is explicitly out of scope for this pilot period. LESSON 2 OF 7 COMPLETE ## You can design the pilot. Now measure it. A pilot without defensible success criteria is a trial run, not an engagement deliverable. Cohort ownership, baseline capture, and scope protection are the three decisions that determine whether you have a Day 30 story worth telling. Up next · Lesson 3 Baseline capture and ROI measurement With a pilot designed, the next job is building the measurement infrastructure before Day 1, so the ROI story is auditable, not asserted. --- # Lección: ROI measurement LESSON 3 OF 7 · DELIVERY METHODOLOGY ## What you don't measure before Day 1 you can't prove at Day 30. By the end of this lesson, you'll be able to capture the right baselines before Day 1, track productivity across four metric categories, and build an ROI story that holds up in a CIO readout. Prefer to scroll? Show all topics The Measurement Window ## Baseline capture is the most important data collection moment in the engagement. The ROI story is written before Day 1. If you don’t have a baseline, you have an anecdote. The common failure mode is starting the pilot first and trying to reconstruct a baseline from memory or estimates after the fact. That reconstruction is always contested. Sponsors remember the past as better or worse than it was depending on whether they want the pilot to succeed. A captured baseline is objective data. An estimated baseline is a negotiation. For most Claude Code engagements, two to three data points are enough: PR cycle time from ticket-to-merge for the target use case, self-reported hours on the specific task category, and a developer NPS or satisfaction score. The first two are objective; the third is directional. Capture all three before kickoff. Measurement Rule A baseline captured after the pilot starts is already contaminated. Data collection is pre-work, not post-work. Next: Four metric categories Back: Why baselines are critical The Metrics Framework ## Four productivity metrics and how to collect them These four categories come from the Claude Code enablement playbook. Use them to structure both the baseline and the Day 30 scorecard. 01 Developer Productivity New feature development time, prototyping velocity, suggested code acceptance rate. Captured from PR analytics, JIRA, or sprint data. The core productivity story. 02 Code Quality First-pass review success rate, security fix velocity, code coverage changes. Captured from PR review data and static analysis tools. Signals whether speed came at a quality cost. 03 Usage and Adoption Daily/weekly active users, % using Claude Code after 30 days, hours in tool. Captured from Claude usage analytics. Shows whether adoption is real or nominal. 04 Sentiment and Culture Developer NPS, qualitative feedback, other-team interest. Captured from short surveys (3–5 questions). Leading indicator for expansion decisions. Next: Day 30 ROI narrative Back: Four metric categories Closing the Loop ## One headline number. One business implication. The Day 30 readout has one job: give the sponsor a number they can repeat in their next leadership meeting. 1 Lock the headline metric Choose the one metric from your four categories that most directly reflects the pilot’s use case. For a migration pilot, this is PR cycle time. For a feature build, it’s spec-to-working-code time. State it as a before/after comparison. 2 Add one business translation Convert the metric to business language. “PR cycle time dropped 34%” becomes “engineering team can ship the equivalent of 1.4x the features in the same sprint.” The translation is what the CIO quotes. 3 Build the Day 30 Scorecard A single page with: use case story (one paragraph), headline metric with before/after, supporting metrics from the other three categories, champion anecdotes, and a proposed Day 60 goal. This is the Activation Summary deck. Next: Simulation and artifact Back: Day 30 ROI narrative Simulation · Make the Call ## The Voxfield ROI Review Voxfield is a 30-day pilot at an enterprise SaaS company. The use case: new feature development velocity. Day 28. The data is in. Three decisions, up to 6 points. Live Scenario The Voxfield ROI Review 3 decisions · 6 pts max Score  0/6 1 Decision 1 · Headline metric The data shows: PR cycle time dropped from 8.2 days to 5.4 days (34% improvement). Developer satisfaction went from 6.2 to 7.8 out of 10. Lines of code produced per developer per week increased 55%. Which metric leads the Day 30 readout? Choose one A PR cycle time: 34% improvement from 8.2 to 5.4 days Objective, auditable, directly tied to the use case. The CIO can verify it from existing tooling. Select B Developer satisfaction: from 6.2 to 7.8 Real signal, but soft. Use it as supporting evidence, not the headline. Select C Lines of code: 55% increase Misleading. More code faster doesn’t mean faster feature delivery. The PR cycle time tells the real story. Select 2 Decision 2 · Business translation The headline is “PR cycle time dropped 34%.” Now translate it into business language for the CIO presentation. Which translation is most defensible? Choose one A Developers are 34% more productive Overstatement. PR cycle time is one productivity signal, not total developer productivity. Select B Claude Code is transforming our engineering culture Untestable claim. This belongs in a press release, not a business case. Select C The team ships features in 5.4 days that previously took 8.2 — equivalent to accelerating the roadmap by roughly 35% for this use case Precise, scoped to the use case, and directly translatable to roadmap velocity. Select 3 Decision 3 · Expansion recommendation The pilot data is strong. The CTO asks for your recommendation for the next 30 days. What’s the right expansion recommendation? Choose one A Expand the same use case to 20 developers, plus one new use case with its own baseline Controlled expansion. The existing ROI story continues to accumulate evidence while Phase 2 generates new data. Select B Roll out Claude Code to all 60 developers immediately Captures the momentum but loses the clean measurement structure. Usage data will be broad but thin. Select C Run another 30-day pilot with the same 8 developers before expanding Unnecessary. The data is sufficient. Delay risks losing sponsor momentum. Select ROI Review Complete 0/6 Your decision trail Run the scenario again Course artifact · Lesson 3 contribution Delivery Plan Pack Delivery Plan Pack: ROI scorecard section By the end of this course you’ll have a complete Delivery Plan Pack. This lesson contributes the ROI scorecard section. 1. Name the headline metric and state the Day 1 baseline value. 2. Write the business translation of your headline metric in one sentence: how does this metric map to roadmap velocity, engineering capacity, or cost? 3. List the three supporting metrics you’ll track from the four categories (Developer Productivity, Code Quality, Usage/Adoption, Sentiment). 4. Draft the Day 30 scorecard structure: use case story, headline metric comparison, supporting metrics, one champion anecdote, Day 60 goal. LESSON 3 OF 7 COMPLETE ## You can measure the pilot. Now watch it run. The ROI story is decided before Day 1. Baseline capture, objective metrics, and a precise business translation are what convert pilot data into an expansion decision. Up next · Lesson 4 The adoption curve With the measurement infrastructure in place, the next challenge is managing what actually happens to developer behaviour across the 30 days, and understanding why it rarely goes in a straight line. --- # Lección: Phased rollout and change management LESSON 4 OF 7 · DELIVERY METHODOLOGY ## Adoption is a curve. Every pilot follows it. By the end of this lesson, you'll be able to read the adoption curve, recognize the two dynamics unique to AI tool rollouts, and make the right call on when to intervene and when to let it run. The Progression ## From supervised to agentic: a predictable progression Every Claude Code adoption follows a three-phase curve. The phases don’t vary much by client. The duration and depth of each phase vary a lot. 1 Week 1: Supervised use Developers run Claude with manual approval for every action. They’re building trust in the output and calibrating their prompting style. Velocity is often slower than without Claude. This is expected. Don’t intervene on velocity in Week 1. 2 Weeks 2–3: Increasing autonomy Developers begin approving more actions in advance and running Claude on larger task chunks. Plan mode usage increases. Some begin exploring auto-accept mode on low-risk tasks. This is where CLAUDE.md quality starts to matter. 3 Week 3–4: Agentic mode for defined task classes Developers identify specific task types where Claude’s output is reliable and hand those off with minimal supervision. PR cycle time improvement becomes visible here. 4 Day 30+: Institutionalized pattern Usage is routine, not experimental. The team has developed informal norms about what to delegate, how to supervise, and how to brief Claude for new task types. This is the target state. It can’t be forced earlier. What’s Different About AI Adoption ## Two dynamics that don’t appear in ordinary tool rollouts Treat Claude Code like a SaaS rollout and you’ll misread the early data and intervene at the wrong moments. The week 1 dip Velocity slows before it accelerates Developers are learning a new interaction model, not just a new tool. The prompting loop, the supervision decisions, the judgment about what to delegate: these take time to calibrate. Usage will look low and output will look inconsistent. This is not a signal to intervene with training. It’s a signal that calibration is happening. The plateau effect Usage stabilizes at sub-optimal levels without a catalyst After the Week 1 dip, many developers find a comfortable usage level and stop experimenting. They’ve learned one or two delegation patterns that work and they stick to them. Without active champion intervention or a structured Week 2/3 session (Code 201, observability depth), plateau can look like adoption but the ceiling is much lower than it should be. This is when champion enabling matters. When to Intervene ## A developer is stuck. The question is whether to help now or wait. The wrong intervention at the wrong moment sends adoption backwards. There is a simple test. The test is whether the developer is stuck on a Claude Code problem or a workflow design problem. If they can’t get Claude to do what they want (hallucinated output, prompt failures, context issues), that’s a technical intervention — help now. If they’re doing the same tasks they always did and Claude is just a faster autocomplete, that’s a workflow design problem — the delegation pattern needs rethinking, not the prompting technique. Week 1 interventions: technical calibration, CLAUDE.md setup, first CLAUDE.md commit. Don’t push for velocity. Week 2 interventions: delegation pattern review, plan mode encouragement, Code 201 session. Watch for plateau. Week 3 interventions: auto-accept mode for defined task classes, hook configuration, agentic task structuring. Look for the teams whose usage is still climbing vs. those who plateaued. Week 4: document the usage patterns. What worked? What broke? What should the team’s CLAUDE.md say that it doesn’t say yet? Adoption Rule A developer who has stopped experimenting is not a success story. Plateau is not adoption. Simulation · Make the Call ## The Helios Software Day 16 Helios Software. Day 16 of a 30-day pilot. 10 developers. Java-to-Kotlin migration use case. The data is starting to come in. Three decisions, up to 6 points. Live Scenario The Helios Software Day 16 3 decisions · 6 pts max Score  0/6 1 Decision 1 · Reading the data PR cycle time is flat compared to baseline. Usage data shows developers averaging 45 minutes per day in Claude Code. Prompting patterns haven’t changed since Week 1. What does this tell you? Choose one A Adoption is failing: Claude isn’t helping with migration tasks The usage data contradicts this. Forty-five minutes daily is real engagement. The pattern hasn’t evolved, not collapsed. Select B The team has plateaued and needs a Code 201 session to advance delegation patterns Flat PR cycle time with consistent usage is the plateau signature. The tool is in their workflow but the ceiling hasn’t been raised. Select C It’s too early to draw conclusions Day 16 is not too early. This is exactly when plateau becomes visible. Waiting until Day 25 leaves insufficient time to intervene. Select 2 Decision 2 · Intervention choice You’ve identified a plateau. What’s the right move? Which intervention best breaks the plateau at Day 16? Choose one A Schedule a Code 201 session focused on plan mode and auto-accept for low-risk migration subtasks This directly addresses the delegation ceiling. Developers learn how to structure tasks for higher-autonomy execution. Select B Share examples of what other teams are achieving with Claude Code Useful context but doesn’t change the delegation pattern. Use it as motivation framing alongside the Code 201 session. Select C Increase check-in frequency to daily standups Monitoring doesn’t change behaviour. The plateau is a workflow design problem, not a visibility problem. Select 3 Decision 3 · Champion activation After the Code 201 session, one developer (Priya) has made rapid progress. Her PR cycle time is down 40% from baseline. The rest of the team is still at plateau. How do you use Priya’s progress? Choose one A Have Priya run a 30-minute demo showing her CLAUDE.md setup, delegation patterns, and two before/after PR examples Peer demonstration is the most effective adoption lever. It’s concrete, credible, and replicable by teammates. Select B Feature Priya in your weekly report to the CTO Good for stakeholder management but doesn’t change the team’s usage patterns. Use this alongside the peer demo, not instead of it. Select C Ask Priya to mentor each developer individually Scales poorly. Priya’s time is better spent on a single group demonstration than ten one-on-ones. Select Day 16 Simulation Complete 0/6 Your decision trail Run the scenario again LESSON 4 OF 7 COMPLETE ## You can read the adoption curve. Now build the team behind it. Adoption is a design problem, not an enthusiasm problem. Plateau is predictable and addressable. The three-phase curve gives you the language to describe what’s happening and the intervention map to respond. Up next · Lesson 5 Champion enablement Champions are the practitioners who turn individual adoption into team-wide change. The next lesson covers what they need to succeed and how to equip them. --- # Lección: Champion enablement and internal documentation LESSON 5 OF 7 · DELIVERY METHODOLOGY ## Every deployment needs someone whose job is to keep it working. By the end of this lesson, you'll be able to define the champion's role, hand over a CLAUDE.md worth inheriting, and set up a health check that tells you whether the deployment is still alive at 90 days. Role Definition ## Being a Claude Code champion is a specific role, not a title A named champion with a clear job description outlasts an enthusiastic team with no ownership. The difference between a deployment that compounds and one that decays is whether someone is actively responsible for it. What they do Active maintenance and growth Maintains and evolves CLAUDE.md files as the codebase and team practices change. Runs weekly office hours or a standing team channel. Onboards new developers. Escalates adoption blockers that need consultant support. What they don't do Be the only expert The champion is not the team's Claude Code help desk. Their job is to build the team's collective capability, not to field every question personally. If they become the sole knowledge holder, the deployment is fragile. What they need Documented handoff and escalation path A populated CLAUDE.md, a custom command catalogue with at least three to five commands, and a clear line to the consultant for issues that exceed their scope. The handoff conversation happens before Day 30, not on it. What makes a good candidate Influence plus intrinsic motivation Senior enough to influence team norms. Technical enough to write CLAUDE.md and evaluate custom commands. Intrinsically motivated, not assigned. The best candidates identify themselves during Phase 2 by engaging deeply without being asked. The Investment That Compounds ## CLAUDE.md is not documentation. It is institutional memory Claude reads every session. A team that invests 30 minutes a week in evolving their CLAUDE.md files gets compounding returns. Claude's behavior at the start of every session reflects the quality of what the team has written. A generic CLAUDE.md produces a generic Claude. A well-maintained CLAUDE.md encodes the team's conventions, patterns, preferred tools, and domain context, and every developer on the team benefits from every update another developer makes. Unlike a Salesforce configuration guide that sits in Confluence until someone needs it, CLAUDE.md is active: it shapes Claude's behavior in real time. The champion's job is to treat it as a living artifact, not a one-time deliverable. The engagement handoff should always include three components in addition to the champion plan: a CLAUDE.md that covers company conventions at the enterprise level, at least one repo-specific CLAUDE.md for the project the pilot cohort worked on, and a custom command catalogue with at least three to five commands documented with frontmatter, parameter descriptions, and example invocations. These are covered in detail in Courses 4 and 5. If the pilot team hasn't built them, that is the work of Phase 3 and the handoff session. Handoff principle The quality of a deployment 90 days after you leave is determined by the quality of the CLAUDE.md you hand over. Check your understanding ## Champion enablement: true or false? Three statements about champion selection and the role of CLAUDE.md in sustainable deployments. Activity · True or false? Select an answer for each statement. "The champion should be the most technically advanced developer on the team." True False False. Technical fluency matters, but influence and intrinsic motivation matter more. The most technically advanced developer may have unusual workflows that don't generalize to the team. The champion needs to shape team norms, not just be good at the tool personally. "CLAUDE.md should be finalized and stable before the engagement ends." True False False. CLAUDE.md is a living document that should evolve continuously as the team's codebase, practices, and Claude usage patterns develop. "Finalized" is the wrong framing. The handoff should include a CLAUDE.md that is good enough to produce meaningful improvement immediately, plus a clear owner who will evolve it. "Custom commands are optional at handoff if the team is small." True False False. Custom commands encode the team's best Claude Code practices in a reusable form that survives personnel changes. A small team that doesn't invest in commands in the first 30 days typically doesn't build them later, and they lose one of the highest-leverage configuration tools in the stack. Three to five commands is a low bar and should be non-negotiable at handoff. Key point: The champion role requires influence and motivation, not just technical skill. CLAUDE.md is a living artifact, not a deliverable. Custom commands at handoff are required infrastructure, not a nice-to-have. Course artifact · Lesson 5 contribution Delivery Plan Pack Delivery Plan Pack: Champion plan section This lesson contributes the champion plan section, the final component of the Delivery Plan Pack. 1. Name the champion candidate: role, why they are the right choice (influence, motivation, technical fit). Note if they identified themselves during Phase 2 or were selected. 2. List the three artifacts you will hand to the champion at engagement close: CLAUDE.md (enterprise and repo-level), custom command catalogue (minimum three commands), escalation path. 3. Write one sentence describing how you will measure champion effectiveness at the 30-day post-engagement check-in. Name the metric or signal you will use. LESSON 5 OF 7 COMPLETE ## You can enable a champion. Now prevent the failure modes. A named champion with a documented role, a strong CLAUDE.md, and a custom command catalogue is the difference between a deployment that compounds and one that decays. Your Delivery Plan Pack is one lesson away from complete. UP NEXT · LESSON 6 Common failure modes and how to preempt them Six failure modes appear consistently across Claude Code deployments. None of them are technical. Lesson 6 covers the pattern and the preemption for each. --- # Lección: Preempting common failure modes LESSON 6 OF 7 · DELIVERY METHODOLOGY ## Most deployments don't fail on the technology. They fail on the handoff. By the end of this lesson, you'll be able to spot all six failure modes that appear consistently across Claude Code deployments, what each one looks like before Day 30, and the specific action that prevents each one. What Goes Wrong ## Six failure modes. All of them are preemptable. None of these failures are technical. Every one of them is a process gap that appears before Day 30 and compounds after the consultant leaves. Failure 1 No baseline captured The ROI case falls apart at the Day 30 readout because there is no before state to compare against. The sponsor has no defensible number. Renewal conversation cannot land. Preemption: baseline sprint in the week before kickoff, non-negotiable. Failure 2 Champion not identified Adoption drops sharply 30 to 60 days after the engagement ends. No one owns the CLAUDE.md. New developers don't get onboarded. The deployment decays to zero within a quarter. Preemption: name the champion by Day 15, begin handoff preparation in Phase 2. Failure 3 Use case too marginal Metrics look flat at Day 30 even with high usage. The sponsor expected transformational impact and saw incremental improvement. Executive support evaporates and the renewal fails on scope, not execution. Preemption: run the structural vs. marginal qualification from Lesson 1 before scoping the pilot. Failure 4 Supervised mode stagnation Usage metrics are low or plateau after week one. Developers report the tool is "slow" or "not useful." PR cycle time doesn't change. The Day 30 readout has no productivity story. Preemption: weekly CoE touchpoint with usage review; workflow-fit coaching for stalled developers in Phase 2. Failure 5 CLAUDE.md not maintained Claude reverts to generic behavior as the codebase evolves past what the initial CLAUDE.md describes. Team trust erodes. Developers stop using Claude for complex tasks. Adoption regresses to supervised mode. Preemption: weekly CLAUDE.md review as a named champion responsibility; include in the champion plan artifact. Failure 6 Readout not tied to business outcome The Day 30 readout presents usage metrics and developer testimonials but no business-level translation. The CIO is not engaged. The conversation moves to cost rather than value. Renewal stalls in procurement. Preemption: align the CIO narrative with the sponsor in week one using the framework from Lesson 3. What Leaving Well Looks Like ## A clean engagement close has four artifacts If any of these four artifacts is missing at Day 30, the deployment's 90-day health is at risk. The list is short by design. Every item on it addresses at least one of the six failure modes above. Delivery Plan Pack (complete). All four sections: qualification, pilot design, ROI scorecard, and champion plan. This is the document that anchors the renewal conversation and serves as the reference point for phase two scoping. CLAUDE.md and custom command catalogue. A populated enterprise-level CLAUDE.md, at least one repo-specific CLAUDE.md for the pilot project, and a command catalogue with a minimum of three to five documented commands. These are the primary tools the champion needs to maintain deployment quality without consultant support. Day 30 readout with metrics against success criteria. The headline number, the supporting data, and the CIO narrative. The readout should be in the client's hands 48 hours before the showcase meeting, not distributed during it. Named champion with documented escalation path. A person, a role description, and a clear line to the consultant for issues that exceed the champion's scope. Include the 30-day post-engagement check-in date in the handoff documentation before you leave. Scenario ## Which items put this deployment at risk? A Day 30 readout is two days away on a 12-developer pilot. Review the engagement status below. Select the 3 items that indicate this deployment is at risk of not renewing. 0 / 3 selected HIGH ROI measurement No baseline captured in the week before kickoff Pre-pilot data collection was deferred to week one of the pilot LOW Adoption Four of 12 developers are still in supervised mode at Day 28 Tracked in weekly CoE touchpoint notes HIGH Champion plan No champion identified as of Day 28 Champion conversation has not happened yet LOW Productivity metrics PR cycle time improved 20% vs. baseline for the migration cohort GitHub data, weeks 2 to 4 HIGH Configuration No custom commands built during the pilot CLAUDE.md exists but command catalogue is empty LOW Usage telemetry Usage data shows three developers at high weekly session counts Claude Code telemetry dashboard Result 0 of 3 correct The three risks are: no baseline (the ROI case has no before state to anchor to), no champion identified (the deployment has no owner after Day 30), and no custom commands (the handoff lacks the configuration infrastructure the champion needs to maintain quality). The non-risks are all normal pilot variance: some developers still in supervised mode at Day 28 is expected and not a renewal risk. A 20% PR cycle time improvement is a good result that should anchor the CIO narrative. Three high-usage developers are champion candidates, not a risk signal. Run the scenario again Course artifact Course artifact · Complete Delivery Plan Pack: All four sections complete You have built the complete Delivery Plan Pack across this course. Four sections, each one directly connected to the engagement decisions it supports. - Qualification section (Lesson 1): use case named, structural or marginal labeled, four criteria scored - Pilot design section (Lesson 2): cohort, scope, duration, two to three measurable success criteria - ROI scorecard section (Lesson 3): three baselines, telemetry metrics, CIO headline number - Champion plan section (Lesson 5): champion candidate named, three handoff artifacts listed, post-engagement health check defined LESSON 6 OF 7 COMPLETE ## You can preempt the failure modes. Now see what 30 days actually looks like. Six failure modes. None of them technical. All of them preemptable before Day 1. A clean handoff with four complete artifacts is the difference between a deployment that renews and one that decays. UP NEXT · LESSON 7 What a 30-day Claude Code activation looks like Walk through the full activation arc: pre-kickoff discovery, weekly rhythm, Day 30 showcase, plugin handoff. The Delivery Plan Pack comes together here. --- # Lección: 30-day Claude Code activation ## 30-day Claude Code activation LESSON 7 OF 7 · DELIVERY METHODOLOGY ## Thirty days. Here's what actually happens. By the end of this lesson, you'll have walked through the full activation arc: from pre-kickoff discovery to the Day 30 showcase, the weekly rhythm that holds it together, and what a clean handoff looks like in practice. The 30-Day Shape ## Five phases. Each one has a clear job and a clear exit condition. The activation arc is not a project plan with tasks. It is a rhythm with phase gates. Knowing when to exit each phase is as important as knowing what to do in it. 1 Pre-kickoff discovery Use case qualification using the framework from Lesson 1. Cohort selection and availability confirmation. Baseline data collection from version control. Draft CLAUDE.md for the pilot project. Exit condition: baseline captured, CLAUDE.md drafted, cohort confirmed, kickoff date set. 2 Week 1: Onboarding sprint All cohort members install Claude Code, connect to the approved deployment configuration from Course 3, and run their first tasks in supervised mode. First office hours session on Day 3 or 4. Exit condition: full cohort is active, no installation blockers outstanding. 3 Weeks 2 to 3: Active pilot Weekly CoE touchpoint on Day 8 and Day 15. Usage data review at each touchpoint. Workflow coaching for stalled developers. Champion candidate identification in week three. Exit condition: at least half the cohort has moved past supervised mode; champion candidate identified. 4 Week 4: Ramp and showcase prep Compile metrics against success criteria. Draft Day 30 readout and CIO narrative. Champion conversation and handoff preparation: CLAUDE.md review, command catalogue build, escalation path documented. Readout delivered to sponsor 48 hours before the showcase. Exit condition: readout sent, champion briefed, four artifacts complete. 5 Day 30: Showcase and readout Live demo from two or three cohort developers using real code on the pilot use case. Metrics readout against success criteria with headline number first. Renewal conversation: what phase two looks like, who the champion is, what the next 90 days unlock. Sponsor in the room. If the sponsor is not available, reschedule. What Happens Every Week ## Two recurring touchpoints. Both on the calendar before Day 1. The weekly rhythm is what separates an activation from a deployment. Deployments happen once and drift. Activations have a structured weekly cadence that holds the adoption curve in place. CoE touchpoint (30 minutes, consultant-led). Runs on Day 8 and Day 15. Agenda is consistent: review usage data from the previous week, identify any developers stuck in supervised mode, agree on one concrete coaching action per stalled developer, and check the CLAUDE.md for needed updates. This meeting is with the champion candidate or engineering lead, not the full cohort. Keep it tight. The decision coming out of this meeting should be a specific intervention or a green light to proceed. Office hours (60 minutes, open attendance). Developer Q&A format. No fixed agenda. Developers bring real tasks, real friction, and real code. The first session is consultant-led. The champion candidate co-facilitates from session two onward. By session three, the champion runs it and the consultant observes. This is the primary handoff mechanism: not a conversation about owning office hours, but doing it while still supported. Both touchpoints should be calendar items with video links created before the kickoff meeting. Scheduling them after kickoff introduces friction and signals that the structure is not fixed. Treat them as immovable until the Day 30 showcase is complete. How to Run the Readout ## Three parts. Thirty minutes. Sponsor in the room. The Day 30 showcase is not a project update. It is a business case presentation with a live demo. Structure it accordingly. Part one: Live demo (10 minutes). Two or three cohort developers show Claude Code on a real task from the pilot. Not a prepared script. Not a polished recording. Real code, real friction, real workflow. The rawness is the point: it shows the sponsor what a developer's day looks like six weeks after deployment. Pick developers who are at Stage 3 or 4 on the adoption curve. Stage 1 developers demo supervised mode interactions, which undersell the capability. Part two: Metrics readout (10 minutes). Lead with the headline number: "PR cycle time dropped 36% for the migration cohort over 30 days." Present the supporting data: adoption metrics, GitHub contribution metrics, developer sentiment. Frame every metric against the success criteria that were agreed before the pilot started. If the criteria weren't met, name them and explain why before the sponsor asks. Part three: Renewal conversation (10 minutes). What phase two looks like: broader cohort, additional use cases, or deeper integration. Who the champion is and what their role entails. The 90-day health check. A specific next step. The sponsor should leave the room with a decision to make, not a follow-up to schedule. Bonus course artifact Sample Activation Plan Your reference for the 30-day arc This lesson walked you through every phase of a Claude Code activation. Use this as your working reference for the next engagement: five phases, two recurring touchpoints, and the exit conditions that tell you when to move. 1. Map the five phases to real calendar dates for your client's engagement window. Assign an exit condition owner for each phase — usually the consultant for phases 1 and 5, the champion candidate for phases 2 to 4. 2. Schedule the CoE touchpoint (Day 8 and Day 15) and the office hours series before the kickoff meeting. Treat them as immovable. Calendar links go in the kickoff deck. 3. Draft the Day 30 showcase agenda in Week 4: three parts, 30 minutes, sponsor confirmed. Send the readout to the sponsor 48 hours before the session. Practice Try this You've covered the full arc of a Claude Code activation — from qualifying the use case to equipping the champion for handoff. To put it to work: take a sample client brief and run it through each stage. Qualify the use case, sketch a pilot design, define the ROI scorecard with real baselines, and draft a champion plan with a named candidate. If you can hand that document to a client's CIO and engineering lead and have both nod, the engagement is ready to start. Delivery Methodology · Complete ## You can run a Claude Code activation end to end. From use case qualification to Day 30 showcase, you now have the framework, the artifacts, and the decision vocabulary to deliver a Claude Code activation independently. The Delivery Plan Pack is your client-ready tool from first conversation to final handoff. Next up The Capstone Demonstrate practical competency across the core engagement workflows.