Iceberg PMO

We have all asked at one point or another why it is so difficult to define a PMO, and why practitioners work at such diverse levels, and with such a range of visions as to what the expected outcomes and deliverables are, depending on where they work.  It is not an easy question to answer, because the very lack of an accepted definition leads people to clutch at straws, narrow the focus, and in the end be misled by appearances.

We get some clues if we go back in history. Project management as we know it is hardly more than 60 years old. People often talk about some of the great projects of the past, and try to deduce lessons for today.  This works only insofar as studying any historical record is helpful to illuminate our day and the future we try to build.  However, the key elements of project management as used in today's organisations date only from the period after WWII.

Two elements gave rise to the current form: one was the realisation that to have the certainty of outcome/benefits required by (tighter) sponsors, there needed to be an explicit link between risk, schedule and budget, backed up by some theory, with at least a sprinkling of mathematics for greater credibility. The Manhattan Project provided Monte Carlo simulation to quantify risk, The Polaris Project provided the PERT technique to blend the risk element to critical path algorithms, and the Work Breakdown Structure (WBS) conventions of the US Department of Defence standards were extended to provide mapping to a Cost Breakdown structure that would allow bottom-up financial forecasting.

The second element was the availability of processing power to manage, at a granular level, the data required to reduce uncertainty. Within a couple of decades, it was obvious that to manage change in a corporate environment the only thing that made sense was to use project management. The advent of the PC made possible the use of data driven techniques by nearly everyone. It is ironic that most project management workers today use that computing power to draw pictures that are not in any way driven from the granular data, but the mystique remains.

The history of the PMO has been inextricably linked to the history of modern project management. The necessary divergence between the two is something we will pick up at another time.

In the days of the massive early projects that gave birth to the discipline in industries such as defence, aeronautics, construction and infrastructure, the project support tasks were the responsibility of the project manager. Staff assigned to the PM role (and to support the PM) did the work that in later decades would be formalised and delimited as the early PSOs (project support offices).  Once project management became a standard competence, a corporate activity, it began to dawn on senior management that, in an environment with a large number of concurrent projects of all sizes, the "investors" (them) need as much if not more support than the recipients of the investment (PMs).  At about the time that Programmes became commonplace, the PMO is born of the need to balance the long term interests of the business vs the intentionally narrow focus of individual projects. Portfolio Management is only a couple of decades old in its current shape, but it formalises the focus on the benefits of investment, and it also tilts the PMO away from individual projects and towards the needs of the organisation as a whole, which uses projects to manage change.

A fairly generic mission statement, which I use as a starting points for the PMOs I work with runs along these lines: "To enable the successful delivery of the Portfolio / Programme / Project plan by working with our project colleagues to ensure that well-informed and  appropriate governance decisions are made at the right time by the right people."  Yet there are still too many ways to implement that mission, so that some PMOs look similar while others looks quite different from each other.

The problem we have now is that although we may have a working definition of PMO and we know roughly how we came to be here, we have not answered the question as to why there are so many different flavours of PMO in reality. 

Moreover, tough as it may be to contemplate, the truth is that if a PMO didn’t exist, the organisation would still govern its investments, however inefficiently. It is also sadly true that defining a PMO's boundaries is pure management convention (office politics).

The situation always brings to my mind the ancient story of the blind men and the elephant.  It is a very well known story: A group of blind men touch an elephant to learn what it is like. Each one feels a different part, but only one part, such as the side or the tusk. They then compare notes and learn that they are in complete disagreement.  The man touching a leg says the elephant is a pillar, but to the man touching the side it is a wall, while the one touching the ear swears it is a fan, which is denied by the one touching the trunk who knows it is a hose, etc.

The answer to our original question is that just as in the early days a PSO was an artificial line drawn around part of the role of the PM team, nowadays the PMO is an artificial line drawn around part of the environment that an organisation uses to deliver change by means of projects.  You can draw the line anywhere, it is a managerial (office-political) decision, it is not, and does not need to be, backed up by theory. On top of that, the actual project environment of every organisation has evolved organically to suit it, and therefore there are as many varieties as there are varieties of organisations and businesses out there.  Imagine an iceberg, seven eighths of it very much there but invisible to you, while the visible part has been shaped uniquely by where it calved from and by the weather it encountered along the way. Yet we know an iceberg when we see it.

We need to say more about project environments, because they hold the key.  We will do that in the next post.