Transformation Program Governance: Who Owns Knowledge Across Discovery, Delivery, and Adoption
Avery Brooks
May 8, 2026
Governance is what breaks the cycle that causes 70% of transformation projects to fail. Not governance as a committee that approves timesheets, but governance as clear ownership of who knows what, when they need to know it, and how knowledge flows from one phase of the transformation to the next. As we explore in "The Transformation Knowledge Gap," this knowledge continuity problem is at the root of most transformation failures—and governance is how you fix it.
Most transformations define governance as a steering committee. The steering committee approves the budget. They review the status report. They make decisions when there's a conflict. That's true, but it's not governance in the sense that matters. That's governance of the project machine. What's missing is governance of the transformation's knowledge—the context that matters more than the budget.
During discovery, one team learns everything about current operations. They map processes, understand workarounds, talk to every stakeholder. They build a comprehensive view of the operational reality. Then discovery ends. The discovery team moves to the next project. The knowledge stays with them or gets lost in a document nobody will read.
During design, a different team creates a future state. They're building on what discovery found, but discovery knowledge is incomplete—most of what matters was never documented. So design makes assumptions. They assume the workarounds don't matter. They assume the informal dependencies will disappear. They assume the constraint that discovery uncovered isn't as important as it seemed. Design finishes. Delivery begins.
During delivery, the assumptions collide with operational reality. A team can't use the new system the way it was designed because of a dependency that wasn't known in design. A workaround that discovery found turns out to be a hard constraint, not a problem to fix. A workflow that design thought was simple turns out to have five informal steps that are critical to how work actually gets done. Delivery becomes problem-solving rather than implementation.
The transformation knowledge that matters isn't formalized. It's held by the people who did the work. When those people move on, the knowledge leaves. And when knowledge leaves, each phase has to rediscover the same operational reality. Governance fixes this by making someone accountable for knowledge continuity across the lifecycle.
Governance doesn't fail because organizations don't want governance. It fails because nobody owns the knowledge. In a well-governed transformation, someone is accountable for knowing the current state. Someone is accountable for understanding the constraints and dependencies. Someone is accountable for translating discovery into design assumptions. Someone is accountable for validating whether design assumptions held in reality. Someone is accountable for capturing what was learned in delivery so that adoption doesn't rediscover the same problems.
But in most transformations, that someone is undefined. The discovery team owns discovery output. The design team owns design output. The delivery team owns implementation. But nobody owns the knowledge that flows between them. Nobody is accountable for whether design actually understands what discovery found. Nobody is accountable for whether the design assumptions held in reality. Nobody is accountable for whether delivery insights made it to adoption planning.
The result is a knowledge gap at every phase boundary. It's not because people aren't trying. It's because responsibility for knowledge isn't explicit.
Governance fixes the knowledge gap by making someone responsible for it. A Knowledge Steward. Not a knowledge manager or knowledge architect. A steward. Someone accountable for stewarding knowledge through the transformation lifecycle.
A Knowledge Steward doesn't create knowledge. The discovery team creates discovery knowledge. The design team creates design knowledge. The delivery team creates delivery knowledge. But the steward is accountable for making sure knowledge flows and is understood at every phase boundary.
The steward makes sure that design understands what discovery found. Not just the formal findings in the discovery report, but the operational reality that matters. A discovery team identifies that a workflow has five informal steps before the formal process starts. A steward makes sure design knows this matters and either designs to accommodate it or explicitly accepts the risk of not accommodating it.
Every design is built on assumptions. A steward makes sure those assumptions are documented and that delivery knows what they are. When delivery finds an assumption was wrong, it's not a surprise. It's feedback into the assumption tracking system.
Delivery teaches the organization how to operate the new way. A steward is accountable for making sure adoption teams know what delivery learned so they can plan adoption without rediscovering constraints.
The role doesn't require creating new knowledge. It requires establishing explicit ownership for knowledge flow. Here's how to implement it:
When the transformation launches, make it explicit who is accountable for making sure knowledge flows from discovery to design, from design to delivery, and from delivery to adoption. Name one person. Make it a role that spans phases. This prevents the handoff problem where every phase transition loses knowledge.
When a phase completes, the gate shouldn't just ask "Are deliverables done?" It should ask "Does the next phase understand what this phase learned?" The steward is accountable for that gate. This makes knowledge flow a governance requirement, not a nice-to-have.
The steward ensures there's a place for knowledge to live. A current-state decision log. A design assumption register. A delivery constraint tracker. These containers aren't bureaucracy; they're how knowledge survives phase boundaries.
At every phase boundary, run a structured handoff meeting. The outgoing phase presents what they learned. The incoming phase asks questions until they understand. This isn't a 30-minute thank you meeting. It's a substantive knowledge transfer session.
The Project Management Office often has the steward function by default. But PMO governance usually focuses on timelines and budgets, not knowledge. To avoid the 70% failure rate, the PMO needs to own knowledge governance as explicitly as it owns schedule governance. That means defining knowledge requirements at every phase gate, maintaining knowledge containers, running phase handoffs, and auditing whether knowledge actually transferred.
Effective knowledge stewardship requires visibility into what people actually know, what dependencies exist, and what constraints shape decisions. But gathering this information manually—through interviews, documents, and meetings—is slow and incomplete.
ClearWork serves as the operational intelligence platform that enables Knowledge Stewards to do their job effectively. Rather than relying on what people remember or what's documented, ClearWork uses AI-driven discovery to interview stakeholders asynchronously and surface the operational reality that governs decision-making.
The platform identifies:
This intelligence becomes the Knowledge Steward's information backbone. Rather than managing knowledge through documents and meetings, the steward works with a platform that continuously surfaces operational truth. Phase handoffs are more productive because both teams have access to the same operational intelligence. Design decisions are made with confidence because they're grounded in actual operational constraints, not assumptions.
A: For transformations under 18 months, the steward role can be part-time (60-70% of someone's time). For larger, multi-phase transformations, it should be full-time. The steward needs continuous presence to run handoffs, validate understanding, and capture knowledge as it emerges. Part-time stewards create a knowledge continuity gap.
A: The ideal steward has credibility with both the business and the delivery team. Someone from the delivery team (PMO, solution architect) who understands business operations works well. Someone from the business who understands how delivery works also works. The key is that they can speak the language of both groups and understand both the business intent and the technical constraints.
A: That's a governance conversation. The steward's role is to ensure the conversation happens and that the decision is documented. Design might say: "This constraint exists, but we're going to design around it." That's a valid decision. But it needs to be an explicit decision with documented rationale, not an implicit assumption. Document what was discovered, what was decided, and why.
A: Build it into the adoption gate. The gate requires that adoption demonstrates they understand what delivery learned. Ask adoption teams: "What constraints emerged during delivery? How are you planning for them? What workarounds did delivery need? Are you planning to eliminate them or preserve them?" If adoption can't answer these questions, the gate holds.
A: Yes. The steward role can be assigned to an existing PMO person. The governance mechanisms (phase gates, knowledge containers, handoff meetings) can be added to existing governance structures. You don't need a major reorganization. You need clarity about who owns knowledge continuity and commitment to the four core practices: define the role, establish phase-gate requirements, create containers, and run handoffs.
Most transformations fail because nobody is accountable for knowledge continuity—knowledge dies at phase boundaries because there's no explicit ownership. A Knowledge Steward role solves this by assigning one person the accountability for ensuring that discovery knowledge flows to design, design intent flows to delivery, and delivery learning flows to adoption. When knowledge stewardship is governed as explicitly as schedule and budget, transformation success rates move from 30% to 70%+.