PMO Transformation Masterclass for Executives

This module is about finding out what your PMO really costs, what it produces, and who would notice if parts of it stopped. Participants look at why many boards and business leaders now question the PMO. Then they go through their own PMO one function at a time and ask four questions: what is it for, who uses it, what does it cost, and what is it worth to them.

Each participant scores every function of their own PMO on cost and worth and sorts it into keep, change, automate or stop, while the other participants question everything placed under "keep". They leave with a PMO function map and a first list of what to change and what to stop, supported by their own numbers. The aim is to cut the PMO time spent on reports that nobody uses to make a decision.

What is covered

• Why the PMO is being questioned: product owners and agile teams now do part of the project manager's job, delivery tools show progress without anyone writing a report, and executives ask what changed for the business rather than whether a milestone was met.
• Breaking the PMO into its functions and the parts inside them: processes, methods and tools; governance, metrics and improvement; mindset and coaching; services; and guidelines for meetings and documents.
• Value engineering for each function: what it is for (a verb and a noun), who uses it, what it costs, and what it is worth to them.
• Finding controls that exist only out of habit: documents nobody reads, approval steps that never stop anything, and reports copied by hand from tools.

In this module, participants will understand how to choose the right model for their own organisation: a Value Management Office, a PMO that starts working with business value, or a stronger traditional or hybrid PMO. The choice is based on facts about how IT is funded, who owns business results, and how the teams deliver. It is not based on what other companies are doing.

Participants score their own organisation in pairs against the eight questions in the decision framework and find the obstacles that cannot be removed in the next 12 months. Each one then presents their choice to a panel playing the finance director, a business unit head and the head of internal audit. They leave with a decision record showing the chosen model, the scores and evidence behind it, the obstacles, and what would need to change before moving to the next step. The first coaching session, in week 2, checks that the sponsor agrees with the choice.

What is covered

• What role IT really plays: keeping things running, providing a service, working as a business partner, or creating new business value. The answer is checked against how IT is funded and measured today.
• Scoring the eight questions with the numbers from the pre-work, and noting where the evidence is weak.
• The obstacles that would stop a VMO: no business leader willing to share ownership, teams that cannot release small changes often, or a finance department that will only fund projects.
• Common failures: the PMO that was renamed but still makes decisions the same way, the PMO that was closed and took its discipline with it, and the change that stayed inside IT and stopped at the business.

The main problem participants will be able to solve after this module is how to make "value" clear enough to decide what to work on, and to check later whether it was delivered. First, they build a simple tree that links company goals to the business results IT can affect, such as more revenue, lower cost or lower risk, and to the numbers that show whether those results are happening. Then they look at how their teams are set up. They map their value streams, meaning the full chain of work that delivers something a customer or the business needs, and see where today's project setup creates handovers and waiting.

Participants start by linking their ten largest initiatives to a business result and a number; any that cannot be linked go on a review list. They then draw two or three value streams on a Miro board, place today's teams and projects on them, and mark every handover between teams. They leave with a value tree, a results scorecard, and a first design of stable teams that each own one value stream from start to finish. Over time this should raise the share of funded work with a clear, measurable result and reduce the number of handovers per initiative.

What is covered

• Linking company goals to business results (revenue, cost, risk and compliance, keeping customers, speed to market) and to a number for each one.
• The difference between what was delivered (features, milestones) and what changed for the business (more sales, fewer errors, lower cost). Decisions are made on the second; the first is tracked.
• Using early signs, such as how many people use a new feature, next to later results, such as revenue or cost, so progress is visible within weeks.
• Linking every funded initiative to a goal for the quarter, and after each release writing down the result that was expected and the result that came.
• Preparing two or three possible business situations in advance, with the goals each would change, so priorities can move without waiting for next year's plan.
• Finding value streams from customer journeys and from what the business does, with business architects drawing the map.
• Moving from teams formed for one project to stable teams that stay together, keep what they learn, and take new work as it comes.
• Mapping where teams depend on each other, and deciding which links to remove by changing the team setup and which to manage by working together.

This module changes how work gets approved and how money follows the work. Many portfolios are overloaded because requests are approved one at a time. Each one looks reasonable, but together they are more than the organisation can deliver. Participants learn to break large projects into smaller pieces that can go live and be useful on their own, to compare all new requests at the same time, and to rank them by how much the business loses while each one waits. They then look at funding stable teams instead of single projects, moving money between areas every quarter, and replacing long approval documents with short checks on business results that finance and audit can accept.

Participants bring 8 to 12 real requests from their own portfolio, break them down, score them and rank them against what their teams can actually handle. They present what falls below the line and how they will explain the "no". They then redesign the funding of one value stream from Module 3 and test it with a colleague playing the finance partner. They leave with a ranked list of work with a capacity line and a stop list, a funding proposal, and a table of controls at team, value stream and portfolio level. The expected effect is fewer initiatives running at once, a shorter time from approval to first release, and faster decisions on funding changes.

What is covered

