High investment, capable professionals and modern technology increase the potential of a transformation. They do not guarantee that this potential becomes business value.
What separates activity from impact is the organization's ability to coordinate strategic direction, executive sponsorship, governance, architecture, engineering, data, security, artificial intelligence and value measurement as a system for organizational change, not as separate agendas.
This distinction matters because technology transformation is the continuous rewiring of business capabilities, not a single project with a clearly bounded beginning and end. The organization has to use technology at scale, adapt its operating model and capture value repeatedly.
The thesis here is consultative. Seven factors provide a practical structure for diagnosing where the conversion of investment into value is being constrained. The model is not a universal law and does not replace specialized frameworks. Its purpose is to make the executive discussion more objective. Which capability must evolve so the strategy can advance with acceptable cost, speed and risk?
Dispersed initiatives block the conversion of investment into value
Large organizations often already run broad portfolios covering modernization, automation, data, security and AI. The problem appears when each workstream optimizes its own outcome without a shared logic of value.
Strategy asks for growth, but the technology road map answers with a platform migration. Leadership asks for productivity, but the program measures the number of deliverables. Risk enters after architecture, supplier and schedule decisions have already been committed. Engineering accelerates a local flow while external dependencies leave the end-to-end time largely unchanged.
Under these conditions, the portfolio looks active and still produces little material change. The right diagnosis begins with three questions, not with "which technology should we buy?".
- Which business outcome needs to change?
- Which organizational capability is constraining that outcome today?
- What evidence will show that the capability has evolved?
The answers define the program. Without them, the company risks funding technically valid solutions for constraints that are not the most material.
The seven factors form a capability system
The seven factors are organized into three layers. The first establishes direction and legitimacy. The second converts intent into choices, boundaries and allocation. The third turns decisions into sustainable operating capability. Value measurement connects the three layers and lets the sequence of evolution be revised.
1. Strategic direction translates ambition into capability
Terms such as modernize, scale, automate and use AI are ambitions, not decisions. To guide investment, each ambition has to become a business outcome, a capability to develop and a testable causal hypothesis.
If the priority is to reduce the time to launch offers, the discussion may involve modular architecture, product autonomy, test automation and portfolio decisions. If the priority is to reduce operating cost, the focus may be process simplification, application rationalization, data quality or automation of repetitive activities.
Strategic direction is strong when it constrains choices. It clarifies what the organization intends to change, where it will not invest yet and which trade-offs it accepts. A strategy that accommodates every initiative does not guide the portfolio. It only legitimizes dispersion.
2. Executive sponsorship turns priority into decisions
Executive sponsorship is the ongoing action required to preserve priority, remove roadblocks, decide when interests conflict and mobilize resources when the normal structure cannot resolve the issue, well beyond the initial approval of a budget. PMI includes removing obstacles, reinforcing strategic alignment and supporting decisions among the expected behaviors of active sponsors.
This role becomes decisive when business, technology, finance, security and risk defend legitimate but incompatible objectives within the same horizon. Without arbitration, the program accumulates exceptions, escalations and dependencies. The schedule starts to reflect internal politics rather than technical complexity.
An effective sponsor defines decision rights, sets boundaries and intervenes when conflict exceeds the authority of teams, instead of centralizing every decision. The required combination is strong executive direction with distributed accountability.
3. Governance and portfolio management enter before commitment
Governance that reviews an initiative only after supplier, architecture, budget and timeline have already been selected arrives too late. At that point, its ability to protect value is limited and its effect is likely to be bureaucratic.
Useful governance connects enterprise objectives, investment, risk, architecture, indicators and accountability before commitment. COBIT structures governance and management of technology through objectives, alignment, risk and metrics, reinforcing that technology decisions have to be treated in the context of the enterprise.
This does not require turning every choice into a committee. It requires explicit criteria for when an initiative enters, continues, changes direction or leaves the portfolio. Good governance reduces irreversible decisions made too early and creates the conditions to stop activity that does not produce sufficient evidence.
4. Architecture determines the cost of change
The most appropriate architecture is the one that supports the strategy with acceptable levels of cost, risk, integration, security and change speed, not necessarily the newest, most distributed or most sophisticated.
The assessment begins with business questions. How long does it take to launch an offer, integrate an acquisition, meet a regulatory obligation or replace a critical supplier? The answer depends on systems, data, interfaces, processes and accountabilities, not only on technical components. The TOGAF Standard positions enterprise architecture as a discipline for guiding change and aligning capabilities with business direction.
Legacy can continue to create value with controlled risk, without being synonymous with failure. The difficulty appears when unknown dependencies, excessive coupling and absent ownership make every change more expensive, slow and unpredictable.
5. Engineering and delivery convert priority into reliable flow
Engineering capability delivers when it converts business priority into changes that are reliable, secure, observable and economically sustainable, without being confused with individual productivity. DORA research treats delivery performance as the outcome of a system of capabilities and conditions, not merely coding speed. This shifts attention toward value flow, quality, feedback, reliability, architecture and developer experience.
Increasing the number of squads, tools or backlog items without reducing dependencies can increase work in progress and coordination cost. In many contexts, gains come from better sequencing, automated controls, internal platforms, fewer handoffs and explicit limits on concurrent work.
Technical metrics remain relevant, but they have to be read in the context of product and business outcomes. A shorter lead time is valuable when it reduces the time to test a hypothesis, respond to an obligation or capture revenue. Deployment frequency alone is not a business result.
6. Data, security and AI must operate inside the system
Data, security and AI are distinct disciplines and should not be reduced to a single problem. They appear together in this model because they share one operating requirement. They have to be integrated with process, architecture, governance and business decisions.
Data without ownership, quality and context limits analytics, automation and AI. Security treated only as a final approval creates rework and reduces the ability to anticipate risk. NIST recommends integrating secure development practices into the software life cycle rather than treating them as an isolated stage.
The same logic applies to AI. A technically capable model does not create sustainable value when it is disconnected from the process, has no owner, lacks supervision criteria or operates without risk and impact measurement. The NIST AI RMF organizes this discipline through govern, map, measure and manage. The sequence of evolution depends on context. In one organization, the best return may come from data governance. In another, from secure software development. In another, from automation of a stable process before any advanced AI initiative. Maturity means selecting the next capability based on impact, risk and execution feasibility, not on the visibility of the technology.
7. Value measurement connects capability and outcome
Project milestones answer whether a deliverable occurred. They do not, by themselves, demonstrate that organizational capability evolved or that a business outcome changed. The most useful measurement combines three levels.
- A capability indicator, showing whether the organization can perform something better.
- An operating indicator, showing change in flow, quality, cost or risk.
- A business indicator, showing the effect on revenue, margin, productivity, experience, compliance or exposure.
The relationship among these levels must be treated as a causal hypothesis, not automatic attribution. Test automation may reduce defects and validation time, this may accelerate a launch window, and financial capture will also depend on demand, pricing, adoption and commercial execution.
This discipline avoids two extremes. The first measures only technical activity. The second requires every capability improvement to demonstrate direct and immediate financial impact. Some capabilities protect resilience, reduce exposure or create strategic options whose value emerges over time.
The dominant constraint is a diagnostic interpretation
The seven factors are interdependent, but they do not have fixed weights. The capability that most constrains the outcome changes with the type of transformation, industry, strategy, stage of the program and accepted risk.
For that reason, the dominant constraint should be used as a diagnostic instrument, not as a law claiming that the least mature factor always determines total performance. A capability may be less mature and still be sufficient for the current ambition. Another may look adequate in a generic assessment and be unable to support a specific priority.
The right question is direct. Which capability is below the level required for the outcome the company is trying to produce now? This formulation prevents maturity from becoming a scoring contest. The objective is to develop the combination that is sufficient for the strategy, preserve options and reduce materially relevant risks, not to raise every factor to the same level.
How to sequence the transformation
A transformation road map should begin with causality, not with a list of initiatives.
- Define the outcome and horizon. Specify the business indicator, decision horizon and boundaries of the problem. "Improve efficiency" is too broad. "Reduce the cost and processing time of a specific journey while preserving control" creates a basis for decision.
- Map the required capabilities. Identify the strategic, organizational and technical capabilities supporting the outcome. Use operating evidence, interviews and flow data. Do not confuse the absence of a tool with the absence of a capability.
- Locate the material constraint. Assess where the largest gap exists between current and required capability. Consider impact, risk, dependencies, cost of delay and the organization's ability to absorb change.
- Select the smallest coherent set of changes. A constraint is rarely solved by one isolated action. At the same time, attacking every workstream at once disperses leadership and execution. The design should combine the smallest set of changes capable of altering the outcome with evidence.
- Define evidence milestones. Each stage has to show capability evolution, operating change and a business signal. The milestone goes beyond "system deployed". It is evidence that the organization can operate differently.
- Revise the portfolio based on evidence. When the hypothesis is not confirmed, governance must allow adjustment, termination or redirection. Persistence without evidence becomes opportunity cost, not strategic commitment.
The framework organizes the seven factors into three layers
The Capability System and Dominant Constraint framework organizes the seven factors into executive direction, strategic direction and executive sponsorship, coordination and control, governance and portfolio and value measurement, and execution system, architecture, engineering and delivery, data, security and AI.
The reading begins with inputs: capital, people, technology and priorities. It then assesses whether the seven capabilities are coordinated and sufficient for the ambition. The outputs are observed in speed, productivity, controlled risk and economic return. The framework does not assign universal scores and does not assume every organization should maximize every factor. It supports a more disciplined decision. Identify the material constraint, sequence capability evolution and measure whether the change actually altered capability and outcome. Prioritization by economic criteria helps order where to invest first.
What leadership must decide
A transformation does not need more narrative. It needs explicit choices about capability. Before expanding the budget or adding technology, leadership should be able to answer which capabilities support the intended outcome, which one is constraining the outcome today, who has the authority to resolve conflicts, which risks and trade-offs have been accepted and which evidence will support continuation, correction or termination.
Conclusion
Investment creates potential. The capability system determines how much of that potential becomes value. The most mature executive decision builds the combination of direction, governance and execution required for the current priority, learns from evidence and repositions investment before activity is mistaken for transformation, instead of promising that every workstream will evolve at the same time. A capability assessment identifies the dominant constraint before the next investment cycle. Which capability is today below the level your ambition requires?
Sources
- WatchZ. "Seven success factors in technology transformation". Revised editorial version, July 2026.
- McKinsey & Company. "What is digital transformation?". https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-digital-transformation
- McKinsey & Company. "Rewired to outcompete". https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/rewired-to-outcompete
- Project Management Institute. "Why Executive Sponsorship Fuels Projects". https://www.pmi.org/blog/why-executive-sponsorship-fuels-projects
- ISACA. "COBIT". https://www.isaca.org/resources/cobit
- The Open Group. "The TOGAF Standard". https://www.opengroup.org/togaf
- Google Cloud. "Announcing the 2024 DORA Report". https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
- Google Cloud. "Announcing the 2025 DORA Report". https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- NIST. "Secure Software Development Framework (SSDF) Version 1.1". https://csrc.nist.gov/pubs/sp/800/218/final
- NIST. "AI Risk Management Framework and Playbook". https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
- MIT CISR. "Develop Ten Capabilities to Accelerate Digital Transformation". https://cisr.mit.edu/publication/2022_0901_TenCapabilities_WoernerSebastianWeill
