Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Why command and control PMOs are killing project management

Colin Ellis | Oct. 29, 2014
If you are questioning the effectiveness of your PMO, you need to act, says Colin Ellis.


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.


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.