From five pillars to GIVE

A month ago this article described five pillars of AI transformation: governance, ideas, value realisation, experimentation and delivery. Running the model with clients taught us two things worth changing in public rather than quietly. First, delivery is not a pillar - it is what the other four earn you, and pretending otherwise muddied the message. Second, "value realisation" was a consultant's phrase for something simpler: value. So the model is now four pillars with a name - GIVE - and this is the revised version, with the reasoning left in.

What has not changed is the core observation. When our leadership team whiteboarded what we were really doing for clients, it looked nothing like a conveyor belt. Some organisations arrive with one burning idea that needs proving. Others have ideas pouring out of every corner and no way to choose. A few cannot move at all because nobody has the authority to say yes. Marching them all through the same stages in the same order wastes the time of everyone who is already halfway in.

Four pillars, not four steps

GIVE treats the pillars as principles of innovation any organisation should have standing, not phases to pass through. You enter at your constraint. A useful way to find it: where does the work currently get stuck? If the honest answer is "we can't get a decision", that is Governance. If it is "we have forty ideas and no idea which is real", that is Value. One thing holds regardless of where you enter: governance runs from day one - at minimum a steering group with a sponsor, a technical person and a business person, meeting monthly.

GGovernance - guard-rails and decision-making

Mission: put the guard-rails and decision-making in place so AI can scale safely and deliberately.

Governance has an image problem - say the word to a room that wants to move quickly and they hear "the thing that stops us". The framing we use comes from motorsport: brakes are not there to slow you down.

"Brakes aren't there to slow you down. They're there so you can carry speed into the corner and get on the power earlier coming out."

• the analogy we use for AI governance

It has two halves. Technical governance is the platform side - where data lives and whether it stays onshore as Australian obligations often require, data loss prevention, environments, application lifecycle management, what new attack surface you have opened. Decision governance is the AI council: a small group with written scope, membership, delegation and decision rights - not a forum full of opinions where everyone can comment and nobody can commit. We cover the working details in the AI council in practice.

IIdeas - fill and feed the pipeline

Mission: fill and continuously feed the pipeline by discovering the opportunities hiding in the business.

Every organisation has hundreds or thousands of processes, most of them inefficient, and IT usually knows nothing about them. The techniques run from a shared-mailbox audit and a simple intake form, through out-of-the-possible sessions with a single department, to hackathons and citizen-developer programmes watched for signals. The best ideas rarely arrive labelled as opportunities - they hide inside things people have stopped noticing: the mailbox everyone dreads, the report someone rebuilds by hand every Monday. The full menu is in where ideas actually come from.

VValue - prioritised value, not the loudest voice

Mission: turn ideas into prioritised value with a shared, signed-off way to measure and sequence work - so focus goes to the highest-value use cases rather than the loudest voice or the biggest budget.

Value does two jobs. First, work out what value genuinely means to this organisation - and it is not always money or time. We worked with a legislative-drafting agency whose only real driver was accuracy; speed barely registered, because a single error in a drafted law is the thing that cannot happen. Optimise that engagement for hours saved and you build the wrong thing beautifully. Second, triage: plot each idea on benefit versus ease and let the picture sort itself out. The tooling is deliberately simple and covered in the priority matrix - benefit versus ease. The one rule we hold even for clients who skip the full framework: every proof of concept articulates its value before it is built.

EExperimentation - prove or kill ideas quickly

Mission: prove or kill ideas quickly and cheaply, before committing to a build.

This is where most organisations fall over. They believe in an idea, so they build it at full scale - and half of those builds quietly die because nobody asked the two questions first. Can we: does this actually work, with our data, in our environment? Should we: even if it works, does it move the value metric we said we cared about? A time-boxed proof of concept with strict acceptance criteria, tested assumptions and exec-sponsor sign-off answers both. The economics are the whole argument:

"We've tried to reduce the cost of doing experiments so that we can do more of them. If you can increase the number of experiments you try from a hundred to a thousand, you dramatically increase the number of innovations you produce."

• Jeff Bezos

Spending $25k to learn an idea is bad beats a $100k project that reaches the same conclusion the slow way. What a disciplined PoC actually hands over is in what a two-week PoC actually produces.

What happened to delivery

Delivery was pillar five, and removing it was the biggest change in the revision - so it deserves the reasoning.

Delivery does not belong in a capability framework because it is not a capability gap in the same sense. The four pillars build your organisation's ability to choose the right things; delivery is what happens once something has earned its build. Keeping it inside the model let it read as step five of a process we kept insisting was not a process. Moving it out keeps the message clean: the framework builds pipeline and proves value. Then - and only then - something gets built, whether by us, alongside your team, or within your own delivery framework. Our delivery record stands on its own on the projects page.

Start where you are - at any time

There is no intake window and no cohort to wait for. At kickoff we diagnose where you sit on each of the four pillars - current state and aspiration - and start at the pillar that matches your maturity and priority. An organisation with a burning-platform process goes straight to Experimentation, with the steering group stood up in parallel. One buried in ideas starts at Value. The point of naming all four is so you can locate yourself honestly, rather than assuming you have to begin at the beginning.