Short answer
#The shape of the four weeks
This is deliberately not a project. It is four short exercises, each of which produces something concrete, and each of which is useful on its own if you stop after it.
| Week | Output | Effort |
|---|---|---|
| One | A list of accounts and whose name each is in, plus a data copy you hold | Two hours, mostly yours |
| Two | An inventory of the parts and what each is for | One instruction, plus half an hour reading it |
| Three | Where customer data lives and what leaves the system | An hour, and one conversation |
| Four | A concentration count and a prioritised question list | An hour |
#Week one — what you own
Start here rather than with the software, for two reasons: it is the only part where a wrong answer can leave you unable to operate, and it is the part you can do entirely by yourself.
Check each of these yourself
- The domain: registrant name, and where the recovery email goes
- DNS: who runs it, and can you sign in
- The cloud account: whose name, who is billed, who is the root user
- The repository organisation: who the owners are
- The payment provider: whose name, and where settlement goes
- Every service on your bank statement that you cannot identify Your invoices are a map of the system's dependencies from an independent direction.
And one thing to do
- Get an independent copy of the production data that you hold and have personally opened Everything else in this guide can be repeated later. This is the one that covers the worst case.
#Week two — what it is made of
Ask for an inventory: every part of the product, its type, and one sentence about what it does, written for somebody who does not read code.
Ask for it derived rather than written. The distinction is practical: a document written from memory takes somebody a week, describes what they remember, and cannot be checked. A derived one takes an instruction, covers what is actually there, and carries a reference for each claim.
What you are looking for when you read it:
- Anything you do not recognise. A component nobody mentioned. This happens more often than people expect and is the main reason to do the exercise.
- How many parts there are. The number itself is useful: it is the answer to "how big is this", which everybody asks and nobody can answer.
- Whether every part has a purpose you understand. If a sentence does not make sense to you, it is either badly written or nobody is quite sure — and both are worth a question.
#Week three — where the data and the money go
Two traces, both of which follow something out of the system rather than around inside it.
-
Follow the customer data outward
Where is it stored, and what leaves? Analytics, email providers, partner feeds, nightly exports, backups. Outbound is the half nobody thinks about and the half that matters legally.
Where a destination is configured outside the code, nobody can answer this from the software alone — which is itself worth knowing explicitly.
-
Follow the money path end to end
From a customer clicking pay to the money arriving. Which components, which external services, and — the important part — what happens when each step fails.
The failure question is where fast-built systems are weakest, and it is a question an owner is entitled to ask in business terms.
#Week four — concentration and gaps
The concentration count. List the parts from week two. Next to each, write the name of every person who could answer a hard question about it. Count the parts with exactly one name.
Web application 3 people
Billing and payments 1 person ← Anna
Subscription logic 1 person ← Anna
Email and notifications 2 people
Infrastructure / deploys 1 person ← Marek
Nightly export 0 people ← nobody, it just runs
Mobile app 1 person ← an ex-contractorNothing is wrong with this company. This is what an ordinary, successful, four-year-old product looks like when somebody counts — and the count is a more accurate technical risk register than most companies have.
The question list. Everything the previous three weeks raised and did not answer, ranked by what it would cost to be wrong about. Ten to thirty items is normal. Four of them will matter.
#Keeping it true afterwards
- Re-derive the inventory when something material changes — after a big release, at the end of an engagement, when a subsystem lands. Not on a calendar.
- Work the question list down and record who answered each one. A shrinking list is the only progress measure that works here.
- Re-check ownership annually. Accounts accumulate, and the recovery addresses drift.
- Keep it where the company can read it, not in your own notes. If you are the only person who knows, the exercise has moved the problem rather than fixed it.
#What goes wrong
Starting with the software rather than the accounts.
Instead Accounts first. It is the only category where a wrong answer is not recoverable with money, and it is the part you can do alone.
Asking for a document.
Instead Ask for the inventory to be derived. A document is somebody's week, describes their memory, and cannot be checked.
Turning it into a project with a steering group.
Instead Four exercises of an hour or two. Formality here produces performance rather than answers.
Doing it once.
Instead A picture eighteen months old describes a different product. The value is in the difference between two of them.
Keeping the result to yourself.
Instead Everything goes somewhere the company holds. Otherwise the single point of failure is now you.
#What this does not cover
What this does not do
- Whether the software is well built. Not a question this method answers and not one an owner needs answered.
- Security assessment. The data trace touches it; a security review is a separate exercise.
- Product decisions — what to build next, what to retire.
- Team capability or performance.
- Anything regulatory specific to your industry.