Cataloguing Strategic Innovations
Executive Alignment Scorecard for Technology Investment.
Sanjay Mohindroo
A seven-question executive alignment scorecard to test business outcomes, capital discipline, accountability, and risk before technology investment.
The Executive Alignment Scorecard I Use Before Technology Gets Funded
Seven questions. Fourteen points. Less than 11, and I would hesitate before committing serious capital.
That may sound harsh. But after decades of sitting in executive meetings where everyone appeared to agree, I have learned that agreement is one of the weakest tests of alignment.
The conventional wisdom says that if the CEO, business leaders, technology team and finance team are all supportive of an initiative, the organisation is aligned.
I disagree.
I have seen rooms full of intelligent executives nod to the same proposal while carrying completely different assumptions about what success meant, how much disruption was acceptable, who owned the result, and when the organisation should stop spending.
That is not alignment.
It is deferred disagreement.
And deferred disagreement becomes expensive once contracts are signed, teams are mobilised and reputations are attached to the programme.
Why Business and IT Alignment Is Usually Tested Too Late
Most organisations test alignment through governance.
There is a steering committee. There is an investment paper. There is a programme sponsor. There are status reports, risk registers and quarterly reviews.
All useful.
But governance begins after one more important question should already have been answered:
Are the executives actually aligned on the decision they are making?
This distinction matters.
A project can have excellent governance and still be solving the wrong problem.
A transformation can be on schedule and still fail to create enough economic value.
A technology investment can meet every technical milestone while the operating business quietly avoids changing the processes required to capture the benefit.
By the time those problems become visible in a steering committee, the organisation may already have committed millions.
This is why I prefer to test alignment before debating architecture, vendors or detailed delivery plans.
The test I use is deliberately simple.
Seven questions.
Each receives a score from 0 to 2.
0 means unclear or disputed.
1 means partially defined or dependent on assumptions.
2 means explicit, measurable and owned.
The maximum score is 14.
The mathematics is not the point. The conversation behind the score is.
The 7-Part Executive Alignment Scorecard
1. Are we aligned on the business outcome?
The first question should never be, “What technology are we implementing?”
It should be:
What business result will be materially different if this works?
A score of 0 means the answer is largely technological: migrate the platform, deploy AI, modernise the core, move to cloud.
A score of 1 means there is a business aspiration, but it remains broad: improve customer experience, increase productivity, enable growth.
A score of 2 requires a business outcome that executives can recognise and measure.
Reduce customer onboarding from twelve days to four.
Lower cost-to-serve by 15 percent.
Release enough working capital to fund expansion without increasing borrowing.
Increase conversion in a strategically important customer segment.
The wording changes by industry. The principle does not.
Technology is not the outcome.
If the executive team cannot state the business consequence clearly, everything that follows is built on weak foundations.
2. Are we aligned on the economic logic?
This is where many apparently strategic programmes become uncomfortable.
Boards are often shown the cost of an initiative and an estimate of its benefits. That is not the same as understanding its economic logic.
I want executives to answer three things:
Where does the value come from?
When should it become visible?
What has to be true for that value to materialise?
The last question is particularly important.
A system may create the capability to reduce operating cost. It does not automatically reduce operating cost.
A new digital channel may create the ability to serve customers more efficiently. Unless volumes migrate, processes change and legacy costs are removed, the economic benefit may never appear.
A score of 2 therefore requires more than a business case spreadsheet.
It requires agreement on the mechanism through which capital becomes business value.
That is a very different conversation.
Capital Allocation Is an Alignment Test
Technology portfolios have a peculiar habit.
Almost everything becomes “strategic”.
Once that label is attached, normal capital discipline can weaken.
I challenge that.
If an initiative is genuinely strategic, executives should be able to explain why it deserves scarce capital ahead of another credible investment.
Which brings me to the third question.
3. Are we aligned on the trade-off?
Every serious investment consumes more than money.
It consumes management attention, organisational capacity, specialist talent and the willingness of employees to absorb change.
So, I ask:
What are we choosing not to do because we are doing this?
If the answer is “nothing”, I become concerned.
Executives often treat prioritisation as deciding which projects are important.
Real prioritisation is deciding which important projects will not happen now.
A portfolio containing 25 “top priorities” is not a prioritised portfolio.
It is a queue.
A score of 2 requires an explicit trade-off.
This initiative receives funding, people and executive attention. Something else is deferred, reduced or stopped.
That is when strategy starts becoming real.
4. Is one executive accountable for the business result?
Technology programmes often have sponsors.
That does not necessarily mean they have owners.
The distinction is critical.
A sponsor can support the programme, remove obstacles and attend governance meetings.
An owner is accountable for the business result.
I look for one named executive who can answer:
If the expected outcome does not materialise, who must explain why?
Not the CIO and the business collectively.
Not a transformation committee.
Not “the programme”.
One executive.
This does not mean that technology leadership escapes accountability. Far from it. The CIO remains accountable for technology choices, execution quality, resilience, security and technology economics.
But if the programme is justified by a business outcome, someone in the business must own that outcome.
Shared accountability too easily becomes diluted accountability.
5. Are we aligned on the downside risk?
Transformation proposals naturally emphasise upside.
Boards need to spend more time on downside.
What happens if implementation takes twelve months longer?
What happens if adoption reaches only 40 percent?
What happens if the new platform increases dependency on one strategic supplier?
What happens if the expected cost reduction requires restructuring that the organisation later decides not to undertake?
What happens if the initiative succeeds technically but fails commercially?
A score of 2 does not mean the risks are small.
It means the executive team understands the material risks, has consciously accepted them, and knows who owns each one.
There is an important difference between a known risk and an owned risk.
Risk registers capture the first.
Leadership creates the second.
Digital Transformation Fails Outside the Technology Function
The next question is the one I have found most revealing.
6. Are we aligned on what the business must change?
Many technology programmes are presented as if value will emerge from implementation.
It rarely does.
Value appears when behaviour changes.
Processes change.
Decision rights change.
Roles change.
Customer journeys change.
Incentives sometimes change.
Legacy activities stop.
An organisation can install a world-class platform and preserve the old operating model around it. When that happens, the new technology often becomes an expensive wrapper around yesterday's business.
A score of 2 therefore requires the business executives to articulate what they themselves will change.
Not what IT will deliver.
What the business will do differently.
This question also exposes one of the most common forms of false alignment.
Executives may enthusiastically support transformation in principle while resisting the organisational consequences required to make it economically worthwhile.
That contradiction needs to surface before the investment is approved, not eighteen months later.
7. Are we aligned on the evidence that would make us stop?
This is the question most executive teams initially dislike.
Under what circumstances would we reduce, redesign or stop this programme?
The usual answer is some version of: “We are committed to making it succeed.”
That sounds decisive. It is also dangerous.
Commitment is useful in execution.
It is dangerous when it prevents leaders from responding to evidence.
Every major initiative should have predefined signals that tell the executive team whether its assumptions remain valid.
Perhaps customer adoption must reach a certain threshold.
Perhaps an initial deployment must demonstrate a measurable productivity gain.
Perhaps costs must remain within a defined range.
Perhaps integration complexity reveals that the original economics no longer hold.
Whatever the measure, leaders should agree on it before sunk costs and reputational attachment distort the decision.
A score of 2 means executives know what evidence would cause them to continue, change course or stop.
That is not pessimism.
It is capital discipline.
How I Read the Executive Alignment Score
The total score creates three useful conversations.
11 to 14: Commit
The leadership team has enough clarity to make a serious capital decision.
There will still be uncertainty. Transformation always contains uncertainty.
But the outcome, economics, trade-offs, ownership, risk, organisational change and evidence thresholds are sufficiently explicit.
8 to 10: Resolve before scaling
This is where many programmes should pause.
Not stop.
Pause.
One or two important questions remain unresolved. Perhaps the technology case is strong but no business executive truly owns adoption. Perhaps the economics depend on cost reductions nobody has agreed to execute.
Those issues are cheaper to resolve in the boardroom than during implementation.
0 to 7: Reframe
At this level, I would question whether there is actually one initiative.
There may instead be several competing ideas hiding under one programme name.
The correct response is usually not better project management.
It is a better executive conversation.
An Illustrative Example: When Everyone Supports the Programme
Consider a multinational organisation debating a major customer platform investment.
Everyone supports it.
The CEO wants better customer experience.
Sales wants more leads.
Operations wants lower service costs.
Technology wants to simplify a fragmented application landscape.
Finance expects productivity improvement.
It sounds perfectly aligned.
Run the scorecard.
The desired outcome? Four different answers.
Economic logic? Benefits depend on customers moving from assisted to digital channels, but nobody owns that migration.
Trade-off? No existing programme is being stopped.
Accountability? The CIO is named sponsor, even though most of the benefits sit in sales and operations.
Risk? Technology risks are documented. Commercial adoption risk is not.
Business change? Existing service processes are expected to continue during an undefined transition period.
Stop rule? None.
The initiative can have unanimous support and still score poorly.
This is exactly why I do not use enthusiasm as a proxy for alignment.
A difficult twenty-minute conversation before approval can save months of difficult conversations after approval.
The Counter-Argument: Can Seven Questions Oversimplify Transformation?
Of course they can.
A large transformation may involve hundreds of decisions, multiple jurisdictions, several technology domains and thousands of employees.
No seven-question scorecard can capture that complexity.
Nor should it try.
Its purpose is not to manage the programme.
Its purpose is to test whether the leaders committing the organisation understand the same decision.
Complexity is often used as an argument for more detail.
At board level, complexity creates the opposite requirement.
Executives need sharper clarity about the few things that determine whether the investment deserves continued capital and attention.
The scorecard is therefore intentionally reductive.
If seven fundamental questions cannot be answered, another seventy slides will not create alignment.
What Boards Should Ask Before the Next Major Technology Decision
If I were advising a board reviewing a significant technology or transformation investment tomorrow, I would ask them to spend less time initially on the solution and more time on seven sentences:
1. The business outcome we are buying is...
2. The economic value will appear because...
3. To fund and execute this, we are choosing not to...
4. The executive accountable for the business result is...
5. The most material downside we are accepting is...
6. The business will have to change by...
7. We will reconsider the investment if the evidence shows...
If those sentences are clear, technology discussions become substantially better.
If they are not, the organisation is probably not ready to make the investment decision it thinks it is making.
Alignment Is Not Agreement
The conventional view of executive alignment places considerable value on consensus.
I place more value on clarity.
An aligned executive team does not need to agree on every detail.
It does need to agree on the outcome, economic logic, capital trade-off, accountability, risk, organisational consequences and evidence that will determine the next decision.
That definition is tougher.
It is also far more useful.
Because when conditions change, as they inevitably will, genuine alignment gives leaders a common basis for making the next decision.
Consensus merely tells you what everybody believed at the beginning.
How does your executive team test alignment before committing major technology capital, and which of these seven questions tends to expose the biggest gap?
If you value practical perspectives on technology, leadership, and enterprise decision-making, subscribe to TechnologyTrends or add your perspective in
Shared Accountability for Technology Outcomes
Sanjay Mohindroo
Technology value is not the CIO's job alone. A practical framework for making business leaders accountable for technology outcomes and ROI.
Making the Business Own Technology Outcomes
After nearly three decades around enterprise technology, I have seen the same sentence end too many difficult meetings:
“IT needs to fix this.”
Sometimes the problem was a delayed platform. Sometimes adoption was poor. Sometimes the investment had delivered the system everyone asked for, but not the business result everyone had promised.
The conventional wisdom is that when a technology programme succeeds or fails, the CIO should be accountable.
I disagree.
The CIO should be accountable for technology delivery, resilience, architecture, security and technology economics. But if the intended outcome is higher revenue, lower operating cost, faster fulfilment, improved customer retention or reduced business risk, then the business must own that outcome.
Otherwise, we create one of the most expensive governance failures in modern enterprises: business leaders approve technology investments, IT delivers them, and nobody outside IT is truly accountable for extracting the value.
That model has to change.
Technology Accountability Is Not the Same as Business Accountability
Most large technology programmes begin with a business case.
The language is rarely technical.
Increase conversion. Reduce processing time. Improve forecast accuracy. Lower inventory. Accelerate product launches. Reduce regulatory exposure. Improve customer retention.
Yet something strange often happens after the investment is approved.
The business objective remains in the presentation, while operational accountability migrates toward IT.
The programme gets a technology steering committee. Progress becomes milestones, integrations, releases and budgets. The CIO is asked why adoption is slow, why productivity has not improved or why the return on investment has not appeared.
But a CIO cannot force a sales organisation to change its selling process.
A technology team cannot redesign decision rights inside a supply chain.
A platform cannot eliminate redundant approval steps if the business insists on preserving them.
And no software can produce a return on investment if management treats implementation as the end of the transformation.
This is where many boards confuse technology accountability with business accountability.
They are not the same thing.
The Conventional Wisdom Is Wrong: The CIO Cannot Own the Entire Outcome
There is a comfortable management assumption that technology transformation belongs to the CIO because technology is involved.
That logic would sound absurd in almost any other area of business.
We do not tell the CFO to own revenue because pricing sits in the financial model.
We do not tell HR to own sales performance because salespeople require recruitment and incentives.
We do not tell the general counsel to own market expansion because contracts are required.
Technology should be treated the same way.
When the objective is a business outcome, the accountable executive must come from the part of the organisation that can change the process, behaviour, incentives and operating model required to achieve it.
The CIO remains a critical co-owner.
But co-ownership is different from becoming the organisational shock absorber for every missed transformation target.
#DigitalTransformation
Why Technology Value Disappears After Approval
The business case for a major technology investment usually receives more scrutiny before approval than after implementation.
That is backwards.
Before approval, executives debate benefits, payback periods, risks, and strategic necessity.
Once capital is committed, attention shifts toward delivery.
The question changes from:
“What business result are we buying?”
to:
“Are we on schedule?”
Schedule matters. Cost matters. Technical quality matters.
But none of those prove that the investment created value.
A programme can be on time, within budget and technically sound, while still being a poor business investment.
That is the distinction boards need to enforce.
Technology delivery is an output.
Business value is an outcome.
The two are connected, but they are not interchangeable.
Shared Accountability Does Not Mean Nobody Is Accountable
There is another danger here.
Whenever organisations hear “shared accountability,” responsibility can become blurred across committees, functions and steering groups.
That is not what I am proposing.
Shared accountability should not mean collective ambiguity.
It should mean two clearly named executives accepting responsibility for different sides of the same investment.
One executive owns the technology capability.
One executive owns the business result.
The relationship should be explicit enough that the board knows who must answer which question.
That distinction becomes especially important when results disappoint.
If the platform is unstable, the technology leader should answer for it.
If the platform works but the business has not changed the process, incentives or behaviours required to capture value, the business leader should answer for that.
If both have failed, both should be accountable.
That is far healthier than asking the CIO to explain every number on the benefits case.
The Shared Outcome Accountability Framework
For any material technology investment, I would encourage boards and CEOs to insist on five things before approving capital.
1. Name a Business Outcome Owner
Every significant technology programme should have one senior business executive whose name sits beside the promised business result.
Not a committee.
Not “the business.”
A person.
If the investment promises to reduce cost-to-serve, improve customer conversion or shorten the order-to-cash cycle, someone with authority over that operating outcome must own it.
The test is simple:
If the technology works exactly as designed but the expected business benefit does not appear, who is called into the CEO's office?
If the answer is automatically “the CIO,” the governance model is incomplete.
2. Name a Technology Outcome Owner
The CIO, CTO, or relevant technology executive should own the technology conditions necessary to produce the business result.
That includes delivery quality, scalability, security, resilience, interoperability, and total technology economics.
This is not diluted accountability.
It is sharper accountability.
The technology leader is no longer expected to own matters outside their control, while becoming far more clearly responsible for the technology commitments that are within it.
3. Translate the Business Case Into Operating Metrics
Many transformation programmes fail because their benefits remain trapped in the original investment paper.
A promise such as “improve productivity” is too vague.
What changes?
Processing time from what to what?
Conversion from what baseline?
Inventory by how much?
How many manual interventions should disappear?
How much working capital should be released?
By when?
If management cannot answer those questions, the programme does not yet have a measurable outcome.
One metric I like boards to ask for is a simple value bridge:
Baseline performance → technology-enabled change → business behaviour change → financial outcome
This forces executives to explain how the investment actually creates value.
It also exposes assumptions hidden inside large return-on-investment numbers.
4. Make Business Change Part of the Investment
This is where many business cases become unrealistic.
The capital request funds the platform but understates the cost of changing the organisation around it.
Training is budgeted.
Transformation is not.
There is a difference.
Real business change may require redesigning processes, removing controls, changing incentives, consolidating roles, rewriting policies or abandoning practices that senior leaders themselves created.
Those decisions cannot be delegated to the technology function.
Boards should therefore ask a harder question before approving transformation capital:
What must the business stop, start or change for this investment to generate the promised return?
If there is no uncomfortable answer, the transformation may not be transformative enough.
5. Review Value After Go-Live, Not Just Delivery
For many programmes, governance intensity peaks before implementation and falls immediately afterwards.
It should continue until the promised outcome is either achieved, revised with evidence or formally written off.
A board does not stop reviewing an acquisition the moment the transaction closes.
Technology investments deserve similar discipline.
At 90 days, six months and twelve months after implementation, management should be able to answer:
What value has been realised?
What has not?
Which assumptions were wrong?
Which business changes have not happened?
What additional capital is required?
Should we continue, change direction or stop?
This turns technology governance into capital governance.
That is where it belongs.
A Useful Boardroom Distinction: Adoption Is Not Value
Another mistake is using adoption as proof of success.
Adoption can be encouraging, but it is an intermediate measure.
A thousand employees logging into a new platform does not demonstrate value.
The important question is what changed because they used it.
Did decisions become faster?
Did error rates fall?
Did customers behave differently?
Did the organisation require fewer manual interventions?
Did revenue improve?
Did risk decrease?
I have seen organisations celebrate usage statistics while the original economics of the investment quietly disappeared from discussion.
That is dangerous.
Management should track adoption because poor adoption can prevent value.
But adoption itself is not the destination.
#CIO
What Happens When the Business Really Owns the Outcome
The quality of decision-making changes.
Business executives begin asking different questions before approving technology expenditure because they know their own performance will ultimately be measured against the result.
Requirements become more disciplined.
“Nice to have” functionality receives more scrutiny.
Process redesign happens earlier.
Adoption stops being somebody else's problem.
And benefits are less likely to become theoretical numbers added to a presentation simply to pass an investment threshold.
There is another benefit.
The relationship between the CIO and business leadership becomes healthier.
Instead of IT acting as supplier and the business acting as customer, both sides become investors in a common result.
That is a far more mature operating model.
The Counter-Argument: The Business Does Not Understand Technology
I often hear a version of this objection:
“The business cannot own something it does not understand.”
I think that confuses understanding the technology with owning the outcome.
A CEO does not need to understand every engineering detail of a factory to hold the operations leader accountable for manufacturing performance.
A board does not need to understand every quantitative model used by treasury to hold the CFO accountable for financial risk.
Business leaders do not need deep technical expertise to own the result a technology investment is supposed to produce.
They need to understand what they are buying, what assumptions underpin the value case, and what their organisation must change to realise it.
If they cannot do that, the answer is not to transfer accountability to IT.
The answer is to improve the quality of executive decision-making.
Technology Governance Should Follow the Money
At board level, technology is increasingly one of the largest pools of discretionary and strategic investment.
That means technology governance cannot remain a specialist conversation.
It is a capital allocation conversation.
For every major programme, directors should know:
What business outcome are we purchasing?
Who owns that outcome?
What assumptions connect the investment to financial value?
Which business changes are required?
What happens if the value does not materialise?
These are not CIO questions.
They are management questions.
And once boards begin asking them consistently, something useful happens: technology stops being viewed as an expensive department that periodically requests capital.
It becomes what it should have been all along, an instrument for changing business performance.
The Real Accountability Test
There is one question I would put to any executive team approving a major technology programme:
If this system works perfectly and the business case still fails, who owns the failure?
If the answer is unclear, the programme is not ready for approval.
If the answer is “IT,” despite the promised benefits sitting in sales, operations, finance or customer experience, the accountability model is wrong.
The best technology organisations I have seen do not ask the business to “support” transformation.
They make the business own the transformation with them.
That is the shift boards should demand.
Not more steering committees.
Not another alignment workshop.
Clear ownership of business outcomes, paired with clear ownership of technology performance.
Because when everybody benefits from technology, but only the CIO is accountable for the result, accountability is not shared.
It is outsourced.
How does your organisation handle this today? When a technology investment delivers the system but misses the business result, who actually owns the outcome?
If this resonates, subscribe to TechnologyTrends or add your perspective in the comments.
How to Run a Technology Investment Committee
Sanjay Mohindroo
Most technology committees review more than they decide. Use the DECIDE framework to improve capital allocation, accountability, and technology outcomes.
How to Run a Technology Investment Committee That Actually Decides
A technology investment committee that ends with “come back with more detail” has usually not exercised prudence. It has postponed accountability.
Across three decades in enterprise technology, I have seen this pattern in different industries and different boardrooms: capable executives, substantial investment at stake, a detailed presentation, sensible questions, and no actual decision.
The conventional wisdom is that technology investment committees need better information.
I disagree.
Most already have more information than they can use. What they lack is a decision system.
A technology investment committee should not be a review forum for IT proposals. It should be a capital allocation mechanism that decides where the enterprise will place money, management attention, and risk.
That distinction changes everything.
The Real Problem with Technology Investment Committees
Many committees are designed around the presentation.
A proposal arrives with a business case, implementation plan, architecture view, risk register, vendor assessment, and a collection of financial projections. The committee reviews it. Finance challenges the assumptions. Technology explains the dependencies. Operations asks about disruption. Someone requests another sensitivity analysis.
The meeting ends with more work.
This feels responsible because nobody has made a reckless decision.
But indecision has a cost too.
A delayed technology decision can prolong operational risk, defer revenue, increase dependence on obsolete platforms, lock in inefficient processes or allow a competitor to move first.
The committee rarely puts a number against that delay.
That is the first mistake.
The second is more fundamental: many committees have never defined what they are actually there to decide.
Are they deciding whether an investment deserves capital?
Whether the proposed solution is the best option?
Whether the risk is acceptable?
Whether funding should be released now?
Or whether the programme should continue after its first phase?
Those are different decisions.
When the decision itself is vague, the discussion expands until every executive can find something else to investigate.
The result is governance theatre.
Lots of challenge. Very little choice.
Technology Governance Is Capital Allocation, Not IT Oversight
The most useful shift a board or CEO can make is to stop treating technology investment as a specialist technology conversation.
Technology consumes capital to change business economics.
The committee therefore needs to ask questions such as:
What business outcome are we purchasing?
What happens if we do nothing?
What risk are we removing?
What new capability becomes possible?
What is the cost of waiting?
What else could we fund with the same capital?
What evidence would cause us to stop?
These are boardroom questions.
Whether the investment involves cloud infrastructure, artificial intelligence, cybersecurity, ERP modernisation, customer platforms or data does not change the principle.
Technology terminology should not be allowed to obscure an ordinary capital allocation question: why is this the best use of the next unit of investment?
That is where I believe many governance models have become too comfortable.
They test whether a proposal is complete.
They do not test whether the decision is good.
The DECIDE Framework for Technology Investment Committees
I use six questions to think about whether an investment committee is capable of making a real decision.
They form a simple framework: DECIDE.
1. Define the Decision
Every proposal should begin with one sentence:
“The committee is being asked to decide whether…”
Not “review.”
Not “note.”
Not “provide guidance.”
Decide.
For example:
“The committee is being asked to approve the first phase of a customer platform modernisation, with funding released against three defined business milestones.”
That sentence immediately disciplines the conversation.
It also exposes proposals that have been brought to the committee prematurely.
If management cannot describe the required decision in one sentence, it is unlikely that twenty additional slides will fix the problem.
The decision should also have a time boundary.
A decision that can apparently wait indefinitely is usually one whose cost of delay has not been understood.
2. Establish the Economic Outcome
Technology teams naturally describe what a system will do.
Investment committees need to understand what the enterprise will gain, protect, or avoid.
I would expect the economic case to fit into a small number of categories:
- Revenue growth or protection
- Cost reduction or productivity
- Working capital improvement
- Risk reduction
- Regulatory necessity
- Strategic capability
- Competitive response
There may be several benefits, but one or two should dominate.
This matters because technology programmes often accumulate benefits during the approval process. A project begins as a cost reduction initiative, then becomes a customer experience programme, then a resilience initiative, then a data strategy.
By the time it reaches the committee, it apparently solves everything.
That should make decision-makers more skeptical, not less.
If the primary value cannot be stated clearly, accountability later becomes almost impossible.
A board does not need fictitious precision. It needs economic clarity.
For some investments, especially cyber resilience or regulatory technology, the right question is not conventional return on investment.
It may be value at risk.
It may be the consequence of a service failure.
It may be the probability and impact of a control breakdown.
The metric should fit the decision rather than forcing every technology investment into the same financial template.
3. Compare Real Alternatives
One of the weakest questions in many investment papers is also one of the most important:
What are the alternatives?
There should almost always be at least three:
1. Proceed with the proposed investment.
2. Choose a credible alternative.
3. Do nothing, defer, or continue with the current environment.
“Do nothing” is not an administrative formality.
It establishes the baseline.
I have seen technology proposals look compelling until management properly describes the economics of continuing with the existing solution.
The opposite happens too.
A large transformation can appear urgent because the current technology is old. Once the business quantifies the actual operational constraints, a targeted intervention can sometimes produce most of the value at a fraction of the risk.
This is where conventional wisdom around technology modernisation often needs challenging.
Old is not automatically bad.
New is not automatically strategic.
The committee should fund the option with the strongest business logic, not the most fashionable technology.
#Technology investments frequently fail this test because the recommendation has effectively been chosen before the committee sees it.
The alternatives section then becomes justification rather than analysis.
A serious investment committee should be willing to choose Option B when management arrives expecting approval for Option A.
Otherwise, it is not really a decision-making body.
4. Identify Risk, Reversibility and the Cost of Delay
Most risk registers are too long and too operational for senior decision-makers.
The committee needs a different view.
I would want to know four things:
What can materially destroy the expected value?
What happens if we delay?
How reversible is the decision?
What exposure are we accepting once we commit?
Reversibility is particularly important.
A six-month experiment with limited contractual commitments deserves a different approval threshold from a multiyear platform decision that changes operating processes across the enterprise.
This is why I prefer staged capital for uncertain technology investments.
Instead of approving the entire journey because management has produced a five-year business case, approve the next economically meaningful commitment.
Release further capital when evidence improves.
This is especially relevant to emerging technology.
A board does not need to predict with certainty which artificial intelligence use cases will create durable value.
It needs to control the size of the bet while management generates evidence.
That is better governance than demanding an artificial level of certainty before approving anything.
5. Design the Decision Rights Before the Meeting
One uncomfortable truth about committees is that consensus is often mistaken for governance.
It is not.
Consensus can be useful, but requiring everyone to be comfortable with every decision is one of the fastest ways to create slow, conservative capital allocation.
Someone must own the decision.
The committee charter should make clear:
- Which investments require committee approval
- Who recommends
- Who challenges
- Who decides
- Who can veto, and on what grounds
- What happens when the committee disagrees
- Which decisions are delegated to management
A committee where every member can delay but nobody can decide is badly designed.
This is particularly damaging when technology decisions cut across functions.
The CFO may focus on capital discipline.
The COO sees operational disruption.
The CIO understands technical debt and execution complexity.
The business leader sees revenue or customer impact.
Those perspectives should improve the decision.
They should not create six unofficial vetoes.
Good governance means structured challenge followed by clear authority.
6. Enforce Post-Decision Accountability
This is the step most investment committees neglect.
They approve.
They move on.
Months later, the project returns because it needs more money, more time, or a revised scope. The original economic assumptions have disappeared beneath programme status reporting.
That is not investment governance.
Every significant technology decision should leave the committee with a short decision record:
What was approved?
How much capital was committed?
Which outcome justified the investment?
Who owns that outcome?
What assumptions mattered most?
What milestones release the next tranche of funding?
What conditions would cause the organisation to stop, redesign or reduce the investment?
The committee should then review the investment against the logic that justified it.
Not simply against whether the implementation is “green.”
A programme can be technically on schedule and economically wrong.
It can also experience implementation difficulty while remaining strategically valuable.
Those are different conversations.
Stop Funding Projects. Fund Evidence.
One of the most important implications of this approach is that large technology investments should not always be approved as single events.
Capital should follow evidence.
Consider the kind of decision faced by a global enterprise replacing a core operating platform.
The conventional approach is to create a multiyear programme, estimate the total benefit, calculate the total cost, secure approval and begin.
The problem is that the organisation has its least reliable information at the moment it is being asked to make its largest commitment.
Instead, the committee can approve the programme in stages.
The first investment might prove integration feasibility, business adoption and the economics of one operating region.
The second tranche is released only if those assumptions hold.
This does not mean endlessly piloting and never scaling.
It means increasing commitment as uncertainty decreases.
Boards understand this logic in acquisitions, new markets and capital projects.
Technology should not be exempt.
But Won’t This Slow Everything Down?
This is the usual counter-argument.
More disciplined governance sounds like more meetings, more gates and more bureaucracy.
It should produce the opposite.
A well-designed investment committee accelerates decisions because management knows exactly what evidence is required and exactly who can decide.
Weak governance creates repeated presentations.
Strong governance creates explicit thresholds.
The objective should not be to send every technology expenditure through the same committee.
Routine infrastructure renewal, small enhancements and investments within established product portfolios should normally operate inside delegated authority.
The investment committee should spend its time where executive judgement matters:
Large commitments.
Irreversible choices.
Strategic dependencies.
Material risk.
Cross-enterprise trade-offs.
New areas where evidence is limited.
If the committee spends twenty minutes debating a routine software renewal, the problem is not governance discipline.
The problem is governance design.
The CEO’s Test: Can the Committee Kill a Technology Investment?
There is one question I would ask any CEO evaluating their technology investment governance:
When was the last time the committee stopped something?
Not delayed it.
Not requested another business case.
Stopped it.
A committee that only approves proposals is probably sitting too late in the process or challenging too little.
Equally, a committee that repeatedly rejects investments may be seeing weak proposals because the organisation has no effective portfolio discipline before they reach the boardroom.
Healthy governance produces all four outcomes:
Approve.
Approve with conditions.
Redesign.
Stop.
Each should be considered legitimate.
Stopping an investment is not evidence that management failed.
Continuing to invest after the economic case has disappeared is.
What a Technology Investment Committee Should Actually Measure
If I were reporting the effectiveness of the committee to a board, I would not start with the number of meetings held or proposals reviewed.
I would look at measures such as:
Decision cycle time: How long does a material proposal take from being decision-ready to receiving a decision?
Capital concentration: Where is technology investment actually going across strategic priorities?
Benefits ownership: What percentage of major investments have a named business executive accountable for the economic outcome?
Stage-gate performance: How often does evidence change the amount or direction of subsequent investment?
Stopped or redirected capital: How much spending has governance prevented from continuing when assumptions no longer held?
Outcome realisation: Are the business outcomes used to secure approval actually appearing?
These measures tell a board whether governance is allocating capital intelligently.
A beautiful committee pack does not.
The Committee Must Be Designed Around Decisions
Technology will continue to consume a larger share of executive attention because increasingly there is no meaningful separation between business strategy and technology strategy.
That makes investment discipline more important, not less.
The mistake is to respond by building larger committees, requesting more documentation and adding more approvals.
The better response is simpler.
Define the decision.
Establish the economic outcome.
Compare real alternatives.
Understand risk and reversibility.
Make decision rights explicit.
Return later and hold the investment to the logic that justified it.
That is the DECIDE framework.
A technology investment committee should not exist to make executives feel that technology has been thoroughly reviewed.
It should exist to make better choices about capital.
And sometimes the best evidence that it is working is not what gets approved.
It is what never gets funded.
How does your organisation know whether its technology investment committee is improving decisions, rather than simply adding another layer of review?
Subscribe to TechnologyTrends or add your perspective in the comments if this is a debate your leadership team is having.