Documentation that is actually used, and the kind that is only written

Why this matters

Documentation has the worst reputation of anything in this exam, and the reputation is earned: most of it is written once, never read, and wrong within six months. Technicians learn early that the documentation is unreliable, and that lesson is passed on by everyone who has been burned by it.

The exam nonetheless gives operational procedures a fifth of the paper, and the reason is that the alternative is worse. Every fault in this course is cheaper to fix when somebody wrote down what the machine is, what changed, and what was tried. So this lesson is about the kinds of documentation that survive — what a record has to contain to be worth keeping, and what makes one get read.

The lesson

Asset inventory: what a record must contain to be worth keeping

An asset record exists to answer questions someone will actually ask, and the test of a field is whether anybody ever queries it.

What a record must contain:

• A unique identifier — an asset tag, physically attached. Serial numbers work and are hard to read on a machine under a desk.
• Make, model and serial number, which is what a warranty claim and a support call need.
• Who has it, and where. The single most-asked question, and the one most often out of date.
• Purchase date and warranty expiry, which decides repair against replace.
• Specification — processor, memory, storage — because the answer to "can this run the new version" is here.
• Status — in use, in stock, being repaired, disposed of.
• Disposal date and method, which is a compliance requirement rather than tidiness.

What makes them worthless:

• Fields nobody maintains, which teach readers not to trust any field.
• No process for updating when a machine moves, which is the usual failure.
• A spreadsheet nobody owns.

The honest minimum for a small organisation is tag, model, serial, user, location, purchase date, status — seven fields, updated when a machine is issued, moved or disposed of. Seven fields that are right beat thirty that are plausible, and a technician who updates the record as part of handing over a machine is doing the only thing that keeps it alive.

Network diagrams and topology documents that survive contact with reality

Network documentation goes stale faster than anything else, and the way to make it survive is to aim lower than people usually do.

What is worth drawing:

• A logical diagram — what is connected to what, which subnets exist, where the internet connection is, where the firewall is. This changes rarely and explains most problems.
• Addressing, which is a table rather than a diagram: subnets, their purpose, the DHCP range, and the fixed addresses with what they belong to.
• Physical documentation where it is genuinely needed — which port on which switch, which cable goes where, labelled at both ends. A rack with labelled cables saves hours; a rack diagram in a folder saves nothing.

What does not survive: a detailed physical diagram of every cable and device. It is wrong within weeks, and being wrong is worse than being absent, because somebody will trust it.

What keeps it current:

• Keep it with the thing it describes — in the network folder, in the ticket system, on the inside of the cabinet door.
• Update it as part of the change, not afterwards. The change management lesson makes this explicit.
• Date it, and put a name on it, so a reader can judge its age.
• Prefer few documents that are right to many that are comprehensive.

A one-page diagram with last month's date is used. A thirty-page pack from three years ago is not, and the person who finds it will spend an hour discovering that.

Knowledge base articles written for the person who will be tired and in a hurry

A knowledge base article is read by somebody at 4pm on a Friday with a queue behind them. Writing for that reader changes almost everything about the article.

What works:

• A title that matches what they will search for — the symptom in the user's words, plus the error text. Nobody searches for "printer subsystem configuration".
• The symptom first, so the reader can tell within seconds whether this is their problem.
• Prerequisites stated — the access needed, the tools needed, what to back up.
• Numbered steps, each one action, in the order they happen.
• The exact commands and exact values, copyable. A step saying "configure the setting appropriately" is not a step.
• How to verify it worked, which is the part that is always missing.
• What to do if it does not work, which prevents the reader inventing something.
• A date and an author.

What fails: background and theory before the steps; screenshots of a version nobody runs any more; passive voice; and articles that assume the reader has the context the writer had.

The test worth applying: could someone with your access and none of your knowledge follow this without asking you a question? If not, the gap is somewhere in the middle and it is usually a step you do automatically.

And the article most worth writing is the one for the fault you just spent two hours on. That is when you have the detail, and it is exactly when nobody feels like writing it.

Standard operating procedures, and the difference between a policy and a procedure

The words get used interchangeably and the distinction is examinable and useful.

A policy says what and why. "Portable devices holding company data must be encrypted." It is short, it is approved by someone with authority, it changes rarely, and it does not tell you how.

A procedure says how, step by step. "To enable BitLocker on a company laptop: ..." It is specific, it changes whenever the technology does, and it is owned by the people who do the work.

A standard sits between them, naming the specific technology or setting a policy implies.

Why the distinction matters in practice:

• A policy with no procedure is an intention. Everyone agrees with it and nobody knows what to do on Monday.
• A procedure with no policy is a habit. It works until someone asks why, or until a different technician does it differently.
• Changing them is different work. Updating a procedure because a menu moved is routine. Changing a policy needs approval, because it changes what the organisation has committed to.

Where a technician meets them: the procedures are the documentation you write and follow; the policies are what you are held to. Two policies show up constantly in this exam — acceptable use, which says what users may do with the organisation's systems, and the security policy family covering passwords, data handling and incidents. Both are things to know exist, to follow, and to point at when a user asks whether something is allowed.

Keeping documentation current, which is the whole difficulty

Everything above is easy to write once. Keeping it current is the whole problem, and it has structural answers rather than motivational ones.

What actually works:

• Update as part of the work, not after it. A change that is not documented is not finished. The change management lesson makes this a step rather than an intention.
• Put the document where the work happens — in the ticket, in the network folder, on the cabinet door — not in a separate documentation system nobody opens.
• Make it easy to edit. Documentation that requires a review board to fix a typo does not get fixed.
• Fewer documents. Every document is a maintenance commitment.
• Date everything and name an owner. A reader who knows a document is two years old can judge it; a reader with no date cannot.
• Fix it when you find it wrong. Five minutes at the moment of discovery, by the person who just proved what is true.

What does not work: an annual review that consists of changing the date, a policy requiring documentation with nothing enforcing it, and expecting people to document at the end of a project when everyone has moved on.

The single highest-value habit for a support technician is the last one in the list: when documentation misleads you, correct it before closing the ticket. It costs minutes, it is done by the one person who now knows the truth, and it is the only mechanism by which a body of documentation gets better rather than older.