Insights & Perspectives

Building a Service Delivery Manual From Scattered Processes

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.

Requirements Traceability: The Thread That Survives Procurement

Every public sector RFP has a requirements table. Hundreds of rows, usually. “Ability to do this, ability to do that,” graded Essential or Desirable, assembled under deadline from workshops, old documents, and whatever the last vendor demo left behind.

Then the questions start. A vendor asks what “ability to manage asset data” actually means. An evaluator asks why row 47 outranks row 48. A year into implementation, someone asks whether the thing being built still serves the process it was bought for, and nobody can answer, because the path from why to what was never written down.

Before Copilot: Finding What Should Never Have Been Shareable

Every Microsoft 365 tenant has content that is technically accessible to far more people than anyone intended. It has always been that way, and it has mostly been harmless, because nobody could find the files. An AI assistant that searches everything a user can see changes that overnight. Copilot does not create over-sharing. It reveals it.

For a public pension administrator preparing its rollout, that made the privacy and security review a data problem before it was a policy problem.

The Dashboard Nobody Used Until We Shipped the Dictionary

The brief was clear enough. A provincial electric utility wanted timely, trustworthy information about what it buys, so that operational and strategic purchasing decisions could rest on data instead of on whoever had the freshest spreadsheet. The supply chain group already had reports. Dozens of them. The problem was that nobody could say which report answered which question, which one was current, or what a given column actually meant when it came out of the SAP warehouse.

Executives First: Piloting Microsoft 365 Where the Stakes Are Highest

Conventional wisdom says pilot new collaboration tools with an enthusiastic, low-risk team, learn, then scale. There is a case for the opposite. If the executive office adopts the platform first and visibly, the rest of the organization stops asking whether the change is real.

That was the bet on the transition-to-digital-platform workstream of a provincial Crown insurer’s transformation program.

Prove the platform can carry the program

Before the pilot, we had to decide what would manage the transformation itself. I led a proof of concept between the advisory partner, the platform vendor’s experts, the insurer’s business leads, and PMO leadership to evaluate whether a dedicated transformation-management platform could handle the program and its initiatives. A proof of concept with all four parties in the room is slower than a demo and far more honest, because the people who will live with the result are the ones testing it.

Running a Transformation Office on SharePoint, DevOps, and Power BI

Once a transformation program signs its vendors, a second project begins that nobody budgeted for: running the program itself. At a provincial Crown insurer, the discovery phase involved five selected system integration and advisory vendors, a management office, and workstreams that each wanted their own tracker, their own template, and their own definition of “at risk.”

We ran it on Microsoft 365, and the choice was less about the tools than about what a shared toolset forces you to agree on.