Successful Project Management - Milton D. Rosenau - ebook

Successful Project Management ebook

Milton D. Rosenau

0,0
399,99 zł

Opis

The Fourth Edition of this internationally bestseller details the quick and easy way to master the basics of project management. Using a lively, conversational style, project management gurus Mickey Rosenau and Gregory Githens equip readers with fundamental principles and "tested-in-the-trenches" techniques for managing projects in any type of organization. They arm readers with easy-to-use tools for resolving any technical, mechanical, or personnel problem that may arise over the course of a project and break project management down into twenty-two chronological steps. Extensively revised and updated, this Fourth Edition examines the role of integration in project planning, risk-and-issues management, virtual teams, new theories, project management offices, and more! Successful Project Management, Fourth Edition is an ideal primer for students and an indispensable quick reference for experienced professionals.

Ebooka przeczytasz w aplikacjach Legimi na:

Androidzie
iOS
czytnikach certyfikowanych
przez Legimi
Windows
10
Windows
Phone

Liczba stron: 527




Table of Contents

Cover

Title page

Copyright page

Preface

WHO THIS BOOK IS FOR

THIS BOOK’S APPROACH TO PROJECT MANAGEMENT

CHANGES IN THIS FOURTH EDITION

PROJECT MANAGEMENT AS A DISCIPLINE

About the Authors

1 Projects, Project Management, and Program Management

PROJECTS ARE A TYPE OF WORK

PROJECTS DISTINGUISHED FROM TASKS AND FROM PROCESSES

PROGRAMS ARE COLLECTIONS OF PROJECTS

PROJECT MANAGEMENT MATURITY

INTEGRATED PROJECT MANAGEMENT

THE PROJECT MANAGEMENT “HAT” IS DIFFERENT FROM THE TECHNICAL OR PRODUCT MANAGEMENT “HAT”

EFFECTIVE PROJECT MANAGERS MANAGE EXPECTATIONS OF STAKEHOLDERS

A ROADMAP OF FIVE IMPORTANT PROGRAM MANAGEMENT FUNCTIONS

HIGHLIGHTS

Part 1: Defining the Goals of a Project

2 Linking the Project to the Product

STRATEGIC ALIGNMENT OF PROJECTS

THE PROJECT LIFE CYCLE AND THE PRODUCT LIFE CYCLE

PROJECT COMPLETION INCLUDES DELIVERING A RESULT THAT MEETS THE REQUIREMENTS

THE DELIVERING ORGANIZATION AND THE CONSUMING ORGANIZATION

ALL PROJECTS INVOLVE AGREEMENTS

GOOD BOUNDARIES

TAKING ACTION

HIGHLIGHTS

3 Balancing Competing Demands with the Triple Constraint

MANY WAYS TO MEASURE PROJECT PERFORMANCE

THE TRIPLE CONSTRAINT

A MODEL TO HELP EVALUATE COMPETING DEMANDS

ADJUSTING THE BASELINE FOR RISK

HOW THE TRIPLE CONSTRAINT HELPS TO EXPLAIN THREE COMMON TRADEOFFS

THE TRIPLE CONSTRAINT DURING CONTROL

OTHER EXAMPLES OF BALANCING COMPETING DEMANDS: FINANCIAL MANAGEMENT

PROJECT MANAGEMENT AS A DECISION-MAKING PROCESS

HIGHLIGHTS

4 Contracts, Negotiations, and Proposals

CONTRACTS

NEGOTIATING THE CONTRACT

PROPOSALS: A SPECIAL KIND OF PROJECT

THE PROPOSAL PROCESS

TYPICAL PROBLEMS

INTERNATIONAL PROJECTS

HIGHLIGHTS

Part 2: Planning a Project

5 Planning the Project

INTEGRATED PROJECT PLANNING

USING COMPUTER SOFTWARE DURING PROJECT PLANNING

“THE PLAN”

APPLYING PROJECT PLANS DURING EXECUTION

PROJECT PLANNING IS AN INVESTMENT, NOT AN EXPENSE

HIGHLIGHTS

6 The Work Breakdown Structure

THE WORK BREAKDOWN STRUCTURE

THE WORK PACKAGE AND THE WBS DICTIONARY

TOP-DOWN PLANNING APPROACH FOR DEVELOPING THE WBS

ORGANIZING THE WBS FOR COMPLETENESS AND CONTROL

BOTTOM-UP PLANNING APPROACH FOR DEVELOPING THE WBS

VALIDATING THE WORK SCOPE

WORK SCOPE IS FUNDAMENTAL TO PROJECT INTEGRATION

HIGHLIGHTS

7 Scheduling

OVERVIEW OF SCHEDULING FORMATS

BAR CHARTS

MILESTONES

NETWORK DIAGRAMS

THE NETWORK LOGIC DIAGRAM

WHY USE A NETWORK DIAGRAM?

COMPUTER SOFTWARE

HELPFUL HINTS

TYPICAL PROBLEMS

HIGHLIGHTS

8 Time Estimating and Compressing the Schedule

TYPES OF TIME ESTIMATES

EARLIEST AND LATEST START AND FINISH TIMES

TYPICAL PROBLEMS

HIGHLIGHTS

9 Cost Estimating and Budgeting

RESOURCE PLANNING

COST ESTIMATING

PROJECT COST SYSTEM

BUDGETING COST

COMPUTER SOFTWARE

TYPICAL PROBLEMS

HIGHLIGHTS

10 The Impact of Limited Resources

RESOURCES

COMPUTER SOFTWARE

TIME-VERSUS-COST TRADEOFF

TYPICAL PROBLEMS

HIGHLIGHTS

11 Project Risk and Issues Management

TEN STEPS FOR TEAM-BASED RISK MANAGEMENT

BUILDING A CULTURE FOR GOOD DECISION MAKING

HIGHLIGHTS

Part 3: Leading the People Who Work on a Project

12 Organizational Design for Delivering Projects

THREE ORGANIZATIONAL FORMS

OTHER ORGANIZATIONAL FORMS

THE INFORMAL ORGANIZATION

TYPICAL PROBLEMS

HIGHLIGHTS

13 Building the Project Team

CORE TEAM AND EXTENDED TEAM

STAFFING STARTS WITH PROJECT SCOPE

FORMAL PROJECT AUTHORITY

ASSIGNING PERSONNEL TO THE PROJECT

SOURCES OF PERSONNEL

COMPROMISE

