The Proving Yard

Four steps, in order, every time. Survey, Chart, Forge, Temper. What follows is how an engagement actually runs — including the parts that are inconvenient to say out loud.

What we need from you

More than most engagements ask for, and this is the single largest predictor of whether the work goes well.

Access to the people doing the work
Not their managers describing it. A few hours each with the people whose hands are actually on the process. This is usually the hardest thing to arrange and the least substitutable.
One person who can decide
Someone with the authority to settle a question in a day rather than a fortnight. Engagements do not usually fail on technical difficulty; they stall waiting for a decision nobody is empowered to make.
Honesty about the workarounds
The shadow spreadsheets, the WhatsApp groups where the real coordination happens, the step everyone skips. None of it is embarrassing and all of it is load-bearing. A map that omits it is fiction.
Tolerance for an uncomfortable finding
Sometimes the bottleneck is a person, a reporting line, or a decision made three years ago for reasons that no longer hold. We will say so plainly.

Shape and duration

Engagements vary, but they vary within a range and it is more useful to say so than to pretend every project is unique.

A survey and map is typically a small number of weeks. A first build — one process, end to end, in real use — is typically a few months. Widening from there depends entirely on how much territory you decide to cross, and that decision is made with the map in hand rather than before it.

We work with a small number of clients at a time. This is a constraint on how fast we can start, and it is why the first conversation is a real piece of work rather than a sales call.

How the engagement ends

Deliberately. Handover is a stage with its own work in it, not the absence of further invoices.

You get the source, the infrastructure, the data and documentation written for whoever inherits it. We stay close through the first stretch of real use, because that is when the things no test caught turn up. After that, we are available but not necessary — and that is the intended outcome.

What we will not do

We will not quote a build before the survey. A number given before anyone has looked at the work is either padded or wrong, and both are worse than saying so.

We will not staff a team to a headcount. We will not take an engagement where the conclusion has already been decided and the map is wanted as justification. And we will not recommend building something you can buy.

The four steps

  1. Survey

    The exploration session.

    We sit with the people doing the work and watch it happen. Not a requirements workshop — an observation. What gets written down is what is actually true, including the parts nobody puts in a process document.

    This is the session you book

  2. Chart

    Current state against target state.

    The work as it runs today, drawn so the gaps are visible rather than argued about. Every handoff, every queue, every place a spreadsheet is doing a system's job. Most of what we find was never designed; it accumulated.

  3. Forge

    Build the mechanism.

    Narrow first — one process, end to end, in front of real users — then widen once it is holding load. Building the whole map at once is how projects arrive eighteen months late and wrong.

  4. Temper

    Harden, hand over, stay close.

    Edge cases, failure modes, and the documentation your team will actually read. Then we stay close while it takes real weight, because the first month of live use finds things no test does.