Skip to content

From Quick Wins to Real Value: What we learnt about getting ROI from AI

Clock icon 9 minutes reading time

Most organisations are using AI. Far fewer can show what it's actually returning. That gap was the starting point for our Leeds Digital Festival event, From Quick Wins to Real Value: Unlocking ROI from AI, held at our Riverside House office on 1 October.

The morning had two halves. First, we showed how we've adopted AI at CDS as a whole organisation, not just a few keen individuals, told by the people doing the work. Then our panel took on the challenges our audience had sent in before the event, from bad data to building a business case.

Here's what we covered, and what we think it means for anyone trying to get real value from AI.

Doing it as an organisation, not leaving it to individuals

Steven Burton opened with a simple point. In most organisations, AI use is still down to individuals trying tools on their own. We chose to do it as a company, with clear rules, approved tools and the same security standards we hold ourselves to everywhere else.

We're a 61-person company, and every one of us has a licence, including sales and operations. In our most recent figures, 54 of those 61 people were actively using Claude Code, and 38 of our permanent staff had recorded an AI skill, with 14 at a level where they're coaching others.

As Steven put it, 61 people is the size of a single team in many organisations. So the real question isn't whether this scales up. It's whether you could do the same in one team by Christmas.

That adoption sits on a few simple foundations:

  • Company accounts only. Everyone signs in through CDS accounts, never personal ones.
  • Every tool is vetted first. Any AI tool goes through supplier checks before we approve it, including AI features added to products we already use.
  • A clear never list. Some information never goes into an AI tool, whatever the task.
  • A person reviews everything. Nothing AI-assisted reaches a client until someone has checked it, because the work carries their name.

Steven also talked about the guardrails plugin we built internally for Claude. It warns people when something they're doing doesn't fit our guardrails, but it doesn't block them or ban them outright. That keeps governance in place without stifling innovation. The accountability sits with the person, and we trust our people to do the right thing.

We were honest about what we got wrong, too. The first version of our AI policy focused on the wrong risk. It worried about the model memorising what you type in. The real risk is that the provider stores and processes what you send, under the terms of whichever account you used. We rewrote the policy in 2026. Getting the risk wrong is common, and it leads to the wrong controls.

From first conversation to live service

The heart of the presentation followed a client engagement from start to finish. At each stage, the person who owns that stage explained what AI has changed, what it hasn't, and one thing that went wrong or is still hard. Before each handover, Steven named the governance control that applies at that point.

Image (23)

1. Shaping the work

AI helps us pull deliverables out of a statement of work, turn client conversations into clear actions, and even test our own thinking by playing the client. It's also changed how we estimate, by comparing new requirements against data from past projects.

The difference can be dramatic. In one example, the estimate for a piece of work came down from 2.5 years to around 6.5 months.

The catch is that estimating gets harder to trust when AI compresses the effort. The question shifts from "how long will this take?" to "what level of quality does the client want?" And comparing against past projects only works if the historical data is good. In most organisations, it isn't.

The control: this is where data rules matter most. Client documents come in, so we're clear about what never goes into a tool. Where a client's contract adds its own AI restrictions, the stricter rule wins.

Image (22)-2

2. Design and build

We ground designs in as much real context from the client's systems and documents as we can, then check the design against the original proposal to make sure we're building the right thing. AI helps break designs down into a working backlog and speeds up development, but the build cycle itself is unchanged.

The control: AI coding tools run with the developer's own access, so we run them through a secure setup with layered controls, and secrets never enter a conversation. The output is treated as the developer's own work, because they're accountable for it.

Image (24)

3. Delivering and keeping clients informed

We explained how AI has shortened the whole delivery lifecycle. Just as importantly, we're now working from more accurate data. When we speak to clients, we're talking about facts, not estimates. That makes for open, honest conversations, and it frees up more time for client relationships.

AI also makes it cost effective to keep delivery records accurate and up to date, so there's no excuse not to. And faster delivery means clients can explore more options within a fixed budget.

One lesson we shared: agree a clear definition of "done" from the start of a project, and update it as you learn, rather than arriving at it late.

The control: a person reviews anything AI produces before a client sees it. A tool producing something faster doesn't change who's responsible for it.

Image (20)-2

4. Testing and assurance

The cycle is still build, review, test, deploy. AI makes that cycle shorter, it doesn't replace it. Because we can do more testing in the same time and budget, the quality bar goes up. It's also lowered the barrier to learning, with some of our testers moving into security testing.

But garbage in, garbage out still applies. More testing only helps if the standards going in are high.

The control: our testing standards didn't change because AI arrived. AI has to meet them.

