Readiness assessment

The engagement is scoped and its deliverable is fixed: a written roadmap naming the candidate use cases, the data each one requires, the integration surface each one needs, what a wrong output would cost in that specific context, and a sequence with its dependencies made explicit. It is priced and delivered independently of anything it might recommend building.

The review covers five things, and only the last is about models at all. The systems of record, and whether they can be read programmatically instead of through a screen. The data — whether it exists, whether it is structured, who is permitted to see it, how long it is kept. The workflows, and whether they have ever been written down. The integration surface, meaning the seams where a new system would have to attach. And the risk exposure: regulatory, contractual, and reputational.

Data is the constraint that decides most programs, and it is unglamorous enough that it rarely comes up in the first conversation. A system asked to answer questions from a company's own material is bounded entirely by whether that material exists in a retrievable place, whether the current version can be told apart from three superseded ones, and whether the permissions attached to it can be expressed in a query. Most organizations find out during implementation that the answer is no, and finding out then reprices the entire project.

Workflows that were never written down are the second recurring blocker. Automating a judgement requires knowing what the judgement is, and what surfaces repeatedly is that the process differs between the people performing it, in ways nobody had compared because nobody had reason to. That finding is worth the engagement on its own, independent of whether anything is subsequently built.

The cost of being wrong is assessed per use case rather than once for the organization. Drafting an internal summary somebody will read before acting, deciding whether a refund is issued, and generating text a customer sees unreviewed are three different risk classes that happen to share an underlying technology. Treating them as one category is how a business ends up applying the governance appropriate to the first against the third.

The assessment can conclude no, or not yet, and that possibility is precisely why it exists as a separate engagement instead of as the opening phase of a build. That conclusion is difficult to reach credibly from inside an implementation contract, and everyone involved knows it. An assessment that can only conclude yes and attach a quote is a sales document with a page count.

Sequencing is a deliverable in its own right. The first thing built should be whichever candidate proves the integration path while carrying the least cost if it fails, and that is reliably not the one generating the most enthusiasm in the room. Starting with the ambitious case means the plumbing and the judgement are being debugged simultaneously, and when it goes wrong there is no way to tell which one is at fault.

The output is a document, not a presentation, because it has to be read months later by someone who was not in the room — a board, an investor, a diligence process, or the person who inherits the work. Slides are a record of a conversation that happened; a document is a record of what was decided, and only one of those survives the departure of everyone who attended.

Build-versus-buy is answered concretely and named. Where an existing product already does the job, the assessment says so and identifies it, including when that conclusion removes the work. A recommendation to build something a vendor already sells is a recommendation nobody should accept without an argument attached, and being the party that would do the building is not a reason to withhold the alternative.

A question asked early and skipped almost everywhere is what the organization already pays for. Software a business holds under contract increasingly ships these capabilities as part of the product, and a use case satisfied by switching one on is not a project at all. Turning up two of those in a review is an ordinary outcome, and it reduces the scope of everything that follows — which is a peculiar thing for the reviewing party to be hunting for, and precisely why the review is priced separately from whatever it recommends.

Preconditions travel with each recommendation. A use case blocked behind a data migration is written down as blocked, with the migration named and sized, rather than listed alongside things that could start on Monday. A roadmap that presents dependent and independent work as one undifferentiated list is a roadmap that will be started in the wrong order.

Ownership after delivery is assessed as a precondition rather than deferred to handover. A system of this kind needs somebody inside the organization who reads its outputs, collects the cases it gets wrong, and has the standing to say when its behavior has drifted far enough to act on. Where no such person exists and none is being appointed, that is recorded as an unmet condition alongside the technical ones, because a system nobody owns carries on producing output long after it has stopped being trusted, and nothing in it will announce that transition.

Schedules are stated against the whole system, not the interesting part of it. The model work is usually small next to the integration, the evaluation, the review interface and the operational monitoring around it, and a plan budgeting only for the first will slip by the size of everything omitted. This is the most common way an otherwise sound program loses its credibility internally.

The assessment is deliberately inexpensive relative to what it governs. Its entire value is arriving at a decision before commitment instead of in month five, when the sunk cost has become an argument in its own right and the organization is choosing between finishing something it no longer believes in and explaining why it stopped.