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 the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.
- Bookmark this page
- Share this article
- Got more on this story? Email CIO
- Follow CIO on twitter
- BI Optimisation: Building a Better Business Case for Business Intelligence
- The Pathways ICT Leadership Development Program | Turning today’s ICT professionals into tomorrow’s business leaders | 2012 Course Curriculum
- Solutions Guide for Data-At-Rest
- Fibre Channel over Ethernet
- Lowering your IT Costs with Oracle Database 11g Release 2
-
All Systems Down
-
Married to your desk? 5 tips for a better relationship
-
Married to your desk? 5 tips for a better relationship
-
NBN to deliver disability support services to regional Australia
-
Beware of malicious QR codes: Report
-
Eight things senior managers need to know about data encryption
Securing sensitive data is a must for every organization. Today’s encryption solutions don’t slow down your users, so you’re not compromising productivity for security. Here are eight things senior managers need to know about encryption to keep their data secure. -
Disciplined Agile Delivery: An Introduction
This evaluation guide is designed to help you choose the best tool to support your current Agile projects, while protecting your investment as your team, needs and agile maturity grow. -
Sanmina-SCI | Webcast
The IT team at Sanmina-SCI works in the competitive high-tech manufacturing industry. It must constantly look for ways to improve service levels while cutting costs. So it took a look at Google Apps, wondering if it could meet the needs of a global, multilingual workforce as a replacement for the company's on premise Microsoft Exchange 2003 system. After careful due diligence and a measured proof of concept phase, the team recently completed a phased migration for 15,000 email users and charted a new course for delivering IT value.
-
Mining Amazon Web Servces
-
Accredited Symbian Developer Primer - Fundamentals of Symbian OS
-
Lpic-1
-
Sharepoint 2007 and Search Server 2008
-
A Pattern Approach to Interaction Design
-
Design Patterns for Dummies
-
Iphone Fully Loaded, 3E
-
The Internet for Dummies, Quick Reference, 8th Edition
-
Objective-c for Dummies®









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