Your PMO Already Has the Data to Become a VMO
The most common objection to evolving the PMO into a Value Management Office is some version of this: "We do not have the data."
It comes up in every conversation. The metrics required to operate as a VMO sound sophisticated. Drag cost, investment health, value per constrained resource hour, portfolio-level economic decisions. Reasonable PMO leaders look at that list and conclude that getting there would require a significant data programme, new systems, and probably a consultant.
That conclusion is almost always wrong. In most cases, the raw material is already there. It is sitting in tools the PMO uses every day - schedules, business cases, resource plans, financial reports, status updates. What is missing is not the data. It is the questions being asked of it.
This is one of the most overlooked truths in portfolio management. The shift from PMO to VMO is mostly a shift in analytical posture, not in source systems.
What you already have
Almost every PMO is already capturing more than enough raw material to start operating as a VMO. The four most useful inputs are:
- Project schedules with task-level detail. If you have any kind of schedule - Microsoft Project, smartsheet, Jira plans, Gantt charts - you have the structural input for calculating critical path and drag cost. The maths is not new. Most schedules already contain it.
- Business cases with stated value. If a project was approved, it almost certainly had a business case. That business case stated an expected value - revenue, savings, strategic benefit. That number, even imperfectly, is the input you need to start calculating drag cost and DIPP.
- Resource plans. Most PMOs maintain some view of who is working on what, when, and at what allocation. That view is the raw material for identifying where shared constrained resources are colliding across projects.
- Historical delivery data. The performance of past projects against their original plans is the most underused asset in most PMOs. It tells you which projects historically deliver close to their business case, which slip systematically, and which constraints recur. That history is what allows future portfolio decisions to be informed rather than aspirational.
Many PMOs already have all four, at least in imperfect form. What they do not have is a function asking these data sources the questions that produce VMO-grade decisions.
What is actually missing
The gap between a PMO and a VMO is not primarily a data gap. It is a thinking gap, supported by a tooling gap.
A PMO asks its data: are projects on track against plan? The data answers in RAG ratings, milestone variance, and resource utilisation.
A VMO asks its data: which interventions across this portfolio would create the most economic value, given finite shared capacity? The raw material needed to answer that question is largely the same. The analytical lens applied to it is completely different.
That lens is the first thing to shift. Flow Economics is, before anything else, a change in how the function thinks about delivery. Projects become investments. Delays become deferred value. Constraints become economic assets to be protected. None of that requires new technology to begin. It requires the function to start asking different questions of the data it already has.
But running that thinking at portfolio scale, continuously, with the data kept live and the calculations kept current, eventually does require systems built for the job. A static Gantt chart and a spreadsheet are fine for demonstrating that the approach works on three projects. They are not fine for operating a Value Management Office across a real portfolio over time. That is a tooling step, and it usually comes after the thinking has been proven.
In practice, the transition is less about a single transformation project and more about a sequence.
The evolution from PMO to VMO therefore involves three things in roughly this order:
- Different thinking - the function starts treating the portfolio as an economic system rather than a collection of plans
- Different reports and calculations - drag cost, DIPP, value per constrained resource hour, applied to the data already in place
- Different systems - tooling capable of holding the economic view live, dynamically, across the full portfolio
The first two can usually begin with what the function already has. The third is what makes the capability sustainable, and it is where most organisations eventually invest once they have seen what the thinking is worth.
Where the data is usually weakest
That said, the data quality is rarely perfect. The two areas that usually need the most attention are predictable:
First, business cases are often forgotten once delivery starts. The project gets approved on a value statement, and then the value statement disappears from the conversation. Six months in, nobody is checking whether the business case still holds. Drag cost and DIPP both require the value side of the equation to be live - to be revisited as conditions change rather than fossilised at approval.
Second, schedules drift from reality. The plan made at the start often stops being maintained with the discipline required to use it as the basis for economic calculation. Critical paths become stale. Dependencies get out of date. Float estimates become unreliable.
Neither of these is a tooling problem. They are operating discipline problems. The data exists. It just needs to be kept current enough to be useful. That is a smaller and more solvable problem than building a new data infrastructure.
What this means for the transition
The practical implication is that the mindset shift can usually start now, with the data the function already has, in the systems it already uses. The point of starting is not to operate the function on a spreadsheet long-term. It is to prove the thinking works, in your context, on your portfolio, with your numbers.
A useful diagnostic looks like this:
- Pick three live projects. Estimate drag cost on the critical-path tasks using the value already stated in the business case.
- Pick five active projects with the highest sunk cost. Calculate DIPP from this point forward, ignoring everything already spent.
- Map the most constrained resource group in the organisation. Look at what they are currently working on. Ask whether the work in front of them is the highest economic return available to the portfolio.
None of those activities require new tooling. They require a few hours of analytical work against data the function already has. And they produce outputs that change the next executive conversation.
What they will also do is reveal the limits of doing this with what you already have. A spreadsheet is fine for proving a point. It is not fine for keeping drag cost live across thirty active projects, updating DIPP every time a business case shifts, or maintaining a dynamic view of where the constraint is moving week by week. That is the work purpose-built Flow Economics systems are designed to support.
The reason most PMOs do not do these calculations is not that the data is missing. It is that the function has not yet been asked to think about delivery as economics. Once that question is asked, the diagnostic is straightforward, and the case for the systems that operate it durably builds itself.
The point of the data is not the data
It is worth stating directly: the goal of evolving the function is not better dashboards. Better dashboards are a side effect. The goal is better decisions - about which projects to start, which to accelerate, which to stop, and how to spend constrained capacity for maximum economic return.
Flow Economics is, in the end, a change in how leadership thinks about delivery. The metrics, the calculations, and the systems that operate them are how that thinking is made durable. But the thinking comes first. A function that has not yet made the shift will not get the value out of better tools, no matter how sophisticated. A function that has made the shift can begin extracting value from data it already has - and will quickly outgrow the spreadsheet that proved the point.
A PMO that already has the raw material to support these decisions, and the leadership willingness to think about delivery economically, is in the most common starting position for a VMO transition. It is also the most encouraging one. The hard part is not collecting entirely new data. It is making the mental shift from delivery governance to economic decision-making - and committing to the systems that make that shift sustainable.
Take the next step
If you suspect your function already has more of the raw material than people realise, take the Flow Economics Maturity Assessment. It takes about ten minutes and gives you a clear read on where your portfolio currently sits, which capabilities are already in place, and which moves would unlock the most value next.
