This article is part of a 27-article series on the AI Business Transformation Methodology. This piece focuses on Phase 3A: Capability Decomposition.
Your charter says “redesign the underwriting process so that 80% of standard applications receive a decision within 4 hours while maintaining or improving risk accuracy.“ That is a clear, outcome-defined Business Transformation Imperative. It tells you what to achieve.
It does not tell you what capabilities your organization needs to achieve it.
Capability decomposition is the process of translating a business outcome into the specific abilities your organization must develop. What must we be able to do that we cannot do today? This is the first substantive work at Level 3, and it determines the trajectory of everything that follows: the education cascade, the workflow redesign, the job redesign, and the AI enablement that eventually brings the transformation to life.
Get this right and every subsequent phase has clear direction. Get this wrong, or skip it, and the organization spends months redesigning workflows that solve the wrong problems or building capabilities that do not connect to the strategic intent.
Before You Decompose Anything: Expand Your Imagination
This is the single most important prerequisite for effective capability decomposition, and it is the one most organizations skip.
You cannot identify transformative capability requirements if you are looking at the imperative through the lens of what was possible before AI. If your understanding of AI is limited to what you have read in briefing decks or seen in vendor demonstrations, your capability decomposition will produce a list of incremental improvements: do what we do today, but faster. That is not transformation. That is optimization, and optimization is what produces the 88% adoption, 6% impact pattern that McKinsey’s research documents.1
The chicken-and-egg problem that existed at Level 1 (you cannot set strategy without understanding what AI enables, but you cannot deploy AI without strategy) now cascades down to your level. You cannot decompose your imperative into transformative capability requirements without understanding what AI now makes possible in your specific domain. Capabilities that were impossible or prohibitively expensive three years ago are achievable today. Capabilities that required entire teams can now be performed by a single person working with AI. Capabilities that required weeks of analysis can be completed in hours.
Before your team touches the capability decomposition, you and your VPs need to invest in understanding what has changed. Work with the CAIO’s department on a tailored engagement. Not a briefing. Not a demo. A working session where you experience what AI can do in contexts relevant to your operations and begin to see your imperative through the lens of what is newly possible.
The domain owner who invests two weeks in building this fluency before starting the decomposition produces a fundamentally different capability list than the one who delegates the decomposition immediately. The first produces capabilities that reimagine the domain. The second produces capabilities that automate the status quo.
The Decomposition Methodology
With AI fluency established, the decomposition follows a structured approach. The domain owner and their VPs lead this work, typically with support from the CAIO’s AI-Business Translators who provide capability feasibility perspective.
Start with the outcome and work backward. Take the imperative’s business outcome and ask: what must be true for this outcome to be achieved? Not what technology do we need, but what must the organization be able to do? For the underwriting example, the capabilities might include: the ability to assess standard risk profiles in minutes rather than days, the ability to route non-standard applications to human underwriters with pre-analyzed risk context, the ability to maintain audit trails that satisfy regulatory requirements at machine speed, and the ability to learn from each decision to improve accuracy over time.
Map the current state honestly. For each required capability, assess what exists today. Not what the process documentation says exists, but what actually happens. This is where tacit knowledge becomes critical. BCG’s research found that most enterprise processes include significant undocumented judgment, exceptions, and workarounds that experienced employees handle intuitively.2 If the decomposition team does not surface this tacit knowledge, the capability requirements will be incomplete, and the redesigned workflows will miss critical decision points.
Identify the gaps. The difference between what the organization can do today and what it needs to be able to do is the capability gap. Each gap falls into one of several categories: gaps that require workflow redesign (the process itself needs to change), gaps that require new AI-enabled technology (the tools do not exist in the current environment), gaps that require new skills (the workforce cannot yet do what the redesigned workflow requires), and gaps that require better data (the information the new capability needs is not available, not clean, or not accessible).
Categorize and prioritize. Not all capability gaps are equal. Some are foundational: they must be closed before other capabilities can be built. A data governance gap, for example, may need to be addressed before a predictive analytics capability can function. Some are sequential: capability A enables capability B. Some are parallel: they can be developed simultaneously without dependency. The prioritization determines the order in which the organization attacks the transformation.
The Data Dimension
During decomposition, your teams will inevitably discover data requirements that the current environment cannot satisfy. This is normal and expected. The question is not whether data gaps exist, but how to handle them when they surface.
Gartner predicts that 60% of AI projects will fail due to insufficient data quality.3 The decomposition phase is where this risk first becomes visible, and surfacing it early is one of the most valuable things the decomposition produces. For each capability requirement, the team should document: what data does this capability need, does that data exist, is it accessible, is it clean enough, and who owns it?
When the team discovers a data gap that blocks a critical capability, they have three options. First, scope the capability to what the current data can support, with a plan to expand as data matures. Second, include a data readiness workstream as a prerequisite in the transformation plan. Third, flag the gap to the Level 1 triad as a dependency that may require a foundational data imperative at Level 2.
The worst option is to design the capability as if the data exists when it does not. That produces workflow designs that fail in deployment, which is one of the seven pitfalls covered in Article 12.
What the Output Looks Like
The deliverable from Phase 3A is a capability map that connects the business imperative to specific, prioritized capability requirements. For each capability, the map should include:
The capability itself, described in business terms. Not “deploy NLP model“ but “analyze customer communications across all channels to identify emerging issues before they escalate.“
The current state: what exists today and how it performs.
The gap: what needs to change, categorized by type (workflow, technology, skills, data).
Dependencies: what must be true before this capability can be built (data readiness, adjacent capabilities, upstream process changes).
Priority and sequence: where this capability sits in the build order.
CAIO feasibility assessment: the CAIO team’s perspective on what is technically achievable, how reliable it is, and what constraints exist.
This map becomes the input for the next two phases. The education cascade (Article 11) uses it to focus the training on the specific capabilities the organization needs to build. The workflow redesign (Article 12) uses it to determine which workflows need to change and how. Without this map, both of those phases operate without clear direction.
The Quality Test for Domain Owners and VPs
As the domain owner, your role during the decomposition is not to produce the capability map yourself. It is to evaluate whether the map your team produces reflects the full potential of what AI makes possible, or whether it is trapped in pre-AI thinking.
Three questions serve as the quality test:
“If we were building this function from scratch today, knowing what AI can do, would we build it this way?” If the answer is “probably not,“ the capability list is too incremental. The team is improving what exists rather than reimagining what should exist.
“Have we identified capabilities that were impossible before AI?” A good capability map should include at least some requirements that simply could not have been met with previous technology. If every capability on the list is a faster or cheaper version of something the organization already does, the decomposition has not gone far enough.
“Does the CAIO’s team agree that these capabilities are technically achievable and worth pursuing?” The CAIO’s AI-Business Translators provide a feasibility check. If they say a capability is technically premature or that a more impactful capability was missed, the map should be revised. This is the productive tension between domain ambition and technical reality that produces the best outcomes.
Common Mistakes in Decomposition
Decomposing into technology requirements instead of capability requirements. If the capability list reads like a technology shopping list (“deploy chatbot,“ “implement ML model,“ “integrate AI platform“), the team has jumped ahead to Level 4. Pull them back. The question at Phase 3A is what the organization needs to be able to do, not what technology to buy.
Skipping the AI fluency investment. Teams that decompose without first understanding what AI makes possible produce capability lists bounded by yesterday’s assumptions. According to Deloitte, only 34% of organizations are truly reimagining their business, while 37% are using AI at a surface level with little or no change.4 The 37% are the organizations whose leaders did not invest in understanding what was newly possible before they started planning.
Treating the decomposition as a one-time exercise. The capability map should be revisited after the education cascade (Phase 3B), because the teams who go through substantive AI education often identify capabilities they missed during the initial decomposition. The map is a living document that gets sharper as the organization’s AI fluency deepens.
Ignoring cross-domain dependencies. Some capabilities your domain needs may depend on capabilities being built in adjacent domains. If the supply chain domain is redesigning its demand forecasting capability at the same time your domain needs that forecast data, the dependency must be identified and coordinated. Failing to surface these during decomposition creates integration failures during deployment.
Sources
- 1.McKinsey, “The State of AI in 2025,“ August 2025 (1,993 participants). 88% adoption, ~6% high performers https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- 2.BCG — research on tacit knowledge in enterprise workflow transformation, consistent with multiple publications.
- 3.Gartner, Inc., widely cited prediction on AI project data quality failures, 2024–2025.
- 4.Deloitte, “The State of AI in the Enterprise 2026,“ January 2026 (3,235 leaders). 34% truly reimagining; 37% surface-level https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html
Frequently Asked Questions
How long should the capability decomposition take?
For a well-scoped imperative, the decomposition typically takes three to four weeks of focused effort, not elapsed calendar time. This includes the AI fluency sessions with the CAIO’s team (one to two weeks), the decomposition workshops (one week), and the review and refinement cycle (one week). Rushing through it in a few days produces a shallow capability list. Stretching it beyond a month risks losing momentum before the education cascade begins.
Who should be in the room for the decomposition workshops?
The domain owner and their VPs should lead and participate. The CAIO’s AI-Business Translators should be present to provide feasibility perspective and to identify capabilities the domain team may not know are possible. Senior directors with deep operational knowledge should participate to ensure tacit knowledge is surfaced. Do not include more than 12-15 people. Larger groups produce lists rather than analysis.
What if the decomposition reveals that the imperative itself needs to be revised?
This happens and it is healthy. If the capability decomposition surfaces information that fundamentally changes the scope, feasibility, or expected value of the imperative, bring it back to the Level 1 triad through the governance cadence described in Article 4. The imperative was built on the best available information at the time. The decomposition may reveal realities that warrant adjustment. This is not a failure of Level 2 planning. It is the methodology working as designed.
How do we handle capabilities that require skills our workforce does not have?
Identify them during the decomposition and categorize them as skills gaps. Some can be addressed through the education cascade and targeted training. Some require new hires. Some require partnership with external expertise. The key is to surface them during Phase 3A rather than discovering them during workflow redesign, when the timeline pressure is higher and the options are more constrained.
Should we share the capability map with the broader organization?
The capability map should be shared with everyone who will be involved in the education cascade and the workflow redesign. It gives them context for why they are being trained on specific AI capabilities and what the redesigned workflows need to deliver. Transparency about the transformation’s direction builds trust and reduces the anxiety that comes from uncertainty. Keep the map at the capability level, not the technology level, so that it communicates business intent rather than technical plans.
This series addresses “what” to do, not “how” to do it. If you are a business executive and would like help thinking through the “how,” please feel comfortable reaching out.
Previous: Article 9: The Domain Owner’s Charter · Next: Article 11: The Education Cascade
© 2026 Plaster Group, LLC. All rights reserved. This article may not be reproduced, distributed, or transmitted in any form without prior written permission from Plaster Group. Brief excerpts may be quoted for review or commentary purposes with attribution to the author and a link to the original article.
Ready to move forward?
Let's discuss how your organization can build with AI — securely, strategically, and starting from where you are today.
Start a Conversation