Building a PMO that delivered 90 enterprise implementations with zero complaints.

The situation

The organisation had grown steadily to 90+ institutional clients. And nobody had stopped to ask whether the way they were working could hold.

When there were ten clients, it was manageable. Each team did what it knew to do. Sales sold. Content Ops crosschecked content, licenses, editions, and versions for every book per institution. Publishing ensured publishers were paid on time and that the necessary licenses and notices were secured. Implementation QAed and uploaded books as the lists came from Content Ops. Support responded to tickets. Everyone worked hard. Everything held.

But at 90 institutions, everything stopped holding.

The previous year, some projects had been delivered on time and in full. But most of the 90 were delivered late, incomplete, and with significant customer complaints that led to churn. Every team was in the dark about what the other teams did. There were no seamless handovers. Teams had SLAs that only their own teams knew about and followed. Customer Success felt harassed managing angry clients. And nobody owned delivery. There was no COO, no ops department, no central accountability. Just teams doing their best in isolation.

£15.9M was in motion across 90 institutions, and nobody could see the full picture.

The diagnosis

The problem was structural.

The teams weren't the issue — they were capable and hardworking. The issue was the absence of a connective layer. Six teams, each operating to their own standards, their own timelines, and their own understanding of what mattered. No portfolio view. No dependency mapping. No shared definition of done. No single owner accountable for delivery end to end.

The organisation had scaled its customer base without scaling its operating model. Nobody had stopped to ask: can our current process hold with 10 more customers? What about 20? The teams had grown in headcount but not in coordination. And because nobody owned delivery, every missed deadline was everyone's fault, which meant it was no one's.

The fix couldn't be a retrofit. There was nothing to retrofit. No existing PMO, no ops department, no shared governance. It had to be built from zero — and it had to start with understanding what was actually happening before designing what should happen.

What I built

1. The diagnosis: as-is process documentation

Before I could standardise, I needed to understand what each team was actually doing.

I reviewed and spoke to all the core team leads across Sales, Customer Success, Implementation, Content Ops, Publishing, and Support. I collated every issue they highlighted. Then I documented the as-is processes for all four operational teams — every current workflow, every handoff point, every place where things broke down.

This was the step that made everything else possible. You can't design a target state until you can see the current state clearly. And the current state was invisible because each team's process lived in their own heads and their own tools.

I then designed the to-be processes — the target workflows that would replace the siloed ones — and certified both. The as-is documentation became the baseline. The to-be documentation became the standard. Everything the PMO did afterwards was built on this foundation.

2. The PMO from scratch

With the diagnosis complete, I built the programme management office from zero — defining its charter, operating model, reporting cadence, and governance gates. The PMO became the single accountable body for portfolio health, risk, and delivery across all 90 institutions.

I developed the operational framework: project documents, templates, reporting dashboards, PMO tools, and communication channels. Every artefact the PMO needed to function, I built from scratch because none of it existed.

The PMO wasn't just a reporting layer. It had the charter, the cadence, and the data to actually move the portfolio — reprioritising, reallocating, and escalating when delivery was at risk.

3. The tooling rollout (ClickUp)

I rolled out ClickUp as the PMO's central platform and designed and automated the process flow within it. Every team got their own space with the necessary permissions. For the first time, all six teams could see into each other's work — what was due, when, and what was required from them.

This was the same principle as the Freshdesk rollout at TradeDepot: you can't coordinate what you can't see. ClickUp gave the organisation its first single source of truth for delivery.

4. The implementation calendar: reverse-engineering from go-live dates

This was the core insight that changed everything.

EdTech implementations for tertiary institutions are largely annual, divided into spring and fall, aligned to when institutions resume their programs. So I built an ops-wide implementation calendar — a rolling schedule of go-live dates, one per institution — and reverse-engineered every other process from those dates.

If an institution needed to go live on September 15th, everything worked backwards from there. Content gathering from publishers had to start earlier. QA had to start earlier. The entire chain was timed to the go-live date, not to when teams happened to get around to it.

We also changed how we involved clients. One of the major causes of delays was that clients would give feedback ad hoc, per book, and wouldn't respond on time. So we batched content and pulled clients into the QA process earlier, in batches. This reduced the back-and-forth dramatically and gave us predictable timelines.

The calendar had workflow, RACI, and core reporting built in. Every status was visible in real time. If a status was orange, it got flagged — because we knew the next step was red. The system didn't just track delivery; it predicted it.

5. Personal project management: 20+ projects worth £9.1M

I didn't just build the PMO and hand it off. I personally managed 20+ of the 90 implementation projects worth £9.1M.

For each project, I created project plans with full stakeholder visibility, RACI charts, and RAID docs so the core teams knew what was required and when. I served as the core point person with the clients. Each project had a CS and a Project Lead directly responsible and accountable to the client. I generated real-time dashboards with reports for leadership, team stakeholders, and client leadership.

This wasn't about being a hero. It was about keeping myself close to the delivery reality. The governance I was designing was tested against real projects, with real clients, in real time. If a process didn't work in practice, I found out immediately — not in a post-mortem.

The transition

I ran the PMO build and the transition in parallel. The existing teams kept delivering while I stood up the governance layer around them. Once the PMO was operational, I migrated projects in waves rather than all at once, starting with the ones I was personally managing.

We started all the processes earlier than they would usually start. We planned and prioritised implementation according to each institution's dates. We treated each go-live like a campaign launch — with a rolling calendar, a clear chain of dependencies, and real-time visibility into where everything stood.

The result: every project delivered on time and in full, with zero customer complaints.

What made it work

The PMO worked because it was built in the right order. I diagnosed before I designed. I documented the as-is before I built the to-be. I stood up the tooling before I migrated the projects. And I reverse-engineered every timeline from the go-live date, not from when teams felt like starting.

Each step unlocked the next. I couldn't standardise workflows without understanding what each team was actually doing. I couldn't build a shared calendar without a shared platform. I couldn't migrate 90 active projects without governance to move them into. And I couldn't justify the governance until I'd proven it worked on the 20+ projects I was running myself.

The reverse-engineering from go-live dates was the insight that changed the delivery. Most organisations plan forward — they start with what they have and work toward a deadline. We planned backward — we started with when the client needed to go live and worked from there. It's the same logic as a dependency chain: the deadline is the last tumbler, and everything else has to turn in the right order for it to fall.

When I walk into an organisation where delivery is stuck, I don't start with a tool or a framework. I start with the question: what does done look like, and when does it need to happen? Then I work backwards until I find the first thing — the thing that nothing else is blocking, the thing that makes the next step possible. Build from there, in order, and the delivery takes care of itself.

The organisation went from 90 islands to one governed portfolio. From siloed teams to a shared operating model. From late and incomplete to on time, in full, with zero complaints. Not because anyone started working harder. Because someone built the system that made the work visible, the timeline real, and the accountability shared.