What a written blueprint contains, and why it comes first

A blueprint is how both sides find out whether we understood the work. It is cheaper to be wrong in a document than in a system, and the client can act on it even if they never build anything with us.

Every engagement starts with one, in insurance, construction, energy and financial services alike. It comes out of the scoping session, it is written before anything is built, and it belongs to the client from the day it is delivered. It describes the work as it actually runs: the queue on an actual morning, the systems of record behind it, and the people who have to sign.

The result is a document the client keeps, whether or not anything gets built.

Why it exists

Most proposals describe the process the way the manual does. The real work is harder: requests that arrive late, records that disagree, thresholds applied differently in practice, and rules nobody wrote down. A blueprint is written for the work as it runs, in every department it touches.

It is also the only honest way to price the work. Nobody can quote a process they have not watched running.

Accuracy vs. Effort

Upper and to the right is better.

One processDepartment

Figures: illustrative

What is in it

The charts that follow are illustrative. They show the four kinds of finding a blueprint has to catch, drawn from the work itself: the exceptions on an insurer's claims desk, the systems behind a contractor's estimates, the controls on an energy developer's approvals, and the short exceptions mentioned once, in passing. A written blueprint misses less in all four, and on exceptions it leads every format we have used.

How it is produced

It is produced by sitting with the people who do the job, for as long as it takes to see the cases that do not fit, and it is written in the client's own vocabulary. If an underwriter or an estimator cannot correct it, it is not finished. Reading it back is where most of the corrections come from.

Corrections at read-back

Share of sections corrected (%). Lower is better. Illustrative.

• Written blueprint, signed
• Draft blueprint, unsigned
• The process manual
• Team interviews

The short exceptions, the ones mentioned once in passing, are the easiest to lose between the interview and the page. On that set, rework after go-live drops from 20.6% to 6.8% once the blueprint is read back.

The sections

Every blueprint carries the same sections, whatever the industry, and the client can hand it to their own engineers, their auditors, or another firm:

• The process as it runs. Step by step, from the first request to the last record it touches.
• The exceptions. Each one we found, who handles it today, and how often it occurs.
• The people. Who does each step, who approves it, and who has to be told.
• The systems. What is read from each system of record, and what is written back.
• The client's vocabulary. Their own terms for their own work, so the people who do it can correct it.
• The controls. Who approves what, what is logged, and what the system is never allowed to do.
• What we will not build. A process about to be replaced, or a step whose rules genuinely need a person, and why.
• The handoffs. Where the system stops and hands the case to a person, with the working attached.

Reviewed by the people who will live with it

A national contractor's estimating desk was rebuilt around its own estimators. Its engineers reviewed every integration in the blueprint, and its security team read the controls section before anything was built. Objections at that stage were cheap: two connections were redrawn on paper instead of in production, and the estimators rewrote the section on how they price unusual jobs.

“We have read a lot of proposals. This was the first document that described how our estimating desk actually works, in our own words, including the jobs we price differently and why. Our estimators corrected it, then it became the build, and it is still what we hand to anyone who asks what the system does.”

Then it becomes the build

What was written guides the build. Where reality forces a change, during the build or after go-live, the blueprint changes with it, and it remains the document that explains what the system does.

When the process changes, the blueprint is revised before the system is, and every earlier version stays on record. To see the version a system was built from, ask for blueprint-v1.0.

Tell us about the process you want handled

Scoping SessionTalk to us