Ship on What You Already Have

Two clocks run in every platform programme and they are never the same length. The delivery clock is the one the business watches, and it is measured in the weeks between a promise and something a person can open. The procurement clock is the one the programme actually runs on, and it is measured in security reviews, legal passes, architecture boards, a sourcing exercise and a signature. Nobody plans for the second clock in the room where the first one is set.

Most programmes handle the mismatch by apologising for it. They put a foundation phase at the front, tell the business that the useful part starts once the platform lands, and spend the interval producing documents. By the time the contract is signed the sponsors have moved on, and the first release arrives into a room that has stopped caring.

A digital transformation blueprint I wrote for a global staffing and HR services group handled it differently. It wrote the mismatch into the plan as a constraint on the work, rather than as an excuse for the wait. Two of the projects in the first stage were forbidden new technology outright. The instruction was to find quick wins on infrastructure the group already owned, while the platform decision would run through selection and procurement on its own track.

The rule written into the grid

The first-stage portfolio sits on one page as a grid: five projects down the side, three objective lenses across the top, one for technology, one for governance and operating model, one for people and skills. Fifteen cells, each holding an indicative objective. It is an ordinary page to look at, and the pattern in it is not.

For the customer experience project, the technology objective reads: identify quick wins using existing infrastructure. For the data project, the technology objective reads: identify quick wins using existing infrastructure. Same sentence, twice, in the two places where a sponsor would most expect to see a shopping list. Neither cell names a product, a licence or a vendor.

The other two lenses for those projects are just as sparse. Governance is a working group set up to implement the quick wins. People and skills is to upskill the teams, or supplement them where needed. That is the whole enabling apparatus for the customer-facing half of the first stage: a working group and a training plan. No procurement line exists for either project, because the objective removed the need for one.

Only one project in the grid was allowed to buy. Its objective is to select, procure and implement the new experience and workflow platform, and that is its entire technology brief. The buying was quarantined into a single lane, and everything else was told to make progress without waiting for it.

What a quick win was allowed to cost

The reason the constraint has force is that the plan priced the alternative on a later page. Its cost model names people, internal and external, and technology as the two dominant drivers of a first stage, and says plainly that each high-level cost area still needed further scoping before anyone could commit to a figure. As a reference point it carries a comparable first-stage scope priced elsewhere at roughly 1.7 million pounds: a cloud-hosted experience platform with third-party support, a new operating model, and a content estate rebuilt to a single common taxonomy.

That page also splits every cost line into one-off and recurring, which is the discipline most business cases skip. Configuration and development end. Licensing, support and the operation of service management do not. A quick win on infrastructure you already run inherits none of the recurring lines, because the licence and the support contract are already sunk. That is not a small accounting point. It is the difference between an experiment a director can authorise and one that has to reach a board.

The staffing plan matches. Its role table places continuous deployment and integration in the first stage; running the platform day to day and managing the platform vendors are both marked for the second. The plan builds the ability to ship before the ability to buy and operate, which only makes sense if you intend to ship something in the interval.

Why this is the rule for a retrieval programme now

Nothing about that plan was written with language models in mind, and the transfer is exact anyway.

Every enterprise I speak to this quarter is somewhere in the same shape. There is enthusiasm for copilots, a shortlist of platforms, a vector store decision that has attracted more debate than it deserves, a security review that has not started, and a European regulation whose text is settled but which has not yet resolved into a compliance checklist anyone can hand to a supplier. The distance from a first workshop to a signed enterprise agreement is measured in quarters, and in a regulated group it is measured in more of them. The demand for a visible result does not pause for any of that.

So apply the constraint. For the period in which nothing can be bought, the technology objective for every business-facing use case is quick wins on existing infrastructure, and the sentence is not negotiable.

In practice that reads as follows. Retrieval-augmented generation prototyped over the document store and the search index you already license, rather than over the one on the shortlist. A copilot placed inside the tool your people already have open, because the adoption question is answered there and nowhere else. Evaluation sets assembled by hand from real queries and real answers, in a spreadsheet if that is what exists, because an evaluation set is an asset that survives every platform decision and costs nothing but judgement. Lineage written down for the handful of sources a use case actually touches, rather than a lineage programme for the whole estate. Early autonomous experiments kept narrow and carefully scoped, on a process where a wrong answer is caught by a person before it reaches a customer.

None of that is the target architecture. All of it is portable, and most of it is the part that was going to be hard regardless. The platform was never the difficult half. The difficult half was the definitions, the evaluation, the data readiness work and the question of whether anyone would use the thing.

5 x 3

Projects against objective lenses in the first-stage portfolio

2 of 5

Projects whose technology objective is quick wins on existing infrastructure

1 of 5

Projects permitted to select and procure a new platform

90 days

Scoping and mobilisation before the first quick win is implemented

What the constraint protects

There is a second reason to forbid new technology in the interval, and it is the one nobody puts in a plan.

If the pilot runs on a trial licence from a shortlisted vendor, the platform decision is finished before the evaluation starts. The team has learned that vendor's interface, written against its retrieval behaviour and built its integration once already. Every subsequent comparison is a formality conducted by people who would have to throw away work they have already done in order to reach a different answer. I have watched procurement processes reduced to paperwork this way more often than I have watched them reach a genuine choice.

Running the quick wins on infrastructure you already own keeps the two decisions honest about each other. It also produces something better than an opinion to buy against: by the time selection reaches a shortlist, you know which retrieval failures were the model's and which were the source data's, which queries the business actually asks, and what an acceptable answer looks like written down. That is a requirements document nobody had to imagine.

A quick win that needs the new platform is not a quick win. It is a demonstration of an invoice nobody has approved yet.

The honest limits of this page

The blueprint I am describing is intent. It is a portfolio of indicative objectives set against a sequence, produced ahead of the work, and nothing in the pages I am reading records a quick win that shipped, a service that launched, or a number that moved. Read it as a design decision taken under a known procurement constraint, which is what it is, and the constraint stands on its own reasoning rather than on an outcome.

The plan is also candid about why the quick wins were there. Its own lessons-learnt note is that progress has to be demonstrated regularly and iteratively, with visibility across the whole group, because that is what builds confidence in a programme and stops people working against it. The quick win is a political instrument as much as a technical one, and a programme that produces nothing visible for long enough loses the argument to whoever is producing something.

Both purposes point at the same rule. Take the outcomes you have committed to for the coming quarters and ask which of them would survive the platform contract slipping. Move every one that would not onto infrastructure you already own, or move its date. The RealAI Platform work starts there, with the estate you have rather than the one on the shortlist, because that is the only part of the programme whose delivery date you control.

Drawn from a digital transformation blueprint written for a global staffing and HR services group: its first-stage project portfolio, its two-speed sequencing plan, its lessons-learnt note, its operations role table and its first-stage cost model. Those pages set out indicative objectives, a sequence and cost drivers still requiring further scoping. They are a plan, not a record of delivery. Reading the "existing infrastructure" constraint as a rule for a retrieval and copilot programme is ours.