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.
RAID with rules
With the advisory partners, we defined the governance for program RAID, the risks, assumptions, issues, and dependencies that every workstream generates and nobody reconciles. The governance was mostly rules about ownership and cadence: who can open an item, who can close it, how a dependency between two vendors gets escalated when neither owns it. The register itself was ordinary. The rules were what made it usable.
A hub, not a folder farm
I led workshops with the insurer’s leadership and the partner leads to elicit content, information architecture, documentation, and metadata requirements for an integrated SharePoint hub with a site per workstream underneath it. The metadata conversation was the important one. Every artifact carried the workstream, the phase, the status, and the owning vendor, which meant the hub could answer “show me everything awaiting approval in discovery” without anyone building a report.
One DevOps, configured once
Five vendors bring five ways of writing a user story. In consultation with the partner leads, I configured Azure DevOps so that every workstream used the same work item types, states, and fields. Standardization sounds bureaucratic until you try to roll up progress across teams that each invented their own “done.” After that, prioritization across vendors became possible, and dependency tracking stopped being a spreadsheet someone updated on Fridays.
The same discipline carried into the statement of work refinement. Managing key activities and dependencies with all five vendor leads, and holding their SOWs to the RFP’s contractual requirements, only worked because the backlog gave everyone the same view of what had been promised.
The report that ran itself
Program-level reporting had been a monthly assembly job: collect status from each initiative, paste, reconcile, argue. I automated it in Power BI, aggregating information from every initiative and workstream straight from DevOps and the hub. The steering committee saw the same numbers the teams saw, on the same day, and the argument moved from “whose number is right” to “what do we do about it,” which is the only argument a steering committee should be having.
What transfers
None of this required a program management platform. It required deciding, early, that the program would have one vocabulary, one backlog, one hub, and one report, and then configuring tools the organization already paid for to enforce that decision. Years later, that idea became a product line: structured program data that renders itself as the documentation and the dashboards, so the assembly job never comes back.