Most Businesses Don’t Have an IT Problem — They Have a Decision-Making Problem
Most firms aren’t failing because Microsoft 365 or the IT team is bad; they’re failing because IT choices stall without clear ownership. Fix the governance: pick a named decision owner (CEO, CFO or an appointed CIO), define one review cadence and one budget line, then stop ad hoc firefighting.
Decision Bottleneck: All IT Choices Land On the CEO’s Desk — Appoint a Single Decision Owner
When every vendor quote, security patch or backup decision must wait for a CEO sign-off, projects stall and costs creep up. That bottleneck usually happens because no one has explicit authority and a clear budget to act. The effect is predictable: delayed upgrades, missed renewal deadlines and a pile-up of small risks that become big incidents.
Fix: assign a named decision owner with delegated authority and a dedicated operating budget. This can be an internal head of IT, an outsourced IT director, or a trusted external advisor given a three-line mandate: approve routine changes, escalate exceptions, and run a quarterly review.
- Who: name a single person and publish their remit.
- What they can approve: list spend thresholds (eg, up to £15k) and contract types.
- When to escalate: specify criteria for board-level sign-off (eg, spend above threshold, material security changes).
This reduces approval time and forces trade-offs into measurable rules rather than ad hoc debates.
Feature Creep Decision: Teams Ask for Tools Not Outcomes — Define the Outcome First
Requests for “a new tool” usually mask an unmet business goal. Sales want CRM features, ops want reporting, and everyone labels their wish a priority. Purchasing technology without a crisp outcome leads to multiple overlapping tools, duplicated licences and wasted staff time.
Fix: require a one-page outcomes statement before procurement. That statement should answer three questions: what measurable gap will this close, which users will adopt it, and how will success be measured in three months.
- Template fields: outcome, users, metrics (eg, reduce manual data entry by 50%, shorten invoice processing from 7 to 2 days).
- Proof of value: mandate a short pilot with at least two end-users and a defined evaluation window (4–8 weeks).
- Cost control: require a TCO estimate for 12 months including licences, implementation and training.
By forcing outcome-first thinking you avoid buying features nobody uses and create a rational renewal decision at 12 months.
Security Compromise: Policies Exist But Nobody Enforces Them — Create Simple, Enforceable Rules
Many organisations have security policies that live in a shared folder and are never enforced. That’s a governance failure, not a technical one. The consequence is inconsistent endpoint protection, weak password practice and unmanaged admin rights — predictable causes of breaches reported by UK authorities.
Fix: translate any policy into three enforceable actions and an audit cadence. For example, if passwords are a policy, enforce MFA on all accounts, set device encryption and run a quarterly user access review.
- Enforceable actions: enable MFA, deploy baseline patching schedule, restrict admin rights to named roles.
- Audit cadence: monthly patch checks, quarterly access reviews, annual tabletop exercise.
- Support: link to a single guidance source for interpretation — for example the NCSC’s board-level guidance on cyber roles can help clarify responsibility (NCSC).
Simple, accountable rules reduce ambiguity and make it clear who fixes what when an incident happens.
Vendor Paralysis: Too Many Overlapping Suppliers — Consolidate Contracts Around Outcomes
Multiple overlapping suppliers create unclear accountability. When an outage occurs, everyone says “not our kit”, and the internal team lacks a single contract to call. This is not primarily an IT architecture issue; it’s a procurement and contract design failure.
Fix: consolidate suppliers where possible and rewrite one key contract to be outcome-based. That means specifying uptime, response times, escalation paths and quarterly business reviews rather than listing technical specs only.
- Consolidation rule: reduce the number of core suppliers for infrastructure and backup to two maximum.
- Contract terms to demand: response SLA (eg, 4 hours for critical incidents), routine change window and a named escalation path.
- Measure: track mean time to resolve (MTTR) for critical incidents and tie it to quarterly reviews.
When responsibility is single-threaded in contracts, decisions about replacement, upgrades or incident handling become business decisions, not finger-pointing exercises.
Final action: pick one of the four failures above that matches your recent pain, assign a named owner this week, and schedule a 30–60 minute decision meeting with clear success criteria to be reviewed in 4–8 weeks. That single move converts fuzzy debate into measurable progress.
Related reading
- How Much Should Local IT Support Cost (with Pricing Benchmarks)
- Why ‘Set and Forget’ Is the Most Dangerous Phrase in Modern IT
- Laptop leasing for business: a practical guide for UK SMEs
- Do You Need 24/7 IT Support or Is It Overkill?
FAQ
How long does it take to remove a decision bottleneck in a small firm?
Typical practical change—naming an owner, delegating a budget line and publishing approval thresholds—can be implemented in one to two weeks; expect behavioural change to settle in 4–8 weeks with consistent enforcement.
What minimum delegation is sensible for an appointed IT decision owner?
Start with an approval threshold (for example up to £15,000) plus a clear list of contract types they can sign without board approval and a quarterly reporting obligation.
How do I measure whether outcome-first procurement worked?
Use three metrics from the procurement brief: user adoption rate, time saved (eg, days per process) and total cost of ownership at 12 months compared to the forecast.
If I consolidate suppliers, how many should I keep for core infrastructure?
A practical rule is two core suppliers for infrastructure and backup: one for the primary service and one for disaster recovery/backstop to reduce single points of failure.







