Advice that never has to survive implementation.
A transformation is a deliberate change in how the organisation operates. The technology that comes with it is a consequence, not the headline. If a programme does not change how decisions are made, how work is sequenced, or how outcomes are measured, it is not a transformation — regardless of how much software was deployed.
Most transformation advice fails because the firm giving it never has to build what it recommends. We do. That changes the recommendation itself: we do not design an operating model we could not implement, or a process we could not put into a system.
Why transformation programmes stall.
No accountable sponsor
The programme reports to IT. Nobody whose operating metric changes owns the outcome, so trade-offs are never resolved.
Strategy with no operating model
An ambition is agreed at board level and never translated into roles, decision rights and process ownership.
Benefits nobody tracks
The business case is built to secure approval and then never revisited, so no one can say whether the programme worked.
Everything at once
Nine workstreams launch in parallel because each department wants to be in phase one. None reaches a measurable outcome.
Change management as a checkbox
Training is scheduled in the final month, with no budget line, no owner and no metric of its own.
Decisions nobody recorded
Eighteen months in, nobody remembers why a key design choice was made, so it cannot be revisited safely.
What the engagement actually includes.
Current-state diagnosis
Two to eight weeks on site, walking each end-to-end process with the people who run it. The output is a quantified diagnosis the client's own numbers confirm — not an interview summary.
Target operating model
How the organisation should work: processes, roles, decision rights, ownership and the controls that hold it. Signed by the sponsor before any platform decision is taken.
Business case
Costed, phased and tied to named operating metrics — built to be tracked after approval, not only to obtain it.
Roadmap & sequencing
What happens first, what waits, and what we advise against entirely. Each phase changes one measurable thing.
Programme governance
Steering structure, decision log, stage gates and monthly reporting against the operating metric written into the engagement.
Benefit realisation
Tracking whether the change actually delivered, reported to the sponsor monthly, with corrective action where it did not.
Five stages, each with a gate.
We are platform-pragmatic. The operating model is designed first; these are the platforms we most often build it on, chosen for the operation rather than for what we resell.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
How is this different from a management consultancy?
A management consultancy hands over a target operating model and leaves. We have to implement what we recommend, which constrains what we are willing to recommend.
Do you take work where the operating model is not ready?
No. If a client wants technology to fix an organisational problem that is not a technology problem, the project will fail and the failure will be blamed on the software. We sequence the organisational work first or decline.
Who must be the sponsor?
Someone whose own operating metric changes if the programme succeeds — typically the COO, the CFO or a sector-line CEO. We do not run a transformation reporting only to IT.
What if the diagnosis says we should stop?
Then we say so in writing. The cost of a failed transformation is not the fee — it is the eighteen months the organisation loses afterwards.
Start a conversation.
Choose the one that fits where you are. None of them is a sales call. Each is an advisory conversation calibrated to a specific question.