HBR Guide to Project Management (HBR Guide Series)

Harvard Business Review

• Publisher: Harvard Business Review Press
• Year: 2013
• Print ISBN: 9781422187296
• eBook ISBN: 9781422187319
• Topic: Personal Development
• Subtopic: Personal Success

MEET YOUR GOALS—ON TIME AND ON BUDGET.

How do you rein in the scope of your project when you've got a group of demanding stakeholders breathing down your neck? And map out a schedule everyone can stick to? And motivate team members who have competing demands on their time and attention?

Whether you're managing your first project or just tired of improvising, this guide will give you the tools and confidence you need to define smart goals, meet them, and capture lessons learned so future projects go even more smoothly.

The HBR Guide to Project Management will help you:

• Build a strong, focused team
• Break major objectives into manageable tasks
• Create a schedule that keeps all the moving parts under control
• Monitor progress toward your goals
• Manage stakeholders' expectations
• Wrap up your project and gauge its success

Phase 1

Planning

Chapter 3

A Written Charter

Every project should have a charter that spells out the nature and scope of the work and management’s expectations for results. A charter is a concise written document containing some or all of the following:

• Name of the project’s sponsor
• Project’s benefits to the organization
• Brief description of the objectives
• Expected time frame
• Budget and resources available
• Project manager’s authority
• Sponsor’s signature

Creating a charter forces senior managers to clearly articulate what the project should do. Consider this example:

Phil was the sponsor of his company’s effort to reengineer its order fulfillment and customer service operations. As an outspoken critic of these functions, he was the right person for the job. He had long been dissatisfied with the time it took to fill orders and with the company’s mediocre customer service, and he thought the costs of these operations were too high. So he put Lila in charge of a project to improve them.

What sorts of cost cutting was Phil anticipating? What exactly were his complaints about the current system? What would success look like? Lila attempted to pin down Phil on those questions, but without success. He was too busy to think it all through and too eager to delegate responsibility for the project’s outcome. Other company executives were also anxious to see improvements but, like Phil, had no clear ideas about the outcomes they wanted. So when Lila quizzed senior managers about the subject, they cited no specific goals. Lacking guidance, Lila and her team members developed their own goals and criteria for success.

The team pushed forward, and Lila reported progress to Phil over the course of the 10-month effort. Resources were always a problem, particularly since Lila was never sure how much money she could spend and how many people she could add to the team at key stages. Every request for resources had to be negotiated on a case-by-case basis with Phil.

The team eventually completed its tasks, meeting all of its self-declared goals. It had cut order-fulfillment time by one-third and the overall costs of fulfillment and customer service by 12%. And 90% of customers could now get all their issues resolved with a single phone call. The team celebrated with a splendid dinner, and members went back to their regular duties.

Senior management, however, was not entirely pleased with the outcome. “You did a pretty good job,” Phil told Lila. “The improvements you’ve made are significant, but we were looking for a more sweeping reorganization and larger cost savings.” Lila was stunned and more than slightly angry. “If he wanted these things,” she thought, “why didn’t he say so?”

Situations like this are common but can be avoided with a charter that clarifies the project’s objectives, time frame, and scope.

Objectives

As Lila’s case demonstrates, project managers need more than a broad-brush description of the objectives for which they will be responsible. Ambiguous goals can lead to misunderstandings, disappointment, and expensive rework.

Take, for instance, the following statement: “Develop a website that’s capable of providing fast, accurate product information and fulfillment to our customers in a cost-effective way.” What exactly does that mean? What is “fast”? How should accuracy be defined? Is one error in 1,000 transactions acceptable? One in 10,000? To what degree must the site be cost-effective? Each of those questions should be answered in consultation with the project’s sponsor and key stakeholders.

A thoughtful charter specifies the ends, but the means should be left to the project manager and team members. Telling the team what it should do and how to do it would undermine the benefits of having recruited a competent group. As J. Richard Hackman writes in Leading Teams: “When ends are specified but means are not, team members are able to—indeed, are implicitly encouraged to—draw on their full complement of knowledge, skill, and experience in devising and executing a way of operating that is well tuned to the team’s purpose and circumstances.”

Time Frame

In addition to setting specific, measurable objectives, you’ll need to establish a time frame for achieving them. The project cannot be open-ended. In some cases, the deadline must be firm, and the scope becomes variable. Suppose a software company promises to deliver a new release every three months. The project team must make adjustments to the scope of its new releases—adding or dropping product features—to meet each deadline.