Image (21)-1

5. Transition and live running

This is where we're seeing some of the clearest gains. AI helps our service team understand scope and responsibilities from day one, triage incidents faster, summarise tickets and produce client reports. The time is takes to write up a major incident report has dropped from around 90 minutes to around 5.

Reporting is faster too. Our service team can now pull up 53 metrics in just 4 clicks, so the information is there the moment someone needs it.

The pitfall here isn't technical. Service teams need to be involved in an engagement early, so they can plan capacity and staffing. AI can't fix being told late.

The control: we measure how our AI tools are used, but we count activity, we never read content. And if the underlying data isn't reliable, none of this works. That makes data quality a governance problem before it's an efficiency one.

Image (19)-1

Being honest about what controls can't do

Steven closed the presentation with the point we most wanted people to take away. Our own security guidance includes a section on what our controls don't do. No set of guardrails is watertight. The value of a control is that it makes choices visible and measurable, so you can see what's happening and act on it.

As Steven put it, a supplier who tells you their controls are watertight is telling you they haven't looked.

That's why we measure, and why we're willing to share numbers that aren't perfect:

  • Use of our secure setup. When we introduced a secure way of launching our AI coding tools, it covered 9% of sessions in the first week. Within six weeks it was 81%. That's real progress, and we're still closing the gap.
  • Whether people are really reviewing. Fewer than 1 in 500 AI-suggested edits were being rejected. That could mean the suggestions are good, or it could mean people are accepting them without enough thought. We don't know yet, so we're looking into it.
  • Whether our own data is good enough. When we built a tool to track delivery performance, only 3 of the 14 projects we tracked could produce reliable data. That's the clearest evidence we have for fixing your data before you trust AI to reason over it.

None of these numbers is the full story. But measuring them is what lets us ask the right questions.

What the panel said

Image (12)-2

For the second half, Matt Evans of techUK, Geoff Barraclough of the Home Office and Steven Burton of CDS answered the challenges our audience had sent in before the event. One theme ran through the whole discussion: put the right guardrails in place, so you can move fast with security and governance in mind, without stifling innovation.

Innovation and guardrails. The panel agreed that technical controls only work if there's a feedback loop with the people driving innovation. Champions who bring others along matter as much as any tool. So does recognising that the people experimenting move much faster than the rest of the organisation.

Governance that keeps up. Some governance is essential, but it has to keep pace with change. Get the balance wrong and people will use AI anyway, which is how shadow AI happens. It's better to build governance around innovation than to push it underground.

Proving ROI. The panel's advice was to start with the problem and the bottleneck, then ask whether AI is the answer. Sometimes it won't be. Build something small quickly, and know what you're measuring against. Look at the whole process too. A gain in one step can create a problem further along.

Trust and compliance. AI is lowering the bar for cyber attacks, so organisations need to use it for defence too. That means strong protection at the edge, and thinking about how far an attack could spread once it's inside. The panel also stressed defining your organisation's own terms and context clearly, because AI is only as accurate as what you give it. In regulated sectors, there are extra questions about issues like model drift and AI assurance.

Bringing people with you. AI isn't going anywhere. The people who'll do well are the ones who learn to work with it. The panel noted that conversations about AI aren't so different from those about earlier technologies, and that having a clear organisational position helps cut through the noise.

Legacy systems and data. If your data and technology are in a bad place, recognise it. Define what good looks like, factor in what it will take to get there, and start with a small, specific use case.

The rapid fire round

We finished with some quick questions to lighten the mood. Asked about their favourite personal uses of AI, our panellists had used it for everything from a retirement plan to a gardening plan to planning holidays.

When we asked whether the future looks more like WALL-E or Terminator, the general view was that Terminator was somehow the better outcome. Everyone agreed both are pretty terrible. And the AI most likely to turn on us first? The panel's money was on Grok.

Three things to take away

  1. Govern the account and the data, not the tool. Tools change constantly. Who signs in, under what terms, and what information goes in are what really protect you.
  2. Keep the cycle and shrink it, don't replace it. The good habits that make delivery work, like review, testing and clear standards, still apply. AI makes them faster.
  3. Fix your data before you trust AI to reason over it. Bad data leads to bad answers, however good the model is.

Thank you to everyone who came along and sent in their challenges, to Matt, Geoff and Steven for an honest and practical panel, and to the CDS team who made the morning happen.

If you're under pressure to show results from AI but aren't sure where to start, our AI Readiness Assessment gives you a clear view of where AI can genuinely help, what needs to be in place first, and what to build first. Get in touch and we'll talk it through.


Want more content like this? Sign up to our monthly newsletter!