Phase 5: Enterprise Rollout - Why the Big-Bang Launch Fails Even When the Technology Works

Picture a company that clears its Phase 4 gate clean: CISO sign-off, compliance attestation, load test passed at 2x peak. The technology is ready. So the company does what feels like the natural next step and turns Claude on for its entire workforce in a single week, with a company-wide email, a link to the tool, and a one-page quick-start guide.

Ninety days later, adoption sits in the low double digits. Not that share using it daily, that share who logged in at all in the prior thirty days. The system has not broken. It performs exactly as hardening validated. What broke is the assumption that provisioning access is the same thing as adoption. Most employees try it once, ask a question the way they would ask a coworker, get a mediocre answer because they were never shown how to give the model context, and never open it again. There is no training, no examples specific to their actual work, and no one to ask when the first attempt underwhelms.

This is the fifth deep-dive in the series on the enterprise Claude deployment roadmap. Phase 1 covered discovery. Phase 2 covered infrastructure. Phase 3 covered pilot construction. Phase 4 covered hardening and compliance. Phase 5 is where a system that is technically ready gets adopted by an organization that is not yet trained to use it, and the wave model exists specifically to prevent this big-bang failure.

Phase 5 is the only phase in the roadmap that repeats. It runs in waves, and each wave's gate depends on the previous wave's real adoption numbers, not on a calendar date. The thirteen tasks organize into four functional groups.

5.1: Audience-Specific Training Curriculum

Training designed for 'everyone' trains no one well. A curriculum built for a claims processor needs different examples, different prompt patterns, and a different definition of a good outcome than one built for a sales engineer or a finance analyst. The task is to design training per role or business unit, grounded in the actual use cases that unit will touch, not a generic tour of the chat interface.

The most common failure is a single one-hour, one-size-fits-all training session that walks through interface features rather than showing people how to bring their actual work into the tool. Interface features are the least useful thing to teach. What determines whether someone becomes a regular user is whether their first few real attempts produce something good enough to want to try again.

5.2: Prompt Library Development

The prompt library gets seeded from the actual pilot use cases proven in Phase 3, not written speculatively. Each entry documents the prompt, the context it expects, and the kind of output it produces, so a new user in a rollout wave can start from a working example rather than a blank text box. A blank text box is the single biggest driver of the mediocre-first-attempt problem that stalls big-bang adoption.

5.3: Champion and Power-User Identification

Every business unit entering a wave needs at least one identified champion, someone who reached genuine proficiency during the pilot or an early wave and can answer questions inside their own team faster than a formal support ticket. Champions are not a formal role with a job description. They are the people other people already ask when something is confusing, given visibility and a small amount of protected time.

5.4: Self-Service MCP Server Catalog

As more business units come online, teams inevitably want to connect Claude to systems beyond the ones built in Phase 3. The catalog exposes the MCP servers that have already passed security review, in Phase 3's Task 3.5 and Phase 4's Task 4.1, as discoverable and self-service, so teams do not build shadow integrations to systems that were never reviewed. An MCP server catalog without this governance layer becomes exactly the unreviewed sprawl the security review process was built to prevent.

5.5: Center of Excellence Charter

The Center of Excellence owns standards across waves: prompt quality guidelines, MCP server governance, training curriculum maintenance, and the intake process for new use case requests that Phase 6 will formalize. The charter needs an actual staffing commitment, not a rotating volunteer assignment, because a CoE that exists on paper but has no dedicated time behind it becomes a Slack channel nobody monitors.

5.6: Support and Escalation Path

A dedicated support path for rollout-specific issues, separate from general IT support, because the failure modes are different: a confusing output, a prompt that doesn't work as expected, a use case that seems like it should be possible but isn't yet supported. General IT support triage is not equipped to answer 'why did the model refuse this request' or 'is there an MCP server for our CRM yet,' and routing those questions through a generic ticket queue adds exactly the friction that turns a curious first-time user into someone who gives up.

5.7: Wave 1 Launch

Wave 1 targets the pilot business unit, or the closest equivalent, at 25 to 50 users. This is deliberately small. The goal is not coverage. It is a controlled test of the enablement content and support infrastructure against a real, if limited, population before the infrastructure has to absorb the load of hundreds of new users at once.

5.8: Wave 1 Adoption Monitoring

A thirty-day monitoring window tracks whether Wave 1 users become active users, not whether they logged in once. Active is defined operationally: repeated sessions, not a single trial. Where adoption lags, the task is remediation, not just observation: identifying whether the gap is training, prompt quality, use case fit, or something in the support path, and fixing it before Wave 2 inherits the same gap at four times the population.

5.9: Wave 2 Launch

Wave 2 expands to two or three additional business units, 100 to 300 users, and only opens once Wave 1's adoption target has been met and remediated where it was not. This is the gate that a big-bang rollout skips entirely: there is no Wave 1 to learn from, so every failure mode shows up simultaneously across the full population.

5.10: Cross-Unit Prompt Library Sharing

As Wave 2 brings in new business units, the prompt library gets updated with patterns proven in Wave 1, and champions from Wave 1 become a resource for Wave 2's onboarding. This is where the wave model compounds in the organization's favor: each wave makes the next one easier, rather than each wave repeating the same discovery process in isolation.

5.11: Wave 3 Launch

The final wave brings on all remaining provisioned seats. By this point, the enablement content has been through two rounds of real-world validation, the support infrastructure has handled real load, and the Center of Excellence has a working intake process. Wave 3 is the largest population and, done correctly, the lowest-risk wave, because it inherits everything the first two waves learned.

5.12: Per-Wave Adoption Target Validation

For each wave, the target is a majority of provisioned users active within thirty days of launch, measured the same way Task 5.8 defined it: repeated use, not a single login. A wave that misses this target does not automatically open the next wave. It triggers remediation, the same diagnostic process from Task 5.8, applied at the current wave's scale, before anyone is added to the population.

5.13: ROI Demonstration Per Use Case

Before the next wave opens, the pilot use cases carried into the current wave need demonstrated ROI, measured against the baselines established in Phase 3's Task 3.10, not against a general sense that people seem to like it. This is the discipline that keeps rollout honest: adoption without demonstrated value is enthusiasm, not evidence, and enthusiasm alone is not a gate condition.

The Gate

Phase 5's gate is not a single event. It is the same two conditions, applied at every wave, before the next wave is allowed to open.

What Gets Deferred and Why

Two deferrals are common in Phase 5.

Role-specific training gets compressed into a single generic session because building curriculum for every business unit takes real time and the pilot already proved the technology works. The consequence is exactly the big-bang outcome: users whose first attempt does not match their actual work, judged as underwhelming, with no second attempt.

The wave gate gets treated as a formality, and business units get added on a fixed calendar rather than on demonstrated adoption, because a calendar is easier to plan against than a variable adoption curve. The consequence is that failure modes discovered in Wave 1 get inherited at scale in Wave 2 and Wave 3 instead of being fixed in between, and by the time the pattern is visible in the data, three times as many people have already had the same bad first experience.

Phase 6, Optimization and Evolution, opens next, and it is the only phase in the roadmap that does not have an end date. It is where a fully rolled-out deployment either gets tended, cost tuned, models kept current, new use cases intaken through a real process, or slowly drifts out of alignment with both the business and the platform it runs on. Next in the series: why 'we're in production' is not the finish line, and what the practice of ongoing optimization actually looks like month to month.