The practice of enterprise project management is finally getting broad respect, not just lip service. Seven out of 10 companies use formal project management methodologies, our new InformationWeek Analytics survey finds. Pay for project managers was on the rise last year, even as pay for most IT pros was flat. Sixty-one percent of the managers we surveyed see the Project Management Institute's project management professional--PMP--certification as important to their companies.
These numbers matter, but more important is the recognition of the project management office's broad role--well beyond being the keeper of the almighty Gantt chart and a budget bludgeon. The PMO is most valued, our research finds, for helping companies prioritize good projects over bad, getting the right people on the job, airing out progress and problems, and executing consistently using the company's standard practices.
"Project management is finally evolving to become more focused on being collaborative, leading and inspiring teams, and ensuring the people angle is taken into account to ensure quicker adoption of changes," says Lynn Batara, director of the enterprise project and portfolio office at Franklin Templeton Investments. However, Batara does see a need for more emphasis on the strategic side of project management, like portfolio management to prioritize projects, and doing a better job of aligning projects with company strategy, minimizing risk, and measuring the benefits.
Asked for the top reasons to create a PMO, 64% of survey respondents say to prioritize projects and 55% say to standardize on an approach--by far the most cited reasons. The next biggest PMO priority is to provide project visibility to leadership teams (34%). Less than a fourth of respondents see tracking project status and project costs as a top reason.
Most companies have some project management methodology in place, and that's part of the problem--if you're not actively questioning your approach, looking for weak spots, and comparing it with other options, it'll creep along in whatever direction it's already headed.
Whether or not you have a formally defined PMO--a single point of responsibility within the scope of business governance--you owe it to yourself to consider how to structure or restructure PMO activities. Each company should consider a number of factors when doing this, including:
How do you track small projects? Companies tend to have a decent handle on large, expensive projects, but they fall short on the smaller ones. Yet those add up to a significant chunk of resources and can put a big dent in IT's reputation and credibility. Complexity and cost, not risk or regulatory compliance, tend to drive whether a PMO is involved in a project, our survey finds.
What tools do you need for project management? Excel dominates, with 82% of companies using it to manage projects. But almost two-thirds use project-specific software as well.
Do you need one PMO office for the whole company? It might seem like the easy answer, but 53% of companies have multiple PMOs. Culture and organizational structure play a big part in what's right for your company.
Does your PMO set priorities or just drive projects home? This is the crossover between portfolio management and project management. You need to apply good project management principles to individual projects whether or not you're doing overall portfolio management. It doesn't have to be the same team, but the groups must talk early and often.
Does your PMO process fit your industry? A lot of project management best practices were born in defense, engineering, pharmaceuticals, and construction. Companies in other industries may need to modify some of those mature disciplines to get buy-in.
Are you communicating the project management office's value? Colleagues shouldn't be left to wonder "What's in it for me?" when it comes to working with the PMO, so keep executives in the loop with project status dashboards and share best practices across project teams.
Rich Carney, who implemented a PMO for a large retailer, warns against adding too much bureaucracy. He's convinced that better processes improve the bottom line, but IT leaders must convince individuals and departments of the upside.
"You always start off with, 'Here's how I can make your life easier, here's how I can reduce your effort or risk,'" Carney says. Because PMO customers aren't forced to "buy services" from the PMO, getting participation is based on that kind of person-to-person marketing campaign.
Something to note: Most companies rate people issues well down on the list of benefits they expect from a PMO. Of the 10 PMO benefits we listed in our survey, managing staffing and tracking customer satisfaction came in eighth and ninth. But centralized project management can't succeed unless project managers have good relationships with end users and project teams have the right leaders and skills.
Ask Eric Choi, who heads e-commerce at credit report company Experian. Choi recently led a $1.2 million project to convert the company's more than 100 independently run, country-specific Web sites into one global Web content platform. That effort took the cooperation of 40 offices worldwide, since Experian wanted the countries to keep their unique, local-language content but to transfer it to the centralized content management system.
The decision to centralize the Web branding and content management was backed by the board of directors. "We had the stick behind us, but we all know the stick goes only so far," Choi says. Success hinged on getting country managers to move their content and buy into a centralized process.
One PMO--Or Many?
Project management purists might like the neat-and-orderly nature of a single, unified project management office, but let's face reality: More than half of companies have multiple offices, and there's no reason to think that'll change. There's no reason it has to. PMOs can reasonably be run just for IT operations, by divisions, or across all capital projects. This is all about governance--who's paying for what, and who controls the activities and resources at a business unit. So for those who think setting up a PMO just for IT is useless, I say prove its worth on the IT level and others will want to learn from you.
Carney, who set up the retailer's PMO, started out by creating one for the IT organization specifically to improve its processes. Another business unit then created a PMO, but it had different objectives--it needed to kill weak projects to free up money and staff for stronger ones. The focus of each PMO aligned with the overall needs of the retailer.
In our survey, which is skewed toward managers in IT organizations, most respondents (57%) say their PMOs report to the CIO, followed by the COO (16%) and CEO (11%).
There can be value in a company-wide PMO, of course. When Randy Mott became CIO at Hewlett-Packard in 2005, he used a centralized project management office and process to help transform the company's IT operations. Every IT project required a cost-benefit analysis from a business unit, including a priority ranking against the unit's other projects. That structure let Mott change the conversation from being mostly about IT's cost to also being about the benefits IT delivers--what Mott calls the "revenue of IT." But Mott's the first to note that such an approach will lead to showdowns with business-unit leaders who refuse to do a cost-benefit analysis. His advice: "Don't blink." (Oh, and make sure the CEO has your back when you take that stand.)
As Mott's experience suggests, such centralized project and portfolio management requires executive time and commitment. So no matter where your PMO sits, providing executive information, during annual reviews as well as regular project updates, is critical. More than a third of the business technology pros we surveyed cite executive insight into projects as a key reason even to have a PMO.
"Project and program management is most valuable when executives can get reporting in a manageable and understandable way," says Steve Haughsworth, who heads up the program office for Plastics Technology. "Without that, they become uninvolved in the project, because they perceive no value, and the project goes sideways." Give them information they find useful, which might mean breaking from strict project management methodologies.
The Right Methodology For The Right Task
While 70% of our survey respondents use formal project methodologies, even advocates can get impatient with the rigidity.
Jim Beinlich, associate CIO at University of Pennsylvania Health System, says most project management principles come from engineering and construction, disciplines where there are a lot of known variables. Given temperature, humidity, and a few other factors, you can predict with a fair amount of certainty how long it'll take concrete to dry.
"When you try to apply that to IT, you are now dealing with a very small set of known variables, and all of a sudden the construction model doesn't work," Beinlich says. Yet IT project managers are trained in the construction model.
Beinlich's project managers make it a priority to spend time with project sponsors to understand what they think the outcome should be. That focus on outcomes borrows from agile software development, where the exact path to the end result stays flexible, and the emphasis is on getting pieces of the project done and back to end users, then reacting to feedback in many iterative bursts.
Web projects, in particular, call for this kind of iterative approach, says Experian's Choi. It's not like an accounting IT system, where perfection may be needed at each step. "On the Web, if we make a mistake, we fix it and republish it," he says.
Because tracking progress is critical to a PMO, project leaders do need to regularly answer the question "How's it going?" The problem is when all that effort is built around a "fantasy deadline." Much of the PMP paradigm focuses on predicting what resources will be needed and the possible risks, and setting a forecast--"the predictive model," says Richard Cheung, a principal with Excella Consulting who's certified in both PMP and the agile-inspired scrum project approach. His experience is that projects benefit from the "adaptive" model--quick and simple estimates, which he says tend to be equally accurate. Plus, with less invested in project milestones, people are more likely to rework plans as requirements change, as new information becomes available, and new roadblocks become apparent.
Small Projects, Big Management Problem
Small projects are the piranhas of IT. Individually, not so bad, but in packs they will eat you alive. HP CIO Mott says most IT teams closely manage only their top 10 or 20 projects--and probably capture only about half the IT spending in the process.
The deployment of 25 new networked printer/scanner/copiers may well be seen as beneath the notice of a PMO, since the risk and cost aren't high. But drop the ball on enough copier installations and you're losing real money--and credibility. If IT can't even get the printers working, how can it reengineer my e-commerce process and Web site?
Nevertheless, it's still surprising that 25% of our survey respondents say they manage all projects the same. Are they really that disciplined--or are they overstaffed or just fooling themselves? Our survey also finds that 25% manage all projects from the PMO, regardless of size or scope. Maybe it's the same 25%.
That approach might work for you, but beware the kill-the-fly-with-the-sledgehammer syndrome. Here are two main strategies for handling small projects.
First, lump them together. Here, portfolio management systems promise to help us classify resources, while making portfolio management practical on a small scale. Classify sets of activities and abstract them into a larger project. So, for instance, don't classify "patch the servers" as a project, but rather track patching as part of staff time spent on "server maintenance."
Second, train business-unit people in enough project management skills to drive small, localized projects. Think of it as similar to having a few "super users" of SharePoint scattered around to help the less tech-savvy colleagues and drive adoption.
What's a small project? There's no real consensus. Less than 40 hours of work is one common breakpoint. Complexity (49%) and cost (38%) are the two most-cited reasons in our survey for when a project gets managed by the PMO.
The Right Tools And People
It's not surprising that spreadsheets are the most common project management tool, used by more than 80% of companies we surveyed. "If you're only managing 15 critical tasks, you can do it easier in Excel," says Beinlich of the University of Pennsylvania Health System.
PMP heresy? Blame project management software vendors for the alternative: using massively complex systems. Besides using Excel, 48% of survey respondents use help desk, work order, or task-tracking systems, and an equal percentage use word processing. Sixty-four percent do use commercial project management software. Of those, 86% use Microsoft Project; just over 10% use Oracle, HP, and CA software. Clearly, project tracking is happening in many different systems.
When it comes to training, only 29% of our survey respondents say their companies don't consider certification important. The PMP cert is twice as likely to be important to a company as any other. IT pros can't go wrong acquiring the PMP, but degree programs, certificates, and vendor certs also carry credibility. The more important issue isn't what specific sheepskin's on the walls, but rather, is everybody using the same approaches, terms, and strategy? Carney says one big problem in getting his retailer PMO up and running was that not everybody followed the same rulebook.Understand the framework and internal organizational challenges and needs, and then create your own processes using the framework.
One last thing about people: Yes, you do need to track the time spent on projects. "If people aren't reporting their time, you're just guessing," Beinlich says. Just as it would be unthinkable to run a project without knowing specific expenditures and revenues, it's crazy to try to wrap your arms around the resource management part of project management without timekeeping. Everybody doesn't need to record their time in six-minute increments, like a lawyer does, but having a rational basis for allocating staff time to projects is critical. This information is probably more readily available than you think: Help desk systems record time spent on operations; calendars capture meetings. The point is, you have to make some effort at tracking how time is spent.
Another piece of advice from HP's Mott is to record what people actually work on, and not what they're scheduled for. Often, people get pulled onto maintenance work and stopgaps when something breaks. That's precious data for determining the real cost of keeping an application--data Mott used in deciding which systems to kill as he slashed HP's app portfolio.
Think long term. We spoke to plenty of people who developed rigorous project management processes while a strong CIO or PMO proponent was in place, only for them to run out of steam once those folks left. Clearly, the company hadn't bought into the approach, and such buy-in is much more critical than individual certifications or any project management philosophy.
So if the predominant feedback about a project management process is that it's way too bureaucratic, listen. And revisit. Is now the time for that key showdown, or a compromise? Circle back to long-standing processes every once in a while and see if they still apply. Show that your PMO can give and take, and you may get broader acceptance that lasts longer than any one project leader's tenure.
Jonathan Feldman serves as IT director for a city in North Carolina.
Write to us at email@example.com.