Digital transformation is the most oversold phrase in this market and one of the few that still describes something real. The oversold version is a programme, a budget and a slide deck. The real version is narrower: a small number of decisions about how work gets done, taken by people with the authority to make them stick, and then actually implemented.
I work with companies and institutions in Kuwait and the GCC that have decided something has to change and are not sure where the first cut should be. Most of what I do in the first month is reduce the scope until it is achievable, because a transformation programme that stalls does more lasting damage than never starting one.
Why these programmes fail here
Over three decades I have watched the same failures repeat, and almost none of them are technical.
- Digitising a broken process. The process was inefficient on paper; now it is inefficient in software, and harder to change.
- No single decision-maker. A programme needing five sequential approvals dies between meetings regardless of its merit.
- Buying the platform before defining the problem. The licence is signed, then the requirement is reverse-engineered to justify it.
- Nobody owns the outcome. A steering committee owns a programme; a person owns a result.
- No baseline. Nothing was measured before, so nobody can prove anything improved, and the second phase never gets funded.
- Ignoring the people who do the work. The staff who know where the process actually breaks are consulted last, if at all.
The last one is worth dwelling on. Whenever I sit with the people processing the transactions rather than the people describing them, the picture changes — usually because there is a workaround everyone relies on that appears in no documentation and no system. Design around the described process and the transformation collides with reality on day one.
What I actually do
Assessment and honest baseline
Where the organisation genuinely is: what systems exist, what they hold, which ones disagree with each other, where information is re-entered by hand, what the volumes are, and what the current process actually costs in time. Interviews go to the people doing the work, not only to the people who own it. The output is short and blunt, and it is the document everything else is judged against.
A roadmap with a sequence, not a wish list
What to do first, what to defer, and what to abandon — with reasons attached to each and an estimate of effort against expected return. A roadmap that only contains things worth doing is not a roadmap; the value is in the ordering, and in what it explicitly excludes.
Systems and integration architecture
Deciding what to keep, what to connect, and what genuinely needs replacing. The instinct in most programmes is to replace, because replacement is easier to specify than integration. It is also slower, riskier and far more expensive, and it is right less often than vendors suggest. Much of the practical gain comes from connecting the systems you already own.
Customer-facing modernisation
The parts customers actually touch: the site, the forms, the enquiry path, the service journey, and whether the Arabic experience is equal to the English one. This is where transformation stops being internal and becomes visible, and it is often where the return arrives soonest. It overlaps directly with web and digital product work.
Data and reporting foundations
Getting to one version of each number. Most organisations discover during a transformation that three systems hold three different customer counts and nobody knows which is right. Until that is resolved, every dashboard built on top is decoration, and every AI project sitting above it inherits the confusion.
Governance that survives me leaving
Who decides what, what gets reviewed and how often, and how a change request is judged. Not bureaucracy — the smallest structure that stops the programme drifting back to whoever shouts loudest.
The order that works
Sequence matters more than ambition, and it is nearly always the same.
| What happens | Why it comes here | |
|---|---|---|
| 1. Fix the process | Remove steps that exist for no reason | Free, and you cannot automate your way out of a bad design |
| 2. Fix the data | Agree one source for each number | Everything above it inherits whatever you leave broken |
| 3. Connect the systems | Stop people carrying information by hand | Highest return per dinar in most organisations |
| 4. Automate | Hand repetitive work to the system | Only worthwhile once 1–3 are true |
| 5. Add intelligence | Apply AI where it changes a decision | Needs clean data and a defined use case to be worth its running cost |
Most failed programmes I review started at step five. It is the most exciting step, the easiest to get budget for, and completely dependent on the four beneath it. Deciding which of those steps you are actually on is much of what AI consulting consists of in practice.
The part that is not technology
A transformation asks people to work differently, and nobody adopts a new way of working because a memo said so. They adopt it when the new way is visibly easier than the old one, or when the old one stops being available. Anything that relies on goodwill and a training session reverts within a quarter.
Two things reliably help. First, involving the people who do the work in the design, early enough that their objections change something — they know where it breaks, and being asked converts opponents into owners. Second, being honest about what it means for their jobs. Staff who suspect an undisclosed agenda will comply on the surface and ensure it fails underneath, and they are usually right to be suspicious when nobody will say.
Where a team needs to build genuine capability rather than sit through a briefing, that is training and workshops — and it works considerably better built around your own systems than around generic material.
What gets measured
Agreed before anything starts, measured before anything changes, and reported on the same basis afterwards. Otherwise the review in six months is a conversation about impressions.
- Cycle time: how long a transaction takes end to end, not how long one department takes
- Touches: how many people handle it, and how many times information is re-entered
- Error and rework rate, which usually falls further than anyone predicts
- Cost to serve one customer or process one case
- Capacity: volume handled without adding staff
- Whether the people doing the work say it got better — asked directly, and worth more than any dashboard
How the engagement works
It starts with a fixed-price assessment ending in a written document: where you are, the three largest risks, and what should happen in the next ninety days. That document is yours and remains useful whether or not we continue — deliberately, because I do not want the decision to carry on to rest on money already spent.
After that, a defined number of days per month: chairing the decisions, reviewing what suppliers and internal teams deliver, keeping the sequence honest when something urgent tries to jump the queue. Implementation is done by your team or your vendors; my role is that the decisions are right and that somebody with a technical eye is representing your interest rather than theirs. Where that becomes the standing role rather than a programme, it is Fractional CTO work.
And it should end. If the sequence holds and governance takes root, you need me progressively less. A transformation adviser who is still indispensable after two years has failed at the part that mattered.
Frequently asked questions
How long does a transformation take?
The honest answer is that it does not have an end date, but it should have visible results within a quarter. If nothing measurable has changed in ninety days, the scope was too wide. I would rather deliver one completed change in three months than six half-finished ones in twelve.
Do we need to replace our ERP or core system first?
Usually not, and I would want strong evidence before agreeing to it. Core system replacement is the longest, riskiest and most expensive path available, and it frequently gets chosen because it is easier to specify than the harder work of fixing processes and connecting what exists. If the system is genuinely at end of life, that is a different conversation — but it should be the conclusion, not the starting assumption.
We are a government or semi-government entity. Does this apply?
Yes, with adjustments. Procurement cycles are longer, approval chains are deeper, and the sequencing has to be designed so that progress does not depend on a single approval landing on time. In practice that means smaller, self-contained phases that can each be approved and completed independently rather than one large programme that stalls entirely if one step is delayed.
Where does AI fit into this?
Last, and only where it changes a decision or removes real repetitive volume. AI applied to clean data and a defined process is genuinely valuable. AI applied on top of inconsistent data and an undefined process produces confident output that nobody can trust, at a running cost that continues indefinitely.
Do you implement, or only advise?
Both, depending on the piece. I build where building is the fastest route, and I oversee where your team or a supplier is better placed to do it. What I will not do is hand over a strategy document and leave — a recommendation nobody executes is worth nothing, and staying through implementation is where the advice gets tested.