Process Documentation

Tehan Wijeratne

Here’s how I try to build process documentation worth reading:

1. Honest · 2. Findable · 3. Readable · 4. Visual · 5. Helpful · 6. Owned · 7. Automation-ready · 8. Alive

1. Honest#

Document the AS-IS first. Not how it’s supposed to work, how it actually works.
Ask three people who do the task. If you get three answers, that’s your first finding.
Only then draw the TO-BE.

2. Findable#

One home, one name. If people need to ask where the document lives, it doesn’t exist.
Name documents by the task (“Open a Regular Saver case”), not the team that wrote them.
Put the owner and last-updated date at the top.

3. Readable#

One page first, with the detail one click deeper.
Be concise (make every word count).
Avoid jargon and acronyms, or define them the first time.
Put the bottom line first: What do I do? When do I stop and escalate?

4. Visual#

A process map beats three paragraphs.
Show the decision points clearly. That’s where mistakes happen.
Keep one diagram per page.

5. Helpful#

Document the exceptions and workarounds, even the ugly ones.
Say what to do when it goes wrong, and who to contact.
Include examples of a good case and a bad one.
Make it easy for readers to say “this step is wrong.”

6. Owned#

Every document has a named owner and a review date.
A document with no owner is already out of date.

7. Automation-ready#

Clear inputs, clear outputs, clear rules.
Write the exception paths. Robots (and new joiners) don’t guess well.
If a human can’t follow the document, a robot can’t either.
Standardise first. Automation makes a messy process messier, faster.

8. Alive#

Update it when the process changes, not at the end of the quarter.
Walk the team through changes live. The questions are where adoption happens.
Delete what’s obsolete.

More writing