A map for a journey

In the last series of posts I have explored a working concept of PMO that highlights the centrality of the project environment and its governance, by tackling some of the questions around that way of positioning PMO.

In the next series of posts, I will consider what we can do in practice to optimise PMOs, starting from where they find themselves. Some posts will deal with ways of tackling problems that are common to many situations, and these will be fairly abstract, so that they can be applied in practice to many different settings. Some posts will deal with specific examples, which aim to provide a way of showing how the more abstract tools are can be used in practice.  Other posts will respond to topics that are emerging now in the wider discussions and implementation of PMOs.

We could start anywhere, but let's start with a tool that should be in every PMO toolbox but in fact is rarely used.  This lack of use is one of the key reasons for the surprisingly high rate of PMO failure. (Some industry estimates put the failure rate of first-time PMOs at more than half).

So what is this basic tool that enables a PMO to use all the other tools to their maximum potential? Let's call it "mapper": let's imagine a virtual Swiss army knife that allows us to map the project environment in which we move.  From our starting point (our working concept of PMO) it should be clear why mapping the project environment is a smart first move, so we won't labour that point.

The essence of a map is that it shows relationships between the elements of the "world" it describes. For example, the most common type of map is a roadmap, and it depicts symbolically all the elements that a road user needs to get from A to B, or to estimate the time various journeys may take, or to understand which spots are more or less accessible to each other, etc. There are also, non-spatial maps like a Gantt chart, for instance, which shows the relationship in time between activities in a project. The PMO needs to map the project environment of the organisation it lives in, because it needs to understand what "journeys" are possible, and also how to improve the "roads" and facilities that exist.

Now that we have been spoiled by satellite imagery and we can see the lay of any place by just tapping a few keys into Google, we tend to laugh at the antique maps displayed in museums.  They seem the work of a child. Well, it's time to access your inner child because your maps of the project environment will not have the help of any equivalent satellite or surveyor.  Like the ancients, you will be relying on the stories of travellers and sailor's tales.  You need to start with such up to date gems as your own organisation charts.  Here be dragons, indeed.  However, just like the maps of the ancients, they will be incredibly valuable.

A useful map of the project environment of your own organisation needs to include all the features that contribute (or hinder) a project. It must include such features as teams that contribute to the project as participants, approvers, or other form of stakeholder. It needs to include the hierarchies that provide resources, governance and usage of the deliverables of projects. It needs to highlight key names, pinch points and bottlenecks. It needs to highlight the main highways from B to E (start to finish). It also needs to highlight the other tortuous little routes that projects typically take in your organisation. It must show all the different supporting operational teams, such as procurement, HR, accounts payable, legal, engineering, compliance, facilities, various IT service areas, management accounts, whatever applies in your organisation.

A collection of features becomes a map when it shows the relationships between the significant elements. How "far" is the Board (or equivalent) from the management of the project? How "far" for each type of project or programme? How "far" does the remit of Portfolio Managers extend? Is there one Portfolio or many? By what routes do decisions get cascaded, who makes them, what are the penalties for ignoring them? How does escalation work for each type of project? Does escalation work, or do we have great impassable bogs or oceans as part of the map?  You are now drawing the equivalent of boundaries, bridges, mountain ranges, borders, mountain passes and Check Points.

You would need to get the information for the map's features and relationships from standard (unreliable) sources, such as organisation charts, standards, methodologies, terms of reference, and other documentation.  You will also need to rely on Lessons Learned repositories, if any.  Ultimately you have to leave your desk and talk to people.  Ask how it really works, what obstacles have been found. Talk not just to various frustrated PMs but to those that frustrate the PM as well. There are (at least) two sides to every story. You are not there to judge, or to resolve, you need to know, you need to map. Solutions (may) come later - at this point to know is more important than to attempt random acts of organisational heroism. Your greatest challenge will be the invisible part of the project environment, because it will be hard to identify who to talk to.  Some PMs and others appear to see only what the lifecycle tells them, nobody remembers procurement, external services or the people who administrate room bookings until it is too late.

Once you have a first pass of the information you need to draft it in a visible format, so that you can test it against the reality of on-going projects. This "map" is mostly for internal PMO consumption, so the format and medium is up to you.  Pragmatically, this depends on what suits you best and what tools you have available. A snapshot of a whiteboard session works, as does a series of tree diagrams, or a series of sketches in some drawing or presentation tool. Others will prefer layered RACI spreadsheets, or a hyperlinked annotated set of life cycles, etc., etc.  The only requirement is that your new map of your PMO related world encompasses the whole of your organisation's project environment, and that it marks clearly what parts of that are under the direct remit of the PMO.

This "mapper" skill should be your first and most important tool.  Refinements will be needed over time. Some day, when you are ready to propose radical improvements to the way projects are run in your organisation, a slick version of the map will help you make your points in front of a senior audience.