Delivery stages

In one paragraph

Every engagement runs in four stages: understand the work, agree a fixed scope, build and test, then run and improve. Each stage ends with something written down that the client keeps, whether or not the next stage goes ahead.

1. Understand the work

We map the task as it runs today: the inputs and the formats they arrive in, the systems involved, who approves what, and where the time goes. This usually means sitting with the people who do the work and looking at real examples, not only reading process documents.

What you keep: a written map of the current process, and a sample set of real examples that will become the test set.

2. Agree a fixed scope

You get a written plan with the outcome, how we will know it is done, and the price, before any build starts. "How we will know it is done" is stated as measurements on the test set, for example the fields that must be extracted and the share that may go to review.

What you keep: the plan, including the acceptance tests.

3. Build and test

We build on your systems and test against examples from your own work before anything goes live. Each component is chosen after evaluation, and the choice is recorded with its reasons (see decision records).

What you keep: the system, deployed in your environment under your accounts, with its configuration, test set and documentation.

4. Run and improve

We monitor the system after launch and improve it as your work changes: new document layouts, new suppliers, new rules, newer models. Every change is scored against the test set before it ships (see evaluation in CI and production).

What you keep: a record of every change and its measured effect.

When not to go ahead

If the map in stage 1 shows that a simpler fix, such as a rule in an existing system or a change to a form, solves the problem, we say so and stop there.