By contrast, if the project’s scope is fixed, then a logical deadline can be established only after the project manager and team break down the objectives into sets of tasks and estimate the duration of each task. Nevertheless, the charter should contain a reasonable deadline— one that can be amended as the project team learns more about what it must do.

Scope

Of course, options are always more plentiful than time and resources. One useful technique for making the right choices is to have key stakeholders and project participants join in a brainstorming exercise to define what should be within scope and what should not.

Think of the sponsor’s expectations (the ends to be sought) as part one of the charter and the project plan (the means) as part two. The project manager typically creates the plan, but it’s important to get the sponsor’s approval on it so you don’t run into the same problems Lila faced with Phil. Ideally, it represents the best ideas from many or all team members. It’s especially valuable for large, complex endeavors because it provides details about tasks, deliverables, risks, and timetables. It serves as a road map for the team.

---

Adapted from Harvard Business Essentials: Managing Projects Large and Small (product #6211BC), Harvard Business Review Press, 2004

Chapter 4

Dealing with a Project’s “Fuzzy Front End”

by Loren Gary

Project management used to be about driving out uncertainty. You nailed down all the deliverables at the outset and fine-tuned your specs so implementation could be as routine as possible. Sure, there were always a few surprises, but overall you had a pretty good idea of what to expect. In many of today’s complex projects, however— whether they involve new-product development, IT installation, or internal process improvement—uncertainty simply can’t be eliminated.

If you were retooling a shoe company’s manufacturing plant, says David Schmaltz, a Washington-based project management consultant, “perhaps only 10% of the work would be devoted to building the new production line, but 50% would have to do with the uncertainty surrounding which shoe style will sell best in the next quarter. . . . 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.”

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 end results. So it’s important to tread carefully. Resist the urge to dive right into implementation. “Defining the problem first gives you greater degrees of freedom in solving it,” says Bob Gill, president of the Product Development and Management Association, a New Jersey-based nonprofit. “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 Your Community Early

You’ll need input from key stakeholders before you can reach a robust understanding of the nature and scope of what needs to be done. Ask people in various groups likely to be affected by your project to help explore the opportunities, advises Peter Koen, a professor at the Stevens Institute of Technology, also in New Jersey. “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.”

As you invite others into the work of defining the problem, you’ll soon realize that your project’s community is much larger than you originally imagined. And it will shift over time, points out Chuck Kolstad, CEO of Antara, a high-tech firm in California. “Stakeholders who have only informational input into the early phases of the project may wield decision-making power later on.” If you make it clear in those early days that you value their insights and will incorporate them, your stakeholders will be much more inclined to give you the buy-in you need. 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 are added, he continues, the relationships you’ve built during this initial phase will “constitute a benevolent conspiracy of people committed to figuring out how to make the project work.”

Work Backward

Research about cognitive bias has shown that decision makers are unduly influenced by how they initially frame their thoughts about a topic. Once you’ve defined the problem, don’t focus yet on the current process or product you want to improve. Instead, says Jim Goughenhour, vice president of information technology at Sealy, “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,” he says, “we’d have spent most of our money making minor improvements that didn’t come close to the ideal.”

Be the Voice of Reason

By the end of the project’s initial phase, you’ll produce a general plan that sets expectations within the project community and the company at large. That’s certainly no small task, but it can be an even bigger challenge to manage the expectations of your sponsor—the project champion three or four levels above you who insists that the work be completed in four weeks.

Remember your “sacred responsibility to disappoint,” says Schmaltz. You know that unsettling hunch you’ve got, now that the fuzzy-front-end conversations are winding down, that the project will take much longer than expected 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.”

____________

Loren Gary was the editor of Harvard Management Update.

---

Adapted from Harvard Management Update (product #U0306C), June 2003

Chapter 5

Performing a Project Premortem

by Gary Klein

Projects fail at a spectacular rate. One reason is that too many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up, you can improve a project’s chances of success.

Research conducted in 1989 by Deborah J. Mitchell, of the Wharton School; Jay Russo, of Cornell; and Nancy Pennington, of the University of Colorado, found that prospective hindsight—imagining that an event has already occurred—increases the ability to correctly identify reasons for future outcomes b...

Table of contents

• Cover
• Harvard Business Review Guides
• Title Page
• Copyright
• What You'll Learn
• Table of Contents
• Overview
• Phase 1: Planning
• Phase 2: Build-up
• Phase 3: Implementation
• Phase 4: Closeout
• Glossary
• Index
• More Books from Harvard Business Review