CONTROL

TASK ASSIGNMENTS

THE VIRTUAL PROJECT TEAM

TURNING A GROUP INTO A TRUE TEAM

COMPUTER SOFTWARE

TYPICAL PROBLEMS

HIGHLIGHTS

14 Organizing the Support Team

INVOLVEMENT AND COMMITMENT

COORDINATION

INTERACTION WITH SUPPORT GROUPS

SUBCONTRACTORS

TYPICAL PROBLEMS

HIGHLIGHTS

15 The Role of the Project Manager

PROJECT MANAGER COMPETENCIES

PROJECT MANAGEMENT CAREER PATH

WHAT A PROJECT MANAGER DOES

THEORIES OF MOTIVATION AND THEIR IMPLICATIONS

THREE USEFUL TECHNIQUES

TYPICAL PROBLEMS

HIGHLIGHTS

16 Practical Tips for Project Managers

COMMUNICATION

CONFLICT RESOLUTION

EFFICIENT TIME MANAGEMENT

TIPS

TYPICAL PROBLEMS

HIGHLIGHTS

Part 4: Controlling the Project

17 Essentials of Project Control

DEVELOP A BASELINE

DEVELOP A PERFORMANCE MEASUREMENT SYSTEM

MEASURE PERFORMANCE AGAINST BASELINE AND DETERMINE VARIANCES

FORECASTS

CORRECTIVE ACTIONS

MULTIPLE PROJECTS

COMPUTER SOFTWARE

TYPICAL PROBLEMS

HIGHLIGHTS

18 Project Reviews

THE NECESSITY FOR REVIEWS

THE CONDUCT OF REVIEWS

PERIODIC REVIEWS

FOLLOW-UP ACTIONS

TOPICAL REVIEWS

TYPICAL PROBLEMS

HIGHLIGHTS

19 Project Cost Reports

COST MONITORING

COMPUTER COST REPORTS

COST MONITORING PROBLEMS

EARNED-VALUE MANAGEMENT

COMPUTER SOFTWARE

TYPICAL PROBLEMS

HIGHLIGHTS

20 Handling Project Changes

A PROJECT PERFORMANCE TRACK RECORD: GOOD OR BAD?

THE PROCESS OF MANAGING CHANGES

UNMANAGED RISKS AND ISSUES

TYPICAL PROBLEMS

HIGHLIGHTS

21 Solving the Inevitable Problems

THE GENERAL APPROACH

DECISION TREES

MATRIX ARRAY

PROBLEM-SOLVING STYLES

TYPICAL PROBLEMS

HIGHLIGHTS

Part 5: Completing a Project

22 Closing the Contract

WINDING DOWN THE PROJECT

ACCEPTANCE

MANAGING SCOPE CHANGE

DOCUMENTATION

INCREASING THE ODDS OF SUCCESS

TYPICAL PROBLEMS

HIGHLIGHTS

23 Final Wrap-Up

PEOPLE ISSUES

LESSONS LEARNED AND AUDITS

INTELLECTUAL PROPERTY AND OTHER OWNERSHIP RIGHTS

TYPICAL PROBLEMS

HIGHLIGHTS

Part 6: Other Issues in Project Management

24 Small Projects

SIMPLIFIED MANAGEMENT

PROBLEMS

TYPICAL PROBLEMS

HIGHLIGHTS

25 New Product Development Projects

WHY NEW PRODUCT DEVELOPMENT PROJECTS ARE UNIQUE

A GENERAL FRAMEWORK

RESOURCE OVERLOADING

TYPICAL PROBLEMS

HIGHLIGHTS

26 Project Management Software

WHEN AND WHERE TO USE COMPUTER PROJECT MANAGEMENT SOFTWARE

CAUTIONS WITH COMPUTER PROJECT MANAGEMENT SOFTWARE

OTHER SOFTWARE

TYPICAL PROBLEMS

HIGHLIGHTS

27 Where Do You Go from Here?

SUMMARY

CONTINUING PROJECT MANAGEMENT SKILL DEVELOPMENT

THE FUTURE OF PROJECT MANAGEMENT

A FINAL THOUGHT

Appendix 1 Abbreviations Used in Project Management

Appendix 2 Glossary of Project Management Terms

Appendix 3 Examples of Planning Checklists for Project Managers

Index

This book is printed on acid-free paper.

Copyright © 2005 by John Wiley & Sons, Inc. All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey. Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, e-mail: [email protected]

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. The publisher is not engaged in rendering professional services, and you should consult a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our web site at www.Wiley.com.

Library of Congress Cataloging-in-Publication Data:

Rosenau, Milton D., 1931–

Successful project management : a step-by-step approach with practical examples / Milton D. Rosenau, Gregory D. Githens.—4th ed.

p. cm.

Includes bibliographical references and index.

ISBN-13: 978-0-471-68032-1 (cloth)

ISBN-10: 0-471-68032-X (cloth)

ISBN-13: 978-1-118-27691-4 (epdf)

ISBN-13: 978-1-118-27690-7 (epub)

ISBN-13: 978-1-118-27696-9 (mobi)

1. Project management. I. Githens, Gregory D. II. Title.

HD69.P75R67 2005

658.4'04—cd22

2005005180

Preface

WHO THIS BOOK IS FOR

This book is for anyone interested in a pragmatic approach to managing projects and programs. We have found that the material is valuable as a refresher for the experienced manager and as a primer for the person who wants an introduction. The factors that lead to project success are known and knowable regardless of the industry, the size of the project, or its technology. Good project performance can be ensured with the skillful application of the processes, tools, techniques, and concepts of project management.

A natural and primary audience for this book is the person named as “project manager.” (In some cases, the label may be “project leader,” “project engineer,” or similar variants.) It is common to find individuals who have been trained in a technical skill (e.g., engineering, science, accounting, and programming) thrust into management roles with little training, coaching, or mentoring. We often will address the reader as “you” in recognition of this important audience.

Another important audience is project team members. Over the years, we have seen many situations where the project manager was well trained in the tools and principles of project management but became frustrated when he or she tried to engage the project team to help them apply the tools. Projects are a collaborative activity. This book will help team members understand their roles and responsibilities in supporting the development and execution of project plans.

In recent years, the “process view” of the enterprise has shown the value of improving performance of complex work activities. It is the job of senior management to help create the system that allows for the consistent and systematic development and delivery of projects. We wrote this book so that people with only limited time but with a need for a strategic perspective can identify the success factors for delivering projects. Thus, another important audience for this book is executive sponsors and customers as well as functional managers.

