What's Next: Project Management

Five biggest project challenges for 2006.

Contributing Writer, Computerworld |

Project management ain't what it used to be. From who's on the team and where team members are located to the tasks they're expected to complete, project management is a changing discipline.

Consider that project teams are increasingly dispersed across large areas, sometimes spanning the globe, and that IT staffers are finding themselves in more partnerships with managed service providers and outsourcers. Even the projects themselves are changing, as the most business-urgent and thus riskiest projects increasingly get the most funding.

"These things add extra layers of complexity that, if not managed well, will lead to chaos," says Gopal Kapur, founder and president of the Center for Project Management in San Ramon, Calif.

It's no wonder that 33% of respondents to a recent Computerworld survey identified project management as the No. 1 management challenge for 2006, beating out budget constraints and regulatory compliance.

Just ask Gordon Gregory, vice president of technology at Mazuma Credit Union in Kansas City, Mo. Even if his team finishes the five key projects planned for 2006, "there's a list of 60 more waiting in the wings," Gregory says. "Some of them just never make it to the top 10."

Here are the biggest project management challenges that IT will face in the coming year and tips for surviving them.

1. Global Teams

It's no longer considered exotic to have project teams stretched across the globe, whether through offshoring arrangements or business expansion. That's why project managers now have to prepare their staffs for overseas collaboration and a greater understanding of cultural differences. Such organizational readiness is sorely lacking today, Kapur says.

Take something as simple as syncing up country calendars, he points out. Some European countries have two to three times the number of national holidays as the U.S., and it's not uncommon for entire project teams to go on vacation for weeks at a time. In Israel, the weekend starts on Friday, when it's still Thursday in the U.S. "People like to say we can move the work to a 24/7 schedule, but if you don't plan well, people will be sleeping when you need to talk with them," Kapur says.

Language differences can also cause project delays, even among English-speaking employees. In India, for instance, the number "77744333" is verbalized, "triple seven, double four, triple three," Kapur points out. "What does that mean to someone who hears it for the first time?" he asks. "In IT, we deal with long numbers -- that kind of misunderstanding can cause a three-day delay." One resolution: Have a document manager search all documents by keyword to translate local nomenclature to a standardized one.

Working with offshore programmers also poses additional management issues, such as high turnover rates, which can reach 25% to 30% among first-level technicians in India, Kapur says. "Knowledgeable companies are requiring offshorers to detail their plans on managing turnover and creating documentation standards," he says. They're also paying to have a knowledge manager at the offshore site to extract knowledge to be passed along to newly hired programmers.

For Bill Hagerup, senior instructor at Ouellette & Associates, relying solely on collaboration tools such as document-sharing systems, groupware, online conferencing and videoconferencing could be catastrophic. But that flies in the face of reality, where budgets are tight and travel is restricted.

As a result, Hagerup says, "I think we'll see some spectacular failures of major global projects, not because they couldn't make the technology work but because they couldn't work effectively together as a team. The only people I've seen manage global teams successfully spend 125% of their time talking on the phone with people and traveling to meet them whenever possible."

TIP: Take it from experienced global CIOs -- you've got to get geographically dispersed teams face to face as often as possible, even though it means upping the budget. Hagerup's advice for project managers in 2006 is to negotiate the biggest travel budgets they can.

"We try to do face-to-face meetings at key junctures," says Jay Crotts, CIO in the lubricants and business-to-business segments of Royal Dutch Shell PLC. "It's extremely expensive, but the length of time that the project goes on dramatically drops."

2. Moving Parts

IT has never been very good at implementing multifaceted, multiyear projects, especially when teams are far-flung and there's less opportunity for close, intense interaction. One resolution, Hagerup says, is to break projects into smaller pieces and do a better job of identifying exactly what you want to accomplish within those microprojects.

"We're sending requirements offshore, and they're doing a great job implementing what we told them to do, but it's not necessarily what we really wanted," Hagerup says. Project managers need to do a better job of defining requirements and partitioning those requirements logically, resulting in more manageable project releases.

But defining requirements will get more tricky, not less so, says Johanna Rothman, president of Rothman Consulting Group Inc. in Arlington, Mass. That's because companies are increasingly eager to fund the projects that promise to address the greatest areas of risk to the business -- which often means treading into unknown territory that's difficult to map without jumping in and seeing what you find.

"Companies will fund the projects where the risk of not doing it is greater than the risk of doing it," she says. A good example is security. In Rothman's view, anything related to security will be funded in 2006, but these projects will involve risk because companies know so little about effective security policies and systems. "It's not a slam-dunk," she says. "There's a bunch of stuff we don't know how to do very well, and that's what's getting funded, because we can't afford not to."

