Delivery operations · Internal PMO · Havas CX Canada

Building the system the projects run on.

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.

PMOBuilt, not inherited
IntakeOne front door for work
$4M+Portfolio it later carried
The delivery operating loop Work enters through one intake, becomes a resource plan, is delivered, and is recorded as utilization, which feeds back to correct the next plan. Four systems sit beneath, each authoritative for one question. THE LOOP INTAKE RESOURCE PLAN DELIVERY UTILIZATION THE ACTUALS CORRECT THE NEXT PLAN ONE SYSTEM OF RECORD PER QUESTION AGRESSO KANTATA MS PROJECT GOOGLE WORKSPACE

Capacity was a conversation.

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.

Confidentiality boundary

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.

One front door, one view of capacity.

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.

The surfacesGeneralized view
01

Intake

One route for new and changed work, carrying the same detail every time: sponsor, outcome, dates, and the skills it needed.

02

Resource planning

The forward view of who is committed, to what, and until when.

03

Utilization visibility

The same picture read backwards, so a plan could be checked against what was actually spent.

04

Onboarding & documentation

The memory: what lets a new person become useful without borrowing a colleague's entire afternoon.

05

Project administration

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.

Decisions that made it worth using.

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.

01

One front door, with a shape

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.

02

The plan and the actuals stay separate

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.

03

Allocation became a standing decision

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.

04

One system of record per question

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.

05

Onboarding written down as a checklist

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.

Capacity stopped being an opinion.

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.

A note on evidence

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.

What building it taught me.

Running a project teaches you to hold a plan. Building the machine teaches you that most plans fail somewhere upstream of the plan.

  • An internal system competes with the workaround, not with the old process. If the form is slower than asking a colleague, the colleague wins—every time, and quietly.
  • A forecast and an actual are two different instruments. Merge them and you lose the use of both.
  • Prioritization is easy to write down and hard to hold. What makes it hold is a standing decision where someone has to say no out loud, on the record, to a named request.
Need the machine built, not just the project run?

Let's design the operating model.

Start a conversation →