Capability-based planning

G233 Business Capability Planning is a TOGAF Series Guide that describes the structured technique for turning capability maps into planning instruments. It builds directly on G211 Business Capabilities and connects capability assessment to roadmap priority, governance attention, and the depth of later architecture work.

G233 describes a structured planning process that transforms a capability map into actionable planning output. The full technique includes the following steps.

Step 1: Establish the capability baseline. Using the G211 capability map and assessment framework, document the current state of each capability across the maturity dimensions. This baseline must be evidence-based. Service metrics, incident records, audit findings, and stakeholder feedback are acceptable evidence. Opinions expressed in workshops without supporting data are not.

Step 2: Define capability targets aligned to strategic intent. For each capability, define the target maturity level required to deliver the enterprise's strategic goals. The target should be specific and measurable. "Improve customer connections management" is too vague. "Achieve average connection offer time below 30 working days with 95% accuracy" is a measurable target that later phases can design toward.

Step 3: Identify capability gaps. Compare baseline and target for each capability across all maturity dimensions. The gap is not a single number. It is a multi-dimensional picture that shows where the capability is weak and why. A capability may have adequate technology support but poor data quality and unclear governance. The intervention needed is different in each case.

Step 4: Assess capability dependencies. Many capabilities depend on other capabilities. Improving customer connections management may require improvements to network planning visibility and data quality management first. G233 recommends mapping these dependencies explicitly because they shape sequencing. A capability that blocks three other improvements should appear early in the roadmap.

Step 5: Prioritise capabilities for intervention. Using strategic importance, gap severity, dependency structure, and consequence of inaction, rank the capabilities that need attention first. G233 recommends against treating all capabilities as equally urgent. If the architecture team cannot rank capability urgency, the planning work is not finished.

Step 6: Define intervention types. Not every capability gap requires a system change. G233 recognises four broad categories of intervention: business change (new processes, roles, or accountability), governance change (new decision paths, review cycles, or ownership), information change (data quality improvement, new data sources, or integration), and technology change (new systems, platform upgrades, or integration). The planning step should name the intervention type, not default to technology.

Step 7: Feed into roadmap and transition architecture. The prioritised capability gaps and intervention types feed directly into Phase E (Opportunities and Solutions) and Phase F (Migration Planning). Capability planning is the bridge between business architecture and the implementation roadmap.

Heatmaps can be helpful if they summarise evidence and lead to an actual decision. They become useless when colours are assigned casually or when the map is not connected to a next step. G233 provides the planning discipline that prevents heatmaps from becoming decoration.

Three disciplines keep heatmaps honest.

1. Evidence anchoring. Every colour should be traceable to at least one piece of evidence: a service metric, an audit finding, a stakeholder complaint, or an incident pattern. If the colour was assigned in a workshop without reference to evidence, it is opinion, not assessment.
2. Decision linkage. Every high-priority capability should connect to a specific planning or governance consequence. If the colour does not lead to an action, it is decorative. G233 is explicit: capability assessments should influence investment priority, governance focus, and architecture depth.
3. Review cycle. Heatmaps should change over time. If the colours have not moved in twelve months, either the enterprise has made no progress or the assessment is stale. G233 recommends periodic reassessment aligned to governance and planning cycles.

G233 is clear that capability planning is useful only when it changes something downstream. Three categories of influence matter most.

Roadmap priority. Which capabilities need early attention because they constrain several other outcomes. A capability that blocks three other improvements should appear early in the roadmap. G233 connects directly to the Phase E and Phase F work that produces the implementation sequence.

Governance attention. Which weak capabilities require stronger review, clearer ownership, or tighter evidence. Planning should help the Architecture Board focus its limited attention on the capabilities that matter most. G233 recommends that governance priority should reflect capability priority.

Architecture depth. Which capabilities deserve deeper business, information, or technology analysis in later stages. Capability planning should tell the architecture team where to invest analytical effort, not spread it evenly. A capability assessed as strategically critical and currently weak deserves deeper analysis in Phase C and Phase D than one assessed as adequate and stable.

In London, capability planning is how the course prioritises the abilities that most affect connection speed, planning visibility, information publication quality, and resilience governance. Applying the G233 steps to the London capability map produces the following planning output.

Priority 1: Network planning visibility

Evidence: Planning data fragmented across GIS, spreadsheets, and legacy systems. Connection offers delayed because planning engineers cannot access a coherent network capacity view. Dependencies: Blocks improvements to connection offer generation, information publication, and evidence-backed decision-making. Intervention type: Information change (data integration) supported by technology change (shared planning data platform). Consequence of inaction: Connection timescales remain non-compliant; LTDS publication accuracy continues to decline.

Priority 2: Evidence-backed decision-making

Evidence: Governance decisions rely on manually assembled presentations rather than traceable evidence. Architecture Board reviews take place monthly regardless of urgency. Dependencies: Depends on data quality management and network planning visibility. Intervention type: Governance change (evidence-based review process) supported by information change (decision-support data feeds). Consequence of inaction: Governance remains reactive; programme decisions continue to be based on opinion.

Priority 3: Information publication

Evidence: LTDS data accuracy below regulatory expectation. Publication process is manual and error-prone. Dependencies: Depends on data quality management and network planning visibility. Intervention type: Information change (automated publication pipeline with quality gates) supported by business change (data governance accountability). Consequence of inaction: Regulatory non-compliance risk; reputational damage from inaccurate publication.

Priority 4: Customer connections management

Evidence: Average connection elapsed time exceeds industry median. Customer communication is inconsistent and often late. Dependencies: Depends on network planning visibility, connection design coordination, and delivery team accountability. Intervention type: Business change (end-to-end process redesign with clear accountability) supported by technology change (integrated connections platform). Consequence of inaction: Continued poor customer experience; regulatory scrutiny under connections reform.

Notice that the prioritisation places information and governance capabilities ahead of the customer-facing capability. This is because network planning visibility and evidence-backed decision-making are blocking dependencies. Improving the connections platform without first improving planning data and governance will produce a faster process that still generates inaccurate offers. The capability dependency analysis from G233 Step 4 is what reveals this sequencing logic.