← Back to Insights
Insight2 min read

Measurement: how you know the source is actually working

By Mohammed AlsaadiLäs på svenska

Most projects measure whether the source exists. Is it built, are the pages written, is the project marked done. That says nothing about whether it actually works. Four tests do.

Test 1: The first question

Give a new hire a real question, day one, and see whether the answer comes from the source without them having to knock on someone's door. Count how often that happens over the first few weeks. If it rarely does, the source doesn't cover what's actually needed, regardless of how much it contains.

Test 2: Update lag

Measure the time between a process changing and the source reflecting it. A source that doesn't stay updated is on its way back to being a binder, no matter how digital it is. A pass is within a week. Months is a sign the ownership isn't working.

Four tests: the first question, update lag, the judgment test, clear ownership

Test 3: The judgment test

The same test as step six of the method: a question only your most experienced person could answer correctly. Not a fact question, a question about why you make an exception in a specific case. It's the hardest test, and the most important one, because it's exactly the knowledge that otherwise disappears without a trace.

Test 4: Clear ownership

Ask three different people who updates a given part of the source. If you get three different answers, or three shrugs, you don't have ownership, you have a hope. A pass is everyone on the team knowing exactly who's responsible, without having to ask.

What to stop measuring

Page count measures effort, not usefulness. Visit count measures that someone opened the document, not that they got a useful answer. Both are easy to count and both measure the wrong thing. A twenty-page source that passes all four tests above beats a two-hundred-page one that doesn't.

Run the tests regularly, not just once

A source that passed at launch can fail six months later, for the exact same reason a binder goes stale over time. Set a reminder, run the tests again every quarter, and treat a failed test as a signal to go back to prioritization, not as a sign the project was wasted.

Want to see how your source holds up against these tests?

We'll walk through your existing documentation and show where it holds and where it breaks. Book a free call.

Book a demo

Request a demo.

Walk through your context gap with us.

Request a demo

Join the newsletter.

A weekly summary of new insights, plus what's new at Opmore. No spam, just insights.