Securing your transformation – program management office practical best practices
22 March 2013 — A program management office (PMO) is established whenever there is a need to manage large programs containing several projects. In this article we go through the PMO establishment process, best practices in running a PMO and common caveats in different phases.
Download this post (PDF)
For any change, improvement or larger transformation, solid follow-up and support is needed. Usually this is done using a program office. Generally a program management office (PMO) is established whenever there is a need to manage large programs containing several projects. Those large programs can be related to post-merger integration, corporate restructurings or simply strategy implementation. No matter what is the business situation, the nature of a PMO and the way of working in it are relatively standard. In this article we go through the PMO establishment process, best practices in running a PMO and common caveats in different phases.
PMO’s responsibility is to ensure successful execution of the program
The ultimate target of the PMO is to ensure that the program is able to reach the business objectives that have been set for it. The PMO can help the program in achieving its objectives by:
- Ensuring that all projects have sufficient plans and resourcing for implementation
- Setting up follow-up mechanisms to track the progress, including KPIs (key performance indicators), weekly routines and monthly reporting
- Identifying and removing bottlenecks of different projects, preferably in a proactive and pre-emptive fashion
- Supporting individual programs in execution when needed by providing an extra pair of hands or specialist resources
- Intervening and instigating corrective actions when the original approach is not having the desired impact
Before establishing a PMO, the program must have clear, tangible and measurable objective against which the success of the PMO can be tracked. Measurable objectives are often related to financial improvements but operational performance indicators like time-to-market can also be used. The PMO should not be established only for providing reactive reporting – the PMO should always be proactive in project planning, solving problems before they occur. The purpose is to identify upcoming bottlenecks and lack of impact, by using leading indicators, before they start affecting progress. By pre-emptive intervention the program can be kept on track and progress maintained. In larger projects, for example software related, leading indicators can be supplemented by quality gates, which are used to determine that the necessary pre-conditions to move into the next stage are in place.
A typical failure of the PMO is “keeping it busy because it is there”. We have seen a PMO that employed several people who only provide reporting for each other, without any clear objective or mission. The reporting was not tracked by anyone in charge and there was no follow-up on the project business cases or impact. It seemed that the PMO was in place only because “it was supposed to be there”. This type of working mode undermines both the transformation program, and the motivation of the people involved.
The PMO should have resources that are capable of tackling different types of business issues that the program can face. The management should be ready to give the PMO the mandate to intervene in the execution of individual projects when needed. If these pre-conditions are in place, the PMO can be set up. While the PMO does provide front line support, it is important that it is also supported by a powerful senior guiding coalition. Having solid ownership and support on the top management level is a key pre-requisite for any change, and the PMO by itself cannot replace that.
Establishing a PMO has eight standard steps with many caveats
When someone has a mandate to establish a PMO, a certain minimum set of actions should be conducted in order to get a grip of the program. We can structure the PMO establishment into some well defined steps:
1. Ensure there is senior ownership and a powerful guiding coalition that sets and supports the overall direction
2. Structure the program to projects and assign responsible project managers
3. Define operative and financial objectives and milestones for each project
4. Set up operative KPIs to track the progress, including leading indicators for pre-emptive intervention, and quality gates in case there are serious dependencies between consecutive phases of a project
5. Build business cases and financial follow-up for all projects (make sure your figures measure real impact – ideally the impact should be visible also in the company’s regular financial reporting)
6. Identify cross-dependencies, risks and mitigating actions
7. Setup weekly and monthly routines both for follow-up, support and intervention
8. Define in advance how intervention will take place in case there is lack of progress, and what the decision criteria are for intervention (this may also include formalized alternatives, “plan B’s”)
All these sound trivial, but mistakes occur too often. The first caveat relates to step one and the need for top management support. Without a guiding coalition of senior managers, projects might seem to progress well temporarily. But ultimately the change effort comes to a halt when the resistance in the organization mounts up. Senior managers can drive the change and play an important role in leading by example. A crucial element in developing the guiding coalition is the establishment of a need for change. This is often initiated by a (potential) crisis or a great opportunity. Only if maintaining the current status is perceived as riskier than exploring new ways, organizations are willing to do things differently.
The caveat related to step two is the most dangerous: if the projects are not structured properly by using the common “mutually exclusive, collectively exhaustive” principle, we can either have overlapping responsibilities or a responsibility gap. The best way to avoid this is to create a simplified operating model which shows the interdependencies between the planned actions and split projects in a way that roles and interfaces are clear. Keep in mind that this is no easy task and it should be given proper attention: we have spent as much as a month just structuring the projects in the right way.
The caveats of the third step are related to details: you should not underestimate the need of defining objectives and milestones explicitly. Quantifiable objectives should always be preferred: for example, the objective for a project could be to reach 10MEUR EBIT improvement or reach five percentage point market share improvement in selected markets. However, these statements are still missing couple of elements needed for a proper definition of an objective: when the improvement should be reached, is the impact a one-time item or continuous improvement and what are the assumptions related to market conditions. The same level of detail should be in place for all milestones of individual projects: they should have verifiable targets and a clear deadline. In one of the PMOs that we have seen, the overall objective was not clear enough and especially the milestones were not defined. This resulted in confusion when defining the objectives for the projects, and eventually led to a situation where project managers were reluctant to take on the projects because of the lack of clarity in the assignment. The PMO had a very slow start and lost some of its credibility, which took a long time to regain.
If the overall objectives of each project are clear, steps four and five are much easier to conduct. The caveat related to these steps is to mix them and their roles. The nature of operative KPIs should be more forward-looking, because the financial KPIs are by default backward-looking. For example, if target is to increase sales, the operative KPIs can be related to the number of customers in different sales phases. If KPIs and business cases are not defined, we end up in a situation when it is impossible to say which parts of the program are progressing and which are not.
In step six, the PMO should define cross-dependencies, risks and mitigating actions. Even though the projects should be mutually exclusive, there will always be some cross dependencies that can become serious bottlenecks at some point. When defining the cross dependencies, project managers and the PMO should not think only about internal issues, but also dependencies related to customers, suppliers and other stakeholders. The risks of project delays increase always when there are dependencies to external stakeholders.
Developing good plans is not sufficient if the structures for following-up on progress and for providing support are missing. Without regular routines for monitoring progress, projects can go off-track unnoticed. Project managers try to fix the problem on their own or are too focused in their perspective while the problem grows out of hands. Established routines and frequent milestones will show needs for support and intervention early on. In order to work efficiently, the routines should be standardized as much as possible. Material should be distributed before meetings as a pre-read. Preparing the material facilitates a fact-based and action-oriented discussion that goes beyond explanations. Some standard items should always be included in the material: 1) challenges, their impact and mitigation actions. 2) Successes and lessons learned to be shared with the organization. 3) Next steps and upcoming milestones. Establishing these routines early is important to shape the working habits and to take the program to a good start.
Without clear objectives and frequent milestones (step 3) the PMO will find it difficult to determine in which cases intervention should take place. Identifying these cases, however, is crucial as they allow the PMO to intervene at an early stage. Explicit, at best quantified, objectives make measurement of success easy and fact based. Quantified thresholds for intervention define clear criteria for the need of intervention. Clearly defined criteria are important as negative developments often do not appear sharply but in a gradual manner over a long time horizon. In such cases, action is delayed as decision makers are waiting for things to turn to the better. Defining quantified targets with their calculation principles will be helpful in understanding why the actual numbers deviate and in creating action plans.
Running a PMO and taking it to the next level
If all the steps of the PMO establishment process are done properly, running the PMO becomes much easier. The routine work the PMO should do with the project managers are:
- Updating KPI reporting, progress against milestones and financial impact
- Adjusting long-term plans according to the progress and potential new targets
- Planning concrete actions for coming weeks
These tasks should be done 1-4 times per month depending on the urgency and nature of the business. The PMO should continuously invest part of its time in automating these routine tasks in order to free up time for supporting those projects which are not progressing according to objectives. The first step to automate these tasks is to create a weekly standard agenda and reports for a weekly meeting with the project owners. A standard monthly reporting format is also important, as well as an established routine to communicate with the executive management and other stakeholders of the PMO.
The PMO should actively work towards avoiding the need for intervention in the projects altogether. This is crucial to ensure that the PMO does not become a function that only provides reporting. When the PMO has set up all the routines, it should move its focus to solving front-line issues, conducting post-project analyses and sharing lessons learned through documentation and trainings. In addition to the weekly reporting and meeting routines, the PMO personnel should for example do some of the analyses to keep an understanding of the substance and talk with the project owners over coffee and in other informal situations to share information and get status updates. However, as discussed earlier, the PMO should have the mandate, the capabilities and the willingness to make deep dives to certain topics by going to the front line to solve bottlenecks. Gathering front line experience is needed to ensure that the PMO can add value in the long term. The more front line experience the PMO has, the better it can support and challenge project managers in problem solving and drive the program towards its objectives.
If things go wrong in one of the projects of the PMO, it is important to keep accountability and resourcing in mind. Only in very exceptional cases the right corrective action is to change the project manager. Usually, it is much more beneficial to let the project manager stay accountable and just ensure that she gets the required resources and support to fix the issue. The role of the PMO in these cases is to allocate those resources and put more focus on following the project by for example requiring daily reports on the progress.
Per Stenius, per.stenius[@]reddal.com