Skip to main content

4-Phases - Explained

Note: Visual Diagram below. But the video covers material not in the guide below — please watch in full.

Action Step

Complete this before moving on.

Open two or three implementation playbooks from the Playbooks Library and look at how the four phases map to each project. Notice how the weight of each phase shifts — a Growth Model project is strategy-heavy, while a CRM migration is engineering-heavy. Compare the sub-phases across the projects you picked and note where they differ.

Comment in Slack

Post your answer in your onboarding channel.

What was your biggest takeaway(s) from this training?


Why a Delivery Framework Exists

Every mature consultancy — McKinsey, Deloitte, Accenture, Bain — has a delivery framework. It's what allows them to deliver consistent results across hundreds of engagements, regardless of which consultant is doing the work.

LeanScale didn't need one when the team was small enough to handle everything with custom, hands-on work. But as the company scaled — more architects, more customers, more projects in parallel — quality became dependent on whichever architect was delivering, and ramping new architects took too long because everything was learned from scratch.

The four-phase framework standardizes how projects are executed while leaving room for the judgment that makes each engagement valuable. The four phases are Strategy, Engineering, Enablement, and Handoff. Each phase narrows a different type of uncertainty — strategic, technical, adoption, and continuity.

Use +/- or scroll to zoom into the diagram, drag to pan

4 Phases Framework
Use +/- or scroll to zoom into the diagram, drag to pan

Phase 1: Strategy

The goal is to get stakeholder sign-off on what you're building. The output is an alignment document and strategic package.

Strategy has its own phase because discovery gets rushed in most consultancies. People jump into execution without aligning on definitions, priorities, or what "done" looks like — and that's where scope creep and rework come from.

The architect mindset here is proactive. You come in with an opinion based on best practices from the playbooks, not a blank slate. If you show up without an opinion, you become an order taker. How the engagement starts dictates how it goes.

Pre-Kickoff runs two parallel tracks. The customer gets homework — educational material, a definition alignment doc, a prefilled intake form. The architect, with agent assistance, gathers inputs, drafts the current and future state, identifies gaps, and creates kickoff assets. By the time the kickoff happens, you're walking in with something 70% pre-filled.

Kickoff is where you present and validate assumptions. After the call, the transcript goes to Claude Code along with the playbook, and the agent produces the V1 asset. There's a mindset shift here: on the call, you're asking questions not just for your own understanding, but because the transcript is going to the agent afterward. You confirm, repeat, and get explicit so the AI has the context it needs.

Alignment Loop is iterative. Take V1 to the customer, get feedback, feed that transcript back to Claude Code, and it produces V2. Each round moves from assumed items to confirmed items. The customer never sees a blank slate.

Strategic Sign-Off is the formal checkpoint where definitions, current/future state, and gap analysis are all confirmed. For some projects — like Growth Model — the strategic deliverable is the actual product, and you skip directly to Handoff.


Phase 2: Engineering

The goal is to build and test the system based on the approved strategic package. Engineering separates the "what" from the "how to build it" — strategic language doesn't always map to how Salesforce or HubSpot thinks about things.

Claude Code translates the strategic package into a tech spec doc with field mappings, workflow logic, and build sequence. The architect and engineer then meet for an engineering handoff — the last checkpoint before building starts. During build and configuration, the engineer leverages Claude Code to implement directly via API or MCP, or to get step-by-step guidance where no API exists. QA and test covers both technical testing (does it work?) and customer testing (does it do what they need?).


Phase 3: Enablement

The goal is making sure the customer team can actually use what was built. Before Enablement became its own phase, training and documentation were afterthoughts — LeanScale would build something, and it would sit on the shelf.

Claude Code drafts training materials from the strategic and technical documentation — Loom scripts, guides, FAQs — tailored for different audiences. Executives get strategic interpretations; operators get tactical maintenance expectations. Training sessions are delivered live or via Loom. Projects that need it get a hypercare period with scheduled office hours and bug triages. Enablement sign-off confirms the customer can operate independently.


Phase 4: Handoff

The goal is a clean project closeout with a maintenance plan and a retention or expansion path. Without this as a distinct phase, you never really know when a project is done.

A maintenance schedule documents ongoing tasks — monthly, quarterly, annual. Claude Code drafts a one-pager from the playbook. Internal handoff transfers context between the project implementer and the embedded architect when applicable. External handoff formalizes completion and positions the next phase — for single-project customers, that means the next project or an embedded engagement. For embedded engagements, the maintenance schedule becomes a retention mechanism. You're planting seeds: in three months they'll need to revisit specific elements. Project close archives artifacts, finalizes billing, and runs an internal debrief to improve playbooks and agents.


Caveats and Operational Realities

This is not linear. Real projects loop. Engineers discover things in the build that change the strategy. The framework uses gate reviews, not gate locks — you advance, advance with conditions, or revisit.

This is V1. The four phases launched in Q1 2026 and are still being iterated on. Legacy accounts still follow the old approach. Don't treat this as dogma — your feedback as an architect or engineer is what improves it.

The weight shifts by project. Growth Model might be 80% Strategy. A CRM migration might be 80% Engineering. The four phases are the rails; the content within each phase is flexible. If the playbook says X but reality says Y, go with reality — then feed that back into the playbook so it gets smarter.