Many organizations now have adopted the concept of a project office. This book will provide important insights to those people who are organizing or operating a project management office.

THIS BOOK’S APPROACH TO PROJECT MANAGEMENT

This book is useful for any type of project, regardless of size, technology, or industry. In addition, we address portfolio management and program management of integrated collections of projects.

We organized this book to provide a simple model of the fundamentals of project management. Our straightforward approach is based on a combined 70 years of experience with new product development for consumer and industrial markets, chemical formulation, engineering, government contracts, research, management consulting, and volunteer organization projects.

This book divides the management of projects into five general managerial functions and emphasizes the importance of integration, as illustrated in Figure P-1.

1. Defining. Defining the project’s goals.

2. Planning. Planning how you and your team will satisfy the Triple Constraint (goal) of performance specification, time schedule, and money budget. The plan depends on the mix of human and physical resources to be used.

3. Leading. Providing managerial guidance to human resources, subordinates, and others (including subcontractors) that will result in their doing effective, timely work.

4. Controlling. Measuring the project work to find out how progress differs from plan in time to initiate corrective action. This often leads to replanning, which may force a goal (definition) change, with a consequent need to change resources.

5. Completing. Making sure that the job that is finally done conforms to the current definition of what was to be done, and wrapping up all the loose ends, such as documentation.

FIGURE P-1. The five activities are different but interdependent.

Although these are distinct, they are interrelated, as shown by the arrows in Figures P-2, P-3, and P-4.

FIGURE P-2. Defining, planning, and leading activities often must be considered simultaneously.

FIGURE P-3. Controlling (or monitoring) is carried out to detect deviations from planning.

FIGURE P-4. Completing depends on the current defining basis.

The first two steps are not necessarily separate and sequential, except when the project initiator issues a firm, complete, and unambiguous statement of the desired project output, in which case the organization that will carry out the project may start to plan how to achieve it. It is more common to start with a proposed work definition, which is then jointly renegotiated after preliminary planning elucidates some consequences of the initially proposed work definition. The definition must be measurable (specific, tangible, and verifiable) and attainable (in the opinion of the people who will do the work) if you want to be successful. Being successful also requires that management agrees that the project is justified and that the resources the project team needs will be available.

Thus, in fact, the resources to be dealt with in the leading phase often must be considered before planning can be finished (Figure P-2). For instance, you might need engineers familiar with carbon fibers if the plan for a materials study project includes the study of that kind of material, whereas you would use a metallurgist if the project were to study only metals.

No project goes in accordance with your plan. What you don’t know when you start is where it will go awry. Consequently, as you will see in later chapters, replanning is almost always required, thus frequently amending the negotiated definition (Figure P-3). Ultimately, the project can be completed when the work that is done satisfies the current requirement (Figure P-4).

Nevertheless, the five-step managerial activity process covers each required action and is a useful conceptual sequence in which to consider all project management. Thus, this book is organized according to it.

Each chapter is short and can be absorbed in 1 to 2 hours. The chapter sequence is a good match for the chronological concerns during a typical project. We caution you, however, that there is no single “cookbook” or template to follow. We encourage you to scan the chapter highlights and use the index.

Because projects are complex and strategic, they require an appropriately sophisticated set of managerial tools. A tool icon is inserted at points where we describe what we consider to be a particularly useful tool that you may want to use. Some of these are simple to use, and some will require practice. Perhaps a few will never be right for your management style. Because not all these tools will be useful for you in specific situations that you encounter, you will have to pick and choose which tools to use when.

We tried to use graphics and examples liberally. This book contains several illustrations of computer project management and other software outputs, most from the widely used shrink-wrap project software package Microsoft Project. We are not endorsing this product, nor are we discouraging its use. There are other widely used and effective single user and enterprise computing systems. Our goal is to explain a few of the key useful aspects of this class of software. Employing such software will not make a person a successful project manager, and using it is not the same as being a project manager. Software is a tool to help but not a solution, especially to “people” problems. Nevertheless, you can be a more effective project manager if you employ such software in situations where it will be helpful to you.

CHANGES IN THIS FOURTH EDITION

The first three editions of Successful Project Management proved the value of the book’s approach to helping readers improve project management skills. In the two decades that followed the publication of the book’s first edition, people have increasingly come to regard project management as a “profession” instead of a “job.” A short list of developments in the field of project management would include the process view, virtual teams, new theories and practices of motivation, the quality view, project management offices, and so on. Practitioners have developed and documented a recognized body of knowledge and an ability to certify individuals and to recognize organizational capability (also called maturity) in the process of project management.

Reflecting the explosion of documented project management knowledge and standards, we have made extensive changes to this fourth edition. This edition clarifies some of the previous material, brings it up to date, and eliminates some material made obsolete or irrelevant by the growing sophistication and professionalization of the project management field.

We rewrote a number of chapters to bring these up to date with contemporary concepts, standards, and practices of project management. We have incorporated and reflected the standards that groups such as the Project Management Institute (PMI) have publicized. Throughout this book, we have used standard language, enhanced and corrected the graphics, and recognized the use of enterprise computing, networks, and the World Wide Web.

Readers familiar with the earlier editions of this book will notice that there have been substantial changes to the book. Five of the first six chapters have been rewritten to better describe the role of integration in project planning. Chapter 11 on risk and issues management is also completely rewritten. Moreover, all the remaining chapters have been augmented to reflect contemporary thinking and practices in the project management field.

Greg Githens joins Mickey Rosenau as coauthor for this fourth edition of Successful Project Management. He brings a substantial background as a project management practitioner, consultant, trainer, and professional contributor to the project management field.

PROJECT MANAGEMENT AS A DISCIPLINE

It is an exciting time to be in project management. There has been an explosion of knowledge and tools for the field and increasing recognition of “good” and “bad” practices. Organizations who have embraced it are achieving outstanding results. Yet, successful project management has been and will be based on people. Project management is a discipline, a word that has its semantic roots in the ideas of teaching and learning. As an individual and organizational competency, project management discipline involves leadership from individuals who have the personal backbone to withstand the criticism of undisciplined, impatient people. It requires an organizational commitment to investing sufficient up-front time and to involving other people, recognizing that different points of view result in more creative, optimal outcomes.

Milton D. Rosenau, Jr., CMC, FIMC

