Why command and control PMOs are killing project management

I setup my first project management office (PMO) because despite the success my company had enjoyed over the years (and failures too), I decided that we needed more structure.

I told myself that over time, project managers would eventually get used to the idea of a PMO. I created a ‘command and control’ situation, setting up a framework, processes, templates, template with guidance notes, and a handbook.

I made sure that I did it all in isolation, completely ignoring all of the sound planning instincts that had served me well as a project manager. I didn’t identify how my customers could add value, ask them for feedback, or share the plan with them.

I just kept returning to the books to check that I was following good practice. Three months later, I was good to go.

There were emails, a small roadshow (think Glastonbury but in a cramped meeting room with six unhappy people and no music), some more emails (with attachments this time) and a couple of phone calls to find out why things weren’t being done the way that I had prescribed.

Note I’m using the word ‘prescribed’ but more on that later.

I introduced a process for project justification, which was well received by the then IT director as he wanted to reduce the number of initiatives we took on and to better understand the priorities of each project.

However, I filled those sheets in myself. I didn't work one-on-one with project sponsors or managers as I wanted to control the information and present my view. This strategy was flawed and led to suspicion.

Keep reading, there’s a point to this I promise.

When people did use my shiny method, I focused all my efforts on the following.

• Was the right version of the template being used?
• Had the version number been updated?
• Had the guidance text been removed?
• Was the grammar, like err, good?
• Had it been signed?
• Had the people who'd been involved in its creation been listed? And had their correct role titles been used?
• :Were the attachments attached and the notes noted?

If there was time left after that, I’d get stuck into the real stuff.

• Was there sound justification for doing it?
• What was its priority in relation to everything else we were doing?
• Did we have enough of the right people to do it?
• Did we have enough money to do it?
• Was the plan comprehensive enough to provide confidence to the IT director?

To be honest though, given my earlier nit-picking, there was barely enough time for all that and the PMO – rightly in hindsight – gained a reputation for being bureaucratic and not adding value.

We managed to reduce reporting to a slow march of death with project managers having their reports rejected if the wrong colour was used for the traffic light indicators.

We reduced planning to a painful lesson in policy writing ‘it must say this, this, this and this and in this way’. Risk management became, well, risky as we put in complicated matrices and more layers of process to manage the actions.

I’m pretty sure our governance meetings accounted for a 2 per cent destruction of the Amazon rainforest despite the fact that no-one read what we produced until an hour before the meeting.

Nicknames such as the ‘Project Police’, ‘Method Madness Brigade’ and ’Project Blockers’ were used; as was Captain Pugwash although I never quite got to the bottom of that one.

The intentions were good - a sound framework to enable projects to be delivered on time, on quality and to budget - and yet ironically, our methods were not. Too much time spent on telling the project manager what they should be filling in and inviting myself to meetings that I had no right to attend.

We ended up by telling project managers to forget everything they've learned because ‘this is how we manage projects here.’ By the book.

Ladies and gentlemen I give you the ‘command and control PMO.’

Now, there will no doubt be those who are up in arms about my description of what bad looks like, usually because they recognise that this is exactly what they are doing now and this is my point (finally) or at least one of them.

Command and control PMOs still exist. In great numbers.

The transformation PMO

Command and control ignores the most important part of project management, that is people who deliver projects, not the methods and processes we implement.

Organisations continue to set up command and control PMOs, staffed by hard working people who in general (not a rule) have little in the way of actual project management experience or else have this experience but lack leadership skills.

It's good to remember that not every project manager makes a good PMO manager.

The days of imposing a one-size-fits-all method on a project management function are gone, principally because there are so many of them out there these days – both waterfall and agile.

Most of them ignore the necessary leadership skills required to get things done well. Even if you do want to introduce good practices into your organisation it has to be done collaboratively with those who will use them and have used them in the past.

Similarly, any good or bad things from previous projects either in your organisation or others should be continuously incorporated into the framework and the PMO should facilitate this to get the best outcome for the organisation.

The PMO has to support the business of good project management and look for ways to increase output and outcome delivery whilst reducing the risk that your organisation faces as a result of project failure. For me, this is non-negotiable regardless of whether the PMO sits at a project, program or portfolio level.

The information it provides to those involved in managing and governing projects has to be clear, concise (there are some people still printing out huge folders of information) and be focussed on the decisions required to remove roadblocks or resolve disagreements.

It also has to predict those things that might not be visible to them in terms of risks around funding, people, suppliers, dependent projects, economic factors and so on.

Project managers - those people with the responsibility to deliver projects – should be supported at every turn by the PMO.

I don’t just mean administratively, as some PMOs don't provide this service, I mean that the PMO should work with them to define the right approach to their project.

It should also provide independent advice in planning workshops, ensure that project managers don’t take their eyes off benefits delivery and that controls are in place to help them manage the risks, issues and people.

In this role, the PMO becomes a trusted advisor and supports the transformation of the organisation.

The PMO has to enhance the reputation of project management by behaving impeccably at all times and demonstrating the required leadership skills to support project managers effectively.

This will also ensure that the PMO is approachable. The language they use must be simple and not acronym heavy and they must strive to create a culture where delivery consistently delights the customer.

A recent blog by Larry Seen at Culture University stated that cultural transformation starts with personal transformation and most PMO managers should start here.

Creating the structures and cultures that support successful transformation in your organisation should be the goal of the PMO, backed up with the metrics which demonstrate how they will achieve this.

A good PMO is literally worth its weight in gold and should be cherished as it continues to adapt to all that is good and bad about your projects.

Unfortunately, there are still a number of poorly performing PMOs out there and if yours is one that you (or your peers) are continually questioning, then you need to act.

Of course, projects are part of our DNA now, so it's likely that a centre of excellence is more relevant; but rather than allowing it watch the action from a heavily fortified tower, send it down into battle with the troops so that it can see where it can really add value.

Colin Ellis is a project management and leadership consultant with almost 20 years’ experience. He set up his first PMO over 10 years ago and got it wrong. He learned quickly and has many successes since. He also runs a boot camp for PMOs that need some help.