AI operating model
A project office that lives in a git repository
Project knowledge lived in people's heads and chat threads, and AI tools were producing confident documents with no provenance. I made the repository the single source of truth and gave every project management role a written protocol.
- Intake, scope, estimation, risk, decisions, communications and more
- 11 rolesIntake, scope, estimation, risk, decisions, communications and more
- Decisions, change requests, risks, meetings, status, financials
- 10 templatesDecisions, change requests, risks, meetings, status, financials
- Pilot with monthly metrics and an explicit go or no-go
- 6 monthsPilot with monthly metrics and an explicit go or no-go
The client
A distributed software services organisation running multiple concurrent client engagements with a small project management function. Delivery knowledge was spread across individuals, and AI adoption was happening informally, project by project.
The engagement
A cloneable template repository plus a six-month pilot with named projects, monthly measurement and a go/no-go at the end.
The problem
Delivery knowledge was distributed across memories, chat threads and a scattering of spreadsheets, so onboarding a project manager onto a live account took weeks and every handover lost something. Introducing AI into that made it worse rather than better: the output was fluent, fast and impossible to trace back to a decision anyone had actually taken.
What I did
I moved the project's working memory into a plain markdown repository under version control — scope, estimates, decisions, risks, meeting records, deliverables — so every statement carries a date, a status and a diff behind it. On top of that sits a catalogue of role protocols: written specifications for the things a project manager actually does, each with its rules, its inputs and its document template, so an assistant executes a defined role rather than improvising a document. Meeting transcripts flow in automatically from the note-taker, which means the record is built from what was said rather than from what someone remembered. The whole thing is a template you clone, and it runs as a six-month pilot with monthly measurement and a real decision at the end rather than being issued as a mandate — including a ledger of where the model helped and where it did not, which is the part most AI adoption programmes carefully avoid keeping.
What was built
A markdown single source of truth under version control covering scope, estimates, decisions, risks, meetings and deliverables; a catalogue of eleven written role protocols and ten document templates; an always-on editor rule so every AI session knows the rules and the role boundaries; and automatic ingestion of meeting transcripts from the note-taker.
On the table at the end
- Template repository with role protocols, templates and folder skeleton
- Onboarding guide for instantiating a new engagement
- Pilot design: metrics, monthly snapshot, privacy and anonymisation rules, go/no-go criteria
What it changed
Cut project manager onboarding from weeks of shadowing to reading a structured repository, made every AI-assisted document traceable to a dated decision, and turned an informal habit into an operating model with a real exit decision rather than a mandate.
How it ran
- 01
Repository as the single source of truth
Markdown under version control with draft, in-review and approved states, dated edits, and source documents preserved untouched beside the derived ones.
- 02
Write down the roles
Eleven role protocols — intake, scope analysis, estimation, deliverables, decisions, meetings, communications, analysis, risk, negotiation, delivery — each with boundaries it must not cross.
- 03
Templates instead of prompts
Ten document formats so output is comparable across projects and people, and so a document is reviewable rather than merely readable.
- 04
Transcripts as an input, not homework
The note-taker connects directly to the workspace, so meeting records land in the repository and decisions are captured where they were made.
- 05
Run it as a pilot with an exit
Named pilot projects, monthly usage, productivity and quality metrics, a helped-or-not ledger, and a go or no-go at the end.
Other work
All case studies →- Enterprise software
Data and people existed; the process and the cockpit did not
A delivery assurance function owned everything and controlled nothing. I diagnosed nineteen gaps, designed the target operating model, and put stop conditions in the roadmap so it could not become another initiative nobody uses.
- Portfolio management
Earned value that survives an empty project
Portfolio dashboards go green because the data model rewards going green. I built one that measures in hours, sorts by trouble, and refuses to report a number it does not have.
- Knowledge operations
Turning sixty-five gigabytes of drive dumps into context an assistant can use
AI assistants are only as good as the context you can hand them, and the context was spread across drives, chats and mailboxes. I turned it into a structured base where every past engagement is a self-contained dossier.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.