AI Readiness and Feasibility Study

Overview

The AI Readiness and Feasibility Study is a short, time-boxed engagement that answers two questions before you invest in a build: is your organisation ready for AI, and will this specific initiative deliver? We assess the foundations AI depends on — data, platforms, access controls, governance and people — then test your priority use case through data discovery, architecture review, stakeholder immersion and a lightweight proof of concept. You finish with a clear recommendation to proceed, pivot or pause, the readiness gaps to close, and an implementation estimate based on your actual systems. It's stage two of our four-stage delivery approach, and the step we never skip.

Who is this for?

You'll recognise the situation

You've chosen an AI use case — perhaps from an AI Strategy Workshop — and need evidence before you fund it.

You suspect your data isn't ready for AI, but don't know how far off it is or what to fix first.

You pointed an AI tool at everything (every document in SharePoint) and got answers that were inaccurate, slow or expensive.

You need an estimate that covers ongoing running costs, not just the build.

Sponsors want evidence, not optimism, before they sign off.

What's included?

Two questions, answered with evidence

Readiness: is the organisation ready?

We assess the foundations AI depends on, so you know what to fix before you start.

Our approach

Data foundations — quality, completeness and whether it's AI-ready: current, curated and trusted.
Platform and architecture — how AI fits your stack, and whether it needs uplift first.
Security and access — whether your permissions can control what AI sees per user.
Governance — whether policies, accountability and oversight are in place.
People and process — skills, ownership and the capacity to adopt and run what gets built.

Feasibility: will this initiative deliver?

We test the specific initiative against real evidence while the cost of being wrong is still low.

Our approach

Stakeholder and process immersion — current-state operations, pain points and success criteria.
Targeted prototyping — a minimal prototype that tests the highest-risk technical assumption.
Integration and infrastructure — the systems, APIs and pipelines needed for production.
Build or buy — whether off-the-shelf covers it, or a tailored build fits better and costs less over time.
Running-cost view and a clear recommendation with a delivery approach and estimate.

How do we deliver it?

Brief, discover, validate, estimate

Brief & scope

Confirm the business problem, success criteria and stakeholders.

Readiness discovery

Assess data, platforms, access, governance and people against what the initiative needs.

Feasibility validation

Immersion in your systems and operations, plus lightweight prototyping to test make-or-break assumptions.

Synthesise

Bring the findings together into a proceed, pivot or pause recommendation.

Estimate & hand over

A detailed implementation and running-cost estimate, with the artefacts and reasoning behind it.

What tools and technology do we use?

The stack behind it

The study is technology-agnostic and works across Azure, AWS and Google Cloud. Prototyping tools are chosen to suit the initiative being tested, so the recommendation reflects what's right for you rather than what we prefer to build.

What you walk away with

Know what to fix first — the readiness gaps that would derail delivery, identified and prioritised.

De-risk before you commit — your toughest assumptions tested while the cost of being wrong is low.

A defensible estimate — evidence-based numbers for both the build and the ongoing running cost.

Alignment and architecture confidence — conflicting expectations surfaced early, target architecture agreed.

A business case that holds up — sponsors presented with evidence rather than optimism.

How is this engagement structured?

Delivered on a time-and-materials basis and scoped to the initiative. Straightforward initiatives can be assessed in a few days; larger enterprise work takes longer. Contact us for a tailored quote.

Common questions

What's the difference between readiness and feasibility?

Readiness looks at your organisation: whether your data, platforms, access, governance and people can support AI. Feasibility looks at a specific initiative: whether it will deliver and what it takes to build and run. We cover both — an idea can be feasible in theory and still fail on weak foundations.

Do we need a lakehouse before we can use AI?

Not always. Some use cases work directly against existing databases if networking and security allow. The study tells you which foundations your use case actually needs, so you don't over- or under-invest.

Can you estimate what AI will cost to run?

Yes. We estimate model consumption based on expected usage and recommend design choices that keep costs predictable.

What if the answer is don't proceed?

That's a valuable outcome — the point is to catch a bad assumption before months of implementation cost, not to justify a decision already made.

Why not go straight to a proof of concept?

A PoC shows a model can work in controlled conditions. It doesn't tell you whether your data, platforms and people are ready for production, or what it'll cost to run — the gaps that stall most AI projects.