COMPEL Certification Body of Knowledge — Module 4.1: AI Transformation Portfolio Leadership
Article 4 of 10
Dependencies are the hidden architecture of every AI transformation portfolio. They determine what can be built, when it can be built, and at what cost. Mismanaged dependencies are the single most common cause of portfolio-level failure — not because individual programs fail, but because the connections between programs collapse under the weight of uncoordinated execution. The EATP Lead must master the discipline of dependency orchestration: identifying, mapping, governing, and actively managing the web of interdependencies that binds the portfolio together.
The Dependency Challenge in AI Portfolios
AI transformation portfolios are inherently dependency-rich. Unlike a portfolio of independent construction projects or marketing campaigns, AI initiatives share data assets, technology platforms, governance frameworks, organizational structures, and talent pools. A customer analytics program depends on data quality standards being established by a data governance program. A model deployment automation program depends on infrastructure provisioned by a cloud migration program. A regulatory compliance program depends on model documentation standards developed by a governance program.
These dependencies create coupling between programs that can amplify delays, propagate failures, and create cascading disruptions across the portfolio. When a data governance program is delayed by three months, every program that depends on its deliverables is at risk — and the programs that depend on those programs are at risk as well.
The challenge is compounded by the fact that many dependencies are invisible at the time programs are launched. Programs are typically designed and approved independently. Their dependency analysis focuses on internal dependencies — the sequencing of activities within the program. Cross-program dependencies are often discovered only when a program reaches a milestone and finds that the input it expected from another program is not available.
Dependency Taxonomy
The EATP Lead must understand the taxonomy of cross-program dependencies to manage them effectively:
Data Dependencies
The most prevalent form in AI portfolios. Program A requires data that Program B is responsible for sourcing, cleaning, or governing. Data dependencies are particularly problematic because data quality issues compound — a deficiency in source data quality affects every downstream consumer.
Technology Dependencies
Program A requires a technology capability — an API, a platform feature, a deployment environment — that Program B is responsible for delivering. Technology dependencies are typically more visible than data dependencies because they involve formal interface contracts, but they can still be underspecified or misaligned.
Capability Dependencies
Program A requires an organizational capability — a trained workforce, a governance process, a decision-making framework — that Program B is responsible for developing. Capability dependencies are the hardest to manage because they involve human systems that resist precise specification and predictable timelines.
Governance Dependencies
Program A requires a policy, standard, or regulatory approval that Program B is responsible for obtaining. Governance dependencies create bottleneck risks because governance decisions often depend on organizational dynamics that neither program controls.
Resource Dependencies
Programs A and B compete for the same scarce resources — data engineers, AI/ML specialists, cloud architects, executive attention. Resource dependencies do not involve explicit deliverables passing between programs but create implicit coupling through shared resource constraints.
The Dependency Mapping Process
The EATP Lead leads a structured dependency mapping process that operates at two levels: initial mapping during portfolio design and continuous discovery during portfolio execution.
Initial Dependency Mapping
During portfolio design, the EATP Lead convenes cross-program workshops to identify dependencies. Each program team maps its external inputs — the deliverables, data, capabilities, and decisions it requires from other programs or from the enterprise — and its external outputs — the deliverables, data, capabilities, and decisions it produces that other programs consume.
These maps are consolidated into a portfolio dependency graph — a directed network that shows the flow of dependencies across all programs. The EATP Lead analyzes this graph for several characteristics:
- Critical paths: Chains of dependencies that determine the minimum possible portfolio timeline
- Bottleneck nodes: Programs or deliverables that appear as dependencies for many other programs
- Circular dependencies: Situations where Program A depends on Program B, which depends on Program C, which depends on Program A
- Long chains: Dependency chains with many sequential links, each of which introduces delay risk
- Orphan deliverables: Program outputs that no other program consumes, suggesting misalignment
Continuous Dependency Discovery
Initial dependency mapping captures the known dependencies. But AI transformation portfolios are complex adaptive systems — new dependencies emerge as programs evolve, requirements change, and the organizational context shifts. The EATP Lead must institutionalize processes for continuous dependency discovery:
- Dependency review sessions at each portfolio governance cadence
- Program interface reviews when programs pass through stage gates
- Dependency impact assessments when any program changes its scope, timeline, or deliverables
- Cross-program retrospectives that capture dependency-related issues and lessons learned
Dependency Governance Models
Identifying dependencies is necessary but insufficient. The EATP Lead must establish governance structures that ensure dependencies are managed actively.
Dependency Owners
Every cross-program dependency must have a named owner — a person accountable for ensuring that the dependency is satisfied on time, at the required quality level. Dependency ownership typically falls to the producing program's leadership, but the EATP Lead must ensure that the consuming program has visibility and escalation rights.
Interface Contracts
Critical dependencies should be formalized through interface contracts — documented agreements between the producing and consuming programs that specify what will be delivered, when it will be delivered, at what quality level, and what the escalation path is if delivery is at risk. Interface contracts bring the discipline of service-level agreements to cross-program dependencies.
Dependency Dashboards
The EATP Lead maintains a portfolio-level dependency dashboard that shows the status of all critical dependencies — on track, at risk, delayed, or blocked. This dashboard feeds into the portfolio performance reporting framework described in Module 4.1, Article 6: Portfolio Performance Dashboards and Executive Reporting and provides the portfolio governance board with early warning of dependency-related risks.
Buffer Management
The EATP Lead builds buffers into the portfolio schedule at dependency integration points. Rather than assuming that every dependency will be satisfied precisely on time, the EATP Lead allocates schedule and resource buffers that absorb normal variation in delivery timing. Buffer sizing should be risk-proportionate — critical path dependencies with high delivery uncertainty warrant larger buffers than well-understood dependencies with predictable delivery.
Dependency Orchestration Patterns
The EATP Lead applies several dependency orchestration patterns to reduce portfolio-level risk:
Platform-First Sequencing
Launch platform and infrastructure programs first, creating shared capabilities that multiple application programs can consume. This front-loads the portfolio with foundational work but dramatically simplifies dependency management for subsequent programs.
Parallel Path Strategies
When a critical dependency is at risk, establish parallel paths — alternative approaches that can deliver a functionally equivalent capability if the primary dependency fails. Parallel paths increase investment but reduce schedule risk for dependent programs.
Dependency Inversion
Restructure programs to reduce cross-program dependencies. If Programs A and B have a complex bidirectional dependency, consider reorganizing their scopes so that the shared work is consolidated into one program, eliminating the cross-program dependency.
Incremental Integration
Rather than waiting for complete deliverables to flow between programs, establish incremental integration points where partial deliverables are shared and validated continuously. This reduces integration risk and provides early warning of misalignment.
Connecting to Portfolio Risk
Dependency management is intimately connected to portfolio risk management. Unmanaged dependencies are portfolio risks by another name. The dependency map directly informs the portfolio risk aggregation framework discussed in the next article, Module 4.1, Article 5: Portfolio Risk Aggregation and Enterprise Risk Exposure.
The EATP Lead must ensure that the dependency management discipline and the risk management discipline are integrated — that dependency risks are captured in the portfolio risk register, that dependency mitigation strategies are reflected in the risk response plan, and that dependency status is reported alongside other portfolio risk indicators to the governance board.
© FlowRidge.io — COMPEL AI Transformation Methodology. All rights reserved.