Will most companies that implement a project management office take on higher IT costs without improving performance?

That's the bold headline of a Hackett Group study of more than 200 organizations. It's not just hype: I happen to agree that the risks of a disastrous PMO implementation have never been greater.

Don't get me wrong: PMOs can be incredibly valuable when they manage the right projects through to business-focused completion and kill the projects that don't measure up. Trouble is, PMOs aren't right for every organization, and every organization won't match the intent with the follow-through. Creating a PMO under the wrong circumstances is likely to produce nothing but more project overhead.

[ Read Social Project Management Gets Big Picture View. ]

Hackett Group, an operations improvement firm, found that PMO use for companies of every stripe grew from 2007 through 2009 but steadily declined thereafter. Its research backed up some of the findings in InformationWeek's 2012 Enterprise Project Management survey, which also traced a reduction in PMOs and formal PMO skill sets over time.

The Hackett bombshell: In some cases, the IT organization's performance actually improved once the PMO was eliminated.

Hackett also found that more PMO oversight doesn't necessarily improve business results. "In a weak PMO, poor management of time, resources, requirements or customer expectations encourages shortcuts that increase design weaknesses that drive higher maintenance and support costs," the Hackett report concludes. "Failure to properly identify and manage risk associated with poor technical decisions can also lead to complexity. Even the selection of projects for the portfolio can influence complexity if the PMO does not understand the long-term tradeoffs associated with certain kinds of technically risky projects."

Many of the PMOs of poorer-performing organizations have employees with Project Management Institute and other formal certifications, Hackett found. The problem is that those employees often lack a working knowledge of the business or its technology infrastructure, and their main functions are as task-list keepers and process cops. Most of us wouldn't want to provision a whole business unit full of those kinds of people, yet I've seen it happen, mostly because management doesn't want to pay extra for business leadership.

In successful organizations, Hackett found four key practices: Centralized IT demand management, accountability for business benefits, standardization of processes and architecture, and program and project reviews. OK, let's translate that consultant speak into English. Their PMOs work with business units to review and set priorities for the IT services they use. They're responsible for results, not allowed to point fingers and say: "Well, you didn't listen to me!" They revisit projects after they're completed to assess lessons and adjust practices.

Yet those key practices might still not be enough to justify a PMO. In some cases, Hackett says, agile development and collaboration methodologies such as Scrum can eliminate the need for heavyweight PMOs.

I don't think the PMO is dead, but given the research findings and my own experiences, proceed with caution. Watch out for career builders who prioritize padding their resumes ("I built a PMO!") over delivering organizational benefits. Be minimalist: Anything that gets implemented should have a plain-English reason.

Above all, ensure that the executive team is committed to the PMO. After many years of observing projects and project management, I know this: A PMO that gets just lip service from the C suite won't get the resources or executive attention it needs to succeed. The PMO will then linger on, both for project managers and the business units it's inflicted upon, for year after year before it's put out of its misery. Bottom line: while the benefits are there, the risks have never been greater.