Before you build: a one week reading

Agreement is not readiness. At blueprinting a client says yes to sharing the data, and whether the record exists in the shape promised is not tested until the build has started. That is where implementations lose months. This page is for the partner who builds: how the reading runs as a one week gate before the build, what it will tell you, and what it will not.

The problem it is for

You build forecasting, planning or analytics for large enterprises. In the blueprinting phase the client agrees to every data point. Then the build starts and the history is shorter than promised, the coverage is partial, the quality differs from market to market, and the people who agreed are not the people who hold the data. Two months go on data hygiene that should have been settled before the first line of code, and the sponsor who expected results is asking why.

What the week does

• One workspace, one unit per market or business unit. Each unit is read with the same people and the same questions: the unit data owner, the unit operations lead, and the central data and IT leads. Ten to fifteen minutes per person, all units in parallel.
• Every answer says what it rests on. A belief, an example someone can point to, a written document, a system record, or a sign off from Finance or audit. An answer on belief scores lower than the same answer backed by a record, so "we have the history" cannot pass on trust.
• Disagreement is a finding. When head office says one thing and a market says another, the difference is shown, not averaged away.
• Weak answers get a request for the record. The owner is asked. It arrives or it does not, and either answer is worth knowing before the build.
• All units on one page, in build order. The readiest units first, each with the step where its value stops, and one sentence for the steering committee: start the build here, fix this there first.

How the week runs

1. Day one, set up. The workspace, the units, the people named for each.
2. Days two to four, people answer. Three or four seats per unit, ten to fifteen minutes each.
3. Day four, records requested. The owners of the weakest answers are asked for the record.
4. Day five, side by side and decisions. The units compared, the build order, and the decisions to make before integration, with owners and dates.

What you get

• One short brief per unit: where value stops, why, what to do first, who decides.
• The units on one page with the build order and the points where teams disagree.
• The proof log, in the PDF: which records were asked for, which arrived, which did not.
• The decisions list with owners and dates, ready for the steering committee.
• The shortlist for the technical check: which units and which tables to open first.

What it will not do

It does not connect to the client's data. It will not tell you that promotion history covers 2.7 years for 40 percent of customers, and it will not pretend to. It tells you which units claim that on belief, which can produce the record, and who owns it. The depth, coverage, keys and freshness check is a short technical audit on the units the reading flags, so you check three or four instead of all of them.

How to start

Sign in, create the client's workspace, and on the setup page name the market or unit the reading describes under Before you build. Invite the same seats for every unit. When two or more units have completed, Business units side by side shows the comparison and the build order. The platform is in pilot, so every workspace has full access.

Start the reading