Certified Management Consultant

Rosenau Consulting Company

Bellaire (Houston), Texas

[email protected]

Gregory D. Githens, PMP, NPDP

Managing Partner

Catalyst Management Consulting, LLC

Findlay, Ohio

[email protected]

About the Authors

Milton D. (“Mickey”) Rosenau, Jr., CMC, FIMC, heads Rosenau Consulting Company, which he founded in 1978 following a 21-year career with industrial and consumer products companies. He is the author of dozens of publications and nine books, including Successful Project Management (3d edition, Wiley, 1998) and Successful Product Development: Speeding from Opportunity to Profit (Wiley, 1999). He was a past president of the Product Development and Management Association (PDMA) and was editor-in-chief of the PDMA Handbook of New Product Development (Wiley, 1996).

Gregory D. Githens, PMP, NPDP, is managing partner with Catalyst Management Consulting, LLC, a management consulting firm specializing in project management and new product development. His clients have achieved improved time to market, better metrics, better strategic alignment, and improved risk management, among other benefits. Mr. Githens has been a frequent contributor to the profession, including developing professional standards, writing over 30 articles, and public speaking.

1 Projects, Project Management, and Program Management

Projects are a kind of work that is temporary, unique, and progressively elaborated. Accordingly, project management is a discipline that includes a specific body of knowledge as well as a specialized set of tools. In this chapter, we explain how project management is different from process management and ad hoc management, the nine knowledge areas—stressing the importance of integration and managing expectations— and overview five managerial functions.

Project success doesn’t just “happen”; it comes from people using commonsense tools that are suited for the special nature of projects and applied in an organizational environment that accepts discipline and rigor. To understand what makes project management “successful,” we need to start with its basic unit, which is the project. In this chapter, we will explain what a project is and isn’t and describe the foundations of project management as a discipline.

PROJECTS ARE A TYPE OF WORK

It is important to understand what a project is so that the project manager and project team can select appropriate project management tools. This section provides a basic definition of a project.

First, let’s examine some characteristics of any kind of work activity, including projects. Thus, all work, including projects:

Uses resources. For the purpose of this definition, resources include people, capital, equipment, ideas, and so forth. Whether the organization is refining oil, building a building, programming a computer, conducting a management consulting assignment, designing an instrument for a satellite, developing a new product or service, or surgically removing a cancerous tumor, a manager is responsible for the effective application of resources.Is requested or needed. Customers, and their willingness to spend their scarce money for goods and services, are the lifeblood of any organization, be it government, business, or charity. Successful organizations pay attention to customer needs to deliver goods and services that customers’ value.Has goals. Generically, management is a process of establishing goals and directing resources to meet those goals.

These three factors are descriptive of projects but are not sufficient to distinguish a project from a nonproject. The accepted definition of a project is that it is a temporary work effort that produces a unique result. Let’s look at each of the three characteristics that distinguish projects from other kinds of work:

Projects are temporary. Temporary means that there is a beginning and end to the project. Projects start when the sponsoring organization authorizes the project, and projects end when the project meets the requirements. All well-managed projects must come to an end! For example, the project of constructing a major downtown hotel would take one or two years to complete, but the project would complete the work.Projects are unique. Unique means that the work product or processes that create it are novel or different. Even though a second software project to write an accounts payable system is very similar to the first such project, there will be some differences, perhaps something as simple as the format of reports. The same is true of digging two ditches (the purpose or terrain may vary) or organizing two conventions (the sites or programs may differ), and so on. For example, while hotels may have similar layouts (“footprints”), the people and materials involved in the construction are different for each hotel.Projects are progressively elaborated. This means that a project proceeds in steps or stages. Most well-managed projects use a phased approach, where the project defines the phases according to its control needs. For example, real estate developers often acquire land speculatively and then put together deals to construct hotels, restaurants, and convention centers according to the needs of the local market. We will describe more on the project life cycle phase in Chapter 5 and later chapters.

A project is a temporary work effort that produces a unique result.

Now let us see how a typical organization might use this definition of projects as temporary, unique, and progressively elaborated to identify work activities that would best benefit from the project management tool set. Figure 1-1 shows three types of work that might take place in an organization. The first and third columns are straightforward. To define what something is, it is helpful to define what it isn’t. Let us look at the column headed, “Might Be a Project.” The “Might Be” column is important in addressing a common complaint about project management, which is project management is bureaucratic, involves many meetings, and so forth. The difference (and need for sophisticated project management) arises from the need to manage across interfaces and deal with complexity.

FIGURE 1-1. Identifying a project, nonproject, and possible project.

Why should you care about distinguishing projects versus nonprojects? Not everything individuals or organizations do is a project, but some things are a project. The things that are projects are typically not the day-to-day work of people but have to do with creating a new outcome. Projects are strategic! Because projects are complex and strategic, they require a particular and sophisticated set of managerial tools.

Not everything individuals or organizations do is a project, but some things are a project

While the term project refers to work activities, people also commonly use the term to refer to organizations of resources. Hence, projects perform work: After initiating the project, they “plan their work and work their plan,” make changes as necessary, and close out the project.

Contemporary thinking identifies projects as essential components of enterprise strategy. Projects are one important kind of organizational work because they create change. Because projects create change, good organizations explicitly align their projects with the investment policies and intention of management. We explore the selection and definition of projects further in the next and subsequent chapter.

PROJECTS DISTINGUISHED FROM TASKS AND FROM PROCESSES

It is important to distinguish projects from other kinds of work. A project is more complex than a task and more unique than a process. There are not clear-cut distinctions, and each individual and organization will develop and apply judgment on where and how to clarify the differences.

Projects are different for other work activities and require different tools.

Projects are more complex than tasks. For an individual, going to work on some mornings might seem to be a major undertaking. It is something that the individual must do in order to maintain employment, it requires resources, and it has a goal. The individual needs to apply some forethought to identify the best route considering the risks involved. He or she could even create a “to do” checklist for the undertaking to help him or her remember all the steps.

However, from the perspective of an enterprise, an individual’s commute to work is a task and not a project. It does not involve the coordination of people (although organizing a car pool could be an exception), does not require capital investment, and does not benefit from managerial oversight. In most organizations, a task is something that an individual can accomplish by himself or herself in a few hours or a few days of time.

