The Problem

You do not build a useful PMO by announcing a new function.

You build it by removing a pain that people already feel.

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

That sounds obvious. It still gets missed.

PMOs often fail because they start with structure before trust. They introduce templates before they understand the work. They ask for status before teams believe the process will help. They create governance before anyone can see which decisions are actually stuck.

There is a reason this matters. PMI's Pulse of the Profession work has repeatedly shown that project performance depends less on paperwork and more on disciplined execution, executive sponsorship, and clear decision-making. A PMO that improves those things is useful. A PMO that mainly collects updates is expensive theatre.

A lightweight PMO has to earn permission.

The first 90 days should prove one thing: this PMO makes execution easier.

The Analysis

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 the PMO has created value. It also teaches the organization to see the PMO as a reporting layer instead of an execution helper.

Start smaller.

Pick one or two operating pains and build the minimum PMO routines needed to solve them.

The pain might be:

• 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 work of the first 90 days is not to design the perfect PMO. It is to create a working operating rhythm around the pain that matters most.

The wrong question is:

What should our PMO look like?

The better question is:

What pain must be visibly better 90 days from now?

The Solution: The 90-Day Permission Model

Use what I call the 90-Day Permission Model.

The idea is simple: the PMO earns scope by making one operating problem visibly better. It does not earn scope by writing a charter, buying a tool, or copying a heavy framework.

The 90 days break into three phases.

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

The first month is not about control. It is about understanding.

Create a simple portfolio view of the active work. Not a perfect system. Not a tool rollout. A practical view that lets leaders and teams see what is already in motion.

For each active project or initiative, capture only the essentials:

• Name
• Owner
• Strategic reason
• Current status
• Next milestone
• Known risk
• Key dependency
• Decision needed, if any

This should fit on one page or in one shared table.

If it takes six weeks to build, it is too heavy.

During the same period, run short interviews with leaders and delivery owners. Ask:

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

You are looking for patterns, not complaints.

By the end of the first 30 days, the PMO should be able to say:

Here is the current work. Here are the top execution pains. Here is the first pain we will solve.

That is the first mandate.

Time estimate: 2-3 weeks for the portfolio view, one week for interviews and synthesis.

Days 31-60: Create the first operating rhythm

Once the pain is clear, create a small rhythm around it.

If the pain is visibility, start with a weekly portfolio review. If the pain is decision latency, start with a decision log and a weekly decision review. If the pain is dependency management, start with a dependency board and a cross-team blocker review.

Do not build all of these at once.

A lightweight PMO should introduce the fewest routines that change behavior.

A good first rhythm usually has four pieces.

1. One shared project view

Everyone should know where to find the current view of active work. This is not a reporting pack. It is a working view, updated because people use it to make decisions.

2. One weekly cadence

Create one recurring conversation where leaders and delivery owners review the work that needs attention.

Keep it focused:

• What changed?
• What is blocked?
• What decision is needed?
• What risk needs escalation?
• What priority conflict needs resolution?

If the meeting becomes a readout of everything people already wrote down, stop and redesign it.

3. One decision log

Many organizations do not have a project problem. They have an unresolved-decision problem.

A simple decision log should capture:

• Decision needed
• Owner
• Options
• Deadline
• Decision made
• Date

This creates accountability without creating drama. The point is not to shame people. The point is to stop important work from waiting in silence.

4. One escalation path

Teams need to know what happens when something is blocked.

The escalation path should answer:

• What counts as a blocker?
• Who raises it?
• Where is it reviewed?
• Who decides?
• How quickly should it be resolved?

Without this, the PMO becomes a place where problems are recorded but not removed.

Days 61-90: Stabilize before you scale

The third month is where many PMOs get impatient.

They have a project view. They have a cadence. They have a few logs. Now they want to standardize everything.

Slow down.

Before scaling, ask whether the first routines are actually working.

Look for evidence:

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

If those signals are not present, adding more templates will not help.

Stabilize the basics first.

This is also the moment to remove anything that is not creating value. If a field in the project view is never used, delete it. If a meeting segment produces no decisions, cut it. If a risk log is just archival, redesign it around action.

A lightweight PMO should be willing to remove its own bureaucracy.

From Theory to Practice

I have seen this pattern work best when the PMO begins as a service to the operating rhythm, not as a control function.

In practice, that means the first 90 days should feel modest.

No new enterprise tool. No 40-page methodology. No promise that every project will now be perfectly governed.

Instead:

• A visible list of active work.
• A weekly conversation that removes blockers.
• A decision log that stops silence from becoming delay.
• A basic escalation path that teams actually understand.

That is enough to start.

The first wins are usually practical. A duplicated initiative gets spotted. A decision that has been floating for three weeks gets an owner. Two teams discover a dependency before it becomes a missed deadline. A leader sees, for the first time, how many projects depend on the same scarce expert.

None of that looks glamorous.

It is still exactly where the PMO starts to earn trust.

Your Action Plan

Use this 90-day starter template as your first PMO operating plan.

Copy it into a shared document and fill it in with your leadership team.

90-Day PMO Starter Template

1. The operating 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:
• Required fields: name, owner, strategic reason, status, next milestone, risk, dependency, decision needed.

3. Weekly cadence

• Meeting 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. 90-day success criteria

• Leaders can see active work in one place.
• Blockers are raised before deadlines are missed.
• Decision log has owners and due dates.
• Priority conflicts are explicit, not hidden.
• Delivery owners say the rhythm removes friction.

Common mistakes to avoid

• Starting with a tool rollout before the operating model is clear.
• Copying a heavy PMO framework into a team that needs basic visibility.
• Becoming the status police.
• Centralizing ownership away from the people who still own delivery.
• Scaling templates before the first cadence is working.

The first 90 days are not about proving that the organization needs more governance.

They are about proving that the right amount of governance can make delivery easier.

Start there.

References

Project Management Institute (2024). "Pulse of the Profession 2024: The Future of Project Work."

Project Management Institute (2023). "Pulse of the Profession 2023: Power Skills, Redefining Project Success."

Harvard Business Review (2021). "Why Good Projects Fail Anyway."

McKinsey & Company (2020). "How to improve the odds of delivering IT projects on time and on budget."