The problem
A municipal asset management program came to us needing a service delivery manual: one document that says how the program actually runs. What we found is familiar to anyone who has worked inside a program office.
The processes were not built. People did the work, and did it well, but the processes existed as habit and memory, not as anything written down in one agreed shape. Where documentation did exist, it came in a pile of formats: a flowchart here, a Word document there, slide decks from past initiatives, templates that each author had invented fresh. No two described a process the same way. Nothing referenced anything else. If the strategy process consumed the policy process’s output, you learned that by asking someone, not by reading it.
So the real question wasn’t “how do we make a nicer manual.” It was: what are the processes, what shape should every one of them take, and how do they connect?
Our approach
We treated the manual as data first and a document second.
Step one was structure. We defined one shape for a process and made every process fit it: purpose, outcomes, who consumes it, how often it runs, inputs, outputs, governance controls, RACI, the systems involved. One row per process in a single inventory, numbered in a hierarchy (1, 1.1, 1.1.1). Dozens of processes that had never shared a template now shared one.
Step two was the steps themselves. Each process got a step table: step ID, description, the role that performs it, whether it’s a start, an action, or a decision, and which step comes next. That’s a flowchart, written as rows. Anyone can edit it without owning a diagramming tool.
Step three was the links. Cross-references became IDs in cells. When one process depends on another, the cell says so: AM Policy [1.1.1]. Frameworks, templates, and reference documents went into a registry with stable names. Then we carried the same IDs forward into more than a hundred user stories and roughly fifty system requirements, so the manual, the stories, and the eventual RFP all share one set of identifiers.
None of this needed special software. It needed decisions: what the pieces are, what shape they take, and how they point at each other. The discipline is the deliverable.
The results
From that one workbook we produced the service delivery manual itself, an 84-page document covering the program’s process hierarchy end to end: profile pages, flowcharts, cross-references, all consistent because they all come from the same rows.
The differences from the old state are practical. Every process now has a definition its owner can read, in a shape its neighbours share. Cross-references are real: follow [1.1.1] and you land on the thing it names. A change to a process is a change to a row, and everything downstream of that row stays consistent because it’s generated, not retyped. And because requirements trace back to numbered steps, the program can defend its procurement choices with line-of-sight instead of recollection.
We’ve since gone further and made these structures render themselves as designed, navigable documentation. That part deserves its own write-up, so it’s coming in a later post.