Roger Agee, coordinating business systems manager at Jeld-Wen Inc., a door and window manufacturer in Klamath Falls, Ore., is already feeling the heat of more-complicated projects. Agee has had to respond to the project needs of his own fast-growing company. Those are often spurred by pressure from Jeld-Wen's strongly competitive and equally fast-growing vendors, which include big-box suppliers such as The Home Depot and Lowe's.

"These projects make your head swim," Agee says. "They used to be simple, like creating new reports or implementing a new database, but now our IS department is struggling to rethink how we effectively manage these new types of projects." Agee says these projects often aren't well defined, tend to cross departmental borders and require agreement among midlevel managers from different areas of the company.

For instance, a recent project involved a request to add a field to an order screen to accommodate sending custom orders directly to the consumer rather than to the store. This raised all sorts of questions about whether the delivery should be sent to a middleman and who would bear that extra cost, Agee says. But in fast-growing businesses, it's not always clear whom to approach for answers.

TIP: One solution to the problem is to assign the project to someone with a high level of responsibility who could see through those gray areas, obtain answers quickly and perhaps even answer them himself, Agee says.

3. Development

Riskier projects will also require more-creative approaches. For one of Rothman's clients, out-of-the-box thinking led to IT inviting the physical security team to help gather requirements for a data security project it was working on. At first, there was a lot of frustration, as the two groups struggled to translate physical security ideas into what could be accomplished with technology. Eventually, IT used a more iterative development approach, where it focused less on predesign and instead plunged into coding, checking back frequently with the security team to get its feedback.

"The agile development technique is enabling people to start risky projects, because they know they can pull the plug before they've spent a lot of money," says Rothman. "You can do it in bits and pieces. If it's what users want, you keep going, and if not, you stop."

TIP: Rothman advocates iterative development in such circumstances because, she says, "trying to plan the whole damn thing never really worked and no longer works at all." But others, such as Kapur, point out the shortcomings of this approach, particularly with global teams. "If programmers are in India, Croatia and the U.S., it's much more difficult, if not impossible, to get timely feedback," he says. "People will be sleeping when you're looking for feedback."

4. Vendor Partners

With so many requests for projects, IT will increasingly turn to vendors, outsourcers and managed service providers to offload some of the burden so they can focus on core competencies.

"It's a resource issue," says Mazuma Credit Union's Gregory. "With the demand to do a lot of things in a relatively short time frame, there will be a tendency to rely more on vendors as partners in implementing projects." The two-edged sword is the loss of institutional knowledge, he says. "For future modifications, you can get caught in the trap of needing to go back to the vendor because of the expertise involved."

TIP: When relying on vendors and outsourcers, it's important to establish a single point of responsibility within the organization to sponsor and manage the project, as well as orchestrate the resources. "Responsibility cannot be outsourced," Kapur says. The person who plays this role needs to have a lot of clout with all the departments involved in the project, he adds, so that person likely shouldn't be someone from within IT. "You need someone who can say no to the business units and live to talk about it," Kapur says.

5. Project Portfolios

Long backlists of projects will also lead to more companies using portfolio management techniques. The theory behind portfolio management is to collect data about all project requests -- including objectives, costs, timelines, accomplishments, resources and risks -- that a manager can regularly review in order to allocate resources and adjust priorities to maximize returns. "You can't do it all at once, so you have to prioritize and set expectations so people understand what you're going to do and not going to do," Gregory says.

"As an industry, we don't do a good job of saying, 'We can't do this' or 'Here's what we can do, and if you want us to do more, we'll have to drop something else, " Rothman says. That's why portfolio management will become more universal, she says. "There are so many pressures on IT to do more."

TIP: To get started on portfolio management, Rothman says, the most important thing is to fund only the projects you absolutely need. Second, make sure to ask how the project fits in with all the other projects going on -- is it for a tactical or strategic objective? And third, review whether the company is ready to take on whatever is required for project success, including having adequate staff resources. "Project portfolio management doesn't have to be impossible, as long as we recognize we don't need to execute every project we consider," Rothman says.

Brandel is a Computerworld contributing writer. Contact her at marybrandel @verizon.net.

Bold Predictions for 2006

Stories in this report:

  • Bold Predictions for 2006
  • Reporter's Notebook: Security
  • Reporter's Notebook: Wireless
  • Reporter's Notebook: Business Intelligence
  • 10 Predictions for 2006
  • Not Happenin'
  • Sound-off On Thin Clients: Wave of the Future
  • Sound-off On Thin Clients: Dead in the Water
  • What to Do: 2006
  • Shark Tank: Doing the Best They Can
  • What's Next in 2006: Project Management
  • Security: Fast and Furious
  • Wireless: Evolution, Not Revolution
  • Business Intelligence: Power to the Poeple
  • Skills Scope
  • Forecast 2006: RFID
  • Forecast 2006: Wireless
  • Forecast 2006: VoIP
  • 2006 IT Agenda

Mary Brandel is a freelance writer based in Massachusetts.

Copyright © 2006 IDG Communications, Inc.