Project Smart ~ Exploring trends and developments in project management today

Calendar icon
Adobe PDF icon

There's a Reason IT PMOs Fail

~ By Ken Hanley, B.A, M. Eng

Red fail sign

Only a third of IT PMOs will ever work, and the rest of 'em won't. For the mathematically challenged, such as myself, that means that two-thirds of all the IT project management offices (or programme management offices, or whatever you want to call them) will fail. Nothing scientific in these numbers, mind you, and I didn't do an extensive survey, this is just what I've seen myself, and you're going to have to take it (or not) on faith.

In my line of business, I see lots and lots of PMOs - in fact, I'd say that they've become almost fashionable in the last couple of years; you can't seem to turn around without someone setting up, re-energising or re-engineering an IT PMO. There's even a conference or two dedicated exclusively to IT PMOs; one recently wrapped up in Savannah, Ga. And I'll bet some expert in Savannah told the attendees: Two-thirds of PMOs will fail, present company excepted, of course.

Think about the implications: that's a significant amount of time and money that major organisations are putting into the idea of improving their project management practices (that's good) and two-thirds of it is going down the drain (that's bad). That's two-thirds of the IS organisations who are ticked off with their PMOs and the people in it. That's two-thirds of a whole bunch of good opportunities being wasted.

Why the dismal number? That's easy: 'cause most PMOs are set up for the wrong reasons. Period. End of column. That's it.

Most of the PMOs that I see are set up as a response to a recurring set of problems in their host organisations: We keep screwing up on our projects (blowing budgets, blowing schedules, failing to deliver what we said we would) - we've got to get some better controls in place or We can't seem to get the information that managers wants into their hands or We're trying to do way too much with too few people - how do we choose the projects we want to stick with and which ones we should drop?

Legitimate problems all, and all noble reasons to pursue improved project and programme management practices, but ultimately wrongheaded if they're what your PMO is all about.

And what makes it even worse, is that just by the nature of the thing, PMOs, and the people in them, aren't going to be popular with their IT colleagues. You think IT in general has a popularity problem with the businesses it supports? PMOs have the same problem inside IT departments. Think about those episodes of NYPD Blue where the IAD guys (I can't remember what IAD it stands for, but they're the internal police guys who investigate transgressions by other police guys) turn up - no one likes 'em, and no one wants to work with them. Why? Because they're not seen as being there to help - they're seen as being there to uncover mistakes and squeal back to management.

From a bad start, many PMOs take the next step in being annoying: they try to tell project teams "how they must report to meet management's expectations," they harangue the teams to use "standards," and they ask for additional reports the teams hadn't planned to provide. In short order, they become the "Project Nazis."

Now to the minority: the one-third of IT PMOs that actually work - how do they do it? As the weathered old cowboy Curly said to Billy Crystal in City Slickers: It's just one thing. And that one thing is looking at the PMO from the perspective of the project teams first, and management second.

Successful PMOs don't start by dictating and/or reporting and/or controlling and/or tracking standards. They don't issue orders, and they never say: you need to do this 'cause management wants it. If you're in the PMO, and you force/cajole/bully the teams into filling out paperwork, your IT colleagues will avoid you in the halls, they'll disparage you behind your back and they won't like you much either.

As John F. Kennedy said, ask not what the project teams can do for the PMO, but what the PMO can do for the project teams (I'm sure he said something like that), and if the PMO doesn't do anything else in its first six months of existence but help the teams execute better, it'll be wildly successful.

PMO guys - repeat after me: Hey! I hear you've stakeholders up the whazoo on your project. Bet it's tough to get them all aligned. We've got this great tool that attacks just that problem…can we help?

Hey! I hear you've got your first project steering committee meeting tomorrow. Those guys drive me nuts when they can't agree on priorities…we've got this project triangle thing that we think might help…

Dig in, do the grunt work and don't expect the teams to produce anything for the PMO that you wouldn't want to produce yourself if you were in their position, and don't ask for anything that doesn't have a direct benefit to the project itself. In fact, for the first few times the project teams use a tool or technique the PMO suggests, the PMO staff had better be prepared to do the work for teams. If you force them to fill out paperwork, they'll avoid you in the halls and disparage you behind your back.

The trick is giving the people who are actually doing the project tools that works on the ground and in the trenches right from day one. Do that, and the project teams will beat a path to the PMO door.

You can worry about putting in the control and reporting and tracking mechanisms later - in fact, those mechanisms should be a natural by-product of a well managed project, well managed partly because the (hugely helpful and supportive) PMO has provided an excellent set of tools, practices and competencies that make the project teams better.


Ken Hanley, B.A, M. Eng specialises in programme and project management. He has worked for a number of major corporations, including KPMG Consulting, Eastman Kodak, Gulf Canada Resources, PanCanadian Petroleum and currently has an international roster of clients. He has extensive experience in information systems strategy and deployment, business process re-engineering, and in the effective planning and execution of major projects in a number of industry areas, with government and with educational institutions. Ken's specialties are project planning, alignment, and risk reduction. He has also had considerable success in project intervention for troubled projects and working with and mentoring project managers on difficult projects in a number of industries. He has a Masters degree in Engineering (specialising in project management) from the University of Calgary.

Ken Hanley wrote the article "There's a Reason IT PMOs Fail." His book, "Guerrilla Project Management," is published by Management Concepts http://www.managementconcepts.com

Ken can be contacted by email ken@kthprojects.com, or visit his website www.kthprojects.com to learn more about programme and project management.

© Ken Hanley. All rights reserved. Published with permission.


Comments (1)

Topic: There's a Reason IT PMOs Fail
5/5 (1)
Gravatar
Full StarFull StarFull StarFull StarFull Star
2nd July 2015 1:08pm
Gene Donohue says...
Most PMOs are out of control. I ask the question - is your PMO helping or hindering? For most organizations the answer is probably the latter where bureaucratic processes and templates actually have the reverse intended effect of slowing down progress. PMOs need to evolve to provide more value to the projects - to help them succeed rather than blocking.

Add a comment



(never displayed)



 
1500
What is the day after Friday?
Notify me of new comments via email.
Remember my form inputs on this computer.

12 Tips for Being a Good Manager

Businessman revealing the inner superhero

Keeping a project management team running smoothly can be a challenge, especially when budgets are lean and expectations are high.

The 8-Step Guide to Creating a Quality Project Schedule

Businessman with a Gantt chart

This article looks at a simple, practical approach to creating project schedules. After reading this article, you will have a sound approach to creating schedules that you can use for future projects.

Resolving Project Team Conflicts

Two women having an argument in an office

Conflicts on project teams are a fact of life! Only on rare occasions do conflicts not arise. As project manager you must manage these conflicts.

Undertaking a Successful Project Audit

Audit checklist clipboard with checkboxes marked for related concepts

A project audit provides an opportunity to uncover issues, concerns and challenges encountered during the project lifecycle.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Samara Grantham commented on…
12 Tips for Being a Good Manager
- Thu 1 December 2:46pm

Adolfina commented on…
Introduction to Project Management
- Mon 21 November 9:52am

Edward Brown commented on…
Project Status Reports Everyone Can Understand
- Wed 16 November 3:38pm

Latest tweets

General Project Management • Re: Project Resource Challenges https://t.co/P5EYYQRLNE #projectsmart #pmot about 8 hours ago

General Project Management • Re: Prioritising Change Requests https://t.co/H7HUyTPAfs #projectsmart #pmot about 8 hours ago

Business Book Reviews • Re: Project Management Booklist https://t.co/uZ1kSXN7OR #projectsmart #pmot about 20 hours ago