While both projects and tasks have an end-state goal and use resources, there is little value in developing a project management approach for the task of going to work. We think it is important to include in the definition of a project—at least for purposes of this book—those endeavors where project management tools add value. There is no sense in adding the sophistication of project management tools for work that simply does not require sophistication.

We want to stress that project management is not managing your “to do” list. In Chapter 6, we again turn to the discussion of tasks but examine them as the activities that the project organizes into a work breakdown structure.

Some organizations fail to recognize the distinction between tasks and projects. An ad hoc approach is suitable for a task but not for a project. In these organizations, a mixture of effort and luck drives performance. Organizations get inconsistent results from their projects and tend to attribute the result (good or bad) to the individual. In the past 10 years, however, there has been a growing movement within the project management profession to measure and develop “project management maturity” systematically at the enterprise level. It is now much easier to identify the causes and consequences of successful project management.

Considerable progress has been made in identifying the factors that lead to successful project management.

Now let’s examine how projects differ from processes. Processes have three components: inputs, transformations, and outputs. From an organizational standpoint, processes are mostly repetitive and produce common outputs. Projects are different from processes because they have less consistency in inputs, transformations, and outputs. For example, if the individual’s project is to build an amplifier circuit, at some point, building a second, third, or fourth amplifier circuit ceases to be a project and becomes a repetitive activity. If each amplifier is virtually identical, we have a production line; thus we are managing a process, not a project. The lesson here is that the individual should determine if the requestor’s requirement is to build a single amplifier, or to build a batch of amplifiers, to build an amplifier production line. Often, the individual performs unwanted or unbudgeted work, a phenomenon known in the project management community as scope creep.

Refer back to the right-hand column of Figure 1-1. Other examples of processes are manufacturing, payroll processing, and building maintenance. Process management focuses on standardization, particularly of the output. To achieve consistent, high-quality, standardized outputs, process management places requirements on the inputs (the raw materials) and the production that transforms the inputs to the outputs. High-volume, high-quality output is typically a goal of process management.

The disciplines of “process management” and “project management” differ in goals and metrics. In process management, goals and metrics are set up to eliminate variation within the process because variation is wasteful. A new product development example is instructive on this point. If a person is purchasing an automobile, he or she assumes that any car that he or she purchases will be consistent with other like models and will meet the advertised performance specifications. Managers design the manufacturing process to eliminate variation in order to produce automobiles of an expected, consistent quality. Henry Ford’s famous quotation about the Model T, that “a customer can have any color that they want as long as it is black,” is an extreme example of the efficiency mind-set. On the other hand, customers desire variety and have requirements for an automobile with features and functionality that make it distinctive, for example, new and different colors. Ford’s competitors were able to create distinctiveness that the customer valued and gained market share in part because of Ford’s rigidity in the use of process management and metrics.

Thus, projects allow organizations to give customers new and value-added choices. In this sense, variation is good, because customer-perceived value is a source of competitive advantage.

In recent years, the project management literature has contained considerable discussion of the process view of project management. Projects do involve repeatable activities such as capturing requirements, building teams, and publishing reports, but the processes are not high-volume, long-term production lines. Except for very large aerospace and construction projects, projects seldom perform high-volume work activities. More typically, projects use process management to develop routines so that people can manage frustrations or focus on creative tasks. For example, project status meetings are a repetitive activity within projects. Project status meetings can benefit from standardizing on agendas, goals, time, and so forth. Then the project effort can focus on creating unique and sometimes first-of-a-kind items.

Finally, don’t confuse a procedure with a process. A procedure is a job instruction for accomplishing an operation. For example, in a chemical processing plant, there are standard “lock-out, tag-out” rules for shutting off equipment or entering a confined space. Technical and process-oriented organizations have volumes and volumes of procedures for people to follow. Some people often use the term methodology to describe a system of procedures. These procedures are necessary because of the following:

There is a considerable amount of detail that a person must remember.The operation must be performed in a specific sequence.Failing to complete all steps in the proper sequence could cost lives or significant money. In some cases procedures are subject to government regulation and oversight, for instance, in the development and manufacture of a new drug or medical device.

It follows naturally that organizations would want to exert some similar types of control over the initiation, planning, execution, controlling, and closing processes of their projects.

However, these attempts to control projects through procedural control seldom work as well as the designers of the control process desire. Once the documents are written, organizations place them in a library to indoctrinate people in the procedures. However, in practice, people do not pay attention to the procedures and soon start ignoring them. When people deviate from the rules (often for a very good reason), the “methodologist” typically writes a new rule. This expansion of “methodology” can grow to a multi-volume set that people view with cynicism. For example, one organization developed a binder of procedures for new product development activities that was so thick and heavy that people developed the slang name “Thud Document” because of the “thud” sound the book made when a person dropped it on a table.

Attempts to control projects through procedural control seldom work as well as the designers of the control process desire.

Here are a few commonsense observations about the difference between a process and a procedure:

Projects have many unique facets, so many of the procedures do not apply or only apply partially.Projects are more complex than tasks, so projects require knowledge of many things.People have limited capacity to absorb abstract information.People are under pressure to get to work and deliver visible results quickly.

The best organizations avoid a rigid set of step-by-step procedures for project management. Instead, the best organizations educate all stakeholders on the principles and allow for discretion and common sense. To be sure, templates and checklists are helpful job aids for the novice; just don’t become a slave to your tools.

Project management is fundamentally a commonsense approach that depends on the good judgment of people.

PROGRAMS ARE COLLECTIONS OF PROJECTS

A program is a collection of projects grouped together to get advantage from their combined management. For example, the trans-Alaska pipeline and the manned lunar landing projects required many years and billions of dollars. The overall success of such programs depends on hundreds or thousands of projects. Programs usually are larger than projects and are collections of projects that come to an end when the sponsoring organization makes a determination to end the program and when the projects that make up the program are completed.

A program is a collection of projects grouped together to get advantage from their combined management.

Better organizations make a distinction between program and project and between program management and project management. These are not interchangeable terms.

The reader should have some awareness of a phrase related to program management that is a set of practices for understanding the relationship of projects to an organization’s strategies: project portfolio management. People and organizations use this phrase to portray projects as assets invested by the organization to achieve its goals. Project portfolio management includes concepts such as the following:

Setting priorities across all projectsAllocating resources across all projects, including project managers and project participantsProject selection and deletionUnderstanding that projects are different and require different approaches (For example, there are capital equipment projects, innovation projects, regulatory compliance projects, system support projects, and so forth.)

