PMO from Scratch, part 2

You do not build a useful PMO by announcing a new function. You build it by removing a pain people already feel.

PMOs often fail because they start with structure before trust: templates before they understand the work, status requests before teams believe the process will help. This article gives you the 90-Day Permission Model, a weekly rhythm with four parts, an example and a starter template you can copy into a shared document today.

The problem: structure before trust

If leaders cannot see the work, the PMO should create visibility. If teams are blocked by unclear decisions, it should clarify decision rights. If every project has its own rhythm, it should create a shared cadence.

That sounds obvious. It still gets missed.

The research points away from paperwork. PMI's 2024 Pulse of the Profession found that average project performance stays relatively uniform whatever approach is used, while organisations that offer at least three enablers, such as coaching and mentoring, training and communities of practice, report significantly higher project performance (PMI 2024). PMI's 2023 report makes a similar case for power skills such as communication, problem-solving and collaborative leadership (PMI 2023).

A PMO that improves how people decide and work together is useful. A PMO that mainly collects updates costs more than it gives.

A lightweight PMO has to earn permission. The first 90 days should prove one thing: this PMO makes execution easier.

The first mistake: owning everything

The first mistake is trying to become the central office for everything. Do not do that.

A new PMO should not immediately own every project, dashboard, risk log, steering meeting and template. That creates resistance before it has created value, and it teaches the organisation to see the PMO as a reporting layer instead of an execution helper.

Start smaller. Pick one or two operating pains, for example:

• Leaders cannot see which projects are active.
• Teams do not know which priorities matter most.
• Dependencies are discovered too late.
• Decisions sit unresolved for weeks.
• Status reporting is inconsistent and mostly decorative.

The wrong question is "what should our PMO look like?" The better one is "what pain must be visibly better 90 days from now?" If you have not diagnosed the pain yet, start with part 1 of this series.

The framework: the 90-Day Permission Model

The idea is simple. The PMO earns scope by making one operating problem visibly better, not by writing a charter, buying a tool or copying a heavy framework. Matta and Ashkenas made a related argument in Harvard Business Review more than 20 years ago: short, results-focused initiatives reveal the gaps between planned activities that big plans miss (Matta & Ashkenas, HBR 2003).

The 90 days have three phases.

Days 1-30: map the work and name the pain

The first month is about understanding, not control.

Create a simple view of the active work. Not a tool rollout, just a shared table. For each initiative, capture only: name, owner, strategic reason, current status, next milestone, known risk, key dependency and any decision needed. If it takes six weeks to build, it is too heavy.

At the same time, run short interviews with leaders and delivery owners:

• Where does work get stuck?
• Which decisions take too long?
• Which status reports do you trust?
• Where do teams wait on each other?

You are looking for patterns, not complaints. After 30 days the PMO should be able to say: "Here is the current work. Here are the top execution pains. Here is the first one we will solve." That is the first mandate.

In my experience, the portfolio view takes two to three weeks, and interviews and synthesis about one more.

Days 31-60: create the first operating rhythm

Build a small rhythm around the pain. Visibility: a weekly portfolio review. Slow decisions: a decision log and a weekly decision review. Dependencies: a dependency board and a cross-team blocker review. Do not build them all at once.

A good first rhythm usually has four parts:

1. One shared project view. A working view people update because they use it to decide, not a reporting pack.
2. One weekly cadence. What changed? What is blocked? What decision is needed? What risk or priority conflict needs escalation? If the meeting becomes a readout of what people already wrote down, redesign it.
3. One decision log. Many organisations do not have a project problem. They have an unresolved-decision problem. Capture the decision needed, owner, options, deadline, the decision made and the date. The point is not to shame anyone. It is to stop important work from waiting in silence.
4. One escalation path. What counts as a blocker, who raises it, where it is reviewed, who decides and how fast. Without this, the PMO records problems instead of removing them. For who decides what, see Role-Clarity Mapping.

Days 61-90: stabilise before you scale

