Excellent project management will definitely help you deliver your projects but do you just want to deliver projects or achieve your strategic goals. For that, you would need to manage your portfolio of projects as a portfolio. This series hopes to share my experience in portfolio management, what I did well and what I messed up in hope you can short-cut your learning.
Most of the time, a project to set up a PMO doesn't crash and burn. More often, though, it got mired into some slow-motion progress that does nobody any good. It delivered something that on paper seems to be what was designed but everyone else can see has morphed into a project police that proponents have promised to avoid. It has become just another group in the company with its own interest and stake in the organisation's projects to justify its existence, and not the enabler of projects.
There is no standard blueprint for building a PMO like there is for building a rocket. Building a PMO may be no rocket science and yet why do so many PMOs fail?
This is the fifth in a series sharing the reasons why the PMO didn't work. The first article may be necessary to provide the background while a guide to the types of PMOs is in the second article.
Parking your PMO
Often a newly-set up PMO is put under the executive who suggested it in the first place, as 'the only one who knows PMO'. This may be expedient but is not necessary the best place to park the PMO in the long run. Ideally, the PMO should be in a position from which it has access to, draw information from and work through, the entire organisation. There is no hard and fast rule on where this could be as the formal organisational structure and the informal power structure differs with each organisation. But here are the common perches of the PMO.
CEO/COO Office
This is normally seen as the natural home for PMOs. However, I would consider it appropriate only for PgMOs and PfMOs. PjMOs should always be reporting to the executive responsible for the delivery of those projects for which the PjMO is responsible.
Being in the CEO/COO Office provides a mandate that is unrivalled elsewhere, but there are drawbacks. Chief disadvantage is that the CEO/COO often has insufficient time to make the necessary decisions as the reporting manager due to other important matters competing for interest. You know, the most scarce resource in any project is always management attention - and the more senior the management is, the more scare the attention is. This means that the PMO Head has to be senior and experienced enough to run the PMO autonomously without input from a reporting manager.
Another risk emerges in an organisation where the CEO/COO has been seen by the management team as disruptive and can lead the PMO to be seen as 'spies'. The best approach to mitigate this problem would be to recognise it openly and offer the access that the PMO has to the CEO/COO and place it at the disposal of the management team. Any manager who is able to convince the PMO of the viability of an idea can use the PMO as a conduit to bring the idea to the attention of the CEO/COO.
Integration
In some organisations, a division is set up to transform the organisation, usually to a level with the capabilty to execute a particular strategic goal in mind. It can be called anything, but commonly have words like Integration, Transformation, Enterprise or Strategic in its title. Its main function is change management and often is a temporary organisation to be disbanded once the capacity of the organisation is sufficiently upgraded, with the units it has incubated transferred to the appropriate divisions.
The PMO can come under such a unit. Such an arrangement usually serves to underline the change management nature of the project to set up the PMO. The changes brought about or required by the project to set up the PMO would also be coordinated with the other changes in the organisation within the Change Architecture held by the Integration Head. This would also ensure that no division in the organisation would be pushed to change beyond its capacity to do so.
Strategy Execution
Placing the PMO under the unit responsible for executing the strategy makes sense, especially for PfMOs and PgMOs. This should be differentiated from the unit that develops the strategy although that also could come under the same umbrella division.
Someone who knows
All the above divisions would be great places for the PMO to be under with one major proviso - the heads of those divisions must understand PMOs - why it is required, how it works and what its limitations are. If none of these divisions exist or if the background or experience of the head is insufficient for them to champion the PMO, it may be necessary to consider being placed under someone to understands PMOs, even if it is not the ideal place to be parked. At least, until the education of the more appropriate executives reaches the point when one executive is ready to sponsor the PMO.
Where not to park it
If you find yourself within 'not so ideal' divisions, it is not the end of the world. Bide your time and wait for the opportunity to migrate. Whether you are able to migrate or not will depend on your stakeholder management skills and political skills to influence events beyond your formal authority. And above all, be patient.
In the meantime, you will need to maintain your independence and be clear that the judgements made by the PMO is not dictated by the division the PMO is in. You can always explain the PMO's position in the division as "Well, we all need to be in one division or another, don't we?" Other than for administrative reasons, the PMO should see such a home division as another stakeholder in the projects they manage, similar to how the internal auditor views the CEO. The independence of the PMO is often the main reason why divisions would approach them to run projects, often more than because of the skills it has.
Technical Delivery
IT or Technology divisions often wishes to terminate its involvement in projects as soon as possible after the software is launched, which may be fine for PjMOs but not for PgMOs and PfMOs. IT and Technology divisions normally have their own PjMOs anyway.
Business User
This is actually not so bad a place to be as many projects/programmes are sponsored by the business users, but I have also seen resistance from IT divisions as "these people don't understand project management".
Finance
This can be rather painful especially if Finance is led by a 'less-of-a-CFO-type' and 'more-of-an- accountant-type'. And especially if Finance takes control of the project initiation process and end up with too much focus on the business case or imposes some form of project supervision as a pre-requisite before releasing funds already budgeted.
Risk Management
Many Enterprise Risk Management units end up as a reporting function (as they do not own any of the risk they report on), which may fine for ERM but not for a PMO. Nobody wants a PMO who comes round once a week before the steering committee meeting to find out what the status of the projects are.
Strategy Development
Such a unit differs from a strategy execution unit in that it focused on planning and as with any planning unit, there is a pre-disposition for a constant updating of the strategic plans with any new development in the internal or external environment.
Anywhere political
Let's not forget that 'playing the politics' to get the job done is integral to any project execution. Reporting to someone who is politically unpopular throughout the organisation could tar you with the same brush. Ditto for someone who has a reputation for Machiavellianism - everyone will wonder if there is an ulterior motive behind your every proposal.
Migrating with maturity
Depending on the approach, the PMO may migrate at least once during the set-up. For instance, it may start off under the executive who understands the PMO and will champion it throughout the set-up but will only act as the formal sponsor only in the initial stage. If there is a pilot phase, the PMO could be parked under the division whose portfolio it manages as a pilot before migrating to the enterprise level.
All these are of course within the project plan as determined by the Maturity Roadmap.
So, is your PMO parked at the right place?
If you wish to continue the series, the next article is about How.
Comments