Watch how organisations choose their next AI project and a pattern appears quickly: the loudest voice wins, or the biggest budget does. Neither is malicious. Without an agreed way to compare use cases, volume and money are the only signals available - so they decide.
The Value pillar of the GIVE framework replaces those signals with a shared, signed-off way to measure and sequence work. Its central tool is deliberately simple: a matrix that plots every candidate use case on benefit versus ease.
The short version: score each use case on benefit (specific to your strategy) and ease (standardised - data complexity, people involved, process steps). High benefit, high ease goes first. The matrix is not the point - the quality of conversation it forces, and the authority to act on it, are.
Ease can be standardised. Benefit cannot.
The two axes behave differently, and treating them the same is the most common mistake.
Ease is largely objective, so we standardise it. The lenses we use:
| Ease lens | What it measures |
|---|---|
| Data complexity | How hard the data is to reach, and its privacy and governability constraints |
| People involved | How many people touch the process, and how many must change behaviour |
| Process shape | How many steps and approval gates the process runs through |
Benefit is the opposite - it is specific to your organisation, which is why the pillar starts by asking what is strategically important to you before any scoring happens. Benefit can be tangible (return on investment, time saved) or intangible (new opportunities surfaced, capacity created), measured against an agreed success metric.
One client gave us a use case where the primary driver on one segment of the process was time saving, and on another segment it was surfacing new opportunities - an intangible, but a measurable one, because they agreed the metric up front: a qualified opportunity that was not already on their book counts as success. Same process, two different definitions of benefit, both scoreable.
The value-driver method
For any single use case, one question sharpens everything: what is the single strongest value driver here? Name it, and everything else becomes secondary - which gives you licence to delete or deprioritise the parts of the project that do not serve it. The method can be re-applied per stage: a primary driver for the whole process, then re-asked for each sub-stage.
This is also where chunking earns its keep. As an illustration: if an eight-step process costs $250k to automate in full, but $60k on the two highest-value steps captures around 70% of the value, the sequencing decision makes itself. Do the high-value chunk, bank the result, and let the rest of the process compete for its place like every other idea. (Those figures are illustrative, not a quoted engagement.)
The matrix is only as strong as the authority behind it
A scored backlog changes nothing on its own. The consequence of this pillar is a signed-off value framework that your AI council can actually wield - including against ideas with powerful sponsors. The sentence it enables is worth the whole exercise:
"On our agreed matrix your project sits here. This one is easier and of equal value, so we are doing that first."
Said by a council with delegated decision rights, that sentence ends the loudest-voice era in one meeting. Said by nobody in particular, it is just another opinion. The council side of this is covered in the AI council in practice.
The baseline, if you do nothing else
You do not need the full framework to start. The non-negotiable in the Value pillar is smaller: every proof of concept must articulate its value - what strategic driver it serves and what success will be measured against - before it is built. A value framework tells you how to assess any idea that arrives; a value proposition is what each PoC must carry regardless. Keep the two distinct and you can start experimenting long before the full matrix is signed off - which is exactly what the Experimentation pillar is for.