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 had never been built. People did the work, and did it well, from habit and memory. Nothing was 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, the only way to learn that was to ask someone.
A nicer manual would have fixed none of that. We had three questions to answer first. What are the processes? What shape should every one of them take? 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. We had to decide what the pieces are, what shape they take, and how they point at each other, and then hold to those decisions for every process in the inventory. That last part was most of the work.
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 from that row. And because requirements trace back to numbered steps, the program can defend a procurement choice by pointing at the step it came from.
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.