How Executives Make Bad Decisions on Technology Programs — and What Protects Against It

There is rarely a single moment where a technology program goes wrong.

More often, it’s a series of decisions — each one reasonable in isolation, each one made under conditions that were less than ideal. By the time the damage is visible, the decisions that caused it are months old and nobody quite remembers how they were made.

Understanding how bad decisions happen is the first layer of protection. Not as a list of rules to follow, but as a map of the terrain we already operate in.

How bad decisions get made

1. Ignoring what the gut is already signalling

We’ve all been in a steering committee where something didn’t feel right. The vendor’s response to a question was slightly too smooth. The timeline looked workable on paper but felt wrong when you thought about your team’s capacity. The status report said green but the conversation in the corridor told a different story.

That discomfort is data. It doesn’t mean the answer is no — it means the question deserves more examination.

On one council ERP program, the CEO had a persistent unease about a particular vendor’s post-go-live support model. The procurement process said everything was fine. She signed anyway. Eighteen months later, her team was managing a support arrangement that was technically compliant but practically useless. The instinct had been right. The process hadn’t created space to surface it.

2. Decisions made under pressure — timelines, budgets, fear of missing out

When a program is behind schedule, the pressure to move accelerates. When a vendor signals that a pricing window is closing, urgency becomes manufactured. When a board is watching, the cost of appearing indecisive often feels higher than the cost of deciding badly.

These conditions don’t produce better decisions. They produce faster ones.

A director of corporate services once told me she approved a go-live date she knew was optimistic because the political cost of another delay felt unbearable. Six weeks later, the go-live was postponed anyway — but by then, with less runway and more damaged relationships. The pressure to decide early had bought nothing except a longer crisis.

Pressure is real. It doesn’t have to be in charge.

3. Decisions made to relieve discomfort rather than to solve the problem

There’s a pattern worth recognising in long programs: the desire to make a decision — any decision — just to get the discomfort off the agenda. Approving a change request to avoid a difficult vendor conversation. Signing off on a scope reduction to make the numbers work. Endorsing a workaround because reopening the original design feels too hard.

These decisions don’t eliminate the problem. They delay it and make it harder to unwind.

The habitual relief of discomfort and the discipline of making the right call are two different things. Programs that drift furthest are usually those where the first instinct, over and over, was to make the discomfort stop.

4. Uninformed decisions made while firefighting

When a program is in crisis, the executive team is often receiving fragmented information from multiple sources under time pressure. Decisions get made not because the picture is clear, but because something needs to be decided now.

The problem isn’t that the decisions are being made — it’s that they’re being made with whatever information happens to be available rather than the information actually needed.

We once reviewed a program where a key integration decision had been made in a brief email exchange between two team members while the project manager was managing a go-live crisis elsewhere. Nobody had flagged it as a decision requiring executive input. It had compounding consequences for two years.

The most dangerous time to make important decisions is when everyone is busy managing something else.

5. Decisions built on optimism rather than evidence

Technology programs attract optimism by design. Vendors present best-case scenarios. Consultants price for the expected, not the contingency. Internal sponsors want to believe the promises. Everyone wants the program to succeed.

This is understandable. It’s also where blind faith becomes a structural risk.

“We’ve done this before, it’ll be fine” is not assurance. Neither is “the vendor has a good track record.” Optimism without independent verification is just hope dressed up as confidence. And hope is not a project assurance strategy.

6. Gravitating toward sunk cost — and other invisible biases

The sunk cost fallacy is well-known but still remarkably powerful in practice. When an organisation has spent $2 million and eighteen months on a program, the psychological cost of admitting it’s off-track feels enormous. So the evidence gets reinterpreted. The risk gets minimised. The optimistic scenario gets more airtime.

The same pattern plays out with authority bias — deferring to the vendor’s expertise because challenging it feels presumptuous. Or with commitment bias — continuing to advocate for an approach because to change position would feel like weakness.

These aren’t character flaws. They’re structural features of how human judgment works under pressure and investment. Knowing they’re operating is the beginning of being less governed by them.

What protects against it

The second half of those notes was solutions. Here’s what each one looks like in practice.

1. Education — and getting help from people who have walked this path before

Not vendor briefings. Not whitepapers. Actual pattern recognition from people who have seen programs succeed and fail across multiple organisations and contexts.

The value isn’t that an experienced advisor has all the answers. The value is that they’ve seen how a particular configuration of signals tends to end — and they’ll say so, without a commercial stake in the outcome.

A good brief from an independent advisor before a major decision is worth more than a governance framework that looks comprehensive but is staffed by people who all need the program to succeed.

2. Be in a position to make decisions on your own terms

This is about pace and positioning. Executives who are reactive — always responding to what the vendor or project team brings to them — are structurally disadvantaged. The agenda is set by whoever has the most information and the most to gain from a particular decision.

Being in a position to decide on your own terms means: having independent visibility into program status, understanding what decisions are coming before they arrive, and not being dependent on a single source for your read of the situation.

It means not being the last person to understand your own program.

3. Slow and measured decisions are safe decisions

Most decisions on technology programs that feel urgent are not actually urgent. The urgency is often constructed — by timelines, by vendor pressure, by internal politics.

The discipline of slowing down, even when everything is pushing for speed, is one of the highest-value things an executive can bring to a program. “Let me sit with this and come back to you tomorrow” is not indecision. It’s a decision to not let the conditions of the moment make a call that deserves better.

There are exceptions — genuine operational crises where speed is necessary. Those situations are rarer than they feel.

4. Understand the trade-offs in every decision

Every major program decision has a trade-off. Approving that scope reduction means accepting reduced capability somewhere. Extending the timeline means something else slips. Accepting the vendor’s proposed workaround means owning a technical debt that will surface later.

The problem isn’t that trade-offs exist. The problem is when they’re not made explicit — when the decision gets made without the executive team understanding what they’re actually trading.

Good decision-making at the executive level isn’t about eliminating trade-offs. It’s about making them visible and choosing consciously.

5. Know which decisions are one-way — and treat them differently

Not all decisions carry the same consequence. Some are reversible. If they don’t work out, you adjust and move on. These can be made faster, with less information.

Some are not reversible. Signing the contract. Approving the go-live. Committing to a particular integration architecture. These decisions close off options. Undoing them, if needed, is expensive — sometimes prohibitively so.

The single most practical thing an executive can do is apply deliberate classification before a major decision: Is this a door I can walk back through? If not, the level of scrutiny, the quality of information required, and the patience required before committing should all increase accordingly.

One-way decisions deserve a different standard. Most programs treat all decisions the same way, which is how the irreversible ones slip through without sufficient examination.

A final observation

What connects all six failure modes is the same thing: decisions made without adequate visibility, without enough time, and without sufficient independence from the conditions producing the pressure to decide.

Project assurance isn’t a governance checkbox. At its core, it’s a structural effort to give executives the conditions they need to make good decisions — independent information, the right pace, clarity about what’s actually at stake.

Most programs provide the opposite: compressed timelines, filtered information, and decisions driven by whoever has the most urgency.

That’s not a technology problem. It’s a decision-quality problem. And it’s fixable.

SP Singh is the founder of Bhani Consulting and a WALGA panel member providing independent ERP oversight to WA local government and Aboriginal corporations.