PPM Implementation Checklist: 30 Things to Do Before Go-Live

What Is a PPM Implementation Checklist?

A PPM implementation checklist is the set of checks a portfolio must pass before go-live, covering intake, capacity, governance, data and the first review cycle. It exists because most implementations fail on operating-model gaps rather than configuration gaps, and configuration is the part teams actually test.

That is the trap this list is built to avoid. Readiness reviews tend to measure what is easy to measure: fields configured, users provisioned, projects migrated. All of those can be green while the portfolio still cannot do the one thing it exists to do, which is decline work and make the decision hold.

Work through the thirty checks below in order. The groups are sequenced the same way a sound implementation is: decisions first, then intake, then capacity, then governance, then data, then the cadence that keeps it alive. If you are earlier in the process, the PPM lifecycle covers where programs typically break down before they ever reach a checklist.

What Should You Confirm Before Configuration? (1 to 6)

Six decisions that are expensive to revisit once people are using the system.

1. A named person or forum can decline work. Written down, communicated, and backed by someone senior enough to survive the first escalation.
2. The portfolio’s unit of account is agreed. Money, people, or both. If engineering weeks are the real constraint, say so now rather than discovering it in month four.
3. A project threshold exists. A size floor, such as four weeks of effort or crossing two teams, so routine work stays out of the portfolio.
4. Portfolio ownership is assigned. One accountable owner per portfolio, not a committee and not a mailbox.
5. The strategic objectives projects align to are published. You cannot score alignment against goals that only exist in a deck.
6. The decision forum has a date in the calendar. Recurring, with the right attendees already accepted, before go-live rather than after.

What Does Intake Need Before Go-Live? (7 to 12)

Intake is the only part of the system that reduces the size of the problem. Everything else describes it more precisely.

7. A single intake route is live and publicised. One front door. If two paths exist, the easier one becomes the real process.
8. The request form captures outcome, sponsor, effort estimate and linked objective. All four mandatory. A form that accepts a title and a paragraph will collect titles and paragraphs.
9. Scoring criteria are written and weighted. Agreed before the first contested request, not during it. The project intake process guide covers which criteria hold up.
10. A triage cadence exists with a named triager. Weekly is usually right. Requests that sit untriaged teach people to route around intake.
11. Rejection is a tested path. Walk one request through to a documented decline, with a reason the requester can read, before go-live.
12. A service-level expectation is published. Something like “a decision within ten working days.” Intake that slows people down without a visible clock gets bypassed.

How Do You Verify Capacity and Resourcing? (13 to 17)

13. Remaining effort is estimated for every active project. Rough is fine. Missing is not, because the overcommitment picture needs every row.
14. Available capacity is loaded by team or skill. Headcount alone overstates it; subtract leave, support rotations and the run-the-business load.
15. The committed-demand-to-capacity ratio has been calculated and shown to leadership. This single number is what creates appetite for the rest of the program of work.
16. At least one over-allocated team has been identified by name. If the capacity view shows no conflict, the data is wrong, not the organization.
17. A rebalancing decision has been made and recorded. Pairing intake with demand and capacity planning is what stops the portfolio refilling the week after go-live.

What Governance Must Be in Place? (18 to 23)

18. Stage gates are defined with explicit entry and exit criteria. “Reviewed at each phase” is not a gate. A checklist that must reach 100% is. In Profit.co, each tollgate carries a checklist the project owner completes before submitting the stage for approval.
19. Each gate has a named approver and a deputy. Single approvers on leave are a standard source of multi-week delay.
20. The gate decision options include stop. Go, hold, or stop, with stop used at least once in testing. See go, hold, or stop tollgate decisions for how benefits data should drive the call.
21. A governance log is configured. Risks, issues, changes, actions, decisions, assumptions and blockers, each with an owner and a date rather than a shared memory.
22. Escalation paths are documented. Who hears about a breach, how fast, and what they are expected to do about it.
23. Reporting roles are set. Executives, portfolio managers and delivery teams need different views. Portfolio governance is the frame for deciding who sees what.

What Data and Integrations Need Testing? (24 to 27)

24. Every integration has been tested with real records, not samples. Sample data is clean. Yours is not, and the difference surfaces on day two.
25. Migration scope is deliberately limited. Active projects only. Importing historical work before intake is governed is the most common way implementations stall, as the PPM migration trap describes.
26. Financial fields reconcile against finance’s own numbers. Pick five projects and check them line by line. A portfolio nobody trusts financially gets quietly replaced by a spreadsheet.
27. Someone has signed off that the data is correct. A named person, on a date. Shared responsibility for data quality means none.

What Should the First Review Cycle Look Like? (28 to 30)

28. A dry-run review has been held with real data. Same agenda, same attendees, same reports as the real thing. Problems found here are cheap.
29. The exception path is agreed. What happens when a project breaches budget or schedule between reviews, and who acts without waiting for the next meeting. A Project Health Score that moves out of range is a practical trigger.
30. A closure and benefits check is scheduled for the first completed project. Most implementations never close this loop, which is why business cases inflate. The project closure process is where it gets caught.

How Do You Know You Are Actually Ready?

Counting completed checkboxes overstates readiness, because the easy items complete first. Judge against these three levels instead, and be honest about which one describes you.

The Three Readiness Levels Compared

Conditionally ready is the most common honest answer, and it is not a failure. Going live with one pilot portfolio while the remaining gaps close beats waiting for a perfect score that never arrives. What does not work is going live organization-wide from the left-hand column, which is how a method gets blamed for an operating-model problem. PPM frameworks matter, but only once these basics hold.

How Does Profit.co Support the Checklist?

Profit.co covers the checklist in one platform, so intake, capacity, gates and benefits share the same records rather than reconciling across tools.