Building a PMO that engineering actually wants to work with

Most PMOs fail engineers for one reason: they optimise for reporting, not delivery.

The problem with traditional PMOs

When I joined my first enterprise programme as a delivery lead, the PMO was a weekly tax. Status updates, RAG reports, RAID logs nobody read. A bureaucratic layer that slowed the team down without giving leadership any real signal.

Engineers tolerated it. They didn’t use it.

What changes when you flip the model

The shift is simple in theory, hard in practice: the PMO’s job is to remove blockers, not document them.

Here’s what that looks like in practice:

1. Cadences that serve the team, not the calendar

Replace the weekly status meeting with a 15-minute RAID triage. The agenda is fixed: what’s blocked, who owns the unblock, what’s the ETA. No slides. No retrospectives. Just forward motion.

2. RAID hygiene as a shared habit

A RAID log nobody updates is worse than no RAID log. It creates false confidence. I enforce one rule. If a risk or issue isn’t updated in 5 business days, it gets escalated automatically in the next executive summary. That single rule changed behaviour faster than any process document.

3. Dashboards that tell stories

Power BI and Zoho Analytics are tools, not reports. A good PMO dashboard answers three questions at a glance: are we on track, where are we bleeding, and what decisions does leadership need to make this week? Everything else is noise.

The result

On the $8M Oil & Energy programme at TCS, we ran a PMO that the engineering leads actually came to voluntarily, because it cleared their path instead of adding to it. Velocity increased. Escalations dropped. Audit scores improved.

The governance didn’t get lighter. It got smarter.