3 PMO Pitfalls That Jeopardise Every Project
- 28 May, 2010 02:09
- Comments (1)
Project management is booming. The Project Management Institute boasts a million members. Project management ranks third on "The Top Five In-Demand Skills" in U.S. News and World Report's University Directory. At the center of all of this project management activity lies the PMO, the project management office. An obscure concept 20 years ago, PMOs are nearly ubiquitous today in a business environment focused on efficiency, standards, metrics, and repeatability.
But all is not well in the PMO world. Resistance to PMOs runs high among line of business project teams. Projects still fail at a worrisome rate. Turnover among project managers remains high, creating inefficiency, and without project team cooperation, the PMO cannot perform its duties. Thus, the mission of the PMO -- to deploy a common set of project management processes and governance across the enterprise so that projects succeed on time and on budget -- has become jeopardised.
The PMO can be saved, however, provided its leadership recognises and avoids the following three common pitfalls that dog PMOs and their relationships with business lines and IT.
PMO Pitfall 1: The One-Way Street
Reciprocity is a staple of all human interactions. Offering value for value expected lubricates everything from commerce to marriage to the playground.
How reciprocal is your PMO? They probably ask for a lot: a lot of forms, rules, meetings and deadlines. They expect timely reports and accurate information, all to be delivered by the project team.
But do they report back to the project team with new information that drives better decisions? Do they offer personalised coaching to project team leaders running their projects more effectively? Do they work with the team leaders to make the PMO role understood? Are your PMO heads expected to exhibit skills like leadership, communications, and the ability to influence people?
I have had project managers say to me, "I give the PMO all my information all the time, but I never see it again. I get what the PMO needs, but how does it help me be better at my business?"
Give to get. Return value to your sources. Remember, you have two sets of "customers" -- executive management and the project teams.
PMO Pitfall 2: One Size Does Not Fit All
Massive projects are complex and risky, and they must be managed accordingly. When your company is spending $150 million over five years in a competitive race to boldly enter a new business with new technology, you want a PMO that can get its arms around the whole monster. You want detail-focused sticklers who value process as much as outcomes and who recognise the relationship between the two. No shortcuts, no apologies.
But how many of your projects are of that magnitude -- maybe ten percent? Most new projects are modest in scope. Most are routine maintenance or repair -- low-risk projects performed by the same team that got it right last year.
Even with small projects, costs and deadlines still need to be met and reported in standard fashion for the enterprise. But does your PMO, on encountering a routine, low-risk, low-cost project sensibly limit what it asks of the project team, omitting certain requirements that are standard on massive projects? Or do the same rules, protocols and forms apply across all projects, no matter what the size?
The maturity of the project group should also play a part in the PMO's expectations. If a PMO staffed with long-time practitioners inherits a project led by employees who are new to the PMO environment, there are bound to be adjustments for both parties. They will unfold more smoothly if the PMO scales up its expectations over time, while the team builds its knowledge of the project and the PMO. Instead of asking, what is the full complement of information that will allow us to manage this project as we do others, ask, what is the most basic information we need for a successful launch of this project?
Moderate PMO requirements according to the project's risk and the team's maturity.
PMO Rule 3. How Am I Doing?
PMOs are good at answering management's central PMO question: How are our projects doing? They tend not to be so experienced at answering another question, probably because management doesn't ask it often enough: How is the PMO doing -- from the standpoint of its customers?
If PMOs tend not to be concerned about resistance or even a low-level rebellion by the project teams, it may be because, rules trump relationships. If the PMO rules are satisfied, the PMO is doing fine.
At one conflict-ridden PMO we were brought in to help, we asked the head to score his performance as he believed his business and IT customers would score it. He acknowledged running about average with the line of business project team, but he was confident that all of the team members in IT would rate the PMO as excellent. "IT gets us -- they value what we do," he told us.
We did a survey of the group VPs in IT. To a person, they said the opposite. "We'd be better off without the PMO," was the refrain. They complied with the PMO's demands, but that's all. With the business teams, the results were even worse.
PMOs can't be the only place where poor working relationships miraculously have no negative effect on productivity and costs. Whether it's a formal blind survey, or informal but authentic questioning, PMOs need to know how their customers rate them and strive for better relationships. And management needs to know, too. Otherwise, what the PMO gains in project efficiency can be squandered on organisational dysfunction.
Cultivate relationships along with rules. Both will benefit. Know how the PMO is valued by its customers.
The complexities of big, difficult projects lend themselves to pitfalls like these, and they can be exacerbated by the constitutional differences of the people who tend to inhabit the business line versus the PMO. Just recognising the pitfalls, and the damage they create among well-intended people, is halfway to avoiding them.
Adam Bookman is a Managing Partner in Collabera LLC's consulting division. Contact info. adam.bookman@collabera.com, (416) 487-2759.
Join CIO, the CIO Executive Council & IDC on 6 October at Australia’s premier Melbourne event for senior IT executives – the CIO Summit 2010. Find out more or register now.
- Bookmark this page
- Share this article
- Got more on this story? Email CIO
- Follow CIO on twitter
- John Holland streamlines projects with integrated portal
- The Self Evident Truths of Project Management: Truth # 7- “All projects are ‘change projects’”
- How Do You Know if Your PMO is Successful? Part IV: Cross-Project Services
- How Do You Know if Your PMO is Successful? Part II: Standards Management Services
- PMO Role 5: The critical success factor for PMOs
-
Red Hat Fedora Linux 3 Multipack for Dummies (Fedora Core 3 Distribution with Source Code on 9 CDs for Customers Without Access to a DVD Drive)
-
Always Be Testing
-
Expert Podcasting Practices for Dummies
-
Supporting Users and Troubleshooting Desktop Applications on a Microsoft Windows XP Operating System (70-272)
-
Excel 2002 Power Programming with VBA
-
Liom
-
Professional JavaScript for Web Developers
-
The Art of Indexing
-
Encyclopedia of Software Engineering, Second Edition























Comments
Mats Alama
Agree 100% with all that the article covers but then it doesn't cover 100% of the problem (of course, no one would have expected that, myself included).
One of the early statements in the article is "a business environment focused on efficiency, standards, metrics, and repeatability". These factors very seldom filter down to projects unfortunately in my experience, in particular if the filter includes the PMO.
PMOs all too often become "black holes", staffed by inexperienced people with no say in the organisation to which they report. Furthermore, people in PMOs work in the dark and are expected to pull information out of thin air - which is exactly what they end up having to do: manufacture the information that is required. This is very scary indeed but not an uncommon practice.
PMOs can, in fact, be abolished all together, with no down side, when projects are provided with adequate instructions, communication channels and tools. We've proven this in any number of organisations and initiatives.
Not only does this save money, it saves time and sanity too.
Post new comment