IT-Business Alignment Is a Structural Illusion
The structural test is simple: if one executive can demand the benefit while another function carries the enduring cost, the organisation is not aligned—it is divided.
Executive Summary
A divisional strategy meeting approves a new electronic sales channel. Two weeks later, the information systems director presents an infrastructure plan built around consolidating servers, stabilising the recently remediated application estate and completing an enterprise package rollout. Both plans are rational. Both have executive sponsorship. Neither contains the other.
The familiar response is to call for better “IT-business alignment”: more meetings, business-facing technology managers, joint planning workshops, service-level agreements and a clearer technology strategy. These measures improve communication, but they rarely correct the underlying defect. They assume that “the business” has one settled strategy and that “IT” is a coherent supplier waiting to support it. In practice, the business is a contest among divisions, functions and time horizons, while information technology is simultaneously an operating service, an investment portfolio, a source of risk and a means of changing work.
The result is not a communication gap. It is a structural gap in authority and accountability.
Evidence from recurring programme patterns in 2000-2001 points to five conditions:
- business priorities are approved in separate forums from technology investment;
- operating executives can demand change without owning its full cost or consequences;
- information systems leaders are accountable for delivery but not empowered to resolve business trade-offs;
- benefits remain in project papers while budgets and performance measures remain functional;
- governance measures whether projects follow process, not whether the enterprise has made a coherent choice.
This paper recommends replacing alignment activity with an integrated investment and operating model. Every material technology-enabled change should have one business outcome owner, one economic case, one end-to-end decision forum and one continuing review of benefits, service consequences and architectural obligations. Technology leadership should be present where business choices are formed, not invited after they have hardened into demands.
This is not an argument for putting information systems in charge of strategy. Nor is it a case for allowing every business unit to buy whatever it wants. It is a recommendation to make business and technology consequences indivisible at the point of decision.
Alignment is the language organisations use when they want coordination without changing who owns the consequences.
The Question Is Framed Incorrectly
The alignment debate has intensified for understandable reasons. The approach to the year 2000 exposed decades of accumulated applications and fragile interfaces. Integrated enterprise packages promise common processes and data. The rapid expansion—and recent retrenchment—of Internet ventures has left boards both excited by new channels and more sceptical about technology claims. Outsourcing has also encouraged organisations to describe information systems as a service that can be specified, measured and purchased.
These forces make “alignment” sound practical. The business sets direction; information technology aligns its plans, resources and services behind it. The metaphor suggests two straight lines brought into correspondence.
But the metaphor conceals three facts.
There Is No Single Business Demand
A sales division seeks faster customer response. Finance seeks control and a common ledger. Operations seeks stability. A newly acquired business seeks local freedom. The chief executive may endorse all four until a programme requires one to give way.
Technology projects make these conflicts concrete because systems encode process, data and authority. A common customer record forces agreement on who owns the customer. A standard purchasing workflow limits local discretion. A consolidated infrastructure programme competes for funds with a new sales channel. The information systems function does not receive “the business strategy”; it receives unresolved claims from several legitimate interests.
Information Technology Is Not Merely Supply
Part of the function is operational supply: run the data centre, support users, maintain networks, recover service, manage suppliers. These activities can be described through service levels and cost.
Another part is institutional design. Decisions about application packages, data definitions, interfaces, access rights and common platforms determine how the organisation can operate for years. A technology choice can enable a strategy, constrain it or make one division’s preference the enterprise standard.
Treating both roles as one supplier relationship produces confusion. The function is told to be responsive to demand while also controlling complexity, cost and risk. It is praised for saying yes quickly and blamed later for a fragmented estate.
Accountability Breaks at the Boundary
Business executives often own a project sponsor title but not the full consequences of their requests. Technology leaders own delivery dates and budgets but not benefit realisation. When results disappoint, each side can give a plausible account:
- the business says the system was late, difficult or insufficiently flexible;
- information systems says requirements changed, decisions were delayed or users resisted;
- finance says the business case benefits were never visible in operating budgets;
- operations says service costs rose because the project introduced another platform.
Each statement can be true. The structure permits all parties to be locally accountable and the enterprise outcome to remain unowned.
What the Evidence Reveals
The following composite examination reflects patterns repeatedly visible in large organisations at the turn of the decade. It is not a named company or a statistical survey. Its value lies in the mechanism it exposes.
A multi-division services organisation reviews 47 active technology initiatives with approved expenditure of £64 million. The register shows strong procedural control: 42 have sponsors, 39 have current plans and 35 report status monthly. The organisation therefore considers governance mature.
A closer examination finds:
- fourteen initiatives are justified by revenue growth, but only three sales plans contain the associated targets;
- eleven promise staff reductions, while the relevant operating budgets assume headcount will remain broadly unchanged;
- eight divisions are separately purchasing customer information or sales-support capabilities;
- six projects require a common customer definition, yet no executive has authority to impose one across divisions;
- nineteen initiatives depend on the same twelve senior technical specialists;
- service and maintenance costs after implementation are absent from twenty-seven business cases;
- the investment committee approves projects individually and never sees the combined demand on infrastructure, data or internal skills.
The portfolio is not misaligned in the ordinary sense. Each project is aligned to a sponsor’s stated priority. The enterprise is structurally unable to decide among those priorities.
The effect becomes visible during one customer-service programme. A division requests a new system to provide representatives with a single view of account history. The case forecasts a 12 per cent reduction in call handling time and £2.4 million annual benefit. Information systems approves the technical design after confirming it fits the current client-server standards.
During design, the team discovers that customer identities differ across five billing applications. Resolving the issue requires divisions to surrender local numbering conventions and agree rules for shared customers. No steering member has authority to make that decision. The project therefore adds a matching interface and a reconciliation team.
The system is delivered four months late at £1.8 million above the original estimate. It provides a screen that appears unified, but representatives still investigate discrepancies. Call handling time falls by 3 per cent, not 12 per cent. Annual support costs rise by £700,000 because the matching rules require specialist maintenance.
Every formal alignment mechanism operated:
- the division sponsored the project;
- information systems approved the architecture;
- a steering committee met monthly;
- users attended workshops;
- finance reviewed the business case;
- the system met the revised acceptance tests.
The failure occurred because no forum owned the combined decision about customer definition, divisional autonomy, cost and benefit. The organisation aligned activity while avoiding choice.
| Visible symptom | Conventional diagnosis | Structural cause |
|---|---|---|
| Changing requirements | Business cannot specify its needs | Competing business authorities have not resolved the policy |
| Slow delivery | Information systems lacks responsiveness | Scarce skills are committed by separate approval forums |
| Rising cost | Weak estimating or supplier control | Service, integration and data consequences were excluded from the decision |
| Low benefits | Poor user adoption | Operating targets and authority did not change with the investment |
| Proliferating systems | Weak technical standards | Divisions retain spending power without enterprise cost accountability |
Why the Usual Remedies Underperform
Several common responses are useful. None is sufficient when applied to a structural problem.
Joint Planning Workshops
Joint workshops improve mutual understanding and expose dependencies earlier. They fail when participants cannot trade one priority against another. A workshop can reveal that two divisions want incompatible customer models; it cannot decide which model prevails unless the relevant authority is present.
The output is often an agreed list containing more priorities than the organisation can fund or staff. Consensus is achieved by postponing conflict.
Business-Facing Technology Managers
Creating managers who understand a division and represent information systems can greatly improve translation. The danger is that the role becomes an order-taking channel. The manager is measured by divisional satisfaction while enterprise architects and operations remain responsible for the long-term consequences.
The liaison then succeeds locally by carrying demand across the boundary faster. It may deepen the structural divide by allowing executives to treat technology choices as somebody else’s internal problem.
Technology Strategies and Architectures
A technology strategy can make principles, standards and investment needs explicit. Architecture can reduce duplication and protect long-term flexibility. Both are essential disciplines.
They underperform when separated from business authority. A standard without an executive decision about where local autonomy ends will be waived under schedule pressure. Architecture boards become the place where technology staff are asked to reject business-sponsored requests that business governance was unwilling to refuse.
Service-Level Agreements
Service levels clarify operational expectations and help distinguish cost from quality. They work well for repeatable services such as availability, response and recovery.
They are a poor instrument for governing change. A business outcome cannot be specified like system availability when its achievement depends on new roles, processes and management behaviour. Applying the supplier-customer model to transformation encourages the business to demand and information systems to deliver, leaving neither responsible for the combined outcome.
More Senior Attention
Placing the information systems director on the executive committee is often recommended. Representation matters, but a seat does not by itself alter decision design. If technology is discussed only after commercial priorities have been set, the director becomes a more senior recipient of demand.
The relevant test is not membership. It is whether technological, operational and economic consequences are considered while the strategy is still being formed.
Options Available to the Executive Team
A defensible response should weigh the principal models rather than assume one arrangement fits every organisation.
| Option | Strength | Limitation | Appropriate use |
|---|---|---|---|
| Supplier alignment | Clear service accountability and cost control | Separates demand from enterprise consequences | Stable operations and bounded commodity services |
| Federated autonomy | Fast local response and strong divisional ownership | Duplicates systems, data and skills; weak enterprise leverage | Businesses with genuinely independent customers and economics |
| Central technology control | Strong standards, scale and risk management | Can detach investment from market need and slow local action | Infrastructure, security, common platforms and mandated controls |
| Integrated outcome governance | Joins business value, operating change and technology consequence | Requires senior time and explicit trade-offs | Material technology-enabled transformation |
The recommended model is not to replace every arrangement with integration. Operational services should retain clear service management. Truly independent divisions may need local freedom. Common infrastructure and data require strong central control.
The recommendation is narrower and more consequential: all material technology-enabled change should be governed through integrated outcome decisions, regardless of where delivery resources report.
The Recommended Integrated Model
The model changes the unit of governance from the project or technology service to the business outcome with its full operating and technology consequences.
One Outcome Owner
Every material change has one accountable business executive. This person owns the benefit, process decision, operating adoption and continuing cost—not merely the sponsorship of a project.
The owner may delegate delivery, analysis and technical decisions. The owner cannot delegate the trade-off among benefit, operating disruption, local autonomy and enterprise obligation.
Where no single executive can own the outcome, the proposal is not ready for approval. Naming two equal sponsors usually records the conflict rather than resolving it.
One Economic Case
The case combines:
- investment expenditure;
- internal staff and transition cost;
- continuing operations and maintenance;
- integration and data obligations;
- benefits reflected in operating plans;
- costs of retiring or retaining existing systems;
- consequences for other approved initiatives.
Benefits must appear in the relevant manager’s budget or performance measures. If a reduction in staff cost is claimed while the operating plan preserves headcount, the benefit should not be counted. If revenue depends on sales action not funded in the plan, it remains an assumption.
One Decision Forum
A single investment forum should have authority to approve, sequence, stop and reshape material initiatives. Its membership must combine operating leadership, finance and information systems. It needs visibility of the full portfolio, not isolated proposals.
The forum asks four questions before approving:
- Outcome: What measurable business condition changes, and who owns it?
- Operating decision: Which process, authority or behaviour must change?
- Technology consequence: What common data, infrastructure, application and service commitments follow?
- Portfolio choice: What will be delayed, stopped or deprived of scarce people if this proceeds?
Approval without the fourth answer is not prioritisation. It is accumulation.
One Continuing Account of Value
The governance relationship continues beyond installation. At agreed intervals—typically three, six and twelve months after implementation—the outcome owner reports benefits, operating behaviour, service cost and unresolved obligations.
A programme cannot declare value complete because the system is in production. Equally, information systems should not carry indefinite blame for a benefit that depends on commercial or operational choices outside its authority. The continuing account makes both contributions visible.
Distinguish Enterprise Obligations From Local Preferences
The executive team should explicitly classify technology decisions:
- enterprise obligation: common infrastructure, critical controls, core data definitions and interoperability;
- shared capability: services used by several divisions where common investment creates economic advantage;
- local choice: bounded applications with no material enterprise dependency;
- experiment: limited, time-bound work designed to test an uncertain opportunity.
This classification prevents two equal errors: treating every local request as an enterprise standard, and treating every enterprise concern as a reason to centralise all decisions.
Experiments deserve particular discipline in the present environment. The rapid rise and fall of Internet ventures has shown the danger of large commitments built on uncertain demand. A bounded experiment should have a spending ceiling, a defined learning question and an explicit decision date. It should not acquire permanent infrastructure by accident.
The purpose of integrated governance is not to make every decision central; it is to make the cost of decentralisation and the cost of standardisation visible to the same authority.
Implementation Without Creating Another Committee
The obvious risk is bureaucracy. Integrated governance can become an additional approval layer while existing forums continue unchanged. The response is to remove duplicated decisions, not add a new meeting.
A practical transition can be made in four moves.
- Reconstruct the current portfolio. For every material initiative, identify the outcome owner, benefit in operating plans, continuing service cost, critical dependencies and scarce skills. Do not begin by improving project templates; begin by revealing conflicting commitments.
- Select the decision authority. Give one executive forum power over business priority, funding and enterprise technology consequence. Retire any separate approval that merely repeats the choice.
- Reframe the largest initiatives. Rewrite their cases around outcomes and operating decisions. Where ownership or benefit evidence is missing, pause new expenditure until the gap is resolved.
- Review installed systems for value. Choose a small number of recently completed investments and test whether claimed benefits, behaviours and costs are visible. Use the findings to correct the model, not to conduct a blame exercise.
The first portfolio reconstruction often produces uncomfortable evidence. In a representative case, an organisation may find that 70 per cent of investment is nominally “strategic”, benefits exceed the total improvement assumed in the annual plan, and the same specialists are committed at 180 per cent of capacity. That discomfort is not a failure of the exercise. It is the first honest view of demand.
Measures That Indicate Structural Improvement
The new model should be judged by decisions and outcomes rather than meeting attendance.
- percentage of initiatives with one accountable outcome owner;
- percentage of financial benefits represented in operating plans;
- investment stopped or reshaped before major expenditure;
- reduction in conflicting demands on scarce skills;
- continuing service cost forecast versus actual;
- number and age of unresolved enterprise data or process decisions;
- benefit performance after installation;
- systems retired as planned.
User satisfaction and service levels remain important for operations. They should not be used as substitutes for enterprise value.
The Strong Objection: Separation Creates Useful Tension
There is a serious argument for maintaining the boundary. Business executives should concentrate on markets, customers and operations. Technology specialists should challenge feasibility, protect standards and deliver reliable services. Combining governance may blur accountability, allow technology detail to dominate strategy and slow commercial action.
That objection deserves respect. Productive tension between demand and technical stewardship is necessary. A technology leader who simply mirrors business enthusiasm provides little protection from cost, risk or fashion. Likewise, a business leader should not be required to master every technical detail.
The recommendation does not remove specialisation. It changes where trade-offs are owned. Specialists still advise, challenge and deliver. Business leaders still choose commercial direction. But a decision that creates a five-year systems obligation, changes a core data definition or adds material service cost is neither purely business nor purely technical. Keeping the forums separate does not preserve accountability; it divides it.
Speed is also a valid concern. The remedy is classification. Local choices and bounded experiments should move quickly within clear limits. Enterprise obligations and material transformation should receive the integrated decision their consequences warrant. Treating every request alike is what creates delay.
Conclusion: Replace Alignment With Ownership
For years, organisations have attempted to close the IT-business gap by building bridges: liaison roles, steering groups, strategies, service agreements and joint planning processes. Bridges are useful when two shores are meant to remain separate.
Technology-enabled transformation does not offer that convenience. Processes, information, authority and systems form one operating design. The organisation cannot make the business decision first and align technology afterwards, because the technology consequences are part of the business decision.
The evidence demands a change in language and structure. Stop asking whether information technology is aligned to the business. Ask instead:
- Who owns the outcome?
- Where are the full economic and operating consequences decided?
- Which enterprise obligations constrain local choice?
- Which approved work will not proceed?
- Who remains accountable after installation?
The structural test is simple: if one executive can demand the benefit while another function carries the enduring cost, the organisation is not aligned—it is divided.
The answer is not more translation across the divide. It is integrated ownership of the choice.