Intake
One route for new and changed work, carrying the same detail every time: sponsor, outcome, dates, and the skills it needed.
Delivery operations · Internal PMO · Havas CX Canada
An agency's only real inventory is its people's time, and at Havas CX Canada that inventory lived in conversation rather than in a system. Work arrived through whoever was asked, staffing was settled request by request, and the question of who was free next month had as many answers as people you put it to. The first stretch of my time there was spent building the places where those answers would live.
The mandate / 01
An agency sells one thing every day: its people's time. When that inventory lives in conversation rather than in a system, every staffing decision becomes a negotiation between whoever asked first and whoever answered fastest.
The work arriving at Havas CX Canada was continuous and real. What was missing sat underneath it. New and changed work entered wherever it happened to land—an email, a hallway, a client call—and each request carried whatever detail its sender thought to include. Allocation was settled person by person. Utilization was something the finance system could reconstruct after the fact, not something a delivery lead could see in time to act on.
The second tension is the one that makes internal work hard: there is no client. Nobody escalates when a resource plan goes stale, and no statement of work obliges anyone to fill in a field. An internal system does not compete with the old process—it competes with the workaround, and the workaround is always one message to a colleague who already knows the answer. Adoption, not design, is the whole problem.
The agency also could not stop to be organized. Every one of these systems had to be built underneath work that was already moving, by people whose day job was that work.
So the mandate was narrower than documenting how the agency operated. It was to give the agency a small number of places where the truth about work and people lived, and to make those places easier to use than asking around.
Internal financial structures, rate information, and client commercial terms are withheld. What is described here is the operating design, the tools it ran on, and the decisions behind it.
The PMO system / 02
The design was a loop rather than a hierarchy. Work comes in; people are committed to it; what actually happened is recorded; the record corrects the next commitment. Most agency operating failures are a break somewhere in that loop, so the system was built as a few surfaces that had to connect to each other.
One route for new and changed work, carrying the same detail every time: sponsor, outcome, dates, and the skills it needed.
The forward view of who is committed, to what, and until when.
The same picture read backwards, so a plan could be checked against what was actually spent.
The memory: what lets a new person become useful without borrowing a colleague's entire afternoon.
Setup, codes, structures—the records that make a project legible to finance. The least interesting surface, and the one whose absence breaks every other surface quietly.
Four systems held pieces of the answer: Agresso, Kantata, MS Project and Google Workspace. None of them agreed with each other by default. A large share of the work was deciding which one was authoritative for which question, and then not letting the others answer it.
What I changed / 03
None of this was built alone; operations, finance and delivery leads all had a hand in it. These are the decisions I argued for, and the reasoning behind each.
Every request for new or changed work entered through the same intake, carrying the same minimum: sponsor, outcome, dates, and the skills required. Requests without them were not refused; they were held at the door until they had them. A request nobody can staff is not yet a request, and admitting it to the plan only moves the problem downstream to the person who has to deliver it.
Utilization describes a month that has already been spent. A resource plan describes one that has not. I kept them as two artifacts with two jobs—the plan for decisions, the actuals for accuracy—and made the gap between them the thing worth reviewing. Merging them produces a single number that everyone quotes and nobody trusts.
Staffing moved out of the inbox and into a recurring session: the same people, the same view, a decision at the end. Urgent requests did not stop, but they now had somewhere to go, which is what kept them from being settled by whoever happened to be asked first. It also made prioritization something stated out loud rather than inferred weeks later from who got the hours.
Each of the four systems can be made to produce a number. I fixed which one answered which question—commitments here, actuals there, plan structure there—and treated a second copy of any answer as a defect. Most reporting disagreements are not analysis problems; they are two people reading two sources and assuming one truth.
A new person's start became a sequence with a named owner for each step: accounts, tools, account context, documentation, and the first piece of real work. Checklists are unglamorous, and that is the point—they convert one colleague's goodwill and memory into something the organization owns and can repeat when that colleague is busy.
Value created / 04
A handful of recurring questions acquired one answer each, and the answer no longer depended on who you asked.
A staffing question had a place to be asked and a place to be answered. A project could be stood up correctly by someone who had never stood one up before. A conflict between two accounts could be seen in the plan before it arrived in the week. A new person's first days ran off a checklist rather than off whoever was free to explain things.
The durable test came later. The same intake, planning and administration surfaces carried the portfolio I went on to run at the agency—more than $4M across clients including TELUS, KPMG, Manulife, SCENE+, PNC Bank, G Adventures and Home Hardware. Systems built early are judged by whether they survive being used under pressure, including by the person who built them.
This page publishes no utilization, onboarding-time or cost figures for this work, because they are not figures I can stand behind. What is verifiable is structural: what existed afterwards that did not exist before, and why it held.
Reflection / 05
Running a project teaches you to hold a plan. Building the machine teaches you that most plans fail somewhere upstream of the plan.