Pg Assessment Practice

How to Actually Run a Pg Assessment Without Losing Your Mind

I've been doing program governance assessments for about eight years, mostly in the NHS and local government sector. The framework looks solid on paper. The reality is messier. Most people blow through the assessment in a couple of days and call it done, then wonder why nothing changes six months later. The assessment itself isn't the hard part. Knowing what to do with the results is where it falls apart for most teams. Pg Assessment Practice means running a structured evaluation of a program's governance maturity across a defined set of criteria. You're not grading the program on whether it delivered outcomes. You're grading whether the oversight mechanisms are in place, whether decisions are traceable, and whether there's actual accountability or just documentation theatre. These are different things. People confuse them constantly.

Starting Pg Assessment Practice the Right Way

The first step is almost always wrong. People open the assessment template and start filling it in without talking to anyone. Don't do that. Spend two weeks just mapping the program's decision architecture before you touch a single criterion. Find out who actually makes decisions versus who signs off on documents. Find out which committees meet regularly and which ones have been autopilot meetings for two years. Your assessment data is only as good as your understanding of the real structure, not the org chart. Here's the practical workflow I use. Week one is documentary review. Grab the program brief, the business case, the latest stage gate reports, and the meeting packs for the last twelve months. Read them, but don't assess yet. You're building a mental model of the program's governance surface area. Week two is stakeholder mapping. Identify every role that touches governance: the executive sponsor, the program director, the project managers, the assurance leads, the finance partner, the external auditors if they exist. Write down what each role claims to do in writing, then verify against what they actually did based on the documents from week one. The gap between claimed and actual is your signal. That's where the real problems live. Week three is the actual assessment. Go criterion by criterion through your chosen framework. For each one, gather evidence from two sources minimum. If a criterion says decision records must be maintained, don't just check that a log exists. Pull three sample decisions from the last quarter and trace them from initiation through approval to outcome. Verify the chain of custody on the evidence itself. Too many assessments treat evidence as binary — either you produced it or you didn't. It's far more useful to assess the quality and recency of your evidence.

I once ran an assessment for a digital transformation program where the governance documentation was technically complete across every criterion. Every meeting had minutes. Every decision had a record. Every risk was logged. The assessment scored came back as mature. I was about to sign off when I noticed something. All the decision records were backdated. The dates in the approval column were consistently two days before the committee meeting they referenced, which meant someone was completing the paperwork before the actual discussion happened. This isn't a documentation problem. It's a compliance theater problem. The program was assessing the appearance of governance while bypassing governance entirely. I flagged it in the findings but the initial scoring methodology doesn't catch this. You have to look for it yourself. After that, I started cross-referencing decision dates against calendar invites and attendance records as a standard step. It adds half a day to the process but it saves you from producing a report that tells management exactly what they want to hear instead of what they need to know.

The Criteria That Actually Matter

Different frameworks use different criteria sets. Some use five domains, some use eight. The specific labels change. The underlying questions don't. Here are the five areas that consistently separate programs that are actually governed from programs that just look governed. Strategic alignment and justification. Does the program maintain a living business case or is it a document created during initiation and then ignored until the next stage gate review? A business case that hasn't been challenged in six months is a warning sign, not a validation. The best programs I've seen update their strategic rationale monthly and document every challenge and revision with clear reasoning. Decision-making clarity. Who decides what, and can you prove it? RACI matrices are useful but they're also easy to file away and forget. The real test is whether someone can name the decision authority for a specific type of change without checking a document. If the answer requires looking something up, the governance is documented, not embedded.

Assurance independence. Is assurance performed by people who can say no without consequences? This is harder to assess than it sounds. Look at the reporting lines of your assurance function. If the assurance lead reports through the same chain as the program director, the independence is theoretical. I've seen programs where the assurance function was formally independent but the sponsor would literally not book meetings with the assurance lead without the program director present, which is a control environment problem regardless of what the org chart says. Risk ownership and response. A risk register with one hundred entries where every risk is owned by the same person and hasn't changed status in four months is not a risk management system. It's a list. Real risk registers have owners who escalate, close, and create new risks as the program evolves. The velocity of change in your risk register is a proxy for how honestly the program is being managed. Benefit realization tracking. Benefits are often assessed at initiation and then never revisited until the program closes, by which point the data is either irrelevant or too late to act on. Programs with genuine governance track benefit drivers throughout delivery, not just the end-state benefit numbers. This requires more discipline but it's the only way to catch a program drifting from its value proposition before it's too late.

Common Pitfalls That Wreck Your Assessment

The biggest mistake I see is treating governance assessment as an audit. An audit checks compliance against a standard. A governance assessment checks whether the oversight mechanisms are actually functioning. These require different questions and different evidence standards. When people apply audit logic to a governance assessment, they end up producing a checklist exercise that confirms nothing useful. Another mistake is over-relying on self-reported data. Yes, you need to ask the program team about their processes. But verify everything. Ask for evidence. Follow trails. Cross-reference. If someone tells you a control exists, ask when it last caught a problem. A control that has never failed is either very effective or has never been tested. You can't tell which from a statement alone. The third mistake is producing a maturity score and calling it a day. A score like "3 out of 5" tells you almost nothing actionable. Break it down. Which criteria scored low? Are they related? Is there a root cause — like a sponsor who is disengaged — that explains multiple weak scores? Is there a strength in one area that you can leverage to improve a weaker area? The pattern matters more than the aggregate number.

Writing the Report So It Gets Used

Most assessment reports sit on a shelf. The ones that get acted on share a few characteristics. They lead with the three findings that matter most, not the full list. They separate observations from recommendations. An observation is something you found. A recommendation is what you think should be done about it. People conflate the two and end up with reports that are either all warnings with no path forward or all suggestions with no evidence base. Include an executive summary that fits on one page. Not everyone who reads your report will read the full document. The summary should state the overall finding, the top risks, and the top three actions. Be specific about consequences. Instead of saying "governance arrangements should be strengthened," say "without a dedicated assurance function reporting independently to the board, a project of this scale and cost carries an elevated risk of undetected scope drift, estimated at 15 to 20 percent based on similar programs in this sector." That gives decision-makers something to react to. Don't be brutal for the sake of it. A governance assessment that reads like an attack will be shelved faster than one that reads like a diagnosis. You're identifying control gaps, not accusing people of malfeasance. Most governance failures are systemic, not personal. The program director isn't negligent. The structure didn't give them the tools or the authority to govern effectively. Say that.

Limitations You Should Acknowledge

A Pg Assessment Practice has real constraints. It captures a snapshot in time. Governance is dynamic. A program that looks well-governed in March may have drifted significantly by September, especially if there's been a leadership change or a major scope revision. Don't present your findings as definitive. Present them as current-state evidence with a defined validity period. The assessment also depends heavily on access to information. If key stakeholders are unavailable, if meeting records are incomplete, or if the program operates in a genuinely opaque environment, your assessment will have gaps. Document those gaps. An assessment that acknowledges its own blind spots is more credible than one that pretends to have full visibility. Finally, governance maturity frameworks assume a level of organizational stability that doesn't always exist. In environments with frequent restructuring, leadership turnover, or shifting strategic priorities, applying a static maturity model can produce misleading results. The framework wasn't designed for that context. If you're working in a volatile environment, consider supplementing the standard assessment with a dedicated volatility analysis that examines how quickly governance arrangements adapt to change rather than how well they document existing processes.

The assessment framework is a tool, not a verdict. Use it to find out where the program's oversight is actually working and where it's performing compliance theater. Then fix the right things instead of the obvious things.