The third month is where many PMOs get impatient. They have a view, a cadence and a few logs, and now they want to standardise everything. Slow down and look for evidence:

• Leaders use the shared view in real decisions.
• Teams raise blockers earlier than before.
• Priority conflicts surface faster.
• Meetings end with actions, not updates.
• Project owners see the PMO as useful, not performative.

If those signals are missing, more templates will not help. This is also the moment to remove what does not create value. A field nobody uses goes. A meeting segment that produces no decisions goes. A lightweight PMO should be willing to remove its own bureaucracy. McKinsey's advice for large IT projects points the same way: a strategic and disciplined project office with a few strong stage gates and a short delivery cycle (McKinsey 2012). A few strong gates, not many weak ones.

An example: the 300-person company, 90 days later

Go back to the illustrative company from part 1: 300 people, three initiatives (a customer portal, a pricing change and a data-platform upgrade) and the same product managers needed everywhere.

In the first month, the PMO builds one table of the active work and interviews the initiative owners. The pattern is clear: the main pain is coordination, with prioritisation close behind.

In month two, it starts one weekly 45-minute review with the three owners and the head of product, plus a decision log. The questions that would typically surface: who decides whether the portal waits for the data platform? Which launch date did sales promise, and has delivery agreed to it?

In month three, it checks the evidence. Are decisions getting owners? Are dependencies found before deadlines? It cuts the risk-log fields nobody used.

No enterprise tool. No 40-page methodology. The first wins look unglamorous: a duplicated initiative spotted, a decision that has floated for weeks given an owner, a dependency found before it becomes a missed deadline. That is where the PMO starts to earn trust.

Your action plan: the 90-day starter template

Copy this into a shared document and fill it in with your leadership team. Items 2 to 5 are the four parts of the weekly rhythm.

1. The pain we will improve. Current pain, why it matters, who feels it most, what will be visibly better in 90 days.
2. Active work view. Source of truth, owner of the view, update rhythm and the required fields above.
3. Weekly cadence. Name, attendees, duration, inputs, decisions expected, output format.
4. Decision log. Decision needed, owner, options, deadline, decision made, date.
5. Escalation path. What counts as a blocker, who raises it, where it is reviewed, who decides, target resolution time.
6. Success criteria for day 90. Active work visible in one place. Blockers raised before deadlines are missed. Every decision has an owner and a due date. Priority conflicts are explicit. Delivery owners say the rhythm removes friction.

Common mistakes to avoid:

• Rolling out a tool before the operating model is clear.
• Copying a heavy PMO framework into a team that needs basic visibility.
• Becoming the status police.
• Pulling ownership away from the people who still own delivery.
• Scaling templates before the first cadence works.

The bottom line

The first 90 days are not about proving that the organisation needs more governance. They are about proving that the right amount of governance makes delivery easier.

Start with one pain, one rhythm and one log. Which decision in your organisation has been waiting in silence the longest?

Read next: PMO from Scratch continues in a later article. In the meantime, read The Governance That Enables (Instead of Killing) Innovation or Role-Clarity Mapping: Who Owns What When Strategy Meets Reality.

Building a PMO from scratch? See how I help with Complex Project & Programme Management.

References

1. Project Management Institute (2024). Pulse of the Profession 2024: The Future of Project Work. https://www.pmi.org/learning/thought-leadership/pulse/future-of-project-work (press release: https://www.pmi.org/about/press-media/2024/work-location-does-not-impact-effectiveness-of-project-performance)
2. Project Management Institute (2023). Pulse of the Profession 2023: Power Skills, Redefining Project Success. https://www.pmi.org/learning/thought-leadership/pulse/power-skills-redefining-project-success
3. Matta, N. F. & Ashkenas, R. N. (2003). "Why Good Projects Fail Anyway." Harvard Business Review, September 2003. https://hbr.org/2003/09/why-good-projects-fail-anyway
4. Bloch, M., Blumberg, S. & Laartz, J. (2012). "Delivering large-scale IT projects on time, on budget, and on value." McKinsey & Company. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value