Cover Design: John Wiley & Sons, Inc.
Cover Illustration: © SOMATUSCANI/iStockphoto
Copyright © 2013 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, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, 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, or online at www.wiley.com/go/permissions.
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 the 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. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for damages arising herefrom.
For general information about 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 publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Project Management Institute (www.pmi.org) is the leading advocate for the project management profession globally. Founded in 1969, PMI has more than 650,000 members and credential holders in 185 countries. PMI’s Project Management Professional (PMP) credential is globally recognized as the gold standard credential in project management.
© 2013 Project Management Institute, Inc. All rights reserved.
“PMI,” the PMI logo, “PMP,” and “PMBOK” are registered marks of the Project Management Institute, Inc. For a comprehensive list of PMI marks, contact the PMI legal Department.
Library of Congress Cataloging-in-Publication Data is available upon request.
ISBN: 978-1-118-43107-8; 978-111-8-54628-4 (ebk); 978-111-8-54639-0 (ebk); 978-111-8-54660-4 (ebk)
This book is designed to help make the Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition more accessible to project managers.
It presents information from the PMBOK® Guide -Fifth Edition, in easily understandable language, and it describes how to apply the various tools and techniques. In short, it makes the PMBOK® Guide easier to understand and helps you implement the practices described in the PMBOK® Guide.
The information in this book is based solely on information from the PMBOK® Guide—Fifth Edition.1 Therefore, you will find identical definitions and many of the same tables and figures. Thus, we will not footnote each reference to the PMBOK® Guide because, as we have stated, that is the sole source for content.
We have included some forms in Appendix A that show you how to use a form or template to record the information in a specific document. These forms can be found in The Project Manager’s Book of Forms,2 published by PMI and Wiley. Again, since this is the sole source for forms, we will not footnote each reference.
To help make this book easier to read, we are using various icons, tables, data flow diagrams, and call-out boxes. For instance, when we use a definition from the PMBOK® Guide we have inserted a dictionary icon. At the beginning of each process we describe the process and then show a data flow diagram from the PMBOK® Guide so you can see how information flows through the process, where it comes from, and where it goes. Call-out boxes may be used to list elements of a particular document.
The information is presented by Process Group as opposed to how the PMBOK® Guide presents it, by Knowledge Area. Because this book is designed to assist you in managing a project we felt it would be helpful to present information more consistent with how you will apply it on a project. We hope this User’s Manual helps you in delivering successful projects!
This book is a wonderful example of the team work it takes to get something published. First, as always, my thanks to Bob Argentieri for your continual support and promotion of my work. I appreciate the effort you put into making sure everything gets done on time and in the most productive way possible. I always look forward to catching up at congress and celebrating the latest achievements! I appreciate the work Amy Odum and Kerstin Nasdeo do to get everything cleaned up and published on a compressed timeline. I know you had to move a lot of things around to get this book out on time. Thank you!
Thank you to my good friends at PMI Publishing. Donn Greenberg, you are a force of nature. You know so much about publishing and how to make things work at PMI. I so appreciate your ongoing support for my books! Barbara Walsh, you are a gem of a human being and so smart in your field. I really appreciate your insight into how to make this second edition more user friendly. Thank you for your professional support and your friendship. Both mean a lot to me. Roberta Storer, you are an editor extraordinaire and a wonderful person! Thank you for your help in making this a better book.
Finally, thank to the PMBOK® Guide—Fifth Edition team. You did a wonderful job updating the standard!
TOPICS COVERED
This book is designed to help make the A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition more accessible to project managers. The PMBOK® Guide is a standard, therefore it defines what is considered to be a good practice on most projects most of the time. Notice it does not define best practices, it defines good practices. Best practices tend to be industry and organization specific. Because the PMBOK® Guide is a standard, it is not descriptive. In other words, it doesn’t tell you how to implement those practices, it merely identifies them.
The PMBOK® Guide also promotes a common vocabulary for project management, thereby enabling effective communication about project management between project managers, their sponsors, and their team members.
Many project managers, PMOs, and organizations mistake the PMBOK® Guide as a project management methodology. It is not. A project management methodology is a set of practices, policies, procedures, guidelines, tools, techniques, and so forth that are used to manage projects. This book is not a methodology. This book takes the information in the PMBOK® Guide and describes it in easily understandable language and explains how to apply the various tools and techniques. In short, it makes the PMBOK® Guide easier to understand and helps you implement the practices described therein.
The information in this book is based solely on information from the PMBOK® Guide—Fifth Edition. Therefore you will find identical definitions and some of the same tables and figures.
To help make this book easier to read we are using various features such as definitions, examples, tips, and data flow diagrams. At the beginning of each process we describe the process, show inputs, tools and techniques, and outputs and then show a data flow diagram from the PMBOK® Guide so you can see how information flows through the process, where it comes from, and where it goes next. In some instances, we provide a list of elements typically found in a particular document. Sometimes we include references of forms that show how you can record the information in the document. These forms can be found in the Appendix and are available in print and electronic form in The Project Manager’s Book of Forms, published by PMI and John Wiley & Sons.
The project management standard is presented as 47 discrete processes. A process is a set of interrelated actions and activities performed to achieve a pre-specified product, result, or service. Processes are comprised of inputs, tools and techniques, and outputs. Therefore, this book will follow that structure of presenting a process and then discussing the individual inputs, tools and techniques, and outputs that comprise the process.
To facilitate understanding of the processes, PMI has identified five Process Groups. These groups are: Initiating Process Group, Planning Process Group, Executing Process Group, Monitoring and Controlling Process Group, and the Closing Process Group.
Note in Figure 1-1 how the Process Groups interact with each other in each phase of the project and for the project overall. The processes in the Initiating Process Group are used to identify the high-level definition of the project or phase and obtain authorization to proceed. Once this is accomplished the high-level information can be further elaborated in the Planning Process Group. Of course, we don’t only plan at the start of the project. We spend much of the first part of our project planning, but as we get into the Executing Process Group, where we are actually creating and developing the work of the project, we will need to plan in finer levels of detail and re-plan when things do not go as expected. In fact, the Monitoring and Controlling Process Group is used to compare our planned progress to our actual progress. If the two are acceptably consistent, we continue on with the project work. If they are not, we will need to plan corrective or preventive actions to get our performance aligned with our plan. Finally, we will use the Closing Process Group to finalize the work and archive the phase or project information.
Figure 1-1 Project Management Process Groups
Source: PMBOK® Guide, Fifth edition
Another way to categorize the project management processes is by Knowledge Area. PMI identifies ten Knowledge Areas:
Figure 1-2 shows how each of the 47 project management processes aligns with the Project Management Process Groups and the Project Management Knowledge Areas.
Figure 1-2 Project Management Process Groups and Knowledge Areas Mapping
Source: PMBOK® Guide, Fifth edition
This book will use the Process Groups rather than the Knowledge Areas to present information. In Chapter 2 we will review some of the key concepts in project management; in Chapter 3 we will discuss the Initiating Processes. The next several chapters will discuss the Planning Processes. This will be followed by chapters on the Executing Processes, Monitoring and Controlling Processes, and finally, the Closing Processes.
TOPICS COVERED
The difference between a project and a program can sometimes be fuzzy. And the difference between a program and a portfolio of projects can also be confusing. Let’s start by looking at definitions for these words and then explore some additional key concepts in project management.
Some people consider a program to be a jumbo-sized project. While this can be the case, it is not always true. For example, the Olympic Games could be considered a very large project with many subprojects. However, because of the size, cost, duration, and the sheer number of projects it takes to produce the Olympic Games, it is more like a collection of projects that is managed in a coordinated fashion—in other words, a program. Many of the projects are construction-related, many are production-related, many are related to press and broadcast, some are technology specific, and still others are about cultural events.
Within the program of the Olympic Games, you could even consider all the construction projects as a portfolio of projects. For the 2012 London Olympic Games, they were grouped together under the Olympic Delivery Authority (ODA) to facilitate effective management. Another portfolio could be considered the projects of the LOCOG. LOCOG is the London Organizing Committee for the Olympic Games. They were responsible for staging the Olympic and Paralympic Games.
Another way to look at the Olympic Games is having a portfolio for ODA, for the Olympics and another for the Paralympics. So you can see that much of the way you organize projects, programs, and portfolios is subjective. You can have programs with projects and portfolios of projects. You can also have portfolios with projects and programs made up of many projects. The main differentiator is that projects are always temporary, while programs and portfolios may have one or more elements that entail ongoing operations.
Most large projects have a defined project life cycle made up of phases.
There can be some confusion about the difference between a project life cycle and the Project Management Process Groups. Remember, the Process Groups are: Initiating, Planning, Executing, Monitoring and Controlling, and Closing. While these appear to be sequential, and could be mistaken for phases, they are groups of processes that are applied iteratively and as needed throughout the project. In some cases, the Project Management Process Groups are applied to each phase in a project. For example, a construction project might have three phases: design, procure, construct. An IT project might have phases such as: requirements, planning, design, detail design, build, test, deploy. Each phase is completed sequentially. The needs of the performing organization(s) and the project will determine the number and the names of the phases.
Many organizations use the end of a project phase to review the progress on the project. This gives the project manager, the sponsor, and the customer the opportunity to review the Charter, the progress, and deliverables to determine if the project should continue, if the approach should change, or if the project should be cancelled. There are times when the need for the project is no longer valid. Circumstances or market forces may have changed, or the duration and cost of the project may no longer justify the expenditure of resources. The end of a phase (sometimes known as a phase gate or kill point) is often the right time to make those decisions.
One of the key concepts in project management is progressive elaboration.
One of the common laments of project managers is that customers and sponsors want accurate estimates in the beginning of a project, before the scope is even fully defined. The concept of progressive elaboration clearly articulates that we can’t have detailed estimates until we have detailed and specific information about the project scope. As we progress in the project we can develop more accurate and complete information.
Projects, by their nature, are unique. Therefore, not all projects will use all processes defined in the PMBOK® Guide. Tailoring means that the project manager and the project team should carefully determine which processes are appropriate for their project, which outputs are appropriate, and the degree of rigor that should be applied when using the various tools and techniques. Some will use more robust processes, some will use less robust processes. It is up to the project manager and his or her team to determine the appropriate approach for the individual project.
Enterprise environmental factors (EEF) are conditions, not under the immediate control of the team, that influence, constrain, or direct the project, program, or portfolio. These factors are from any or all of the enterprises involved in the project and include organizational culture and structure, infrastructure, existing resources, commercial databases, market conditions, and project management software. The following is a list from Chapter 2.1.5 in the PMBOK® Guide.
As project managers we don’t have control over these factors, but overlooking them can lead to problems on our projects. Therefore, we need to be conscious of how these factors influence and constrain our options on projects.
Organizational process assets (OPA) include plans, policies, procedures, and knowledge bases that are specific to and used by the performing organization. These process assets include formal and informal plans, policies, procedures, and guidelines. The process assets also include the organizations’ knowledge bases such as lessons learned and historical information. There are two general categories of organizational process assets: processes and procedures and the corporate knowledge base. The following is a list from Chapter 2.1.4 in the PMBOK® Guide.
The difference between enterprise environmental factors (EEF) and organizational process assets (OPA) can be confusing. One way of looking at it is that EEFs tend to limit or constrain your options on a project and OPAs tend to assist, or provide guidance. For example, industry standards significantly restrict options in product development. You can develop a product that is not consistent with industry standards, but it will not be very successful. So this EEF is something that the project team must take into consideration in planning, and it is something that will constrain their options.
OPAs that provide assistance, such as templates for the Project Charter, or the WBS, are artifacts that the team does not have to invent for themselves. They provide a shortcut. Lessons learned from prior projects can also provide guidance and assistance when planning a project. In short, EEFs constrain, OPAs assist.