If you work for a large organization, you should find out if your organization has a project or project management office and consult with its leaders to understand how your own organization defines projects, programs, and portfolios. In addition, find out what kinds of job aids, training, coaching, and support are available to project managers and project participants.

PROJECT MANAGEMENT MATURITY

Humankind has performed and managed projects since the earliest of times. People have looked on the artifacts of projects—both from earlier civilizations and from contemporary periods—with amazement. Was “project management” used to create these wonders? In a sense, yes. History shows that people used many advanced insights in their planning and logistical practices. Still, we can’t help but visualize a brutal taskmaster with a whip standing over cowering laborers and know that this type of coercive power would be an inappropriate “people skill” in today’s organizations.

In the three decades that followed World War II, organizations found significant economies of scale and centralized massive “mainframe” computation capabilities, leading to the development of sophisticated techniques for task scheduling, estimating, and resource management. The “project manager” often was the only person with the training and desire to use this system, which unfortunately caused many people to regard the project manager as the “schedule mechanic.” The use of information technology continues to be important to project management because it has changed and even eliminated many of the middle management roles. Organizations have decentralized steadily and have become more networked. Now, any person with access rights can view and update the project documentation instead of waiting for a directive from their manager. Information technologies have allowed all project team members to multitask and contribute to a number of work activities in a number of different ways. This decentralization has led to more empowerment and more accountability for results at the individual and team level of the project. The project manager is the person we look to help the team achieve the results.

The project manager is not the schedule mechanic.

In recent years, it has been popular to say that project management is the “accidental profession,” but that is changing. Most project managers did not start their careers as project managers. Most people get exposure to projects early in their careers as technical contributors, and gravitate (or are pushed) into taking on a more systematic view of projects. As they gain experience with projects, individuals often decide that the project management career path is more to their liking than the technical path.

Now, in the twenty-first century, there is a solid and global recognition of the importance of project management as an explicit organizational activity with best practices and skills. One source of support for this statement is standards developed and publicized by such groups as the Project Management Institute (PMI). Through PMI and other similar organizations, people increasingly have developed and documented a recognized body of knowledge and an ability to certify individuals and to recognize organizational capability (also called maturity) in the process of project management. At the university level, there is a growing understanding and dissemination of the principles and practices that make for successful project management.

Project management is the application of knowledge, tools, and techniques to an individual project. People also commonly use the term to respond to the enterprise’s capacity and capability to deliver projects.

What does this mean to the various project stakeholders? First, individuals should give serious thought to expanding their knowledge of the profession beyond what we describe in this text. Second, individuals should consider including a stint in project management in their career path, especially if they aspire to top management positions in their organizations. Third, project management is not simply a cadre of competent project managers. Successful project management is also a result of a systematic organization-wide capability. Many leading organizations have and are investing significant resources to ensure that they manage projects well.

Thus, the contemporary view of project management is that it is larger than a “tool” that individuals use. Project management is a discipline: There is an active and growing cadre of people researching and documenting the practices and issues associated with the success of projects.

INTEGRATED PROJECT MANAGEMENT

This section describes a contemporary and systematic view of project management. There are many published global bodies of knowledge. This book will adopt the model published by the Project Management Institute (PMI) in its reference, A Guide to the Project Management Body of Knowledge.

The project management profession recognizes nine areas of project management knowledge. Review Figure 1-2, which shows the nine elements of project management, noting that the center of the diagram is integration, which will be our starting point. One of the key points to remember in this book is this: Project management is primarily an integrative activity. Here are some reasons for making this claim:

FIGURE 1-2. Integrated project management.

Integration is a process of synthesizing different concepts into a unified whole.

Most product failure is at the interface of subsystems, and individual contributors typically do not pay attention to interfaces until after they have completed most of their work on their assigned piece of the system.Time and again, the biggest complaint of people in projects is poor communications.Senior managers expect project managers to manage their projects as if they were a business, taking a strategic and holistic perspective on the project.

Within a project, there are three integrative processes (listed below). When managing a single project, the team performs integration with respect to the other knowledge areas. This includes the following:

Developing the project plan. Integrating the requirements that comprise the product scope with the activities that comprise the work scope while establishing plans for cost, time, quality, risk, communications, human resources, and procurement.Executing the project plan. Now that the project has “planned its work,” it is now time to “work its plan,” and the execution must be systematic.Managing the changes to the plan. All projects encounter changes that are different from the assumptions on which the plan was based. This change needs to be managed, and in an integrated way.

Of course, there are integration needs: the product into the established systems and the project with other work in the organization. We will touch on this type of integration thoughout this book.

We hope that we have convinced you that project integration is significant. Recall that many people enter project management “accidentally.” Experience shows that most of these new entrants tend to stay in their comfort zone. These three assertions are fundamental to Successful Project Management:

Integration is at the heart of project management and distinguishes the excellent project manager from the mediocre one.Integration expertise is as important as technical expertise.Integration adds value to the customer.

The discussion of the nine knowledge areas is a useful foundation for understanding the vital concept of successful project management: balancing competing demands. We will describe the concept of balancing competing demands in Chapter 2 and elsewhere in this book. The paragraphs that follow describe each of the remaining eight knowledge areas in more detail.

Project Scope Management

In project management, project managers use the word scope to indicate that there is a boundary where things are “in scope” and “out of scope.” There are three kinds of scope, as we describe in the following paragraphs.

The problem scope is the definition of the problem or opportunity, often called requirements. Many frustrations that project managers and participants face originate with poor requirements, suggesting that many organizations need to improve the ways they set boundaries over what is “in” and “out” of the problem scope. We will take up this challenge in Chapter 3.

The product scope includes the features and functionality of the product of the project. The product scope is the “solution” that satisfies the customer’s needs, wants, and requirements. In Chapter 3, we will discuss how product requirements set the boundaries for the design of the product scope.

Product is synonymous with result, so don’t assume that the term product means a tangible item. The term product means any result—tangible or intangible— delivered by the project to the user. Here are three examples: The result of a research and development (R&D) project into the cellular behavior of Alzheimer’s disease is new scientific knowledge, the result of a project to change hospital visiting hours is better patient and visitor satisfaction, and the result of a project to educate people on cancer prevention is the increased appearance of healthy behaviors.

Project scope and work scope are terms describing the work that creates the product that satisfies the requirements. As we will explore further later, the “project is the work that creates the product of the project.” Project managers manage work. Completion of the product scope is measured against the requirements, whereas completion of the project scope is measured against the plan. In Chapter 6, we will describe how the work breakdown structure (WBS) is the measurement tool for project scope.