• Breaking large projects into the smallest pieces that can go live and be useful on their own. Value starts earlier, and a piece that is not working can be stopped.
• Collecting new requests and deciding on them together once a month or once a quarter, so they are compared with each other and with work already running.
• Ranking requests by what the business loses for each month the work waits, compared with how long the work takes. Short, urgent and valuable work goes first.
• Showing executives why half the value three months early is often worth more than all of it a year from now.
• Limiting how many initiatives run at the same time. Starting less means finishing more.
• Agreeing in advance when to stop: if a piece does not bring the expected result, the rest of its budget goes back to the pool.
• Funding the teams in each value stream instead of single projects. A stable team costs about the same every month, so the cost is fixed and what gets built is what changes. Money is moved between value streams every quarter.
• Replacing the long business case with one page: the problem, the expected result, how it will be measured, the first piece to deliver, the cost, and what would make us stop.
• Making regular delivery a condition for funding: no visible result within a quarter, no further money.
• Using what the work already produces as proof of control (records in delivery tools, demo notes, release data) instead of extra documents, and agreeing accounting and audit rules with finance before the change.

In this module, participants will understand how to run the portfolio week to week with real data, and who should run it. The first part shows why keeping everyone fully busy makes delivery slower, how to find the one step that holds everything else back, and which few numbers tell an executive more than a page of red, amber and green reports. The second part is about the office itself. Participants who keep a PMO design one that adjusts its rules to each project and checks results after go-live. Participants who move to a VMO design an office with business, finance and IT people in it, clear decision rights and a fixed meeting schedule.

To practise, participants take three months of data from their own delivery tool, work out how long work takes and how much is waiting in one value stream, and find its bottleneck. They then name the real people who would sit in their office and test its decision rights on three recent decisions that caused disagreement. They leave with a portfolio board design, a short set of numbers with starting values, a meeting calendar, and either a PMO service list with a project tailoring guide or a VMO charter. The aim is a shorter time from request to release, more work finished each month, and more reporting produced directly from tools.

What is covered: running the portfolio

• When people and teams are fully loaded, queues grow quickly and everything waits longer. Find the bottleneck, protect it, and plan the rest of the work around it.
• Judging work on value, quality and limits, and not only on scope, time and cost.
• The numbers to watch: how long work takes from request to release, how much is finished each month, how much is started but not finished, and where work is waiting.
• Shared boards, on a wall or in the tools teams already use, instead of status reports, so that blocked work is visible to everyone.
• Planning at four levels, each with its own rhythm: strategy twice a year, portfolio every quarter, releases every month, and team work every one or two weeks. Teams that depend on each other plan together once a quarter.

What is covered: keeping a traditional or hybrid PMO

• Choosing the delivery approach for each project based on how stable the requirements are, how regulated the work is, and how often it can release.
• Heavier approval steps for risky, high-value work and lighter ones for small, low-risk work.
• One result measure per project, checked with the sponsor 3 and 6 months after go-live.
• A list of PMO services showing who uses each one, reviewed every year so services that are no longer useful are stopped.

What is covered: moving to a VMO

• Who sits in it: a business sponsor, the VMO lead, a finance partner, business architects, value stream leads, product, delivery and architecture leads, and someone from risk or audit.
• Who decides what: funding, priorities, team capacity, review of results, and escalation.
• Fixed meetings: a short meeting two or three times a week where each area shares good and bad news and every problem gets an owner; a monthly portfolio review; a quarterly replanning and funding review.
• Two connected flows of work: getting ideas ready (goals, one-page cases, ranked pieces of work, technical groundwork) and delivering them (plan, build, release, measure, adjust).
• Starting with one office for one portfolio, and adding a company-wide level only when several portfolios compete for the same teams.

This module is about leading the move from today's PMO to the chosen model. A new structure on paper changes very little. People change how they work when funding rules, personal goals, job roles, supplier contracts and audit rules all support the new way. Participants build the case for change from their own numbers, choose a first area to start with and set it up to succeed, and plan new roles for current PMO staff.

Working on their own organisation, participants list their stakeholders and the resistance they expect, choose their first value stream or pilot, and plan the first 90 days. The module ends with the final assignment. Each participant brings all their outputs together into one transformation plan: the decision record, value tree, value stream map, ranked list of work, funding and control design, office design, 90-day plan, and 3 to 5 measures with starting values. They present it in 15 minutes to a panel of colleagues and a Start to Start facilitator, answer questions, and improve it during the coaching that follows.

What is covered

• Explaining why the change is needed, using the pre-work numbers. People support a real problem more readily than a new model.
• Setting a target for the result, for example cutting the time from approval to first release in half, and letting teams work out how to reach it.
• Checking everything around the teams: funding rules, personal goals, job descriptions and careers, supplier contracts and audit rules. If one of them still rewards the old way, people will go back to it.
• Using funding to support the change: stop paying for work that does not deliver regularly, and move the money to work that does.
• Involving middle managers in the design before asking them to lead it.
• Repeating the message often and through every channel for many months. Most people only notice the change when it reaches their own work.
• Giving PMO staff a path into new roles such as value stream lead, portfolio analyst, coach or governance lead.