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.
What has to happen before you decompose a capability?
Before decomposing anything, the domain owner and their team must expand their imagination about what AI makes possible — 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.
The scale of what is newly possible keeps expanding. McKinsey’s April 2026 research on the rise of the human-AI workforce estimates that more than half of current work hours are automatable with proven technology, while entirely new human-in-the-loop work (guiding, prompting, validating, and refining AI output) is being created alongside it.5 The McKinsey Global Institute sharpens the question leaders should carry into this phase: not which tasks can be automated, but which end-to-end workflows should be rethought.5 Decomposition done well operates at that altitude.
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.
How does capability decomposition actually work?
Capability decomposition follows a structured approach led by the domain owner and their VPs, typically with support from the CAIO’s AI-Business Translators who provide capability feasibility perspective. With AI fluency established, the decomposition proceeds from the business imperative down to specific capability requirements.
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. One more dimension is worth building into the triage: worker preference. Stanford’s 2026 audit of automation and augmentation potential across the US workforce introduced a Human Agency Scale that measures which tasks workers want automated and which they want augmented.6 Decomposition teams that ask that question alongside technical feasibility produce capability maps the workforce is far more willing to operate.
This decomposition discipline is no longer a niche practice. Deloitte’s 2026 Global Human Capital Trends names “AI Agent Orchestration” a critical competency for the AI era and defines it in exactly these terms: decomposing complex business tasks into sub-tasks, distributing them among agents, coordinating the work, and verifying the results. In Deloitte’s words, this is not programming, it is strategic workflow design.7
How do you handle data gaps during decomposition?
When your teams discover data requirements the current environment cannot satisfy, treat it as normal and expected rather than a crisis — during decomposition, such data gaps will inevitably surface. The question is not whether data gaps exist, but how to handle them when they do.
Gartner predicts that 60% of AI projects will be abandoned through 2026 because the data was not ready, a prediction it reaffirmed as its headline at the March 2026 Data & Analytics Summit.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 is the output of capability decomposition?
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.
How does a domain owner know the capability map is good?
The domain owner’s role during decomposition is not to produce the capability map, but to evaluate whether the map the team produces reflects the full potential of what AI makes possible, or whether it is trapped in pre-AI thinking. That quality test is the domain owner’s primary responsibility at this stage.
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.
What mistakes do teams make during decomposition?
The most common decomposition mistake is producing 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,“ November 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., prediction that 60% of AI projects will be abandoned through 2026 without AI-ready data, February 2025; reaffirmed at the Gartner Data & Analytics Summit, March 2026 https://www.gartner.com/en/newsroom/press-releases/2026-03-11-gartner-announces-top-predictions-for-data-and-analytics-in-2026
- 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
- 5.McKinsey, “The Rise of the Human-AI Workforce,” April 2026; McKinsey Global Institute, “A New Year’s Resolution for Leaders: Redesign Work for People and AI,” January 2026. More than half of work hours automatable with proven technology; new human-in-the-loop work; reframe from tasks to end-to-end workflows https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-rise-of-the-human-ai-workforce
- 6.Stanford University, “Future of Work with AI Agents: Auditing Automation and Augmentation Potential Across the U.S. Workforce,” 2026. Human Agency Scale (H1-H5); worker preferences on automation versus augmentation https://arxiv.org/pdf/2506.06576
- 7.Deloitte, “2026 Global Human Capital Trends: From Tensions to Tipping Points,” March 4, 2026 (9,000+ business and HR leaders, 89 countries). “AI Agent Orchestration” named a critical competency https://www.deloitte.com/us/en/insights/topics/talent/human-capital-trends.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