Sale on now: 30% off Advanced Project Planner until Oct 28 · 20% off CapGate Pro until Oct 18.

Shop the Sale

How to Set Up PMO Governance on an IT Project from Scratch

A 90-day setup for project managers handed a project with a delivery date, three vendors and no rules about who decides what.

By Pankaj Nalavade · October 4, 2026 · 7 min read

The project that has no rules yet

Illustrative scenario: a composite of patterns common on IT programs, not a named client.

A regional retailer is moving its order-management platform to the cloud. The budget is $2.4 million, the schedule is nine months, three vendors share the work, and go-live is pinned to a trading window the business will not move. You became the project manager two weeks ago.

By week six, three things have happened. The Operations Director asked for an extra payment integration in a corridor conversation. The integration vendor started building it because the request sounded urgent. Finance then found a $180,000 variance that nobody can trace to an approval.

Nobody in that story behaved badly. The project simply had no answer to four questions: who decides what, on what information, how fast, and what happens when it goes wrong. Those four questions are governance. ISO 21505, the international guidance on governing projects, programmes and portfolios, treats governance and management as distinct. A practical reading of that line: governance sets direction and decision rights, and management delivers the work inside them. The PMO is the function that makes the first half real.

What missing governance looks like at scale

PMI’s 2021 Pulse of the Profession put the share of project investment wasted through poor performance at 9.4%, down from 11.4% in 2020, and found that 34% of projects experienced scope creep. Those are averages, not a diagnosis of any single project, but scope creep is exactly what the retailer’s corridor request produced.

The clearest public example of a governance failure is Canada’s Phoenix pay system, rolled out in two waves in February and April 2016. The Auditor General’s 2018 audit called it “an incomprehensible failure of project management and oversight.” The findings that matter to a project manager setting up governance are structural, not technical:

  • Project information reaching the deputy minister could only come from the Phoenix executives running the project.
  • The independent readiness review was not independent, because the executives had authority over the reviewers.
  • The decision to go live had no documented formal approval, even though the executives held substantial warning information.

Three design rules follow. Give the sponsor a line of sight that does not pass only through the project manager. Make reviewers independent of the people they review. Record every go-live decision against written criteria.

Step 1 of 3

List the decisions before you write any documents

Most project managers start governance by downloading a template pack. Start instead with a decision inventory. List the ten or so decisions that recur on an IT project: schedule changes, budget variances, scope changes, vendor change orders, risk acceptance, architecture and security exceptions, resource conflicts, and go-live. For each one, write down who decides and at what size the decision moves up a level.

The sizes are what turn governance from bureaucracy into a speed tool. When the project manager can approve anything under a clear threshold, only the big decisions wait for a committee.

Decision-rights matrix for an IT project showing which of the project manager, project board or steering committee decides on schedule slips, budget variances, scope changes, risk acceptance and go-live, with example thresholds.
Figure 1. A decision-rights matrix with tolerances. The thresholds are starting values for a project of roughly $1M to $3M, not a standard.

Agree the thresholds with the sponsor in the first two weeks and get them signed. A tolerance the sponsor has not accepted is only a suggestion.

Step 2 of 3

Build three tiers, not one big committee

A single weekly meeting of fifteen people ends up reviewing status and deciding nothing. Split the work by the size of the decision instead.

Three-tier governance structure: a monthly steering committee, a fortnightly project board and a daily or weekly delivery cadence, with the PMO serving all tiers and an independent assurance function reporting to the sponsor.
Figure 2. Three tiers, with the PMO serving all of them and independent assurance reporting straight to the sponsor.

Two details are easy to miss. Tier 1 should hold four to six people with real authority over money and scope, because a steering committee full of observers cannot decide anything. And the PMO should report to the sponsor as well as to the project manager, which restores the independent line of sight that Phoenix lacked.

Which PMO model fits?

PMI’s literature describes PMOs by degree of control, and the lightest model that does the job is usually the right one.

  • Supportive: offers templates, advice and training, and projects choose whether to use them. It fits when project managers are experienced and projects vary a lot.
  • Controlling (PMI sources also call it “governance”): requires specific methods and checks conformance, for example before a gate passes. It fits when you need consistency and audit evidence across projects.
  • Directive: supplies the project managers and runs the projects directly. It fits when delivery capability is thin and the stakes are high.

For a new project, a sensible default is controlling on a short mandatory list (charter, RAID log, change log, gate checklists) and supportive for everything else.

Step 3 of 3

Put gates where decisions are expensive to reverse

Four gates are enough for most IT projects: mobilize (charter and funding), design approved, test and cutover readiness, and go-live. For each gate, write the pass criteria before the work starts, name the approver, and record the decision.

For the retailer, go-live criteria might be: no open severity-1 defects, the order-to-cash regression suite passed, a rollback rehearsed at least once, and the service desk lead signing off the support runbook. A gate that cannot fail is not a gate.

The 30-60-90 setup

You do not need every control on day one. Sequence them so each layer has something to run on, and test each phase with one question before you move on. On a twelve-week project, compress each phase to two weeks.

30-60-90 day plan for IT project governance: days 1 to 30 set decision rights and the charter, days 31 to 60 start change control, gates and forecasts, days 61 to 90 run a health check and trim unused reports, each with an exit test question.
Figure 3. A 30-60-90 setup sequence, each phase closed by an exit test.

Replay: the corridor request, with governance in place

Back to the retailer. The Operations Director raises the payment integration again. This time the project manager logs it as change request CR-007 the same day. The architect and the finance partner produce an impact assessment within three working days: six extra weeks of effort, $210,000, and a collision with the holiday change freeze.

That exceeds both the project manager’s and the project board’s tolerance, so it goes to the Steering Committee, which defers it to phase two and records why. Elapsed time: four days, with no unapproved vendor effort. In the original version of the story, the same kind of request ran for weeks before anyone noticed.

Four signs it is working, and four ways it goes wrong

Signs that governance is earning its keep:

  • Decisions are logged with an owner and a date, inside the agreed time.
  • No escalation is older than ten working days.
  • Every RAID item has a named owner and a next-review date.
  • No change is worked on before it is approved.

Ways it commonly goes wrong:

  • Copying an enterprise framework onto a twelve-week project, so the process outweighs the work.
  • A steering committee that only receives status. If the minutes record no decisions for two meetings in a row, change the agenda or cancel the meeting.
  • A sponsor who sends a deputy with no authority to the committee.
  • Gates that nobody has ever failed.

Your first ten working days

  1. Interview the sponsor: which decisions do they want to see, and which can be delegated?
  2. Draft the decision inventory and thresholds, then agree them in one 45-minute session.
  3. Name the Steering Committee members and book the next six meetings.
  4. Open the RAID log and the change log, and give every item an owner.
  5. Write pass criteria for the next two gates only.
  6. Agree the one-page status format and the reporting calendar.
  7. Confirm the PMO’s reporting line to the sponsor, and who will run the independent health check at day 60.
  8. Publish a one-page “how decisions work here” summary to the whole team.

For the formal frameworks behind all of this, start with ISO 21505 and PMI’s practice guide on governance of portfolios, programs and projects. The scenarios, thresholds and meeting cadences above are illustrative starting points drawn from common practice. They are not requirements of PMI or ISO.

Sources