Audit project documentation through reader tasks

Documentation can look complete while failing the person who needs an answer. Test what a reader can find and apply rather than counting pages. In this fictional example, an onboarding page points to two different release-approval checklists. The audit should produce a prioritized repair list with exact locations, not another summary that adds a third competing version.

Choose tasks with observable completion

Select a few questions a reader must answer to continue work. For the fictional project, ask them to identify the release approver, find the prerequisite for requesting review, and determine which checklist is current. State what a successful answer must include, such as an owner and the source establishing that owner's authority.

Do not ask only whether the documentation is clear. That invites an impression instead of a test. Use tasks appropriate to the reader's role and access. An inaccessible confidential document may be correctly restricted; the issue could be that the public instructions never explain how an authorized person requests the needed information.

Let an unfamiliar reader follow the actual links

Give the reader the ordinary starting page and let them navigate without author coaching. Record the pages they visit, the terms they search for, and where they stop. Ask them to explain their reasoning after an attempt, rather than supplying a hint at every hesitation.

In the example, one checklist names a project lead and the other names a rotating reviewer. Note both document locations and the contradictory instruction. If the reader succeeds only because an author says which link to ignore, record the task as requiring that hint. Oral knowledge is useful evidence of a missing instruction, not proof that the page passed.

Classify the information failure

Distinguish a dead link, a missing prerequisite, an unclear term, conflicting authority, and an unsupported instruction. Each calls for a different repair. Renaming a heading will not settle which checklist governs approval. Adding a link will not establish that the linked procedure is current.

Keep a finding record with the reader task, exact page or section, observed obstacle, consequence, and unresolved question. Quote only the small instruction needed to identify the conflict. Avoid copying private documents into a broadly shared audit note when a restricted reference will let the responsible owner inspect them.

Repair the authoritative path first

Ask the relevant owner to determine which instruction applies. Then update that page and its incoming links, mark obsolete material according to the team's existing document practice, and explain any necessary prerequisite. Assign a repair owner and prioritize failures that block required work over optional wording improvements.

For the fictional checklists, the repair might establish one approval rule and replace the outdated onboarding link. Do not make that authority decision merely because one document has a newer date. A newer edit can still describe the wrong process. Keep the decision and the revised location connected in the repair record.

Retest without the missing hints

Ask an unfamiliar reader to attempt the original tasks again from the same starting point. Confirm they can identify the approver and current checklist using the revised documents alone. Also check the alternative route that previously led to the obsolete version.

Close a finding only when its task works or its remaining limitation is explicitly accepted by the responsible owner. Keep an unresolved access or authority question visible. The useful output is a repaired information path and evidence that a reader can follow it, rather than an attractive document that still depends on somebody standing nearby to explain it.