Case Study · PMO & Operating Mechanisms

Making projects visible: building a PMO operating mechanism at a global industrial gas company in Tokyo

Role — Project Manager / PMO & C-IMP Leader Scope — 12+ parallel projects, phased rollout Recognition — ALJ Stars Award
~50%
Reduction in administrative reporting effort
10→0%
Recurring monthly correction issues eliminated
12+
Parallel projects under one operating cadence

The situation

A newly formed project delivery team at ALJ was scaling fast, managing a portfolio of more than twelve projects in parallel across gas-plant construction, plant improvement, and internal initiatives, with experienced colleagues brought together from operations, manufacturing, and sales. The talent and commitment were there; what a new team naturally hadn't had time to build yet was a shared way of working.

Because each project had grown up independently, teams used different templates and different definitions of "done," and KPI updates were largely manual. That meant monthly reviews often spent their first stretch reconciling figures before turning to the questions that mattered most: what decisions do we need to make, and what's blocking delivery?

The opportunity was clear. With a shared operating rhythm, the same effort already going into reporting could go further; less time reconciling inputs, more time removing blockers and moving projects forward.

The diagnosis

Before proposing anything, I mapped where reporting actually failed — reviewing previous monthly cycles and sitting in on each project's status routine. Four failure points repeated everywhere: actions without owners, action status nobody could interpret, KPI definitions that varied by project, and no shared rhythm — every team reported on its own clock.

That diagnosis shaped the core idea: the problem wasn't effort or tooling — it was inputs. So instead of tracking only outcome metrics (cost and schedule performance), the mechanism would track the controllable input metrics that predict them: overdue actions, aging change requests, milestones at risk in the next three weeks, open decisions, and missing vendor inputs. Make the work visible early enough to act on it.

Alternatives I rejected

I chose a phased path: stabilize inputs first, automate second, dashboards last — built entirely on tools we already had internally (structured inputs and automation in Smartsheet, with consolidated portfolio views feeding leadership reporting), at zero additional licence cost.

What I built

Standards first. Working with the project managers — not around them — I defined a minimum standard: a common WBS baseline teams could adapt rather than rebuild, a RAID log with mandatory owner and due-date fields, a change intake and closure checklist, and a standard intake format for incoming internal requests linked to a simple portfolio view. The design rule was to standardize what people were already doing, so adoption felt like relief, not reset.

Then quality controls. Validation checks and lightweight automation caught gaps — missing owners, stale statuses, blank KPI fields — before reviews, with flags sent back to owners automatically. Within a few cycles, leadership meetings stopped being the place where data problems were discovered.

Then cadence. Weekly project health checks, automated reminders on overdue items, a rolling three-week look-ahead, and a monthly KPI and milestone prep cycle that fed leadership a decision-ready pack — instead of a stack of slides each PM had built by hand.

Then adoption. Short onboarding sessions, hands-on support through the first cycles, and deliberately sequenced quick wins — automated consolidation alone gave each project manager time back every month — so the mechanism earned its keep before it asked for anything. I incorporated feedback continuously while keeping the core standard stable.

The design rule was to standardize what people were already doing — so adoption felt like relief, not reset.

Results

What I'd tell another PMO lead

The tools were never the point. The invention was a mechanism that made ownership visible and surfaced leading indicators early — and that kept improving, because we added and removed input metrics based on what actually predicted delivery outcomes.

Good PMO work isn't producing documents. It's building simple, repeatable ways of working that survive without you. The best evidence this one worked: it kept running when I stopped pushing it.

Facing a similar visibility problem?
Book 30 min → See the tools I build