Operational drivers are the six things a portfolio operating system has to govern: workflow, meetings, people, metrics, artifacts, and the tools pipeline. Every organization already runs all six, whether or not anyone designed them. The only question is whether they are governed deliberately or left to settle on their own, and the driver nobody owns is usually where the visible failure eventually shows up. In PPM4Agile the six are configured during Align, before any initiative is planned, because they are what makes a portfolio an operating system rather than a recurring meeting.
What are the six operational drivers?
The six are workflow, meetings, people, metrics, artifacts, and the tools pipeline. Each governs a different part of how work moves and how decisions get made, and each fails in a recognizable way when nobody owns it.
| Driver | What it governs | What the ungoverned version produces |
|---|---|---|
| Workflow | The stages work passes through, from intake to delivery | Reporting turns into guesswork, because no two people mean the same thing by "in progress" |
| Meetings | Where decisions get made and blockers get cleared | A calendar full of sessions that feel productive and decide nothing |
| People | Who decides, not who holds the title | The wrong people decide, and someone else quietly unmakes it later |
| Metrics | Whether program health is evidence or opinion | A dashboard nobody acts on |
| Artifacts | The record of what was decided, by whom, and why | An argument you settled six months ago starts over from zero |
| Tools pipeline | The systems that hold the work at each stage | Sprawl, hand-syncing between systems, and reporting that stops being true |
Notice what is not on the list: methodology, team structure, and funding model. Those are choices an organization makes on top of the drivers. The drivers themselves are neutral, which is why the same six apply whether the teams underneath run Scrum, Kanban, SAFe, or none of them.
How do the six drivers work as a system?
They work as a set, and the weakest one caps what the others can do. A clean workflow reports nothing useful if the tools pipeline holds the same work in four systems. Well-chosen metrics change nothing if the meeting that reviews them contains nobody who can act. Decision rights written into an artifact that nobody maintains revert to whoever speaks first in the room.
That coupling is why PPM4Agile treats the drivers as a grid rather than a checklist. Each driver is configured for each of the four phases (Portfolio Development, Planning, Execution, and Evaluation, Value & Learning), so every phase has a defined workflow stage, a decision forum, named deciders, its own metrics, its own artifacts, and a system of record. The grid is what leaders return to when a decision goes wrong, because it says where that decision should have been made and what it should have produced.
Why is OCM OS governance the seventh piece?
OCM OS governance is the organizational change management of the operating system itself, and it sits beside the six drivers rather than among them. Putting a portfolio operating system in place is a change initiative in its own right, with sponsorship, resistance, and reinforcement to manage. The six drivers define what your operating system is. OCM OS governance decides whether it becomes how the organization actually works, and it is the piece rollouts often skip.
The distinction is practical rather than academic. The six drivers can be designed by a small group in a few working sessions. OCM OS governance is sponsorship that survives the first escalation, communication that reaches the people whose week changes, reinforcement after the launch meeting, and a plan for the roles whose informal influence the new grid reduces. Design without it and you get a documented operating system the organization routes around.
What do well-governed operational drivers look like?
Picture a PMO running about forty initiatives across six delivery teams, where status reporting takes two weeks to assemble and is disputed when it arrives. All six drivers are present and none of them are governed: several intake paths, a steering committee that reviews rather than decides, status by percent complete, a slide deck as the only record, and work spread across a ticketing system, spreadsheets, and email.
Governed, the same portfolio has one door for new work, a forum that actually decides, a named person behind each kind of decision (its decision rights), a short list of metrics someone acts on, a record of every yes and every no, and one system of record for each stage. Each driver has one owner, because shared ownership is the quickest way back to the ungoverned version. None of it is exotic. What makes it an operating system is that the six are decided together and written down, so a new request has one path through them, and a real decision like a portfolio approval passes through without anyone having to improvise. You do not get there all at once: the driver behind the loudest complaint is usually the place to start.
What goes wrong with operational drivers?
Configuring tools first. A tool encodes a workflow and a workflow encodes who decides, so buying the platform before settling those two installs someone else's operating model and calls it a migration.
Treating metrics as the whole of governance. A dashboard reports on the other five drivers. It cannot substitute for them, and a portfolio with excellent reporting and no decision forum simply documents its drift with precision.
Governing five of the six. Artifacts is often the one dropped, because the work of recording a decision falls after the moment everyone cares about it. The cost arrives later, when the same question reopens and no one can say what was decided or why.
Confusing the People driver with the org chart. The driver is about who decides, not who reports to whom. Publishing a reporting structure answers a different question than naming the person who can approve an exception.
Leaving OCM OS governance to the PMO. The PMO can run the grid, but it cannot sponsor the change to it. When enforcement rests only with the team that keeps the spreadsheet, the first senior bypass ends the experiment.
Operational drivers vs a governance framework
A traditional governance framework describes the bodies, the thresholds, and the approval paperwork. It answers who signs. Operational drivers answer something wider: how work moves, where it is recorded, what is measured, and which system holds it at each stage. Governance in the traditional sense is roughly one and a half of the six drivers, the People driver plus part of Meetings.
The practical difference shows up when nothing is going wrong. A governance framework is exercised at stage gates and is otherwise dormant. The drivers are in use continuously, because they describe the machinery that produces the information a gate would review. An organization can pass every gate and still be ungoverned in the sense that matters, which is usually what people mean when they say the process is heavy and nothing improves.
For the full vocabulary that sits on top of the drivers, see the glossary of agile portfolio management terms. A PPM4Agile implementation configures the grid phase by phase, starting with Align.
Sources
- GAO, Agile Assessment Guide (GAO-20-590G), September 2020, on governance, decision authority, and oversight practices in agile programs