PMO: What is it and do you need one?

Setting up an office to manage programmes across the business from the top down could be a smart idea. But, says Danny Bradbury, developing a mature team for this purpose is no mean feat.

Like all attractive business concepts, programme management is a great idea in theory but moving from theory to practice is hard work.

Programme management involves pulling together a number of different projects into a single initiative reflecting a broad business goal. Launching a new product, for example, may involve a research and development effort, a training project for sales staff and a marketing communications campaign, all of which may be separate projects with a common goal (a programme).

To manage all of these projects, a separate team in the form of a programme management office (PMO) may be needed.

A PMO allocates a dedicated team to a programme. Richard Morton, a management consultant at Amtec Consulting, says: "If you have just a couple of projects, you could find that one of the project managers doubles up as the programme manager with an aide to manage the administration. When you get into something major, say £10m or more, you need a formal programme management office."

The staff in a PMO will focus on a number of individual functions to keep the various projects within the programme working smoothly together. The emphasis is on enforcing standard processes so that all projects are governed in the same way.

One function the PMO staff will manage is the programme plan, explains Morton. It ties individual projects to a broad business goal, monitoring their interdependencies and giving the programme management staff a snapshot of the state of each project at any given time.

Other functions include financial control, which constantly reviews the business case for an evolving programme and communications, which creates a brand to help unify the projects within the programme by distributing internal newsletters, for instance.

Risk management is an important goal for the PMO, says Morton. "The goal is to make sure that all the risks are owned and that all necessary risk mitigation activity is identified and undertaken," he says. Although generally the register of risks focuses on programme-level threats, it can in some cases refer to risks within individual projects, if they are so significant that they will have an adverse effect on the programme.

Just as a PMO will contain a register of risks, so it will so contain a register of benefits. "Here, you are looking at overall outcomes from the programme which will meet your high-level goal," says Morton. The register is often used because benefits can be managed quantitatively. If one project is not delivering the expected benefits, then other benefits may be enhanced. "It's about getting trade-offs between the projects to ensure that your goal is delivered," Morton suggests.

But one of the most crucial elements of a PMO is change control. Ian Rutherford, a partner in infrastructure managed services at Unisys, uses PMOs internally to manage customer programmes. Many programmes suffer from diversion, he says. Changes requested by the business can send a programme off the rails if they are carried out without regard to other changes. For example, change one may remove a system bug but change two may add a feature that works around the bug. Change two could break the system if change one has already been carried out. "A well executed PMO with the right level of governance will look at those changes and slot them into a programme at the right time, so that they bring benefits," says Rutherford.

Not all PMOs are mature enough to handle functions such as change management effectively. Chuck Coletta, senior partner in the consulting group at CSC, has developed a PMO maturity model that shows how PMOs develop in terms of effectiveness. At level one in the model, the PMO does not exist. Instead, projects are self-directed and pay little regard to business objectives. At level five, the PMO is sponsored at the highest level and uses techniques such as Six Sigma to drive constant improvement, alongside resource management and project portfolio tools to help maintain a consistent set of processes within individual projects. In between these two levels, PMOs achieve the varying levels of consistency and adherence to wider business goals.

Coletta envisages an enterprise PMO (E-PMO) that manages all programmes at the highest level, with sub-programmes addressing discrete business objectives at a second level. This creates a hierarchy which can help to reinforce well-defined programme and project management processes. Tools used by the subprogrammes would have to be sanctioned by the higher level E-PMO.

"That is pretty typical of a well-organised programme governance operation," says Unisys' Rutherford of the E-PMO idea but he adds a caveat: "The only risk of taking that route is over-engineering it and putting so many checks and balances in that you bog the whole thing down."

Hierarchies generally breed bureaucracies and companies interested in PMOs must find a balance between circulating top-level strategy throughout their project structure and restricting workflow with red tape. Overly rigid and complex structures that tie your projects down risk choking off innovation that comes from the bottom up.

Disruptive activities and technologies that often first appear at the grassroots level have been known to dramatically improve efficiency when adopted officially and companies that don't recognise these disrupters in time risk being left behind. For example, the first company to sell insurance directly in the mid-1980s instead of through high-street brokers experienced dramatic success, leaving slow movers to catch up. How can a company allow for business-changing innovation like this while also imposing necessary structure from the top down?

There is nothing to stop you creating a project or programme that focuses on making your own products obsolete, says Coletta. A programme can look for innovative ideas that can be given credibility by being absorbed into the top down PMO structure. Such a programme could create an environment in which innovation becomes a defined business goal, rather than a chance occurrence.

All of this takes a financial and cultural effort and developing a PMO with sufficient maturity to marry projects to business goals is no easy task. "It's not a bad model to say that you have a number of projects delivering things, and another one which is the PMO itself," says Amtec's Morton.

Agreeing to devote the necessary resources to a team that does nothing other than manage other teams is the first step along this road but it is far from the last.