Project scope management is concerned primarily with defining and controlling the work that “is” or “is not” performed. Because scope is an ambiguous concept, we recommend using a modifier in front of the word scope: Be clear whether you are talking about problem scope, product scope, or work scope.

Project Time Management

Time is a very visible project dimension. Time is easy to understand (as evidence of its ease, people learn how to read a calendar at an early age), customers are demanding, and people are impatient. Hence, projects must make skilled use of the tools and techniques that generate a project time schedule. The techniques and skills of project time management include defining the work activities, sequencing the activities, estimating the duration of the activities, and integrating these into a time schedule. During execution, the project needs to manage work to the schedule and make appropriate changes.

In the ideal world, the customer and sponsor define the problem scope and the product scope before asking for a schedule. Unfortunately, the more common experience is that dates for project completion are set before the individuals participating in the project understand the problem and product scope. We elaborate on this in Chapter 25, especially in Figures 25-6 through 25-9. Sometimes people view the job of the project manager as being the “schedule mechanic,” but this is a too-narrow role that does not ensure that projects are successful. Good project managers manage time expectations well but in balance with other performance parameters.

Project Cost Management

Projects typically measure cost in terms of some unit of currency, but it is important to remember that the currency is just a metric for some kind of underlying resource. For example, an individual’s time is a resource, and it has value. Project cost management thus has to do with estimating, valuing, and managing resources.

In this knowledge area, projects need to develop and manage two related processes: cost estimating and budgeting. Cost estimating includes planning the resources needed to accomplish the project work scope, pricing the resources, and generating a total project price (or cost). The project budgeting process is different from the estimate. The budget is the baseline plan for the cost, by which the project will measure its progress and its variances. Of course, as the project work scope changes, the budget may change, and the project manager needs to manage this change.

Project Quality Management

Like the definition of project scope, the definition of project quality is ambiguous. Consider that there are at least four ways that people judge quality, and people feel passionately that they have the “right” definition of quality:

Satisfaction of product requirementsConformance to standards and policyAbsence of product defectsDelighting the customer

Thus, one of the important activities that take place in a project is defining quality for the product and for the project. Generally, it is best to define quality in terms of the customers’ needs (both expressed and unexpressed). The project manager leads the project quality effort through quality planning, quality control, quality assurance, and quality improvement. Some projects have elaborate quality systems in place to ensure quality, whereas others are less formalized.

Project Human Resources Management

Projects involve people, and the techniques and skill applied to leading and managing people significantly affect the project’s performance. Project human resource management involves a number of activities, including organizational planning, staff acquisition, and team development.

Good project managers make effective use of the people involved with the project and treat them as important stakeholders. One measure of project success is that participants feel like their involvement was a worthwhile experience.

Project Communication Management

The intent is the proper generation, collection, dissemination, storage, and ultimate disposition of information. It provides the critical linking of people, ideas, and information that is necessary for success. Different project stakeholders have different communication needs.

The component processes of project communications management are communications planning, information distribution, progress reporting, and administrative closure.

Project Risk Management

As we wrote in the first line of this chapter, successful projects don’t just happen. Regrettably, poor project performance occurs frequently. Risk management is at the heart of successful project management and deserves considerable attention. Project risk management includes identifying, analyzing, and responding to project risk. Risk-response planning includes defensive actions such as risk avoidance, risk mitigation, risk transfer, and risk acceptance (which includes the passive response of “dealing with it when it happens” and active acceptance—the use of contingency planning).

Often practitioners include issues management as an associate practice of risk management. We will cover both risk and issues management in Chapter 11.

Project Procurement Management

One of the most pronounced current trends in project management is the use of contractors, vendors, and partners to accomplish significant pieces of a project’s work. Project procurement management is concerned with the processes for acquiring goods and services from outside the performing organization. A good project needs to pay attention to procurement planning, solicitation planning, source selection, contract administration, and contract closeout.

THE PROJECT MANAGEMENT “HAT” IS DIFFERENT FROM THE TECHNICAL OR PRODUCT MANAGEMENT “HAT”

In the preceding paragraphs, we described the importance of project integration and the knowledge areas that comprise project management. We hope you are recognizing that the knowledge and skills of project management cover a broad area and that there is much to know. Start with this simple principle: The roles needed for project management work are different from the roles needed for technical work.

Most experienced project people agree with this statement: “The best technical people seldom make the best project managers.” Why? For some, managing people is the most difficult aspect of managing a project, especially for recently appointed managers whose academic training is primarily in a technical discipline such as engineering, computer science, or even construction management. Such people tend to be more comfortable with things and numbers than with people.

Project management is not technical work. There is a significant difference between product-oriented work and project-oriented work. Product-oriented work involves applying technical or “domain-specific” knowledge to creating a product. For example, the knowledge necessary to create computer code, design a circuit board, dig a foundation, or create a graphic is product-oriented knowledge.

Project-oriented knowledge involves the nine previously described knowledge areas. Project management is an integrative activity. Good project managers avoid the expert’s propensity to concentrate on the technical or quantitative aspects (e.g., engineering analyses or task budgets)—and instead become more oriented toward making things happen through people.

The project is “hat” is different from the technical “hat.”

* Most project managers must provide both technical expertise and integration expertise. They need to perform the project in order to develop the product! Here is a tip that has helped many technically trained project managers. At any given time, stop and ask yourself: What hat am I now wearing? The project manager hat? The technical hat? Some other hat? People find that if they can identify the role they are playing at any particular time, they can select the appropriate behaviors for that role.

EFFECTIVE PROJECT MANAGERS MANAGE EXPECTATIONS OF STAKEHOLDERS

Projects involve multiple organizations, for example, different departments on a cross-functional new product development team, different businesses on a shopping mall joint venture, or even public-private partnerships for a charity fund drive. Each of these organizations has multiple goals, functions, and missions at any given moment if for no other reason than that each is composed of many individuals with varied skills, interests, personalities, and values.

