The 8 components of a PMO Controls Framework

PThe PMO Controls Framework should be a simple, concise set of activities or processes, clearly articulated through a PMO handbook or similar document, that enables project and programme managers to understand the what, how and why of everything they need to report. It provides the business with a clear understanding of how delivery of change will be controlled and it satisfies operational risk and audit requirements.

In this post I am going to assume two things:

1. You have to get the basics right:

  • You have the right sponsorship and remit. This is the most critical thing.
  • You have staffed the PMO with the right people – proactive experienced people with at least a smattering of delivery experience mixed with enthusiastic and technology literate less experienced staff is the second key to success. And they have the right attitude because attitude is everything.

2. You are going to apply the bureaucracy avoidance tests to each aspect of your control framework:

  • Does it add value
  • Is there a clear purpose
  • Does it contribute to the overall objectives
  • Is it consistent with a single source of data

So let’s get into the detail:

Status reporting

Status reporting needs to be clear and concise and appropriate to the level at which the report is targeted. Something that is important for an individual project may not be appropriate when it is rolled up to a programme or portfolio. A project manager is in the detailed delivery of change and needs to articulate progress to the programme manager. However, in the bigger scheme of things, the programme manager is concerned with reporting progress across a number of projects up to the portfolio head.

Lots of organisations use Red/Amber/Green (RAG) coding to indicate status. The rules on what drives a particular colour need to be very clear and the status report needs to support and explain the status colour. If non-Green, the report should clearly articulate what the problem is, the impact on the project or programme’s objectives, and what the plan is to return to a Green status and by when. Some organisations use component RAG statuses e.g. for costs, benefits, schedule, resourcing etc. Some even use a weighted average of these to drive the overall status. That is too much detail for this post where we want to keep it simple.


Risk, issue, assumption and dependency (RAID) management

This is a key aspect of managing any project or programme but can lead to over engineering and bureaucracy. Each risk, issue and assumption needs to pass the ‘so what’ test. So what does it mean if the risk or issue occurs or the assumption is wrong. If there are no impacts, don’t record it. Risks could be associated with a specific deliverable (such as the complexity of a particular task) or may be general across the project or programme  (resource availability to deliver the project). Where appropriate they should be linked to milestones so that it is clear when things need to be resolved by. Issues need resolution now and should be a key focus of the management team.

Dependencies are a special case. Within the project they should be built in as links within the plan. Microsoft project handles this particularly well. For dependencies between projects of programmes and external dependencies I tend to manage these through milestones in both plans with the dependency clearly documented and agreed by both projects. External dependencies should always be the subject of contractual terms unless it is on some external event.



Planning is essential and could take a whole series of blog posts in its own right. The key things to remember though are that detailed plans are only really practical in the 3-6 month time horizon. Beyond that things will change and you could spend you life re-planning if you try and maintain a full plan for an 18 month project. Giving your plan visibility to management is key to demonstrating progress and control. This is best done through milestone reporting with senior management only really interested in the top two levels of milestones. However, these need to be supported by lower level milestones to allow the project and programme managers to drill down into the supporting detail to validate a Green status or understand a non-Green status.


Resource management

Resource management is closely aligned to good planning. If you don’t have a good plan you wont have a clue what resources you need when, leading to either wasted capability because people are idle or delays because you don’t have the right people. Key to effective resource management is having everyone using the same role descriptions an a common means of assessing skills and capabilities. That way vacancies or demand can be matched to available talent or supply.


Financial management and reporting

Good financial control is essential. Responsibility for the project budget should rest with the project manager. They must be able to forecast spend to completion in a realistic way. Underspending against budgets and forecasts means that the organisation allocates too much money for a project, potentially missing opportunities to invest in other projects with good returns.


Change control

Effective change control is vital to Protect the project budget. Excessive changes, particularly in the latter stages of a project lead to large amounts of rework, wasting the previous effort. It also increases the uncertainty for the business and unsettles the staff that are being impacted. One large accounting system project I got involved in had just such an issue. It took three months to get control of the changes being requested. Little wonder the project had missed four target delivery dates.


Communications management

Project deliver change and impact people. To deliver change effectively you need good communication within the team to make sure you maximise the capabilities of the team. You also need good communication with the project sponsor and key stakeholders so they understand the progress being made and the challenges facing the project. You also need good communication ith the people being impacted by the change. Communication needs to be clear and concise and has to involve listening as well as broadcasting. You need to hear and act on hat you hear, adjusting your messages to ensure they are being understood and interpreted as planned.


Stakeholder engagement

Notice the title of this section – stakeholder engagement, not management. You cannot manage your stakeholders. You can manage the engagement with them and that is very important. Not all stakeholders will be supportive and you may need to have a plan to either change their perception and position on your project. If that is not possible, you ill need a plan to negate or minimise the impact they could have. Stakeholder engagement is a series of process to assess positioning, actively engage and promote supporters views and negate those against the project. It is a continuous process and one where you have to actively use you sponsor and key supporters to promote or market your project.


The above sections just skim the surface of the key components, each of which could form a blog post on their own. If you would like me to do just that and publish a more detailed post on any of the components just comment on this post and I’ll get writing.

Tagged with:
2 comments on “The 8 components of a PMO Controls Framework
  1. Paul Byrne says:

    A good supportive PMO is very hard to find, sometimes I have to build it myself
    But that is like marking my own homework

  2. albert says:

    Hi Allen,

    please can you publish a more detailed post on the components. it would really be great for my development.

    many thanks


Leave a Reply

Your email address will not be published. Required fields are marked *