Building a Living Transformation System: Knowledge Architecture Across Phases
Avery Brooks
May 8, 2026
Seventy percent of transformation projects fail. But the failures aren't all the same. Some fail because the business case was wrong. Some fail because the team wasn't ready. Some fail because the technology didn't work. But most fail for a reason that's invisible in the project plan: knowledge doesn't flow across phases creating misalignment, missed requirements, and rework - pushing out timelines and diluting success.
A transformation moves through phases. Discovery. Design. Delivery. Adoption. Each phase is run by a different team. Each team creates knowledge about the transformation. But that knowledge doesn't travel to the next team. So each phase has to rediscover the same operational reality. And by the time a transformation realizes that knowledge is being lost, the failure is already baked in.
The difference between a 30% success rate and a 70% success rate is the difference between transformations that let knowledge die at phase boundaries and transformations that build a system to keep knowledge alive.
Want to learn more about the impact of the lack of consistent transformation intelligence? Check out our story defining and outlining the challenge of the Transformation Knowledge Gap.
Traditional transformations treat knowledge like it flows naturally from one phase to the next. It doesn't.
During discovery, a team interviews everyone. They map processes. They understand workarounds. They find the hidden dependencies that the formal process maps don't show. They build a comprehensive picture of how work actually gets done. This knowledge is gold. But when discovery ends, the team moves on. The knowledge either gets written into a document that nobody reads, or it stays locked in the heads of the people who discovered it.
Design doesn't have complete context. They know the formal process. They know the business requirements. But they don't know the informal coordination steps. They don't know that a system workaround is actually a hard constraint. They don't know that a workflow that looks simple in the process map has five hidden steps in reality.
So design makes assumptions. "This workaround will disappear because we're automating it." "This informal coordination will become formal in the new system." "This constraint isn't real—it's just how they've always done it." Design locks in. Delivery begins.
Delivery hits reality. The workaround isn't a workaround—it's a hard constraint. Teams can't use the new system the way it was designed because of a dependency that wasn't in the design. A process that design thought was optional turns out to be critical. Delivery becomes firefighting instead of implementation.
The transformation goes live. Adoption teams are responsible for helping the organization use the new way of working. But they don't know what delivery discovered. They don't know which workarounds were necessary. They don't know which constraints caused rework. So adoption plans based on the designed future state, not the operational reality that delivery learned.
And the cycle repeats. Every phase rediscovers the same operational truth. Every phase wastes time relearning what the previous phase knew.
Breaking this cycle requires a system that keeps knowledge alive across phases. A Knowledge Continuity Model. Not a knowledge repository or a knowledge management system. A model that explicitly owns how knowledge flows from one phase to the next.
The model has four layers:
Knowledge starts with evidence. What actually happens? Not what the process map says. Not what people think happens. What actually happens. Discovery captures evidence. Design should validate evidence. Delivery confirms what evidence was right. Adoption acts on evidence.
Without evidence, knowledge is opinion. With evidence, knowledge is actionable.
Evidence gets turned into decisions. Discovery finds a constraint. A decision gets made: accept it, redesign around it, or invest to remove it. Design makes assumptions. Decisions get made about which assumptions matter and which don't. Each decision should be documented: what was the question, what evidence informed it, what did we decide, why?
Without documented decisions, each phase has to rethink what the previous phase decided.
Decisions get executed. Delivery executes the design. Execution almost always surfaces new questions. A design assumption was wrong. A constraint showed up that wasn't expected. A workaround was necessary that wasn't planned. These become new evidence. New decisions get made. The execution knowledge flows back to inform the next phase.
Without capturing execution knowledge, the next phase learns nothing from what the previous phase did.
After execution, learning happens. What did we discover? What assumptions were right? What assumptions were wrong? What constraints were real? What workarounds were necessary? This learning becomes evidence for the next phase.
Without systematic learning, transformation knowledge dies when the phase ends.
The model creates a Knowledge Steward role. Not a person who creates knowledge. A person or system accountable for stewarding knowledge through the lifecycle. The steward's job:
The steward doesn't create knowledge. The teams do. But the steward makes sure knowledge doesn't get lost.
Start with three things:
Name one person & give them the tools they need to maintain consistency in knowledge. Make them responsible for knowledge continuity across all phases. Their tenure runs from program launch through adoption completion. They don't manage people. They manage knowledge flow.
The steward ensures there are places where knowledge lives:
At every phase boundary, the steward runs a structured handoff meeting. The outgoing phase presents what they learned. The incoming phase asks questions until they understand. Understanding gets documented. The handoff isn't optional. It's a governance gate. If the next phase doesn't understand what the previous phase learned, the gate holds.
When knowledge flows across phases, several things change:
Design makes better assumptions because they understand discovery reality. Delivery doesn't get surprised because they understand design intent. Adoption is successful because they understand what delivery learned. And future transformations learn from past transformations because the knowledge is preserved.
The difference: transformations that build a Knowledge Continuity Model succeed at much higher rates than transformations that let knowledge die at phase boundaries.
Seventy percent of transformations fail because knowledge doesn't survive phase transitions. Thirty percent succeed because they've figured out how to keep knowledge alive. The difference isn't complicated. It's the difference between treating knowledge as something that happens naturally and treating knowledge as something that requires explicit ownership. Build a Knowledge Continuity Model. Name a steward. Create containers. Run handoffs. Knowledge stays alive. Transformation succeeds.
The Knowledge Continuity Model requires that organizations understand what people actually know, what decisions have been made, what execution revealed, and what learning has emerged. But capturing this information across phases is difficult without a systematic approach.
ClearWork is the transformation intelligence layer that makes this possible. Instead of relying on meetings, documents, and institutional memory, ClearWork uses AI-driven operational discovery to interview people asynchronously across all phases and pair this with automatically ingested meeting transcriptions and any other unstructured information you have. The platform captures evidence of how work actually gets done, identifies the constraints and dependencies that matter, documents decisions and their rationale, and preserves the learning that emerges during execution.
The result: the Knowledge Steward has a comprehensive intelligence system that tracks knowledge continuity. The evidence container is populated automatically. Decisions are documented as they're made. Execution knowledge is captured in real-time. Learning is preserved and accessible to the next phase.
Instead of knowledge being held in people's heads or scattered across documents, it becomes a structured asset that flows across phase boundaries. The transformation intelligence layer ensures that design understands discovery. Delivery understands design intent. Adoption understands what delivery learned. And future transformations learn from past transformations.
A: A Knowledge Manager typically maintains a knowledge repository—they organize documents, manage databases, ensure information is accessible. A Knowledge Steward owns the flow of knowledge across the transformation lifecycle. They ensure that knowledge is created, captured, transferred, and embedded at each phase boundary. A Knowledge Manager is about storing knowledge. A Knowledge Steward is about knowledge movement.
A: The steward should allocate roughly 30-40% of their time to active knowledge continuity work (running handoffs, validating understanding, documenting decisions) and 60-70% to participating in phase activities and understanding what's happening. The goal isn't to create bureaucracy; it's to ensure knowledge flows while the transformation is happening.
A: That's a governance gate. If design doesn't understand discovery findings, the gate holds. Handoff meetings continue until the incoming phase demonstrates they understand. This creates short-term delay but prevents long-term rework. The cost of holding the gate is far lower than the cost of proceeding with incomplete understanding.
A: Track: (1) Time to understand context when moving to a new phase—is it getting faster? (2) Number of late-stage surprises—are hidden dependencies being surfaced earlier? (3) Adoption of documented decisions—are people following the decisions that were made, or are they rethinking them? (4) Engagement in phase handoffs—are people participating actively, or is it theater? If understanding time is decreasing and surprises are surfacing earlier, the model is working.
A: That's exactly why the Knowledge Continuity Model matters. Knowledge shouldn't live in people's heads; it should be documented and transferred. If knowledge is being actively documented and transferred at phase boundaries, departure of key people is disruptive but not catastrophic. The organization has captured what they know. If knowledge wasn't being transferred, that person's departure is a crisis. Build the model to prevent this scenario.
Seventy percent of transformations fail because knowledge doesn't flow from discovery to design, from design to delivery, and from delivery to adoption. The Knowledge Continuity Model solves this by creating explicit ownership of knowledge through each phase—using a Knowledge Steward role, creating containers where knowledge lives, and running structured handoffs where understanding is validated. When knowledge survives phase transitions, transformations move from a 30% success rate to a 70% success rate.