Why Documentation Is Part of the System

Ask most businesses where their documentation sits in the project plan and the answer is “at the end, if there is time”. It is treated as a by-product: something produced after the real work of configuring software, building a process or training the team. That framing is the source of the problem. Documentation is not a record of the system. It is part of it.

Consider what a system actually is. It is not only the software and the integrations. It includes the people who operate it, the rules they follow, the knowledge they carry and the way that knowledge reaches the next person. Remove the written part of that knowledge and the system still runs, until the person who remembers the details is unavailable. Then it behaves like a different system, one with a missing component.

If a process only works when a particular person is in the building, then that person is part of the system, and nothing has been written down about them.

What documentation actually does in a system

It helps to think of documentation by function rather than as a single thing. Written material does at least four jobs that the software cannot do for itself.

It carries intent. A configuration shows what a system does, not why it was set that way. The reason a discount is capped at 12% or an invoice needs a second approval is rarely visible in the settings screen.
It transfers capability. A new bookkeeper, a locum or a manager covering leave can perform the task from the written procedure instead of interrupting a colleague.
It enables recovery. When something breaks, the steps to restore it, the contacts to call and the order of operations are needed at exactly the moment people are least able to work them out from memory.
It supports change. Before altering a process or replacing a tool, someone has to know what depends on it. Documentation is how that knowledge survives long enough to be used.

The Atlassian guide to knowledge management makes a similar case from the service-desk side: capturing knowledge as part of resolving work, rather than as a separate exercise afterwards, is what keeps it accurate and findable. Microsoft's operational excellence guidance for workloads likewise treats documented procedures, runbooks and automation as standard practice for reliable operation rather than optional extras.

How a missing document changes the system's behaviour

When documentation is absent, a predictable set of behaviours appears. Questions are answered by interrupting whoever is most likely to know. Tasks are done differently depending on who does them, so outputs vary. Small deviations accumulate until two people believe they are following the same process while performing different steps. And when the knowledgeable person leaves, the loss shows up as errors weeks later rather than on their last day.

These effects are described from different angles elsewhere: the operational drag of repeated questions in the cost of the same internal questions with undocumented knowledge, and the fragility of the arrangement in what happens when the only person who understands the system leaves. The common thread is that missing documentation is not a neutral absence. It is a defect that has an operational cost, even if no line in the budget shows it.

Why documentation decays, and why that matters

A document written once and never touched is less useful than it appears, because a wrong document is worse than none. People follow it with confidence. Documentation decays for ordinary reasons: software updates change screens, suppliers change, a workaround becomes the standard method, and the author moves on. If documentation is outside the system, nothing triggers a review when the system changes. If it is part of the system, then changing the process includes updating the instruction, in the same way that changing a form includes changing the field.

That is a design principle rather than a discipline problem. Build the update into the change itself. A change to a payment run is not complete until the written steps match the new run. The reasoning behind controlling changes is set out in why uncontrolled configuration changes create operational risk, and documentation is the simplest control that goes with it.

Document by priority, not by completeness

Few small businesses have the time to document everything, and trying is a good way to document nothing. Start with the work where the cost of a gap is highest. A sensible order is:

Work that happens on a deadline: payroll, VAT submissions, month-end close, and anything linked to SARS or a statutory date.
Work that only one person can do today.
Recovery steps: how to restore access, restart a service, or reach a vendor when something fails.
Work that is handed between teams, where misunderstandings are common.
Everything else, as time allows.

A more detailed ranking approach is given in what business processes need documentation first.

What good documentation looks like in practice

Useful documentation is short, specific and located where people already look. A single page that says who does the task, when, in which system, what a correct result looks like and what to do when it does not is more valuable than a forty-page manual that nobody opens. Screenshots, numbered steps and the exact names of reports help. So does recording the reason for non-obvious rules.

The test of quality is not whether the document looks professional but whether a competent person who has never done the task can complete it from the page alone. The best way to test is to ask someone unfamiliar to follow it and watch where they hesitate. Each hesitation is a gap. The pattern of keeping this work close to the work is discussed in why automation documentation matters, and a related checklist for integrations is in what to document before connecting two business platforms.

Where it should live, and who owns it

Documents scattered across personal drives, WhatsApp groups and old email attachments might as well not exist. Choose one location for operational documentation, make it searchable, and give it a structure that matches how people think about the work, usually by process or by system rather than by author. Every document needs an owner, shown on the page, and a review date. Ownership is what keeps it alive, and unowned documents become stale together with the systems they describe. If staff cannot find what they know exists, the problem is structure, not effort.

The continuity and compliance dimension

Documentation is also a requirement of resilience planning. The NIST guidance on contingency planning for systems treats documented recovery procedures, contact lists and roles as core elements of a plan that works under pressure. For South African businesses, the Protection of Personal Information Act adds another reason. Section 19 requires a responsible party to take appropriate, reasonable technical and organisational measures to secure personal information. A written account of who has access to what, how data is backed up and what happens in a breach is difficult to separate from those measures, because it is the way the organisation shows that it knows what it is protecting.

An illustrative example

The following is a hypothetical case. A Pretoria property-management firm with 35 staff relies on one bookkeeper who runs the monthly levy billing. The process involves an export from the tenant system, a manual adjustment for units on payment arrangements, and an import into accounting. None of it is written down. When she is unwell for a week at month-end, the standby clerk follows the visible steps, misses the adjustment, and sends incorrect statements to forty tenants. The cost is not the software. It is two days of corrections, several irritated owners and a loss of trust in the statements.

The firm responds by writing a one-page procedure, including the reason for the adjustment, and by having the clerk run it once with the bookkeeper observing. The next month the billing run is done by the clerk while the bookkeeper is on leave.

Treating it as part of the build

The practical conclusion is to change when documentation happens. Include it in the definition of done for any new system, workflow or change. Allocate time for it in the project, and review it alongside the systems it describes. A process that has been built, but not documented, is not finished. It is simply working until the next time someone is absent.

Sources and further reading

Knowledge Management in ITSM: Process & Benefits - Atlassian (last verified 10 October 2026)
Operational excellence quick links - Microsoft Azure Well-Architected Framework (last verified 10 October 2026)
SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems - CSRC (last verified 10 October 2026)
Section 19 Security measures on integrity and confidentiality of personal information - POPIA (last verified 10 October 2026)