A stakeholder is a person or organization that has an interest in a project or the outcome of a project. Figure 1-3 illustrates the project manager at the center of a web of stakeholders. Each stakeholder has differing values, missions, and aspirations that become the foundation for different expectations about the definition of project success. Experience shows that each stakeholder will evaluate the project’s performance independently. For example, a company decides to fully absorb an operating division that previously was independent in order to gain efficiencies of scale in operations. Economic, political, and social forces may be external to the company, too, such as industry restructuring to “outsource” organizational functions (e.g., operating a help desk) to a specialized firm. Individuals (you as project manager, your boss, others) are affected by changes in tax rates and laws that may be altered during a project. If your country (or the country in which a key project participant is located) declares war on another nation, that potentially will affect all parties. Thus, project success is subjective (in the eye of the beholder), and an important task of the project manager is to manage stakeholder’s expectations, a point we will emphasize throughout this book.

FIGURE 1-3. The project manager must manage expectations of stakeholders, where each has differing values, and missions reflective how they perceive the economic, political, and social environment.

Project management success means actively managing the expectations of various stakeholders.

All project managers have experienced the frustration of dealing with the many other directions in which the organization seems to be (and often is) moving. People act logically based on the way they see the data. Because each stakeholder perceives the situation differently, each develops a set of beliefs and behaviors that will cause differences in opinions and style. Project management, in large part, is the management of interpersonal conflict, which is inherent in complex organizational situations. Part 3 of this book will cover ways to deal with this “soft stuff,” which one sage observer noted was often the “really hard stuff.”

A ROADMAP OF FIVE IMPORTANT PROGRAM MANAGEMENT FUNCTIONS

Project management requires many different managerial activities. It is helpful to have a way to orient oneself.

Consider the predicament of one project manager.

I am a project manager working with four or five other people. Our project consists of redesigning a piece of hardware, making any improvement possible, and then making five to ten prototype systems. Our customer has not specified any time limit or deadline for our project to be completed. All that is expected is to accomplish “something” every calendar quarter. I know the day will come when the customer will say that he wants it now!

My problem is that I don’t seem to be able to motivate my people to work at a faster pace. I have tried setting goals with each of them individually; I have tried letting them set their own goals; I have tried to set deadline dates for a particular part of the job to be done; but nothing seems to work. I have tried to work with them and actually help do their work. They seem to get their part of the job done when they get around to it.

How should this project manager address this predicament? Figure 1-4 gives a few simple prescriptions that can help any project manager get started.

FIGURE 1-4. Do’s and don’ts for successful projects.

Focus on the “do” not the “don’t” items when confronting difficulty.

We also suggest considering the following five functions, as illustrated in Figure 1-5. The figure implies that the five functions are linked and interdependent. If the project is simple and straightforward, the functions probably will occur.

1. Defining. Projects don’t fail at the end; they fail at the beginning. Our project manager needs to develop some expectations and boundaries for the project. The project manager needs to start asking questions and determine the requirements for product performance and expectations for delivery date and cost. Good project objectives are SMART (specific, measurable, agreed to, realistic, and time bound). Project definition also includes developing an understanding of management’s rationale for investing in the project rationale.

2. Planning. The project manager and team need to examine their strategy for planning the project. This includes estimating resource needs, timing, budgeting, and so forth. The project members also should determine how they will organize themselves to meet the customer’s requirements and the control needs of their home (sponsoring) organization.

3. Leading. The project manager needs to provide managerial guidance to human resources, subordinates, and others (including subcontractors) that will result in their doing effective, timely work.

4. Controlling. The project manager needs to measure performance to find out how progress differs from plan in time to initiate corrective action. The controlling activities often cause a redefinition of the project objectives.

5. Completing. The project manager needs to make sure that the product scope conforms to the product requirements and the demands of the delivering organization (e.g., documentation and lessons learned).

FIGURE 1-5. Five management functions.

Projects don’t fail at the end, they fail at the beginning.

This chapter establishes several fundamentals, including the definition of a project and of project management. As you continue reading this book, you probably will find yourself referring back to many of the framework ideas established in this first chapter. If you are starting a project—or in the middle of one—feel free to use the table of contents and index to help you identify the “just in time” knowledge and prescriptions that you need. We intend book this as a pragmatic resource.

HIGHLIGHTS

Projects are a type of work distinguished from other types of work because projects are temporary, unique, and progressively elaborated.A task is similar to a project in that it is temporary, but typically, a project is larger and more complex than a task. Tasks are smaller elements of work in a project.A program is a collection of projects.Project management is not simply developing and managing a “to do” list.The factors that cause success and failure in projects are well known.Project management has a professional body of knowledge.This book presents five managerial functions for projects: defining, planning, leading, controlling, and completing.

Note

* The tool icon is used next to a paragraph that describes a particularly useful tool that you may want to use. See the preface, page xvi, for more information.

Part 1: Defining the Goals of a Project

2 Linking the Project to the Product

Customers and their product requirements are one determinant of project success. This chapter will help you to understand the relationship between the project life cycle to the product life cycle and give you other important knowledge that will help you get your project off to a good start.

Successful project managers manage expectations well. These expectations are set early in the project and reveal themselves in terms of needs, wants, requirements, requests, and other things. Good project managers continually manage expectations of the stakeholders. In this chapter, we will describe several important principles and rules for establishing and managing the goals and expectations of a project.

STRATEGIC ALIGNMENT OF PROJECTS

Recall from Chapter 1 that a project is part of a portfolio of assets. Organizations that perform projects consistently well do a good job of portfolio management. Projects are not an operational expense to be minimized but rather an important instrument for organizations to reach their goals. Top management has an important role in successful project management. First, top management has a fiduciary responsibility to invest the organization’s assets wisely; thus, it commissions projects to align with its strategic intentions. Since all organizations have finite resources, management will select projects wisely to optimize value creation over the short and long term. Most organizations will find it better to select the projects that have the best returns on their investment. Second, top management recognizes that it must nurture and support its projects. The most innovative and risky projects are often the most fragile because people are reluctant to have their names associated with a project that failed and stick with more conservative and conventional investments. Third, top management reprioritizes projects, or changes the boundaries and objectives, because the organization’s environment is dynamic and things change. Project managers support top management by providing much of the data that allow them to make their decisions. Some of the goals of portfolio management include the following:

Projects are better considered as organizational investments than as operational expenses.

Matching the number of projects for the resource base—such that the organization is neither spreading its resources too thin nor missing opportunitiesSetting and communicating priorities for creating value, balance, and strategic changeSetting and communicating processes for escalating issues and managing change to project directionSetting and communicating completion criteria, including criteria for terminating projectsSelectively leveraging the use of external resources such as consultants, contractors, suppliers, and partners