Where we start
Session 3 ran both gates over twelve candidates at once and the headline result came out of the unlock table at the bottom of the bench. The entity that releases the most value on that board is not attached to any of the exciting cases. It is a free-text box the front desk fills in about a third of the time, and finishing it is a form change. Tonight is about why that keeps being true, and about the skill that turns it into a decision: telling the difference between a gap you can close once and a gap that becomes somebody's job forever.
★ What you walk out with tonight. Your own entity map with every partial entity tested rather than assumed, a released-value figure against each gap, and each gap labelled form change, pipeline change or standing job. One of those labels is a headcount and you should know which before you nod at it.
Held, partly, not at all
7 min liveTwo of the three states are honest. Not held at all is visible to everybody: nobody thinks there are sensors on the machines. Held in full is fine and needs no conversation. The middle state is the one that quietly wastes quarters, and it is the state most organisations are in for the fields they care about most.
Ridgeline Fitness is constructed, and every figure on this page describes it and nothing else. Twelve candidate cases and twelve entities were written so that the mechanism being taught is visible: the arithmetic is real and was computed from the entity map before any of these pages quoted it, but the chain is not. No published rate exists for how often a real portfolio is blocked, or for how often the entity that unlocks the most turns out to be a half-filled field, so no rate is claimed anywhere in these six sessions. What transfers is the method, not the numbers.
LiveWhy held partly is the state that wastes projects4 min▶
The two honest states both produce useful conversations. "We do not have that" ends a discussion in one sentence and everybody in the room can verify it. "We have all of that" lets work start. Neither costs you a quarter.
Held partly costs you a quarter because nothing about it announces itself. The column exists in the table. The join succeeds. The count comes back non-zero. A dashboard renders. Somebody ranks the top five cancellation reasons, puts the ranking in a deck, and a retention programme gets designed around reason number one. The ranking was computed over a third of the cancellations, and the third that got a reason written down is not a random third: it is the shifts where the front desk was quiet enough to type something.
So the analysis is not noisy, which would be survivable. It is biased in a direction nobody measured, and it comes with the full confidence of a real query over real rows. That is worse than having no reason field at all, because with no field somebody would have had to go and ask members.
The other half of the story is the reason this session exists at all. Held partly is also the cheapest state to fix, because the collection route already exists and somebody is already standing in front of it. That combination, worst failure mode and lowest cost to close, is what makes the half-held entity the most valuable position on the board.
LiveHow to test which state you are actually in4 min▶
Counting nulls is the first move and it is not sufficient. A field can be 95 per cent populated and still be unusable for the question you are asking. Run all four checks before you write "held in full" next to anything.
1 · Count the nulls, as a share, per year. Not overall. A field that is 80 per cent filled across five years and 20 per cent filled last year is a field somebody stopped using, and last year is the year you are about to analyse.
2 · Group the non-nulls by site, team or branch. This is the check people skip and it is the one that finds the worst problems. If 90 per cent of the filled-in rows come from two of twenty-two sites, you do not have a partially filled national field. You have a complete field for two sites and an empty one for twenty, and any conclusion you draw is a conclusion about those two sites wearing a national label.
3 · Group the non-nulls by time window. Same test on the other axis. Filled rows clustered into one six-month stretch usually means a manager ran a push, or an audit happened, or a system changed. Whatever the cause, the population you can analyse is that window and not your business.
4 · Count the distinct values, and look at the top one. If the most common value accounts for most of the rows and it happens to be the first item in the drop-down, or "Other", or an empty string that is not technically null, then the field is not being filled in. It is being dismissed. Default values are the most convincing kind of missing data because they survive every null check you can write.
Any one of the four coming back badly means the entity is held partly, whatever the schema says. If you are unsure after running them, it is partly.
Self-studyThe same four checks, phrased as questions for somebody else's data3 min▶
You will often be gating a case against data you cannot query yourself, on a call with the team that owns it. The four checks convert into four questions that are hard to answer vaguely.
"What share of rows have a value in that field, for last year only?" A confident round number here is usually an estimate. Ask for it in writing after the call.
"If we split the filled rows by site, are they even?" The tell of a problem is hesitation followed by "well, the newer sites are better at it". That is the answer. Write it down.
"Did anything change in how that field gets captured in the last two years?" A system migration, a new front-desk process or a compliance push all produce a time-clustered field, and the owner always remembers the event even when they have never looked at the distribution.
"What are the three commonest values?" If the answer is a default, an "Other" and a blank, you have found a form problem rather than a data problem, and the fix is upstream of anything analytical.
One more, worth asking about every entity regardless of state: "who would notice if this stopped being collected tomorrow?" If the honest answer is nobody, then the field is already decaying and any plan built on it has a clock running.
Somebody has done this properly, and said so carefully
6 min liveThree states is a working simplification. There is a published scheme with far more resolution, and the useful thing about it is not the extra levels. It is the argument that readiness is a property of a dataset and a question together, never of a dataset alone.
Use it, do not dress it up. Neil Lawrence's "Data Readiness Levels" is explicitly a position paper, offered by its author to trigger a discussion rather than as a finished or adopted standard. It should be cited that way. If you present it in a steering meeting as an industry standard somebody will check, and when they find it is a proposal your credibility takes the hit rather than the framework's. Equally, the three states on the session 3 bench are a deliberate simplification of it and not an implementation: they compress two of the three bands into one word, which is fine for gating a portfolio in an afternoon and is not fine as a substitute for reading the original.
LiveBand A is the one to take away: readiness is a pair, not a property4 min▶
The single most useful claim in the paper is that a dataset does not have a readiness level. A dataset and a question have a readiness level, together. The same rows can be fully ready for one question and only halfway ready for the next one, with nothing about the data having changed.
Ridgeline's membership records make the point. For "how many members do we have per site, month by month", those records are as ready as data gets: complete, agreed, machine-readable, and containing exactly the variables the question needs. For "why did this site's retention drop", the very same records are not ready at all, because the question needs a reason and the reason lives in a different field that is a third full. Nobody moved the data. The question moved.
This is why "is our data ready" is an unanswerable question and a slightly dangerous one, since it invites a yes. The answerable version always names a question: is this data ready for that. It is also why a data-quality programme with no use case attached tends to spend money improving band B on entities nobody was going to ask anything about.
The practical form of this for the rest of tonight: when you mark an entity on your map, mark it against the case that needs it. The same entity can legitimately be held in full for one case on your list and held partly for another, and a map that cannot express that is hiding the finding.
Self-studyWhat the three-state simplification loses, and when to reach for the full scheme3 min▶
Three states buys speed. You can gate a twelve-case portfolio in an afternoon with a whiteboard, and the gate output is unarguable enough to survive a planning meeting. What it loses is worth naming, so you know when to stop using it.
It merges two very different kinds of failure. "We cannot legally use this" and "this field is a third full" both collapse into held partly, and they are not the same problem: one is a permission question with a legal owner, the other is a form. The full scheme separates them by band, which is exactly the resolution you want once you are actually planning the fix rather than gating the case.
It has no room for degree. A field 90 per cent full and a field 5 per cent full are both partly, which is the right call for a gate and the wrong call for an estimate.
It is silent about the question, which is the band A insight above. Three states invites you to write one label per entity for the whole portfolio, and that label will be wrong for some case on the list.
The honest division of labour: use three states to gate the portfolio, then use the bands to describe the specific gap you have decided to close, and read the original paper before quoting it at anybody.
A form change, a pipeline change, or a standing job
6 min liveKnowing what an entity would release tells you whether the gap is worth closing. It tells you nothing about what closing it costs, and the cost question has three answers that are not on the same scale. Two of them are projects. One of them is a headcount.
| The gap | What kind of work | Releases | Why it lands there |
|---|---|---|---|
| Cancellation reason partly, filled about a third of the time | Form change | 3 | The field exists, the person is already standing at the screen, and the fix is to make it required with a short pick list instead of free text. Finite, and it improves from the day it ships |
| Member goals at intake partly, on paper, never keyed in | Form change | 2 | Already being collected, just not into a system. Moving the paper question onto the signup screen is a change to one flow, plus a decision about whether to backfill the paper |
| Injury and incident log partly, a paper folder per site | Form change | 1 | Same shape as the one above and with a compliance owner already attached, which usually makes it easier to get agreed and slower to get built |
| Cafe till linked to member not held, separate system, no member id | Pipeline change | 1 | Both systems already hold their half. Nobody has to collect anything new; somebody has to carry an identifier across a boundary. Bigger than a form and still finite |
| Competitor pricing and per-machine equipment use neither held at all | Standing job | 2 and 1 | Pricing is somebody checking twenty-two local markets, forever, or it goes stale in a month. Sensors on 900 machines is a capital programme and then a feed to maintain, forever. Neither has a finish line |
LiveWhy the two rankings have to be read together4 min▶
Read the value ranking alone and you get a sensible-looking order: finish the cancellation reason, then member goals or competitor pricing, then the three ones. Two of those four top entries are not the same kind of commitment at all.
Member goals and competitor pricing both release 2. On a value ranking they tie. Member goals is a question that already gets asked on paper at signup, moved onto the screen the person is already looking at: one flow changed, one decision about backfill, done. Competitor pricing is somebody visiting twenty-two local markets and writing down what the gyms across the road charge, and then doing it again next month because a pricing table that is six months old is worse than no pricing table, since it will be used with confidence.
Read the kind-of-work ranking alone and you get the opposite error: you do all the cheap things first regardless of whether they release anything, and a quarter later the board asks what changed and the answer is that three forms are tidier.
The combination is what produces a decision, and on this board it produces a clear one. Everything in the form-change group releases 6 between them and every one of those three entities is already being collected. Nothing in the standing-job group can be started without somebody agreeing to a permanent cost, and the best of them releases less than the single best form change. That is the shape to look for on your own map, and it is common enough to be worth checking for first.
Self-studyHow a standing job gets agreed to without anybody deciding3 min▶
Nobody signs off a permanent headcount for a data field. It arrives sideways, and there are three reliable routes.
It enters as a project line. "Competitor price benchmarking" appears in a plan with an effort estimate of four weeks. That estimate is honest about the build and silent about the refresh, because the refresh is not a build. Four weeks buys you one snapshot and a decaying asset. The question that catches it is not "how long will this take" but "what happens to this in month seven".
It enters as somebody's goodwill. An analyst starts maintaining the spreadsheet because they need it for their own work. It becomes load-bearing, and then they leave. This is the commonest version and the hardest to see, because while it is working it looks free.
It enters attached to a piece of capital. Sensors on 900 machines is a purchase, which means it gets scrutinised as capital and approved or not. What rarely gets costed in the same paper is the feed: calibration, failures, the site where they get unplugged, and the person who notices when the data stops arriving. Hardware makes the standing job invisible by giving everybody a big number to argue about instead.
None of this makes standing jobs wrong. Some are obviously worth it, and a business whose whole strategy is price position should absolutely have somebody watching competitor prices. The rule is only that it should be chosen as an ongoing commitment, by somebody who can commit to it, rather than absorbed as a line item on a roadmap.
Your entity map, gated and priced
★ 22 min · bring the map from session 3Five stages on the map you brought. You should finish with every partial entity tested rather than assumed, a released figure against each gap, a kind-of-work label on each, and one name to say out loud on Monday.
Mark each entity held in full, held partly, or not held at all, and do it against a named case rather than in general. The same entity can be held in full for one case on your list and held partly for another, and if your map cannot express that, widen the map rather than picking one label. Be harsh about the middle state: "we have that field" is not "that field is filled in".
For each partial entity, test how it is partial, because the four ways fail differently. Count the nulls as a share and per year. Group the non-nulls by site or team, which is the check that finds the worst surprises. Group them by time window. Then look at the commonest value and ask whether it is a default, an "Other" or a blank string. Write down which of the four it failed, in a few words, next to the entity.
Compute what each gap would release, by counting the blocked cases behind it. Walk your candidate list and, for each entity, tally the cases that would clear the gate if that one entity were held in full, along with whatever value score you use. This is a pass over the whole list per entity, it takes about ten minutes for a dozen cases, and it is the only way the released figure means anything. Do not estimate it from memory: the entity you expect to win frequently does not.
Label each gap form change, pipeline change or standing job, using the test rather than the feeling. Is the data already being recorded somewhere, including on paper? Form change. Do two systems each already hold their half? Pipeline change. Would somebody have to start collecting something new and keep collecting it? Standing job, and write the name of the person or team who would still be doing it in month seven.
Pick the best released-value-to-kind-of-work ratio and name it out loud. Rank by released value, then cross out everything labelled standing job that releases less than your best form change. What is left at the top is usually a field somebody is already half-filling. Say its name in the next planning meeting, along with what it would unblock, because it will not appear on any roadmap by itself: nobody ever asks for a required field.
If your best gap turns out to be a standing job. It happens, and it is a real answer rather than a failure of the exercise. Some businesses genuinely need a permanent collection effort for the thing that matters most to them, and price-led businesses are the obvious case. What changes is who has to agree: a form change is a decision for whoever owns the flow, while a standing job is a decision for whoever owns a budget line, and taking it to the first person because they are easier to reach is how a headcount gets absorbed instead of chosen.
Before session 5
30 min- Run the four partial tests for real on your single most important half-held field, or get somebody to run them and send you the numbers. The share filled for last year only, the split by site or team, the split by time window, and the top three values. Most people find at least one of the four comes back worse than they expected.
- Write the released figure next to every gap on your map, counted by walking the candidate list rather than guessed. Then check whether the entity at the top is one anybody has ever asked for. Usually it is not, and that gap between what unlocks value and what gets requested is the finding to bring back.
- Label each gap form change, pipeline change or standing job, and for every standing job write one sentence naming who would still be doing it in month seven. If you cannot name a person, the job has not actually been agreed to yet, whatever the plan says.
- Take your top form change to whoever owns that flow and ask what it would take to make the field required, with a pick list instead of free text. Bring their answer to session 5, along with your list of what clears, because session 5 sequences the survivors against how the business makes money.
Three questions
Clear all three and session 4 gets stamped in your passport.
1 · A cancellation reason field is 95 per cent populated, and 90 per cent of the filled rows come from two of the chain's twenty-two sites. What state is that entity in?
This is why counting nulls is the first check and not the only one. A null count of 5 per cent looks like a healthy field and the grouping check is what exposes it. D is tempting because readiness really does depend on the question, but the problem here is the population rather than the question: the field fails for any question about the chain as a whole.
2 · Two gaps on the unlock table both release 2: member goals at intake, already collected on paper at signup, and competitor pricing, which nobody collects. How should that tie be read?
The released figure answers what is worth closing and says nothing about what closing it costs, which is why both rankings are needed. C is the answer that gets a standing job absorbed without anybody deciding: it reads the tie as an argument for scope rather than as a question about what kind of work each one is.
3 · Somebody asks whether the membership records are "ready". What does the published readiness scheme suggest about that question?
The band A idea is the most useful part of the scheme and the one that changes behaviour: mark each entity against a named case, not in general. C is wrong twice over, since the author presents the scheme explicitly as a position paper meant to trigger a discussion rather than as a finished or adopted standard. D is exactly the habit the band A argument is written against.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Session 4 cheat sheet · pin this
You now have a map where every gap carries a released figure and a kind-of-work label, which tells you what is possible and what it costs. It still does not tell you what any of it is worth, because that depends on something outside the data entirely. Session 5 is the second gate: why the same use case is worth different amounts at different businesses, and why a case that pays handsomely at one company is a rounding error at the company across the road with the same data. It also takes apart the failure-rate statistics people quote to justify roadmaps, because you will be handed at least one of them and none of them survives being looked up.