Project management used to be about driving out uncertainty. You nailed down all the deliverables right at the outset, thought through issues around scale, sequence, and size, and fine-tuned your specs so that the implementation could be as routine as possible. Sure, there were always a few surprises, but when you were retooling your fifth manufacturing plant in a year, you could pretty well predict what you were in for.
With today's projects, however—whether they involve new-product development, IT installation, civil engineering, or internal process improvement—much of the uncertainty surrounding information management simply can't be eliminated.
If you were retooling a shoe company's manufacturing plant, says David Schmaltz, a Walla Walla, Wash.-based project management consultant, "perhaps only 10 percent of the work would be devoted to building the new production line, but 50 percent would have to do with the uncertainty surrounding which shoe style will sell best in the next quarter. There's no objective means of determining which style will be most attractive to buyers, so that places a greater premium on being adaptable. Thus, instead of trying to cut its time to market by building production lines faster, the company focuses on building production lines that can more easily accommodate changing shoe styles."
If you're in charge of a complex project, all the talk you hear at business conferences about the importance of being able to manage uncertainty and adapt to unanticipated developments takes on new urgency. Now, how do you make that talk actionable?
| The traditional operational focus of project management will doom a complex project. |
Studies of exceptional project managers in fast time-to-market industries show that the initial phase of a complex project, often referred to as the fuzzy front end, has a disproportionately large impact on the end results. All the recommendations that follow flow from one counterintuitive insight: The traditional operational focus of project management will doom a complex project.
Beware certainty
"It's very easy to look at a fuzzy situation and, based on scant experience, assume you know everything about it," says Schmaltz, author of The Blind Men and the Elephant: Mastering Project Work (Berrett-Koehler, 2003). This quickly leads to the conclusion that you already know what the solution should be—and the urge to dive right into the implementation.
Resist this operational thinking and focus instead on articulating the problem as clearly and as broadly as you can. "Defining the problem first gives you greater degrees of freedom in solving it," says Bob Gill, president of the Product Development and Management Association (PDMA), a Mt. Laurel, N.J.–based nonprofit professional association. "Instead of assuming that your riveting equipment is operating too slowly, if you step back and say, ‘The real issue is that my cost of manufacturing the product is too high,' you enable other possible alternatives to solving the problem—for example, redesigning the process so that the product requires fewer rivets."
Build the community
"Many organizations develop the plan to do the project and hope to build the community around it," Gill says. But complex projects often require input from key stakeholders before you can reach a robust understanding of the nature and scope of what needs to be done. "That's why you first want to build the community to develop the plan before you can do the project."
The goal here is to achieve what Schmaltz calls coherence: Making the perspectives of different stakeholders converge into a collectively meaningful understanding of the problem.
Ask people in a variety of groups likely to be affected by your project to help you explore the opportunity space, advises Peter Koen, a professor at the Howe School of Technology Management at the Stevens Institute of Technology (Hoboken, N.J.). "Asking up-front the questions about the unmet needs and the value of what you're doing can help prevent unsatisfactory results down the road—for example, bringing out products to a mature and declining market."
Other questions to ask: What do you think the issue is here? What's at stake? What resources do we need and where can we find them? Who else should I talk to? As you invite others into the work of defining the problem, you soon realize that the community affected by your project is much larger than you originally imagined. It also shifts over time, points out Chuck Kolstad, CEO of the Campbell, Calif.-based Antara, a high-tech firm that makes network-stressing appliances. "Stakeholders who have only informational input into the early phases of the project may wield decision-making power later on."
You can't treat everyone in the project community equally, but you do need to identify the key stakeholders at each stage of the project and include them at the appropriate time. Here's where your recruitment skills come into play: As you share your developing vision for the project with a colleague whose assistance you'll need, ask her what's in it for her. Help her find her project within yours.
Assuming a typical complex project, which lasts less than a year, "the week or two you spend at the outset just having conversations with people is far from useless, despite its appearance," says Schmaltz. When plans slip or new requirements get unexpectedly added on, as they invariably do, the relationships you've built during this initial phase will prove invaluable, he continues. "They constitute a benevolent conspiracy of people committed to figuring out how to make the project work anyway."
Work backward
Research about cognitive bias has shown that decision makers are often unduly influenced by their starting points—how their thoughts about a topic are initially framed. Once you've defined the problem, don't focus on the current process or product you want to improve. Instead, says Jim Goughenhour, vice president of information technology at Sealy (Trinity, N.C.), "imagine what the ideal end state would look like, then work back to put in as much of it as you can given the time, budget, and political realities."
The traditional approach to one of the projects Goughenhour oversees—creating a consistent sales reporting system—would have been to revisit the purpose of all the existing reports used by sales and marketing people throughout the company and explore ways of combining them. "If we'd done that, we'd have spent most of our money making minor improvements that didn't come close to the ideal," he says.
Aggressively manage expectations
The general plan that you produce by the end of the project's initial phase helps you manage expectations within the project community and the company at large. "It should describe the following for the overall project: key deliverables, critical milestones, the technology deployment plan (including specifications and requirements), the major risks you foresee and how you plan to mitigate them, how you plan to handle change control, and the estimated costs," says Kent Crawford, president of the Philadelphia-based consulting firm PM Solutions. "It should also include a detailed description of the next phase."
But your biggest expectations-management task concerns the project champion—the person three or four levels above you who insists that the project be completed in four weeks. Remember your "sacred responsibility to disappoint," says Schmaltz. That unsettling hunch you've got, now that the fuzzy front-end conversations are winding down, that the project will take much longer than originally foreseen and will cost a lot more, too?
"Only by disappointing the project champion with this news in the beginning can you delight him in the end," Schmaltz says. "Otherwise you end up being a slave to his unrealistic expectations, and instead of guaranteeing success, you're almost certain to produce failure."
