Insights & Perspectives

One Front Door, One Case File, One Contract Library

A municipal purchasing office is a small team carrying a large liability. Every competition has to be fair, every award defensible, every contract insured and current, and every record findable when an auditor or an access to information request arrives. The team we worked with was doing all of that through email, phone calls, a shared network drive, and spreadsheets.

They told us where it hurt in three sentences. They spent their days chasing information and re-explaining the process. They could never be sure which draft of a document was the current one. And they tracked insurance, workers’ compensation clearance, and budgets by hand, in scattered spreadsheets.

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 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.

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. The over-sharing was already there. Copilot makes it findable.

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.