Intended for Phylis Young Project management work
chloemomma2016
a12389-a_guide_to_the_project_managem-5th.pdf
Project Management Institute
2
A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK® Guide) – Fifth Edition
An American National Standard ANSI/PMI 99-001-2013
3
Library of Congress Cataloging-in-Publication Data A guide to the project management body of knowledge (PMBOK® guide). -- Fifth edition.
pages cm
Includes bibliographical references and index.
ISBN 978-1-935589-67-9 (pbk. : alk. paper) 1. Project management. I. Project Management Institute. II. Title: PMBOK guide.
HD69.P75G845 2013
658.4’04--dc23
2012046112
ISBN: 978-1-935589-67-9
Published by:
Project Management Institute, Inc.
4
14 Campus Boulevard Newtown Square, Pennsylvania 19073-3299 USA Phone: +610-356-4600
Fax: +610-356-4647
Email: [email protected]
Internet: www.PMI.org
©2013 Project Management Institute, Inc. All rights reserved.
“PMI”, the PMI logo, “PMP”, the PMP logo, “PMBOK”, “PgMP”, “Project Management Journal”, “PM Network”, and the PMI Today logo are registered marks of Project Management Institute, Inc. The Quarter Globe Design is a trademark of the Project Management Institute, Inc. For a comprehensive list of PMI marks, contact the PMI Legal Department.
PMI Publications welcomes corrections and comments on its books. Please feel free to send comments on typographical, formatting, or other errors. Simply make a copy of the relevant page of the book, mark the error, and send it to: Book Editor, PMI Publications, 14 Campus Boulevard, Newtown Square, PA 19073-3299 USA.
To inquire about discounts for resale or educational purposes, please contact the PMI Book Service Center.
PMI Book Service Center P.O. Box 932683, Atlanta, GA 31193-2683 USA Phone: 1-866-276-4764 (within the U.S. or Canada) or +1-770-280-4129 (globally) Fax: +1-770-280-4113
Email: [email protected]
Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any means, electronic, manual, photocopying, recording, or by any information storage and retrieval system, without prior written permission of the publisher.
The paper used in this book complies with the Permanent Paper Standard issued by the National Information Standards Organization (Z39.48—1984).
10 9 8 7 6 5
5
NOTICE The Project Management Institute, Inc. (PMI) standards and guideline
publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While PMI administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.
PMI disclaims liability for any personal injury, property or other damages of any nature whatsoever, whether special, indirect, consequential or compensatory, directly or indirectly resulting from the publication, use of application, or reliance on this document. PMI disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. PMI does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.
In publishing and making this document available, PMI is not undertaking to render professional or other services for or on behalf of any person or entity, nor is PMI undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.
PMI has no power, nor does it undertake to police or enforce compliance with the contents of this document. PMI does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to PMI and is solely the responsibility of the certifier or maker of the statement.
6
TABLE OF CONTENTS 1. INTRODUCTION
1.1 Purpose of the PMBOK® Guide
1.2 What is a Project?
1.2.1. The Relationships Among Portfolios, Programs, and Projects
1.3 What is Project Management?
1.4 Relationships Among Portfolio Management, Program Management, Project Management, and Organizational Project Management
1.4.1 Program Management
1.4.2 Portfolio Management
1.4.3 Projects and Strategic Planning
1.4.4 Project Management Office
1.5 Relationship Between Project Management, Operations Management, and Organizational Strategy
1.5.1 Operations and Project Management
1.5.2 Organizations and Project Management
1.6 Business Value
1.7 Role of the Project Manager
1.7.1 Responsibilities and Competencies of the Project Manager
1.7.2 Interpersonal Skills of a Project Manager
1.8 Project Management Body of Knowledge
2. ORGANIZATIONAL INFLUENCES AND PROJECT LIFE CYCLE
2.1 Organizational Influences on Project Management
2.1.1 Organizational Cultures and Styles
2.1.2 Organizational Communications
2.1.3 Organizational Structures
2.1.4 Organizational Process Assets
2.1.5 Enterprise Environmental Factors
7
2.2 Project Stakeholders and Governance
2.2.1 Project Stakeholders
2.2.2 Project Governance
2.2.3 Project Success
2.3 Project Team
2.3.1 Composition of Project Teams
2.4 Project Life Cycle
2.4.1 Characteristics of the Project Life Cycle
2.4.2 Project Phases
3. PROJECT MANAGEMENT PROCESSES
3.1 Common Project Management Process Interactions
3.2 Project Management Process Groups
3.3 Initiating Process Group
3.4 Planning Process Group
3.5 Executing Process Group
3.6 Monitoring and Controlling Process Group
3.7 Closing Process Group
3.8 Project Information
3.9 Role of the Knowledge Areas
4. PROJECT INTEGRATION MANAGEMENT
4.1 Develop Project Charter
4.1.1 Develop Project Charter: Inputs
4.1.2 Develop Project Charter: Tools and Techniques
4.1.3 Develop Project Charter: Outputs
4.2 Develop Project Management Plan
4.2.1 Develop Project Management Plan: Inputs
4.2.2 Develop Project Management Plan: Tools and Techniques
4.2.3 Develop Project Management Plan: Outputs
4.3 Direct and Manage Project Work
8
4.3.1 Direct and Manage Project Work: Inputs
4.3.2 Direct and Manage Project Work: Tools and Techniques
4.3.3 Direct and Manage Project Work: Outputs
4.4 Monitor and Control Project Work
4.4.1 Monitor and Control Project Work: Inputs
4.4.2 Monitor and Control Project Work: Tools and Techniques
4.4.3 Monitor and Control Project Work: Outputs
4.5 Perform Integrated Change Control
4.5.1 Perform Integrated Change Control: Inputs
4.5.2 Perform Integrated Change Control: Tools and Techniques
4.5.3 Perform Integrated Change Control: Outputs
4.6 Close Project or Phase
4.6.1 Close Project or Phase: Inputs
4.6.2 Close Project or Phase: Tools and Techniques
4.6.3 Close Project or Phase: Outputs
5. PROJECT SCOPE MANAGEMENT
5.1 Plan Scope Management
5.1.1 Plan Scope Management: Inputs
5.1.2 Plan Scope Management: Tools and Techniques
5.1.3 Plan Scope Management: Outputs
5.2 Collect Requirements
5.2.1 Collect Requirements: Inputs
5.2.2 Collect Requirements: Tools and Techniques
5.2.3 Collect Requirements: Outputs
5.3 Define Scope
5.3.1 Define Scope: Inputs
5.3.2 Define Scope: Tools and Techniques
5.3.3 Define Scope: Outputs
5.4 Create WBS
9
5.4.1 Create WBS: Inputs
5.4.2 Create WBS: Tools and Techniques
5.4.3 Create WBS: Outputs
5.5 Validate Scope
5.5.1 Validate Scope: Inputs
5.5.2 Validate Scope: Tools and Techniques
5.5.3 Validate Scope: Outputs
5.6 Control Scope
5.6.1 Control Scope: Inputs
5.6.2 Control Scope: Tools and Techniques
5.6.3 Control Scope: Outputs
6. PROJECT TIME MANAGEMENT
6.1 Plan Schedule Management
6.1.1 Plan Schedule Management: Inputs
6.1.2 Plan Schedule Management: Tools and Techniques
6.1.3 Plan Schedule Management: Outputs
6.2 Define Activities
6.2.1 Define Activities: Inputs
6.2.2 Define Activities: Tools and Techniques
6.2.3 Define Activities: Outputs
6.3 Sequence Activities
6.3.1 Sequence Activities: Inputs
6.3.2 Sequence Activities: Tools and Techniques
6.3.3 Sequence Activities: Outputs
6.4 Estimate Activity Resources
6.4.1 Estimate Activity Resources: Inputs
6.4.2 Estimate Activity Resources: Tools and Techniques
6.4.3 Estimate Activity Resources: Outputs
6.5 Estimate Activity Durations
10
6.5.1 Estimate Activity Durations: Inputs
6.5.2 Estimate Activity Durations: Tools and Techniques
6.5.3 Estimate Activity Durations: Outputs
6.6 Develop Schedule
6.6.1 Develop Schedule: Inputs
6.6.2 Develop Schedule: Tools and Techniques
6.6.3 Develop Schedule: Outputs
6.7 Control Schedule
6.7.1 Control Schedule: Inputs
6.7.2 Control Schedule: Tools and Techniques
6.7.3 Control Schedule: Outputs
7. PROJECT COST MANAGEMENT
7.1 Plan Cost Management
7.1.1 Plan Cost Management: Inputs
7.1.2 Plan Cost Management: Tools and Techniques
7.1.3 Plan Cost Management: Outputs
7.2 Estimate Costs
7.2.1 Estimate Costs: Inputs
7.2.2 Estimate Costs: Tools and Techniques
7.2.3 Estimate Costs: Outputs
7.3 Determine Budget
7.3.1 Determine Budget: Inputs
7.3.2 Determine Budget: Tools and Techniques
7.3.3 Determine Budget: Outputs
7.4 Control Costs
7.4.1 Control Costs: Inputs
7.4.2 Control Costs: Tools and Techniques
7.4.3 Control Costs: Outputs
8. PROJECT QUALITY MANAGEMENT
11
8.1 Plan Quality Management
8.1.1 Plan Quality Management: Inputs
8.1.2 Plan Quality Management: Tools and Techniques
8.1.3 Plan Quality Management: Outputs
8.2 Perform Quality Assurance
8.2.1 Perform Quality Assurance: Inputs
8.2.2 Perform Quality Assurance: Tools and Techniques
8.2.3 Perform Quality Assurance: Outputs
8.3 Control Quality
8.3.1 Control Quality: Inputs
8.3.2 Control Quality: Tools and Techniques
8.3.3 Control Quality: Outputs
9. PROJECT HUMAN RESOURCE MANAGEMENT
9.1 Plan Human Resource Management
9.1.1 Plan Human Resource Management: Inputs
9.1.2 Plan Human Resource Management: Tools and Techniques
9.1.3 Plan Human Resource Management: Outputs
9.2 Acquire Project Team
9.2.1 Acquire Project Team: Inputs
9.2.2 Acquire Project Team: Tools and Techniques
9.2.3 Acquire Project Team: Outputs
9.3 Develop Project Team
9.3.1 Develop Project Team: Inputs
9.3.2 Develop Project Team: Tools and Techniques
9.3.3 Develop Project Team: Outputs
9.4 Manage Project Team
9.4.1 Manage Project Team: Inputs
9.4.2 Manage Project Team: Tools and Techniques
9.4.3 Manage Project Team: Outputs
12
10. PROJECT COMMUNICATIONS MANAGEMENT
10.1 Plan Communications Management
10.1.1 Plan Communications Management: Inputs
10.1.2 Plan Communications Management: Tools and Techniques
10.1.3 Plan Communications Management: Outputs
10.2 Manage Communications
10.2.1 Manage Communications: Inputs
10.2.2 Manage Communications: Tools and Techniques
10.2.3 Manage Communications: Outputs
10.3 Control Communications
10.3.1 Control Communications: Inputs
10.3.2 Control Communications: Tools and Techniques
10.3.3 Control Communications: Outputs
11. PROJECT RISK MANAGEMENT
11.1 Plan Risk Management
11.1.1 Plan Risk Management: Inputs
11.1.2 Plan Risk Management: Tools and Techniques
11.1.3 Plan Risk Management: Outputs
11.2 Identify Risks
11.2.1 Identify Risks: Inputs
11.2.2 Identify Risks: Tools and Techniques
11.2.3 Identify Risks: Outputs
11.3 Perform Qualitative Risk Analysis
11.3.1 Perform Qualitative Risk Analysis: Inputs
11.3.2 Perform Qualitative Risk Analysis: Tools and Techniques
11.3.3 Perform Qualitative Risk Analysis: Outputs
11.4 Perform Quantitative Risk Analysis
11.4.1 Perform Quantitative Risk Analysis: Inputs
11.4.2 Perform Quantitative Risk Analysis: Tools and Techniques
13
11.4.3 Perform Quantitative Risk Analysis: Outputs
11.5 Plan Risk Responses
11.5.1 Plan Risk Responses: Inputs
11.5.2 Plan Risk Responses: Tools and Techniques
11.5.3 Plan Risk Responses: Outputs
11.6 Control Risks
11.6.1 Control Risks: Inputs
11.6.2 Control Risks: Tools and Techniques
11.6.3 Control Risks: Outputs
12. PROJECT PROCUREMENT MANAGEMENT
12.1 Plan Procurement Management
12.1.1 Plan Procurement Management: Inputs
12.1.2 Plan Procurement Management: Tools and Techniques
12.1.3 Plan Procurement Management: Outputs
12.2 Conduct Procurements
12.2.1 Conduct Procurements: Inputs
12.2.2 Conduct Procurements: Tools and Techniques
12.2.3 Conduct Procurements: Outputs
12.3 Control Procurements
12.3.1 Control Procurements: Inputs
12.3.2 Control Procurements: Tools and Techniques
12.3.3 Control Procurements: Outputs
12.4 Close Procurements
12.4.1 Close Procurements: Inputs
12.4.2 Close Procurements: Tools and Techniques
12.4.3 Close Procurements: Outputs
13. PROJECT STAKEHOLDER MANAGEMENT
13.1 Identify Stakeholders
13.1.1 Identify Stakeholders: Inputs
14
13.1.2 Identify Stakeholders: Tools and Techniques
13.1.3 Identify Stakeholders: Outputs
13.2 Plan Stakeholder Management
13.2.1 Plan Stakeholder Management: Inputs
13.2.2 Plan Stakeholder Management: Tools and Techniques
13.2.3 Plan Stakeholder Management: Outputs
13.3 Manage Stakeholder Engagement
13.3.1 Manage Stakeholder Engagement: Inputs
13.3.2 Manage Stakeholder Engagement: Tools and Techniques
13.3.3 Manage Stakeholder Engagement: Outputs
13.4 Control Stakeholder Engagement
13.4.1 Control Stakeholder Engagement: Inputs
13.4.2 Control Stakeholder Engagement: Tools and Techniques
13.4.3 Control Stakeholder Engagement: Outputs
ANNEX A1 THE STANDARD FOR PROJECT MANAGEMENT OF A PROJECT
APPENDIX X1 FIFTH EDITION CHANGES
APPENDIX X2 CONTRIBUTORS AND REVIEWERS OF THE PMBOK® GUIDE – FIFTH EDITION
APPENDIX X3 INTERPERSONAL SKILLS
REFERENCES
GLOSSARY
15
LIST OF TABLES AND FIGURES Figure 1-1. Portfolio, Program, and Project Management Interactions
Figure 2-1. Functional Organization
Figure 2-2. Weak Matrix Organization
Figure 2-3. Balanced Matrix Organization
Figure 2-4. Strong Matrix Organization
Figure 2-5. Projectized Organization
Figure 2-6. Composite Organization
Figure 2-7. The Relationship Between Stakeholders and the Project
Figure 2-8. Typical Cost and Staffing Levels Across a Generic Project Life Cycle Structure
Figure 2-9. Impact of Variable Based on Project Time
Figure 2-10. Example of a Single-Phase Project
Figure 2-11. Example of a Three-Phase Project
Figure 2-12. Example of a Project with Overlapping Phases
Figure 2-13. Example of Predictive Life Cycle
Figure 3-1. Project Management Process Groups
Figure 3-2. Process Groups Interact in a Phase or Project
Figure 3-3. Project Management Process Interactions
Figure 3-4. Project Boundaries
Figure 3-5. Project Data, Information and Report Flow
Figure 3-6. Data Flow Diagram Legend
Figure 4-1. Project Integration Management Overview
Figure 4-2. Develop Project Charter: Inputs, Tools and Techniques, and Outputs
Figure 4-3. Develop Project Charter Data Flow Diagram
Figure 4-4. Develop Project Management Plan: Inputs, Tools & Techniques, and Outputs
Figure 4-5. Develop Project Management Plan Data Flow Diagram
16
Figure 4-6. Direct and Manage Project Work: Inputs, Tools and Techniques, and Outputs
Figure 4-7. Direct and Manage Project Work: Data Flow Diagram
Figure 4-8. Monitor and Control Project Work: Inputs, Tools & Techniques, and Outputs
Figure 4-9. Monitor and Control Project Work Data Flow Diagram
Figure 4-10. Perform Integrated Change Control: Inputs, Tools & Techniques, and Outputs
Figure 4-11. Perform Integrated Change Control Data Flow Diagram
Figure 4-12. Close Project or Phase: Inputs, Tools & Techniques, and Outputs
Figure 4-13. Close Project or Phase Data Flow Diagram
Figure 5-1. Project Scope Management Overview
Figure 5-2. Plan Scope Management: Inputs, Tools & Techniques, and Outputs
Figure 5-3. Plan Scope Management Data Flow Diagram
Figure 5-4. Collect Requirements: Inputs, Tools & Techniques, and Outputs
Figure 5-5. Collect Requirements Data Flow Diagram
Figure 5-6. Example of a Requirements Traceability Matrix
Figure 5-7. Define Scope: Inputs, Tools & Techniques, and Outputs
Figure 5-8. Define Scope Data Flow Diagram
Figure 5-9. Create WBS: Inputs, Tools & Techniques, and Outputs
Figure 5-10. Create WBS Data Flow Diagram
Figure 5-11. Sample WBS Decomposed Down Through Work Packages
Figure 5-12. Sample WBS Organized by Phase
Figure 5-13. Sample WBS with Major Deliverables
Figure 5-14. Validate Scope: Inputs, Tools & Techniques, and Outputs
Figure 5-15. Validate Scope Data Flow Diagram
Figure 5-16. Control Scope: Inputs, Tools & Techniques, and Outputs
Figure 5-17. Control Scope Data Flow Diagram
Figure 6-1. Project Time Management Overview
Figure 6-2. Scheduling Overview
17
Figure 6-3. Plan Schedule Management: Inputs, Tools & Techniques, and Outputs
Figure 6-4. Plan Schedule Management Data Flow Diagram
Figure 6-5. Define Activities: Inputs, Tools & Techniques, and Outputs
Figure 6-6. Define Activities Data Flow Diagram
Figure 6-7. Sequence Activities: Inputs, Tools & Techniques, and Outputs
Figure 6-8. Sequence Activities Data Flow Diagram
Figure 6-9. Precedence Diagramming Method (PDM) Relationship Types
Figure 6-10. Examples of Lead and Lag
Figure 6-11. Project Schedule Network Diagram
Figure 6-12. Estimate Activity Resources: Inputs, Tools & Techniques, and Outputs
Figure 6-13. Estimate Activity Resources Data Flow Diagram
Figure 6-14. Estimate Activity Durations: Inputs, Tools & Techniques, and Outputs
Figure 6-15. Estimate Activity Durations Data Flow Diagram
Figure 6-16 Develop Schedule: Inputs, Tools & Techniques, and Outputs
Figure 6-17. Develop Schedule Data Flow Diagram
Figure 6-18. Example of Critical Path Method
Figure 6-19. Example of Critical Chain Method
Figure 6-20. Resource Leveling
Figure 6-21. Project Schedule Presentations—Examples
Figure 6-22. Control Schedule: Inputs, Tools & Techniques, and Outputs
Figure 6-23. Control Schedule Data Flow Diagram
Figure 7-1. Project Cost Management Overview
Figure 7-2. Plan Cost Management: Inputs, Tools & Techniques, and Outputs
Figure 7-3. Plan Cost Management: Data Flow Diagram
Figure 7-4. Estimate Costs: Inputs, Tools & Techniques, and Outputs
Figure 7-5. Estimate Costs Data Flow Diagram
Figure 7-6. Determine Budget: Inputs, Tools & Techniques, and Outputs
18
Figure 7-7. Determine Budget Data Flow Diagram
Figure 7-8. Project Budget Components
Figure 7-9. Cost Baseline, Expenditures, and Funding Requirements
Figure 7-10. Control Costs: Inputs, Tools & Techniques, and Outputs
Figure 7-11. Control Costs Data Flow Diagram
Figure 7-12. Earned Value, Planned Value, and Actual Costs
Figure 7-13. To-Complete Performance Index (TCPI)
Figure 8-1. Project Quality Management Overview
Figure 8-2. Fundamental Relationships of Quality Assurance and Control Quality to the IPECC, PDCA, Cost of Quality Models and Project Management Process Groups
Figure 8-3. Plan Quality Management Inputs, Tools & Techniques, and Outputs
Figure 8-4. Plan Quality Management Data Flow Diagram
Figure 8-5. Cost of Quality
Figure 8-6. The SIPOC Model
Figure 8-7. Storyboard Illustrating a Conceptual Example of Each of the Seven Basic Quality Tools
Figure 8-8. Perform Quality Assurance: Inputs, Tools & Techniques, and Outputs
Figure 8-9. Perform Quality Assurance Data Flow Diagram
Figure 8-10. Storyboard Illustrating the Seven Quality Management and Control Tools
Figure 8-11. Control Quality: Inputs, Tools & Techniques, and Outputs
Figure 8-12. Control Quality Data Flow Diagram
Figure 9-1. Project Human Resource Management Overview
Figure 9-2. Plan Human Resource Management: Inputs, Tools & Techniques, and Outputs
Figure 9-3. Plan Human Resource Management Data Flow Diagram
Figure 9-4. Roles and Responsibility Definition Formats
Figure 9-5. RACI Matrix
Figure 9-6. Illustrative Resource Histogram
19
Figure 9-7. Acquire Project Team: Inputs, Tools & Techniques, and Outputs
Figure 9-8. Acquire Project Team Data Flow Diagram
Figure 9-9. Develop Project Team: Inputs, Tools & Techniques, and Outputs
Figure 9-10. Develop Project Team Data Flow Diagram
Figure 9-11. Manage Project Team: Inputs, Tools & Techniques, and Outputs
Figure 9-12. Manage Project Team Data Flow Diagram
Figure 10-1. Project Communications Management Overview
Figure 10-2. Plan Communications Management: Inputs, Tools & Techniques, and Outputs
Figure 10-3. Plan Communications Management Data Flow Diagram
Figure 10-4. Basic Communication Model
Figure 10-5. Manage Communications: Inputs, Tools & Techniques, and Outputs
Figure 10-6. Manage Communications Data Flow Diagram
Figure 10-7. Control Communications: Inputs, Tools & Techniques, and Outputs
Figure 10-8. Control Communications Data Flow Diagram
Figure 11-1. Project Risk Management Overview
Figure 11-2. Plan Risk Management: Inputs, Tools & Techniques, and Outputs
Figure 11-3. Plan Risk Management Data Flow Diagram
Figure 11-4. Example of a Risk Breakdown Structure (RBS)
Figure 11-5. Identify Risks: Inputs, Tools & Techniques, and Outputs
Figure 11-6. Identify Risks Data Flow Diagram
Figure 11-7. Influence Diagram
Figure 11-8. Perform Qualitative Risk Analysis: Inputs, Tools & Techniques, and Outputs
Figure 11-9. Perform Qualitative Risk Analysis Data Flow Diagram
Figure 11-10. Probability and Impact Matrix
Figure 11-11. Perform Quantitative Risk Analysis: Inputs, Tools & Techniques, and Outputs
20
Figure 11-12. Perform Quantitative Risk Analysis Data Flow Diagram
Figure 11-13. Range of Project Cost Estimates Collected During the Risk Interview
Figure 11-14. Examples of Commonly Used Probability Distributions
Figure 11-15. Example of Tornado Diagram
Figure 11-16. Decision Tree Diagram
Figure 11-17. Cost Risk Simulation Results
Figure 11-18. Plan Risk Responses: Inputs, Tools & Techniques, and Outputs
Figure 11-19. Plan Risk Responses Data Flow Diagram
Figure 11-20. Control Risks: Inputs, Tools & Techniques, and Outputs
Figure 11-21. Control Risks Data Flow Diagram
Figure 12-1. Project Procurement Management Overview
Figure 12-2. Plan Procurements: Inputs, Tools & Techniques, and Outputs
Figure 12-3. Plan Procurement Management Data Flow Diagram
Figure 12-4. Conduct Procurements: Inputs, Tools & Techniques, and Outputs
Figure 12-5. Conduct Procurements Data Flow Diagram
Figure 12-6. Control Procurements: Inputs, Tools & Techniques, and Outputs
Figure 12-7. Control Procurements Data Flow Diagram
Figure 12-8. Close Procurements: Inputs, Tools & Techniques, and Outputs
Figure 12-9. Close Procurements Data Flow Diagram
Figure 13-1. Project Stakeholder Management Overview
Figure 13-2. Identify Stakeholders: Inputs, Tools & Techniques, and Outputs
Figure 13-3. Identify Stakeholders Data Flow Diagram
Figure 13-4. Example Power/Interest Grid with Stakeholders
Figure 13-5. Plan Stakeholder Management: Inputs, Tools & Techniques, and Outputs
Figure 13-6. Plan Stakeholder Management Data Flow Diagram
Figure 13-7. Stakeholders Engagement Assessment Matrix
Figure 13-8. Manage Stakeholder Engagement: Inputs, Tools & Techniques, and Outputs
21
Figure 13-9. Manage Stakeholder Engagement Data Flow Diagram
Figure 13-10. Control Stakeholder Engagement: Inputs, Tools & Techniques, and Outputs
Figure 13-11. Control Stakeholder Engagement: Data Flow Diagram
Figure A1-1. Process Group Interactions in a Project
Figure A1-2. Project Management Process Interactions
Figure A1-3. Project Boundaries
Figure A1-4. Initiating Process Group
Figure A1-5. Develop Project Charter: Inputs and Outputs
Figure A1-6. Identify Stakeholders: Inputs and Outputs
Figure A1-7. Planning Process Group
Figure A1-8. Develop Project Management Plan: Inputs and Outputs
Figure A1-9. Plan Scope Management: Inputs and Outputs
Figure A1-10. Collect Requirements: Inputs and Outputs
Figure A1-11. Define Scope: Inputs and Outputs
Figure A1-12. Create WBS: Inputs and Outputs
Figure A1-13. Plan Schedule Management: Inputs and Outputs
Figure A1-14. Define Activities: Inputs and Outputs
Figure A1-15. Sequence Activities: Inputs and Outputs
Figure A1-16. Estimate Activity Resources: Inputs and Outputs
Figure A1-17. Estimate Activity Durations: Inputs and Outputs
Figure A1-18. Develop Schedule: Inputs and Outputs
Figure A1-19. Plan Cost Management: Inputs and Outputs
Figure A1-20. Estimate Costs: Inputs and Outputs
Figure A1-21. Determine Budget: Inputs and Outputs
Figure A1-22. Plan Quality Management: Inputs and Outputs
Figure A1-23. Plan Human Resource Management: Inputs and Outputs
Figure A1-24. Plan Communications Management: Inputs and Outputs
Figure A1-25. Plan Risk Management: Inputs and Outputs
22
Figure A1-26. Identify Risks: Inputs and Outputs
Figure A1-27. Perform Qualitative Risk Analysis: Inputs and Outputs
Figure A1-28. Perform Quantitative Risk Analysis: Inputs and Outputs
Figure A1-29. Plan Risk Responses: Inputs and Outputs
Figure A1-30. Plan Procurement Management: Inputs and Outputs
Figure A1-31. Plan Stakeholder Management: Inputs and Outputs
Figure A1-32. Executing Process Group
Figure A1-33. Direct and Manage Project Work: Inputs and Outputs
Figure A1-34. Perform Quality Assurance: Inputs and Outputs
Figure A1-35. Acquire Project Team: Inputs and Outputs
Figure A1-36. Develop Project Team: Inputs and Outputs
Figure A1-37. Manage Project Team: Inputs and Outputs
Figure A1-38. Manage Communications: Inputs and Outputs
Figure A1-39. Conduct Procurements: Inputs and Outputs
Figure A1-40. Manage Stakeholder Engagement: Inputs and Outputs
Figure A1-41. Monitoring and Controlling Process Group
Figure A1-42. Monitor and Control Project Work: Inputs and Outputs
Figure A1-43. Perform Integrated Change Control: Inputs and Outputs
Figure A1-44. Validate Scope: Inputs and Outputs
Figure A1-45. Control Scope: Inputs and Outputs
Figure A1-46. Control Schedule: Inputs and Outputs
Figure A1-47. Control Costs: Inputs and Outputs
Figure A1-48. Control Quality: Inputs and Outputs
Figure A1-49. Control Communications: Inputs and Outputs
Figure A1-50. Control Risks: Inputs and Outputs
Figure A1-51. Control Procurements: Inputs and Outputs
Figure A1-52. Control Stakeholder Engagement: Inputs and Outputs
Figure A1-53. Closing Process Group
Figure A1-54. Close Project or Phase: Inputs and Outputs
23
Figure A1-55. Close Procurements: Inputs and Outputs
Figure X1-1. Refined Data Model
Table 1-1. Comparative Overview of Project, Program, and Portfolio Management
Table 2-1. Influence of Organizational Structures on Projects
Table 3-1. Project Management Process Group and Knowledge Area Mapping
Table 4-1 Differentiation Between the Project Management Plan and Project Documents
Table 5-1. Elements of the Project Charter and Project Scope Statement
Table 7-1. Earned Value Calculations Summary Table
Table 11-1. Definition of Impact Scales for Four Project Objectives
Table A1-1. Project Management Process Group and Knowledge Area Mapping
Table X1-1. Section 4 Changes
Table X1-2. Section 5 Changes
Table X1-3. Section 6 Changes
Table X1-4. Section 7 Changes
Table X1-5. Section 8 Changes
Table X1-6. Section 9 Changes
Table X1-7. Section 10 Changes
Table X1-8. Section 11 Changes
Table X1-9. Section 12 Changes
Table X1-10. Section 13 Changes
24
1
INTRODUCTION A Guide to the Project Management Body of Knowledge (PMBOK® Guide) –
Fifth Edition provides guidelines for managing individual projects and defines project management related concepts. It also describes the project management life cycle and its related processes, as well as the project life cycle.
The PMBOK® Guide contains the globally recognized standard and guide for the project management profession (found in Annex A1). A standard is a formal document that describes established norms, methods, processes, and practices. As with other professions, the knowledge contained in this standard has evolved from the recognized good practices of project management practitioners who have contributed to the development of this standard.
The first two sections of the PMBOK® Guide provide an introduction to key concepts in the project management field. Section 3 summarizes the Process Groups and provides an overview of process interactions among the ten Knowledge Areas and five Process Groups. Sections 4 through 13 are the guide to the project management body of knowledge. These sections expand on the information in the standard by describing the inputs and outputs, as well as tools and techniques used in managing projects. Annex A1 is the standard for project management and presents the processes, inputs, and outputs that are considered to be good practice on most projects most of the time.
This section defines several key terms and the relationship among portfolio management, program management, project management and organizational project management. An overview of the PMBOK® Guide is found within the following sections:
1.1 Purpose of the PMBOK® Guide
1.2 What is a Project?
1.3 What is Project Management?
1.4 Relationships Among Portfolio Management, Program Management, Project Management, and Organizational Project Management
1.5 Relationship Between Project Management, Operations Management, and Organizational Strategy
1.6 Business Value
25
1.7 Role of the Project Manager
1.8 Project Management Body of Knowledge
1.1 Purpose of the PMBOK® Guide The acceptance of project management as a profession indicates that the
application of knowledge, processes, skills, tools, and techniques can have a significant impact on project success. The PMBOK® Guide identifies that subset of the project management body of knowledge that is generally recognized as good practice. “Generally recognized” means the knowledge and practices described are applicable to most projects most of the time, and there is consensus about their value and usefulness. “Good practice” means there is general agreement that the application of the knowledge, skills, tools, and techniques can enhance the chances of success over many projects. “Good practice” does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project.
The PMBOK® Guide also provides and promotes a common vocabulary within the project management profession for using and applying project management concepts. A common vocabulary is an essential element of a professional discipline. The PMI Lexicon of Project Management Terms [1]1 provides the foundational professional vocabulary that can be consistently used by project, program, and portfolio managers and other stakeholders.
Annex A1 is a foundational reference for PMI's project management professional development programs. Annex A1 continues to evolve along with the profession, and is therefore not all-inclusive; this standard is a guide rather than a specific methodology. One can use different methodologies and tools (e.g., agile, waterfall, PRINCE2) to implement the project management framework.
In addition to the standards that establish guidelines for project management processes, the Project Management Institute Code of Ethics and Professional Conduct [2] guides practitioners of the profession and describes the expectations that practitioners should hold for themselves and others. The Project Management Institute Code of Ethics and Professional Conduct is specific about the basic obligation of responsibility, respect, fairness, and honesty. It requires that practitioners demonstrate a commitment to ethical and professional conduct. It carries the obligation to comply with laws, regulations, and organizational and professional policies. Practitioners come from diverse backgrounds and cultures, and the Project Management Institute Code of Ethics and Professional Conduct applies globally. When interacting with any stakeholder, practitioners should be committed to honest, responsible, fair practices and respectful dealings. Acceptance of the code is essential for project managers, and is a requirement for
26
the following PMI® exams:
Certified Associate in Project Management (CAPM)®
Project Management Professional (PMP)®
Program Management Professional (PgMP)®
PMI Agile Certified Practitioner (PMI-ACP)SM
PMI Risk Management Professional (PMI-RMP)®
PMI Scheduling Professional (PMI-SP)®
1.2 What is a Project? A project is a temporary endeavor undertaken to create a unique product,
service, or result. The temporary nature of projects indicates that a project has a definite beginning and end. The end is reached when the project's objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists. A project may also be terminated if the client (customer, sponsor, or champion) wishes to terminate the project. Temporary does not necessarily mean the duration of the project is short. It refers to the project's engagement and its longevity. Temporary does not typically apply to the product, service, or result created by the project; most projects are undertaken to create a lasting outcome. For example, a project to build a national monument will create a result expected to last for centuries. Projects can also have social, economic, and environmental impacts that far outlive the projects themselves.
Every project creates a unique product, service, or result. The outcome of the project may be tangible or intangible. Although repetitive elements may be present in some project deliverables and activities, this repetition does not change the fundamental, unique characteristics of the project work. For example, office buildings can be constructed with the same or similar materials and by the same or different teams. However, each building project remains unique with a different location, different design, different circumstances and situations, different stakeholders, and so on.
An ongoing work effort is generally a repetitive process that follows an organization's existing procedures. In contrast, because of the unique nature of projects, there may be uncertainties or differences in the products, services, or results that the project creates. Project activities can be new to members of a project team, which may necessitate more dedicated planning than other routine work. In addition, projects are undertaken at all organizational levels. A project can involve a single individual or multiple individuals, a single organizational unit, or multiple organizational units from multiple organizations.
27
A project can create:
A product that can be either a component of another item, an enhancement of an item, or an end item in itself; A service or a capability to perform a service (e.g., a business function that supports production or distribution); An improvement in the existing product or service lines (e.g., A Six Sigma project undertaken to reduce defects); or A result, such as an outcome or document (e.g., a research project that develops knowledge that can be used to determine whether a trend exists or a new process will benefit society).
Examples of projects include, but are not limited to:
Developing a new product, service, or result; Effecting a change in the structure, processes, staffing, or style of an organization; Developing or acquiring a new or modified information system (hardware or software); Conducting a research effort whose outcome will be aptly recorded; Constructing a building, industrial plant, or infrastructure; or Implementing, improving, or enhancing existing business processes and procedures.
1.2.1. The Relationships Among Portfolios, Programs, and Projects
The relationship among portfolios, programs, and projects is such that a portfolio refers to a collection of projects, programs, subportfolios, and operations managed as a group to achieve strategic objectives. Programs are grouped within a portfolio and are comprised of subprograms, projects, or other work that are managed in a coordinated fashion in support of the portfolio. Individual projects that are either within or outside of a program are still considered part of a portfolio. Although the projects or programs within the portfolio may not necessarily be interdependent or directly related, they are linked to the organization's strategic plan by means of the organization's portfolio.
As Figure 1-1 illustrates, organizational strategies and priorities are linked and have relationships between portfolios and programs, and between programs and individual projects. Organizational planning impacts the projects by means of project prioritization based on risk, funding, and other considerations relevant to the organization's strategic plan. Organizational planning can direct the management of resources, and support for the component projects on the basis of risk categories, specific lines of business, or general types of projects, such as infrastructure and
28
process improvement.
1.3 What is Project Management? Project management is the application of knowledge, skills, tools, and techniques
to project activities to meet the project requirements. Project management is accomplished through the appropriate application and integration of the 47 logically grouped project management processes, which are categorized into five Process Groups. These five Process Groups are:
Initiating, Planning, Executing, Monitoring and Controlling, and Closing.
Managing a project typically includes, but is not limited to:
Identifying requirements; Addressing the various needs, concerns, and expectations of the stakeholders in planning and executing the project;
29
Setting up, maintaining, and carrying out communications among stakeholders that are active, effective, and collaborative in nature; Managing stakeholders towards meeting project requirements and creating project deliverables; Balancing the competing project constraints, which include, but are not limited to:
Scope, Quality, Schedule, Budget, Resources, and Risks.
The specific project characteristics and circumstances can influence the constraints on which the project management team needs to focus.
The relationship among these factors is such that if any one factor changes, at least one other factor is likely to be affected. For example, if the schedule is shortened, often the budget needs to be increased to add additional resources to complete the same amount of work in less time. If a budget increase is not possible, the scope or targeted quality may be reduced to deliver the project's end result in less time within the same budget amount. Project stakeholders may have differing ideas as to which factors are the most important, creating an even greater challenge. Changing the project requirements or objectives may create additional risks. The project team needs to be able to assess the situation, balance the demands, and maintain proactive communication with stakeholders in order to deliver a successful project.
Due to the potential for change, the development of the project management plan is an iterative activity and is progressively elaborated throughout the project's life cycle. Progressive elaboration involves continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available. Progressive elaboration allows a project management team to define work and manage it to a greater level of detail as the project evolves.
1.4 Relationships Among Portfolio Management, Program Management, Project Management, and Organizational Project Management
In order to understand portfolio, program, and project management, it is important to recognize the similarities and differences among these disciplines. It is also helpful to understand how they relate to organizational project management
30
(OPM). OPM is a strategy execution framework utilizing project, program, and portfolio management as well as organizational enabling practices to consistently and predictably deliver organizational strategy producing better performance, better results, and a sustainable competitive advantage.
Portfolio, program, and project management are aligned with or driven by organizational strategies. Conversely, portfolio, program, and project management differ in the way each contributes to the achievement of strategic goals. Portfolio management aligns with organizational strategies by selecting the right programs or projects, prioritizing the work, and providing the needed resources, whereas program management harmonizes its projects and program components and controls interdependencies in order to realize specified benefits. Project management develops and implements plans to achieve a specific scope that is driven by the objectives of the program or portfolio it is subjected to and, ultimately, to organizational strategies. OPM advances organizational capability by linking project, program, and portfolio management principles and practices with organizational enablers (e.g. structural, cultural, technological, and human resource practices) to support strategic goals. An organization measures its capabilities, then plans and implements improvements towards the systematic achievement of best practices.
Table 1-1 shows the comparison of project, program, and portfolio views across several dimensions within the organization.
31
1.4.1 Program Management A program is defined as a group of related projects, subprograms, and program
activities managed in a coordinated way to obtain benefits not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in the program. A project may or may not be part of a program but a program will always have projects.
Program management is the application of knowledge, skills, tools, and techniques to a program in order to meet the program requirements and to obtain benefits and control not available by managing projects individually.
Projects within a program are related through the common outcome or collective capability. If the relationship between projects is only that of a shared client, seller, technology, or resource, the effort should be managed as a portfolio of projects
32
rather than as a program. Program management focuses on the project interdependencies and helps to
determine the optimal approach for managing them. Actions related to these interdependencies may include:
Resolving resource constraints and/or conflicts that affect multiple projects within the program, Aligning organizational/strategic direction that affects project and program goals and objectives, and Resolving issues and change management within a shared governance structure.
An example of a program is a new communications satellite system with projects for design of the satellite and the ground stations, the construction of each, the integration of the system, and the launch of the satellite.
1.4.2 Portfolio Management A portfolio refers to projects, programs, subportfolios, and operations managed
as a group to achieve strategic objectives. The projects or programs of the portfolio may not necessarily be interdependent or directly related. For example, an infrastructure firm that has the strategic objective of “maximizing the return on its investments” may put together a portfolio that includes a mix of projects in oil and gas, power, water, roads, rail, and airports. From this mix, the firm may choose to manage related projects as one program. All of the power projects may be grouped together as a power program. Similarly, all of the water projects may be grouped together as a water program. Thus, the power program and the water program become integral components of the enterprise portfolio of the infrastructure firm.
Portfolio management refers to the centralized management of one or more portfolios to achieve strategic objectives. Portfolio management focuses on ensuring that projects and programs are reviewed to prioritize resource allocation, and that the management of the portfolio is consistent with and aligned to organizational strategies.
1.4.3 Projects and Strategic Planning Projects are often utilized as a means of directly or indirectly achieving
objectives within an organization's strategic plan. Projects are typically authorized as a result of one or more of the following strategic considerations:
Market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response to gasoline shortages); Strategic opportunity/business need (e.g., a training company authorizing a project to create a new course to increase its revenues);
33
Social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of infectious diseases); Environmental consideration (e.g., a public company authorizing a project to create a new service for electric car sharing to reduce pollution); Customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park); Technological advance (e.g., an electronics firm authorizing a new project to develop a faster, cheaper, and smaller laptop based on advances in computer memory and electronics technology); and Legal requirement (e.g., a chemical manufacturer authorizing a project to establish guidelines for proper handling of a new toxic material).
Projects, within programs or portfolios, are a means of achieving organizational goals and objectives, often in the context of a strategic plan. Although a group of projects within a program can have discrete benefits, they can also contribute to the benefits of the program, to the objectives of the portfolio, and to the strategic plan of the organization.
Organizations manage portfolios based on their strategic plan. One goal of portfolio management is to maximize the value of the portfolio through careful examination of its components—the constituent programs, projects, and other related work. Those components contributing the least to the portfolio's strategic objectives may be excluded. In this way, an organization's strategic plan becomes the primary factor guiding investments in projects. At the same time, projects provide feedback to programs and portfolios by means of status reports, lessons learned, and change requests that may help to identify impacts to other projects, programs, or portfolios. The needs of the projects, including the resource needs, are rolled up and communicated back to the portfolio level, which in turn sets the direction for organizational planning.
1.4.4 Project Management Office A project management office (PMO) is a management structure that standardizes
the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of one or more projects.
There are several types of PMO structures in organizations, each varying in the degree of control and influence they have on projects within the organization, such as:
Supportive. Supportive PMOs provide a consultative role to projects by
34
supplying templates, best practices, training, access to information and lessons learned from other projects. This type of PMO serves as a project repository. The degree of control provided by the PMO is low. Controlling. Controlling PMOs provide support and require compliance through various means. Compliance may involve adopting project management frameworks or methodologies, using specific templates, forms and tools, or conformance to governance. The degree of control provided by the PMO is moderate. Directive. Directive PMOs take control of the projects by directly managing the projects. The degree of control provided by the PMO is high.
The PMO integrates data and information from corporate strategic projects and evaluates how higher level strategic objectives are being fulfilled. The PMO is the natural liaison between the organization's portfolios, programs, projects, and the corporate measurement systems (e.g. balanced scorecard).
The projects supported or administered by the PMO may not be related, other than by being managed together. The specific form, function, and structure of a PMO are dependent upon the needs of the organization that it supports.
A PMO may have the authority to act as an integral stakeholder and a key decision maker throughout the life of each project, to make recommendations, or to terminate projects or take other actions, as required, to remain aligned with the business objectives. In addition, the PMO may be involved in the selection, management, and deployment of shared or dedicated project resources.
A primary function of a PMO is to support project managers in a variety of ways which may include, but are not limited to:
Managing shared resources across all projects administered by the PMO; Identifying and developing project management methodology, best practices, and standards; Coaching, mentoring, training, and oversight; Monitoring compliance with project management standards, policies, procedures, and templates by means of project audits; Developing and managing project policies, procedures, templates, and other shared documentation (organizational process assets); and Coordinating communication across projects.
Project managers and PMOs pursue different objectives and, as such, are driven by different requirements. All of these efforts are aligned with the strategic needs of the organization. Differences between the role of project managers and a PMO may include the following:
The project manager focuses on the specified project objectives, while the
35
PMO manages major program scope changes, which may be seen as potential opportunities to better achieve business objectives. The project manager controls the assigned project resources to best meet project objectives, while the PMO optimizes the use of shared organizational resources across all projects. The project manager manages the constraints (scope, schedule, cost, quality, etc.) of the individual projects, while the PMO manages the methodologies, standards, overall risks/opportunities, metrics, and interdependencies among projects at the enterprise level.
1.5 Relationship Between Project Management, Operations Management, and Organizational Strategy
Operations management is responsible for overseeing, directing, and controlling business operations. Operations evolve to support the day-to-day business, and are necessary to achieve strategic and tactical goals of the business. Examples include: production operations, manufacturing operations, accounting operations, software support, and maintenance.
Though temporary in nature, projects can help achieve the organizational goals when they are aligned with the organization's strategy. Organizations sometimes change their operations, products, or systems by creating strategic business initiatives that are developed and implemented through projects. Projects require project management activities and skill sets, while operations require business process management, operations management activities, and skill sets.
1.5.1 Operations and Project Management Changes in business operations may be the focus of a dedicated project—
especially if there are substantial changes to business operations as a result of a new product or service delivery. Ongoing operations are outside of the scope of a project; however, there are intersecting points where the two areas cross.
Projects can intersect with operations at various points during the product life cycle, such as:
At each closeout phase; When developing a new product, upgrading a product, or expanding outputs; While improving operations or the product development process; or Until the end of the product life cycle.
At each point, deliverables and knowledge are transferred between the project and operations for implementation of the delivered work. This implementation
36
occurs through a transfer of project resources to operations toward the end of the project, or through a transfer of operational resources to the project at the start.
Operations are ongoing endeavors that produce repetitive outputs, with resources assigned to do basically the same set of tasks according to the standards institutionalized in a product life cycle. Unlike the ongoing nature of operations, projects are temporary endeavors.
1.5.1.1 Operations Management Operations management is a subject area that is outside the scope of formal
project management as described in this standard.
Operations management is an area of management concerned with ongoing production of goods and/or services. It involves ensuring that business operations continue efficiently by using the optimum resources needed and meeting customer demands. It is concerned with managing processes that transform inputs (e.g., materials, components, energy, and labor) into outputs (e.g., products, goods, and/or services).
1.5.1.2 Operational Stakeholders in Project Management While operations management is different from project management (see
1.5.1.1), the needs of stakeholders who perform and conduct business operations are important considerations in projects that will affect their future work and endeavors. Project managers who consider and appropriately include operational stakeholders in all phases of projects, gain insight and avoid unnecessary issues that often arise when their input is overlooked.
Operational stakeholders should be engaged and their needs identified as part of the stakeholder register, and their influence (positive or negative) should be addressed as part of the risk management plan.
The following list includes examples of operational stakeholders (depending upon the business):
Plant operators, Manufacturing line supervisors, Help desk staff, Production system support analysts, Customer service representative, Salespersons, Maintenance workers, Telephone sales personnel, Call center personnel,
37
Retail workers, Line managers, and Training officers.
1.5.2 Organizations and Project Management Organizations use governance to establish strategic direction and performance
parameters. The strategic direction provides the purpose, expectations, goals, and actions necessary to guide business pursuit and is aligned with business objectives. Project management activities should be aligned with top-level business direction, and if there is a change, then project objectives need to be realigned. In a project environment, changes to project objectives affect project efficiency and success. When the business alignment for a project is constant, the chance for project success greatly increases because the project remains aligned with the strategic direction of the organization. Should something change, projects should change accordingly.
1.5.2.1 Project-Based Organizations Project-based organizations (PBOs) refer to various organizational forms that
create temporary systems for carrying out their work. PBOs can be created by different types of organizations (i.e., functional, matrix, or projectized (see 2.1.3)). The use of PBOs may diminish the hierarchy and bureaucracy inside the organizations as the success of the work is measured by the final result rather than by position or politics.
PBOs conduct the majority of their work as projects and/or provide project rather than functional approaches. PBOs can refer to either entire firms (as in telecommunications, oil and gas, construction, consultancy, and professional services) multi-firm consortia, or networks; it is also possible that some large project-based organizations have functional support areas or that the PBO is nested within subsidiaries or divisions of larger corporations.
1.5.2.2 The Link Between Project Management and Organizational Governance
Projects (and programs) are undertaken to achieve strategic business outcomes, for which many organizations now adopt formal organizational governance processes and procedures. Organizational governance criteria can impose constraints on projects—particularly if the project delivers a service which will be subject to strict organizational governance.
Because project success may be judged on the basis of how well the resultant product or service supports organizational governance, it is important for the project manager to be knowledgeable about corporate/organizational governance policies and procedures pertaining to the subject matter of the product or service
38
(e.g., if an organization has adopted policies in support of sustainability practices and the project involves construction of a new office building, the project manager should be aware of sustainability requirements related to building construction.)
1.5.2.3 The Relationship Between Project Management and Organizational Strategy
Organizational strategy should provide guidance and direction to project management—especially when one considers that projects exist to support organizational strategies. Often it is the project sponsor or the portfolio or program manager who identifies alignment or potential conflicts between organizational strategies and project goals and then communicates these to the project manager. If the goals of a project are in conflict with an established organizational strategy, it is incumbent upon the project manager to document and identify such conflicts as early as possible in the project. At times, the development of an organizational strategy could be the goal of a project rather than a guiding principle. In such a case, it is important for the project to specifically define what constitutes an appropriate organizational strategy that will sustain the organization.
1.6 Business Value Business value is a concept that is unique to each organization. Business value is
defined as the entire value of the business; the total sum of all tangible and intangible elements. Examples of tangible elements include monetary assets, fixtures, stockholder equity, and utility. Examples of intangible elements include good will, brand recognition, public benefit, and trademarks. Depending on the organization, business value scope can be short-, medium-, or long-term. Value may be created through the effective management of ongoing operations. However, through the effective use of portfolio, program, and project management, organizations will possess the ability to employ reliable, established processes to meet strategic objectives and obtain greater business value from their project investments. While not all organizations are business driven, all organizations conduct business-related activities. Whether an organization is a government agency or a nonprofit organization, all organizations focus on attaining business value for their activities.
Successful business value realization begins with comprehensive strategic planning and management. Organizational strategy can be expressed through the organization's mission and vision, including orientation to markets, competition, and other environmental factors. Effective organizational strategy provides defined directions for development and growth, in addition to performance metrics for success. In order to bridge the gap between organizational strategy and successful business value realization, the use of portfolio, program, and project management techniques is essential.
39
Portfolio management aligns components (projects, programs, or operations) to the organizational strategy, organized into portfolios or subportfolios to optimize project or program objectives, dependencies, costs, timelines, benefits, resources, and risks. This allows organizations to have an overall view of how the strategic goals are reflected in the portfolio, institute appropriate governance management, and authorize human, financial, or material resources to be allocated based on expected performance and benefits.
Using program management, organizations have the ability to align multiple projects for optimized or integrated costs, schedule, effort, and benefits. Program management focuses on project interdependencies and helps to determine the optimal approach for managing and realizing the desired benefits.
With project management, organizations have the ability to apply knowledge, processes, skills, and tools and techniques that enhance the likelihood of success over a wide range of projects. Project management focuses on the successful delivery of products, services, or results. Within programs and portfolios, projects are a means of achieving organizational strategy and objectives.
Organizations can further facilitate the alignment of these portfolio, program, and project management activities by strengthening organizational enablers such as structural, cultural, technological, and human resource practices. By continuously conducting portfolio strategic alignment and optimization, performing business impact analyses, and developing robust organizational enablers, organizations can achieve successful transitions within the portfolio, program, and project domains and attain effective investment management and business value realization.
1.7 Role of the Project Manager The project manager is the person assigned by the performing organization to
lead the team that is responsible for achieving the project objectives. The role of a project manager is distinct from a functional manager or operations manager. Typically the functional manager is focused on providing management oversight for a functional or a business unit, and operations managers are responsible for ensuring that business operations are efficient.
Depending on the organizational structure, a project manager may report to a functional manager. In other cases, a project manager may be one of several project managers who report to a program or portfolio manager who is ultimately responsible for enterprise-wide projects. In this type of structure, the project manager works closely with the program or portfolio manager to achieve the project objectives and to ensure the project management plan aligns with the overarching program plan. The project manager also works closely and in collaboration with other roles, such as a business analyst, quality assurance manager, and subject matter experts.
40
1.7.1 Responsibilities and Competencies of the Project Manager In general, project managers have the responsibility to satisfy the needs: task
needs, team needs, and individual needs. As project management is a critical strategic discipline, the project manager becomes the link between the strategy and the team. Projects are essential to the growth and survival of organizations. Projects create value in the form of improved business processes, are indispensable in the development of new products and services, and make it easier for companies to respond to changes in the environment, competition, and the marketplace. The project manager's role therefore becomes increasingly strategic. However, understanding and applying the knowledge, tools, and techniques that are recognized as good practice are not sufficient for effective project management. In addition to any area-specific skills and general management proficiencies required for the project, effective project management requires that the project manager possess the following competencies:
Knowledge—Refers to what the project manager knows about project management. Performance—Refers to what the project manager is able to do or accomplish while applying his or her project management knowledge. Personal—Refers to how the project manager behaves when performing the project or related activity. Personal effectiveness encompasses attitudes, core personality characteristics, and leadership, which provides the ability to guide the project team while achieving project objectives and balancing the project constraints.
1.7.2 Interpersonal Skills of a Project Manager Project managers accomplish work through the project team and other
stakeholders. Effective project managers require a balance of technical, interpersonal, and conceptual skills that help them analyze situations and interact appropriately. Appendix X3 on Interpersonal Skills describes important interpersonal skills, such as:
Leadership, Team building, Motivation, Communication, Influencing, Decision making, Political and cultural awareness, Negotiation, Trust building,
41
Conflict management, and Coaching.
1.8 Project Management Body of Knowledge The PMBOK® Guide contains the standard for managing most projects most of
the time across many types of industries. The standard, included in Annex A1, describes the project management processes used to manage a project toward a more successful outcome.
This standard is unique to the project management field and has interrelationships to other project management disciplines such as program management and portfolio management.
Project management standards do not address all details of every topic. This standard is limited to individual projects and the project management processes that are generally recognized as good practice. Other standards may be consulted for additional information on the broader context in which projects are accomplished, such as:
The Standard for Program Management [3] addresses the management of programs, The Standard for Portfolio Management [4] addresses the management of portfolios, Organizational Project Management Maturity Model (OPM3®) [5] examines an enterprise's project management process capabilities.
1The numbers in brackets refer to the list of references at the end of this standard.
42
2
ORGANIZATIONAL INFLUENCES AND PROJECT LIFE CYCLE
Projects and project management take place in an environment that is broader than that of the project itself. Understanding this broader context helps ensure that work is carried out in alignment with the organization's goals and managed in accordance with the organization's established practices. This section describes how organizational influences affect the methods used for staffing, managing, and executing the project. It discusses the influence of stakeholders on the project and its governance, the project team's structure and membership, and different approaches to the phasing and relationship of activities within the project's life cycle. The following major sections are addressed:
2.1 Organizational Influences on Project Management
2.2 Project Stakeholders and Governance
2.3 Project Team
2.4 Project Life Cycle
2.1 Organizational Influences on Project Management An organization's culture, style, and structure influence how its projects are
performed. The organization's level of project management maturity and its project management systems can also influence the project. When a project involves external entities such as those that are part of a joint venture or partnering agreement, the project will be influenced by more than one organization. The following sections describe organizational characteristics, factors, and assets within an enterprise that are likely to influence the project.
2.1.1 Organizational Cultures and Styles Organizations are systematic arrangements of entities (persons and/or
departments) aimed at accomplishing a purpose, which may involve undertaking projects. An organization's culture and style affect how it conducts projects. Cultures and styles are group phenomena known as cultural norms, which develop over time. The norms include established approaches to initiating and planning projects, the means considered acceptable for getting the work done, and recognized authorities who make or influence decisions.
Organizational culture is shaped by the common experiences of members of the
43
organization and most organizations have developed unique cultures over time by practice and common usage. Common experiences include, but are not limited to:
Shared visions, mission, values, beliefs, and expectations; Regulations, policies, methods, and procedures; Motivation and reward systems; Risk tolerance; View of leadership, hierarchy, and authority relationships; Code of conduct, work ethic, and work hours; and Operating environments.
The organization's culture is an enterprise environmental factor, as described in Section 2.1.5. Cultures and styles are learned and shared and may have a strong influence on a project's ability to meet its objectives. A project manager should therefore understand the different organizational styles and cultures that may affect a project. The project manager needs to know which individuals in the organization are the decision makers or influencers and work with them to increase the probability of project success.
In light of globalization, understanding the impact of cultural influences is critical in projects involving diverse organizations and locations around the world. Culture becomes a critical factor in defining project success, and multicultural competence becomes critical for the project manager.
2.1.2 Organizational Communications Project management success in an organization is highly dependent on an
effective organizational communication style, especially in the face of globalization of the project management profession. Organizational communications capabilities have great influence on how projects are conducted. As a consequence, project managers in distant locations are able to more effectively communicate with all relevant stakeholders within the organizational structure to facilitate decision making. Stakeholders and project team members can also use electronic communications (including e-mail, texting, instant messaging, social media, video and web conferencing, and other forms of electronic media) to communicate with the project manager formally or informally.
2.1.3 Organizational Structures Organizational structure is an enterprise environmental factor, which can affect
the availability of resources and influence how projects are conducted (see also Section 2.1.5). Organizational structures range from functional to projectized, with a variety of matrix structures in between. Table 2-1 shows key project-related characteristics of the major types of organizational structures.
44
The classic functional organization, shown in Figure 2-1, is a hierarchy where each employee has one clear superior. Staff members are grouped by specialty, such as production, marketing, engineering, and accounting at the top level. Specialties may be further subdivided into focused functional units, such as mechanical and electrical engineering. Each department in a functional organization will do its project work independently of other departments.
Matrix organizations, as shown in Figures 2-2 through 2-4, reflect a blend of functional and projectized characteristics. Matrix organizations can be classified as weak, balanced, or strong depending on the relative level of power and influence
45
between functional and project managers. Weak matrix organizations maintain many of the characteristics of a functional organization, and the role of the project manager is more of a coordinator or expediter. A project expediter works as staff assistant and communications coordinator. The expediter cannot personally make or enforce decisions. Project coordinators have power to make some decisions, have some authority, and report to a higher-level manager. Strong matrix organizations have many of the characteristics of the projectized organization, and have full-time project managers with considerable authority and full-time project administrative staff. While the balanced matrix organization recognizes the need for a project manager, it does not provide the project manager with the full authority over the project and project funding. Table 2-1 provides additional details of the various matrix organizational structures.
46
At the opposite end of the spectrum to the functional organization is the projectized organization, shown in Figure 2-5. In a projectized organization, team members are often colocated. Most of the organization's resources are involved in project work, and project managers have a great deal of independence and authority. Virtual collaboration techniques are often used to accomplish the benefits of colocated teams. Projectized organizations often have organizational units called
47
departments, but they can either report directly to the project manager or provide support services to the various projects.
Many organizations involve all these structures at various levels, often referred to as a composite organization, as shown in Figure 2-6. For example, even a fundamentally functional organization may create a special project team to handle a critical project. Such a team may have many of the characteristics of a project team in a projectized organization. The team may include full-time staff from different functional departments, may develop its own set of operating procedures, and may even operate outside of the standard, formalized reporting structure during the project. Also, an organization may manage most of its projects in a strong matrix, but allow small projects to be managed by functional departments.
48
Many organizational structures include strategic, middle management, and operational levels. The project manager may interact with all three levels depending on factors such as:
Strategic importance of the project, Capacity of stakeholders to exert influence on the project, Degree of project management maturity, Project management systems, and Organizational communications.
This interaction determines project characteristics such as:
Project manager's level of authority, Resource availability and management, Entity controlling the project budget, Project manager's role, and Project team composition.
2.1.4 Organizational Process Assets Organizational process assets are the plans, processes, policies, procedures, and
knowledge bases specific to and used by the performing organization. They include any artifact, practice, or knowledge from any or all of the organizations involved in the project that can be used to perform or govern the project. The process assets
49
also include the organization's knowledge bases such as lessons learned and historical information. Organizational process assets may include completed schedules, risk data, and earned value data. Organizational process assets are inputs to most planning processes. Throughout the project, the project team members may update and add to the organizational process assets as necessary. Organizational process assets may be grouped into two categories: (1) processes and procedures, and (2) corporate knowledge base.
2.1.4.1 Processes and Procedures The organization's processes and procedures for conducting project work
include, but are not limited to:
Initiating and Planning: Guidelines and criteria for tailoring the organization's set of standard processes and procedures to satisfy the specific needs of the project; Specific organizational standards such as policies (e.g., human resources policies, health and safety policies, ethics policies, and project management policies), product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization); and Templates (e.g., risk register, work breakdown structure, project schedule network diagram, and contract templates).
Executing, Monitoring and Controlling: Change control procedures, including the steps by which performing organization standards, policies, plans, and procedures or any project documents will be modified, and how any changes will be approved and validated; Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions); Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking; Organizational communication requirements (e.g., specific communication technology available, authorized communication media, record retention policies, and security requirements); Procedures for prioritizing, approving, and issuing work authorizations; Risk control procedures, including risk categories, risk statement
50
templates, probability and impact definitions, and probability and impact matrix; and Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria.
Closing: Project closure guidelines or requirements (e.g., lessons learned, final project audits, project evaluations, product validations, and acceptance criteria).
2.1.4.2 Corporate Knowledge Base The organizational knowledge base for storing and retrieving information
includes, but is not limited to:
Configuration management knowledge bases containing the versions and baselines of all performing organization standards, policies, procedures, and any project documents; Financial databases containing information such as labor hours, incurred costs, budgets, and any project cost overruns; Historical information and lessons learned knowledge bases (e.g., project records and documents, all project closure information and documentation, information regarding both the results of previous project selection decisions and previous project performance information, and information from risk management activities); Issue and defect management databases containing issue and defect status, control information, issue and defect resolution, and action item results; Process measurement databases used to collect and make available measurement data on processes and products; and Project files from previous projects (e.g., scope, cost, schedule, and performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact).
2.1.5 Enterprise Environmental Factors Enterprise environmental factors refer to conditions, not under the control of the
project team, that influence, constrain, or direct the project. Enterprise environmental factors are considered inputs to most planning processes, may enhance or constrain project management options, and may have a positive or negative influence on the outcome.
Enterprise environmental factors vary widely in type or nature. Enterprise environmental factors include, but are not limited to:
51
Organizational culture, structure, and governance; Geographic distribution of facilities and resources; Government or industry standards (e.g., regulatory agency regulations, codes of conduct, product standards, quality standards, and workmanship standards); Infrastructure (e.g., existing facilities and capital equipment); Existing human resources (e.g., skills, disciplines, and knowledge, such as design, development, legal, contracting, and purchasing); Personnel administration (e.g., staffing and retention guidelines, employee performance reviews and training records, reward and overtime policy, and time tracking); Company work authorization systems; Marketplace conditions; Stakeholder risk tolerances; Political climate; Organization's established communications channels; Commercial databases (e.g., standardized cost estimating data, industry risk study information, and risk databases); and Project management information system (e.g., an automated tool, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems).
2.2 Project Stakeholders and Governance A stakeholder is an individual, group, or organization who may affect, be
affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. Stakeholders may be actively involved in the project or have interests that may be positively or negatively affected by the performance or completion of the project. Different stakeholders may have competing expectations that might create conflicts within the project. Stakeholders may also exert influence over the project, its deliverables, and the project team in order to achieve a set of outcomes that satisfy strategic business objectives or other needs. Project governance—the alignment of the project with stakeholders’ needs or objectives—is critical to the successful management of stakeholder engagement and the achievement of organizational objectives. Project governance enables organizations to consistently manage projects and maximize the value of project outcomes and align the projects with business strategy. It provides a framework in which the project manager and sponsors can make decisions that satisfy both stakeholder needs and expectations and organizational strategic objectives or address circumstances where these may
52
not be in alignment.
2.2.1 Project Stakeholders Stakeholders include all members of the project team as well as all interested
entities that are internal or external to the organization. The project team identifies internal and external, positive and negative, and performing and advising stakeholders in order to determine the project requirements and the expectations of all parties involved. The project manager should manage the influences of these various stakeholders in relation to the project requirements to ensure a successful outcome. Figure 2-7 illustrates the relationship between the project, the project team, and various stakeholders.
Stakeholders have varying levels of responsibility and authority when participating on a project. This level can change over the course of the project's life cycle. Their involvement may range from occasional contributions in surveys and focus groups to full project sponsorship which includes providing financial, political, or other support. Some stakeholders may also detract from the success of the project, either passively or actively. These stakeholders require the project manager's attention throughout the project's life cycle, as well as planning to address any issues they may raise.
Stakeholder identification is a continuous process throughout the entire project life cycle. Identifying stakeholders, understanding their relative degree of influence on a project, and balancing their demands, needs, and expectations are critical to the success of the project. Failure to do so can lead to delays, cost increases,
53
unexpected issues, and other negative consequences including project cancellation. An example is late recognition that the legal department is a significant stakeholder, which results in delays and increased expenses due to legal requirements that are required to be met before the project can be completed or the product scope is delivered.
Just as stakeholders can positively or adversely impact a project's objectives, a project can be perceived by the stakeholders as having positive or negative results. For example, business leaders from a community who will benefit from an industrial expansion project will see positive economic benefits to the community in the form of additional jobs, supporting infrastructure, and taxes. In the case of stakeholders with positive expectations for the project, their interests are best served by making the project successful. In contrast, the interests of negatively affected stakeholders, such as nearby homeowners or small business owners who may lose property, be forced to relocate, or accept unwanted changes in the local environment, are served by impeding the project's progress. Overlooking negative stakeholder interests can result in an increased likelihood of failures, delays, or other negative consequences to the project.
An important part of a project manager's responsibility is to manage stakeholder expectations, which can be difficult because stakeholders often have very different or conflicting objectives. Part of the project manager's responsibility is to balance these interests and ensure that the project team interacts with stakeholders in a professional and cooperative manner. Project managers may involve the project's sponsor or other team members from different locations to identify and manage stakeholders that could be dispersed around the world.
The following are some examples of project stakeholders:
Sponsor. A sponsor is the person or group who provides resources and support for the project and is accountable for enabling success. The sponsor may be external or internal to the project manager's organization. From initial conception through project closure, the sponsor promotes the project. This includes serving as spokesperson to higher levels of management to gather support throughout the organization and promoting the benefits the project brings. The sponsor leads the project through the initiating processes until formally authorized, and plays a significant role in the development of the initial scope and charter. For issues that are beyond the control of the project manager, the sponsor serves as an escalation path. The sponsor may also be involved in other important issues such as authorizing changes in scope, phase-end reviews, and go/no-go decisions when risks are particularly high. The sponsor also ensures a smooth transfer of the project's deliverables into the business of the requesting organization after project closure. Customers and users. Customers are the persons or organizations who will
54
approve and manage the project's product, service, or result. Users are the persons or organizations who will use the project's product, service, or result. Customers and users may be internal or external to the performing organization and may also exist in multiple layers. For example, the customers for a new pharmaceutical product could include the doctors who prescribe it, the patients who use it and the insurers who pay for it. In some application areas, customers and users are synonymous, while in others, customers refer to the entity acquiring the project's product, and users refer to those who will directly utilize the project's product. Sellers. Sellers, also called vendors, suppliers, or contractors, are external companies that enter into a contractual agreement to provide components or services necessary for the project. Business partners. Business partners are external organizations that have a special relationship with the enterprise, sometimes attained through a certification process. Business partners provide specialized expertise or fill a specified role such as installation, customization, training, or support. Organizational groups. Organizational groups are internal stakeholders who are affected by the activities of the project team. Examples of various business elements of an organization that may be affected by the project include marketing and sales, human resources, legal, finance, operations, manufacturing, and customer service. These groups support the business environment where projects are executed, and are therefore affected by the activities of the project. As a result, there is generally a significant amount of interaction between the various business elements of an organization and the project team as they work together to achieve project goals. These groups may provide input to requirements and accept deliverables necessary for a smooth transition to production or related operations. Functional managers. Functional managers are key individuals who play a management role within an administrative or functional area of the business, such as human resources, finance, accounting, or procurement. They are assigned their own permanent staff to carry out the ongoing work, and they have a clear directive to manage all tasks within their functional area of responsibility. The functional manager may provide subject matter expertise or their function may provide services to the project. Other stakeholders. Additional stakeholders, such as procurement entities, financial institutions, government regulators, subject matter experts, consultants, and others, may have a financial interest in the project, contribute inputs to the project, or have an interest in the outcome of the project.
Project stakeholders and stakeholder engagement are further defined in Section 13 on Project Stakeholder Management.
55
2.2.2 Project Governance Project governance is an oversight function that is aligned with the organization's
governance model and that encompasses the project life cycle. Project governance framework provides the project manager and team with structure, processes, decision-making models and tools for managing the project, while supporting and controlling the project for successful delivery. Project governance is a critical element of any project, especially on complex and risky projects. It provides a comprehensive, consistent method of controlling the project and ensuring its success by defining and documenting and communicating reliable, repeatable project practices. It includes a framework for making project decisions; defines roles, responsibilities, and accountabilities for the success of the project; and determines the effectiveness of the project manager. A project's governance is defined by and fits within the larger context of the portfolio, program, or organization sponsoring it but is separate from organizational governance.
For project governance, the PMO may also play some decisive role. Project governance involves stakeholders as well as documented policies, procedures, and standards; responsibilities; and authorities. Examples of the elements of a project governance framework include:
Project success and deliverable acceptance criteria; Process to identify, escalate, and resolve issues that arise during the project; Relationship among the project team, organizational groups, and external stakeholders; Project organization chart that identifies project roles; Processes and procedures for the communication of information; Project decision-making processes; Guidelines for aligning project governance and organizational strategy; Project life cycle approach; Process for stage gate or phase reviews; Process for review and approval for changes to budget, scope, quality, and schedule which are beyond the authority of the project manager; and Process to align internal stakeholders with project process requirements.
Within those constraints, as well as the additional limitations of time and budget, it is up to the project manager and the project team to determine the most appropriate method of carrying out the project. While project governance is the framework in which the project team performs, the team is still responsible for planning, executing, controlling, and closing the project. The project governance approach should be described in the project management plan. Decisions are made
56
regarding who will be involved, the escalation procedures, what resources are necessary, and the general approach to completing the work. Another important consideration is whether more than one phase will be involved and, if so, the specific life cycle for the individual project.
2.2.3 Project Success Since projects are temporary in nature, the success of the project should be
measured in terms of completing the project within the constraints of scope, time, cost, quality, resources, and risk as approved between the project managers and senior management. To ensure realization of benefits for the undertaken project, a test period (such as soft launch in services) can be part of the total project time before handing it over to the permanent operations. Project success should be referred to the last baselines approved by the authorized stakeholders.
The project manager is responsible and accountable for setting realistic and achievable boundaries for the project and to accomplish the project within the approved baselines.
2.3 Project Team The project team includes the project manager and the group of individuals who
act together in performing the work of the project to achieve its objectives. The project team includes the project manager, project management staff, and other team members who carry out the work but who are not necessarily involved with management of the project. This team is comprised of individuals from different groups with specific subject matter knowledge or with a specific skill set to carry out the work of the project. The structure and characteristics of a project team can vary widely, but one constant is the project manager's role as the leader of the team, regardless of what authority the project manager may have over its members.
Project teams include roles such as:
Project management staff. The members of the team who perform project management activities such as scheduling, budgeting, reporting and control, communications, risk management and administrative support. This role may be performed or supported by a project management office (PMO). Project staff. The members of the team who carry out the work of creating the project deliverables. Supporting experts. Supporting experts perform activities required to develop or execute the project management plan. These can include such roles as contracting, financial management, logistics, legal, safety, engineering, test, or quality control. Depending on the size of the project and level of support required, supporting experts may be assigned to work full time or may just participate on the team when their particular skills are
57
required. User or Customer Representatives. Members of the organization who will accept the deliverables or products of the project may be assigned to act as representatives or liaisons to ensure proper coordination, advise on requirements, or validate the acceptability of the project's results. Sellers. Sellers, also called vendors, suppliers, or contractors, are external companies that enter into a contractual agreement to provide components or services necessary for the project. The project team is often assigned the responsibility to oversee the performance and acceptance of sellers’ deliverables or services. If the sellers bear a large share of the risk for delivering the project's results, they may play a significant role on the project team. Business partner members. Members of business partners’ organizations may be assigned as members of the project team to ensure proper coordination. Business partners. Business partners are also external companies, but they have a special relationship with the enterprise, sometimes attained through a certification process. Business partners provide specialized expertise or fill a specified role such as installation, customization, training, or support.
2.3.1 Composition of Project Teams The composition of project teams varies based on factors such as organizational
culture, scope, and location. The relationship between the project manager and the team varies depending on the authority of the project manager. In some cases, a project manager may be the team's line manager, with full authority over its members. In other cases, a project manager may have little or no direct organizational authority over the team members and may have been brought in to lead the project on a part-time basis or under contract. The following are examples of basic project team compositions:
Dedicated. In a dedicated team, all or a majority of the project team members are assigned to work full-time on the project. The project team may be colocated or virtual and usually reports directly to the project manager. This is the simplest structure for a project manager, as the lines of authority are clear and team members can focus on the project's objectives. Part-Time. Some projects are established as temporary additional work, with the project manager and team members working on the project while remaining in their existing organizations and continuing to carry out their normal functions. The functional managers maintain control over the team members and the resources allocated to the project, and the project manager is likely to continue performing other management duties. Part-time team members may also be assigned to more than one project at a time.
58
Dedicated and part-time project team compositions may exist in any of the organizational structures. Dedicated project teams are often seen in projectized organizations, where most of the organization's resources are involved in project work and project managers have a great deal of independence and authority. Part- time project teams are common within functional organizations, and matrix organizations use both dedicated and part-time project teams. Other members who have limited involvement at various stages of a project can be thought of as part- time project team members.
Project team composition may also vary based on organizational structure. An example of this is a partnership-based project. A project may be established as a partnership, joint venture, consortium, or alliance among several organizations through contracts or agreements. In this structure, one organization takes the lead and assigns a project manager to coordinate the efforts among the partners. Partnership-based projects can offer flexibility at lower cost. These advantages may be offset by the project manager's lower degree of control over team members and the need for strong mechanisms for communication and monitoring progress. Partnership projects may be set up to exploit industrial synergies, to undertake ventures that one partner could not afford alone, or for other political and strategic reasons.
Project team composition may also vary based on the geographic location of its members. An example of this is virtual project teams. Communication technologies allow team members in different locations or countries to work as virtual teams. Virtual teams rely on collaborative tools, such as shared online workspaces and video conferences, to coordinate their activities and exchange information about the project. A virtual team can exist with any type of organizational structure and team composition. Virtual teams are often necessary for projects where resources are located onsite or offsite or both, depending on the project activities. A project manager who is leading a virtual team needs to accommodate differences in the culture, working hours, time zones, local conditions, and languages.
2.4 Project Life Cycle A project life cycle is the series of phases that a project passes through from its
initiation to its closure. The phases are generally sequential, and their names and numbers are determined by the management and control needs of the organization or organizations involved in the project, the nature of the project itself, and its area of application. The phases can be broken down by functional or partial objectives, intermediate results or deliverables, specific milestones within the overall scope of work, or financial availability. Phases are generally time bounded, with a start and ending or control point. A life cycle can be documented within a methodology. The project life cycle can be determined or shaped by the unique aspects of the organization, industry, or technology employed. While every project has a definite
59
start and a definite end, the specific deliverables and activities that take place in between will vary widely with the project. The life cycle provides the basic framework for managing the project, regardless of the specific work involved.
Project life cycles can range along a continuum from predictive or plan-driven approaches at one end to adaptive or change-driven approaches at the other. In a predictive life cycle (Section 2.4.2.2), the product and deliverables are defined at the beginning of the project and any changes to scope are carefully managed. In an adaptive life cycle (Section 2.4.2.4), the product is developed over multiple iterations and detailed scope is defined for each iteration only as the iteration begins.
2.4.1 Characteristics of the Project Life Cycle Projects vary in size and complexity. All projects can be mapped to the
following generic life cycle structure (see Figure 2-8):
Starting the project, Organizing and preparing, Carrying out the project work, and Closing the project.
This generic life cycle structure is often referred to when communicating with upper management or other entities less familiar with the details of the project. It should not be confused with the Project Management Process Groups, because the processes in a Process Group consist of activities that may be performed and recur within each phase of a project as well as for the project as a whole. The project life cycle is independent from the life cycle of the product produced by or modified by the project. However, the project should take the current life-cycle phase of the product into consideration. This high-level view can provide a common frame of reference for comparing projects—even if they are dissimilar in nature.
60
The generic life cycle structure generally displays the following characteristics:
Cost and staffing levels are low at the start, peak as the work is carried out, and drop rapidly as the project draws to a close. Figure 2-8 illustrates this typical pattern. The typical cost and staffing curve above may not apply to all projects. A project may require significant expenditures to secure needed resources early in its life cycle, for instance, or be fully staffed from a point very early in its life cycle. Risk and uncertainty (as illustrated in Figure 2-9) are greatest at the start of the project. These factors decrease over the life of the project as decisions are reached and as deliverables are accepted. The ability to influence the final characteristics of the project's product, without significantly impacting cost, is highest at the start of the project and decreases as the project progresses towards completion. Figure 2-9 illustrates the idea that the cost of making changes and correcting errors typically increases substantially as the project approaches completion.
While these characteristics remain present to some extent in almost all project life cycles, they are not always present to the same degree. Adaptive life cycles, in particular, are developed with the intent of keeping stakeholder influences higher and the costs of changes lower throughout the life cycle than in predictive life cycles.
61
Within the context of the generic life cycle structure, a project manager may determine the need for more effective control over certain deliverables or that certain deliverables are required to be completed before the project scope can be completely defined. Large and complex projects in particular may require this additional level of control. In such instances, the work carried out to complete the project's objective may benefit from being formally divided into phases.
2.4.2 Project Phases A project may be divided into any number of phases. A project phase is a
collection of logically related project activities that culminates in the completion of one or more deliverables. Project phases are used when the nature of the work to be performed is unique to a portion of the project, and are typically linked to the development of a specific major deliverable. A phase may emphasize processes from a particular Project Management Process Group, but it is likely that most or all processes will be executed in some form in each phase. Project phases typically are completed sequentially, but can overlap in some project situations. Different phases typically have a different duration or effort. The high-level nature of project phases makes them an element of the project life cycle.
The phase structure allows the project to be segmented into logical subsets for ease of management, planning, and control. The number of phases, the need for phases, and the degree of control applied depend on the size, complexity, and potential impact of the project. Regardless of the number of phases comprising a project, all phases have similar characteristics:
The work has a distinct focus that differs from any other phase. This often
62
involves different organizations, locations, and skill sets. Achieving the primary deliverable or objective of the phase requires controls or processes unique to the phase or its activities. The repetition of processes across all five Process Groups, as described in Section 3, provides an additional degree of control and defines the boundaries of the phase. The closure of a phase ends with some form of transfer or hand-off of the work product produced as the phase deliverable. This phase end represents a natural point to reassess the activities underway and to change or terminate the project if necessary. This point may be referred to as a stage gate, milestone, phase review, phase gate or kill point. In many cases, the closure of a phase is required to be approved in some form before it can be considered closed.
There is no single ideal structure that will apply to all projects. Although industry common practices will often lead to the use of a preferred structure, projects in the same industry—or even in the same organization—may have significant variation. Some will have only one phase, as shown in Figure 2-10. Other projects may have two or more phases.
Some organizations have established policies that standardize all projects, while others allow the project team to choose and tailor the most appropriate approach for their individual project. For instance, one organization may treat a feasibility study as routine pre-project work, another may treat it as the first phase of a project, and a third may treat the feasibility study as a separate, stand-alone project. Likewise, one project team may divide a project into two phases whereas another project team may choose to manage all the work as a single phase. Much depends on the nature of the specific project and the style of the project team or organization.
63
2.4.2.1 Phase-to-Phase Relationships When projects have more than one phase, the phases are part of a generally
sequential process designed to ensure proper control of the project and attain the desired product, service, or result. However, there are situations when a project might benefit from overlapping or concurrent phases.
There are two basic types of phase-to-phase relationships:
Sequential relationship. In a sequential relationship, a phase starts only when the previous phase is complete. Figure 2-11 shows an example of a project with three entirely sequential phases. The step-by-step nature of this approach reduces uncertainty, but may eliminate options for reducing the overall schedule.
Overlapping relationship. In an overlapping relationship, a phase starts prior to completion of the previous one (see Figure 2-12). This can sometimes be applied as an example of the schedule compression technique called fast tracking. Overlapping phases may require additional resources to allow work to be done in parallel, may increase risk, and can result in rework if a subsequent phase progresses before accurate information is available from the previous phase.
64
For projects with more than one phase, there may be different relationships (overlapping, sequential, parallel) between individual phases. Considerations such as level of control required, effectiveness, and degree of uncertainty determine the relationship to be applied between phases. Based on those considerations, both relationships could occur between different phases of a single project.
2.4.2.2 Predictive Life Cycles Predictive life cycles (also known as fully plan-driven) are ones in which the
project scope, and the time and cost required to deliver that scope, are determined as early in the project life cycle as practically possible. As shown in Figure 2-13, these projects proceed through a series of sequential or overlapping phases, with each phase generally focusing on a subset of project activities and project management processes. The work performed in each phase is usually different in nature to that in the preceding and subsequent phases, therefore, the makeup and skills required of the project team may vary from phase to phase.
65
When the project is initiated, the project team will focus on defining the overall scope for the product and project, develop a plan to deliver the product (and any associated deliverables), and then proceed through phases to execute the plan within that scope. Changes to the project scope are carefully managed and require re planning and formal acceptance of the new scope.
Predictive life cycles are generally preferred when the product to be delivered is well understood, there is a substantial base of industry practice, or where a product is required to be delivered in full to have value to stakeholder groups.
Even projects with predictive life cycles may use the concept of rolling wave planning, where a more general, high-level plan is available and more detailed planning is executed for appropriate time windows, as new work activities are approaching and resources are to be assigned.
2.4.2.3 Iterative and Incremental Life Cycles Iterative and incremental life cycles are ones in which project phases (also
called iterations) intentionally repeat one or more project activities as the project team's understanding of the product increases. Iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the product. These life cycles develop the product both iteratively and incrementally.
66
Iterative and incremental projects may proceed in phases, and the iterations themselves will be performed in a sequential or overlapping fashion. During an iteration, activities from all Project Management Process Groups will be performed. At the end of each iteration, a deliverable or set of deliverables will be completed. Future iterations may enhance those deliverables or create new ones. Each iteration incrementally builds the deliverables until the exit criteria for the phase are met, allowing the project team to incorporate feedback.
In most iterative life cycles, a high-level vision will be developed for the overall undertaking, but the detailed scope is elaborated one iteration at a time. Often the planning for the next iteration is carried out as work progresses on the current iteration's scope and deliverables. The work required for a given set of deliverables may vary in duration and effort, and the project team may change between or during iterations. Those deliverables that are not addressed within the scope of the current iteration are typically scoped at a high level only and may be tentatively assigned to a specific future iteration. Changes to the scope of an iteration are carefully managed once work begins.
Iterative and incremental life cycles are generally preferred when an organization needs to manage changing objectives and scope, to reduce the complexity of a project, or when the partial delivery of a product is beneficial and provides value for one or more stakeholder groups without impact to the final deliverable or set of deliverables. Large and complex projects are frequently executed in an iterative fashion to reduce risk by allowing the team to incorporate feedback and lessons learned between iterations.
2.4.2.4 Adaptive Life Cycles Adaptive life cycles (also known as change-driven or agile methods) are
intended to respond to high levels of change and ongoing stakeholder involvement. Adaptive methods are also iterative and incremental, but differ in that iterations are very rapid (usually with a duration of 2 to 4 weeks) and are fixed in time and cost. Adaptive projects generally perform several processes in each iteration, although early iterations may concentrate more on planning activities.
The overall scope of the project will be decomposed into a set of requirements and work to be performed, sometimes referred to as a product backlog. At the beginning of an iteration, the team will work to determine how many of the highest priority items on the backlog list can be delivered within the next iteration. At the end of each iteration, the product should be ready for review by the customer. This does not mean that the customer is required to accept delivery, just that the product should not include unfinished, incomplete, or unusable features. The sponsor and customer representatives should be continuously engaged with the project to provide feedback on deliverables as they are created and to ensure that the product backlog reflects their current needs.
67
Adaptive methods are generally preferred when dealing with a rapidly changing environment, when requirements and scope are difficult to define in advance, and when it is possible to define small incremental improvements that will deliver value to stakeholders.
68
3
PROJECT MANAGEMENT PROCESSES Project management is the application of knowledge, skills, tools, and techniques
to project activities to meet the project requirements. This application of knowledge requires the effective management of the project management processes.
A process is a set of interrelated actions and activities performed to create a pre- specified product, service, or result. Each process is characterized by its inputs, the tools and techniques that can be applied, and the resulting outputs. As explained in Section 2, the project manager needs to consider organizational process assets and enterprise environmental factors. These should be taken into account for every process, even if they are not explicitly listed as inputs in the process specification. Organizational process assets provide guidelines and criteria for tailoring the organization's processes to the specific needs of the project. Enterprise environmental factors may constrain the project management options.
In order for a project to be successful, the project team should:
Select appropriate processes required to meet the project objectives; Use a defined approach that can be adapted to meet requirements; Establish and maintain appropriate communication and engagement with stakeholders; Comply with requirements to meet stakeholder needs and expectations; and Balance the competing constraints of scope, schedule, budget, quality, resources, and risk to produce the specified product, service, or result.
The project processes are performed by the project team with stakeholder interaction and generally fall into one of two major categories:
Project management processes. These processes ensure the effective flow of the project throughout its life cycle. These processes encompass the tools and techniques involved in applying the skills and capabilities described in the Knowledge Areas (Sections 4 through 13). Product-oriented processes. These processes specify and create the project's product. Product-oriented processes are typically defined by the project life cycle (as discussed in Section 2.4) and vary by application area as well as the phase of the product life cycle. The scope of the project cannot be defined without some basic understanding of how to create the specified product. For example, various construction techniques and tools need to be considered when determining the overall complexity of the house to be built.
69
The PMBOK® Guide describes only the project management processes. Although product-oriented processes are outside the scope of this document, they should not be ignored by the project manager and project team. Project management processes and product-oriented processes overlap and interact throughout the life of a project.
Project management processes apply globally and across industry groups. Good practice means there is general agreement that the application of project management processes has been shown to enhance the chances of success over a wide range of projects. Good practice does not mean that the knowledge, skills, and processes described should always be applied uniformly on all projects. For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process.
Project managers and their teams should carefully address each process and its inputs and outputs and determine which are applicable to the project they are working on. The PMBOK® Guide may be used as a resource in managing a project while considering the overall approach and methodology to be followed for the project. This effort is known as tailoring.
Project management is an integrative undertaking that requires each project and product process to be appropriately aligned and connected with the other processes to facilitate coordination. Actions taken during one process typically affect that process and other related processes. For example, a scope change typically affects project cost, but it may not affect the communications management plan or level of risk. These process interactions often require tradeoffs among project requirements and objectives, and the specific performance tradeoffs will vary from project to project and organization to organization. Successful project management includes actively managing these interactions to meet sponsor, customer, and other stakeholder requirements. In some circumstances, a process or set of processes will need to be iterated several times in order to achieve the required outcome.
Projects exist within an organization and do not operate as a closed system. They require input data from the organization and beyond, and deliver capabilities back to the organization. The project processes may generate information to improve the management of future projects and organizational process assets.
The PMBOK® Guide describes the nature of project management processes in terms of the integration between the processes, their interactions, and the purposes they serve. Project management processes are grouped into five categories known as Project Management Process Groups (or Process Groups):
Initiating Process Group. Those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase.
70
Planning Process Group. Those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve. Executing Process Group. Those processes performed to complete the work defined in the project management plan to satisfy the project specifications. Monitoring and Controlling Process Group. Those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes. Closing Process Group. Those processes performed to finalize all activities across all Process Groups to formally close the project or phase.
The remainder of this section provides information for project management of a single project organized as a network of interlinked processes, details the project management processes, and includes the following major sections:
3.1 Common Project Management Process Interactions
3.2 Project Management Process Groups
3.3 Initiating Process Group
3.4 Planning Process Group
3.5 Executing Process Group
3.6 Monitoring and Controlling Process Group
3.7 Closing Process Group
3.8 Project Information
3.9 Role of the Knowledge Areas
3.1 Common Project Management Process Interactions The project management processes are presented as discrete elements with well-
defined interfaces. However, in practice they overlap and interact in ways that are not completely detailed in this document. Most experienced project management practitioners recognize there is more than one way to manage a project. The required Process Groups and their processes are guides for applying appropriate project management knowledge and skills during the project. The application of the project management processes is iterative, and many processes are repeated during the project.
The integrative nature of project management requires the Monitoring and Controlling Process Group to interact with the other Process Groups, as shown in
71
Figure 3-1. Monitoring and Controlling processes occur at the same time as processes contained within other Process Groups. Thus, the Monitoring and Controlling Process is pictured as a “background” Process Group for the other four Process Groups shown in Figure 3-1.
Project Management Process Groups are linked by the outputs which are produced. The Process Groups are seldom either discrete or one-time events; they are overlapping activities that occur throughout the project. The output of one process generally becomes an input to another process or is a deliverable of the project, subproject, or project phase. Deliverables at the subproject or project level may be called incremental deliverables. The Planning Process Group provides the Executing Process Group with the project management plan and project documents, and, as the project progresses, it often creates updates to the project management plan and the project documents. Figure 3-2 illustrates how the Process Groups interact and shows the level of overlap at various times. If the project is divided into phases, the Process Groups interact within each phase.
72
An example of this interaction is the exit of a design phase, which requires sponsor acceptance of the design document. Once it is available, the design document provides the product description for the Planning and Executing Process Groups in one or more subsequent phases. When a project is divided into phases, the Process Groups are used, as appropriate, to effectively drive the project to completion in a controlled manner. In multiphase projects, processes are repeated within each phase until the criteria for phase completion have been satisfied. Additional information on project organization, life cycles, and project phases is provided in Section 2.
3.2 Project Management Process Groups The following sections identify and describe the five Project Management
Process Groups required for any project. These five Process Groups have clear dependencies and are typically performed in each project and highly interact with one another. These five Process Groups are independent of application areas or industry focus. Individual Process Groups and individual processes are often iterated prior to completing the project and can have interactions within a Process Group and among Process Groups. The nature of these interactions varies from project to project and may or may not be performed in a particular order.
The process flow diagram, Figure 3-3, provides an overall summary of the basic flow and interactions among Process Groups and specific stakeholders. The project management processes are linked by specific inputs and outputs where the result or outcome of one process becomes the input to another process but not necessarily in the same Process Group. The Process Groups are not project life cycle phases.
73
In fact, it is possible that all Process Groups could be conducted within a phase. As projects are separated into distinct phases or subcomponents, such as concept development, feasibility study, design, prototype, build, or test, etc., all of the Process Groups would normally be repeated for each phase or subcomponent along the lines explained previously and illustrated in Figure 3-2.
The project management processes are shown in the Process Group in which most of the related activities takes place. For example, a process that normally takes place in the planning phase is put into the Planning Process Group. When this process is updated by an Executing Process Group process or activity, it is not considered a new process within the Executing Process Group but is still a Planning Process Group process or activity. The iterative nature of project management means that processes from any group may be reused throughout the project life cycle. For example, in response to a risk event, executing a risk response may trigger further analysis, which leads to another iteration of the Identify Risks process and the associated Perform Quantitative Risk Analysis and Perform Qualitative Risk Analysis processes to evaluate the impact.
74
3.3 Initiating Process Group The Initiating Process Group consists of those processes performed to define a
new project or a new phase of an existing project by obtaining authorization to start the project or phase. Within the Initiating processes, the initial scope is defined and initial financial resources are committed. Internal and external stakeholders who
75
will interact and influence the overall outcome of the project are identified. If not already assigned, the project manager will be selected. This information is captured in the project charter and stakeholder register. When the project charter is approved, the project becomes officially authorized. Although the project management team may help write the project charter, this standard assumes that business case assessment, approval, and funding are handled externally to the project boundaries (Figure 3-4). A project boundary is defined as the point in time at which the start or completion of the project or a project phase is authorized. The key purpose of this Process Group is to align the stakeholders’ expectations with the project's purpose, give them visibility about the scope and objectives, show how their participation in the project and its associated phases can ensure that their expectations are achieved. These processes help set the vision of the project—what is needed to be accomplished.
Large complex projects should be divided into separate phases. In such projects, the Initiating processes are carried out during subsequent phases to validate the decisions made during the original Develop Project Charter and Identify Stakeholders processes. Performing the Initiating processes at the start of each phase helps to keep the project focused on the business need that the project was undertaken to address. The success criteria are verified, and the influence, drivers and objectives of the project stakeholders are reviewed. A decision is then made as to whether the project should be continued, delayed, or discontinued.
Involving the sponsors, customers, and other stakeholders during initiation creates a shared understanding of success criteria, reduces the overhead of involvement, and generally improves deliverable acceptance, customer satisfaction, and other stakeholder satisfaction.
Initiating processes may be performed at the organizational, program, or
76
portfolio level and therefore, would be outside of the project's level of control. For example, prior to commencing a project, the need for high-level requirements may be documented as part of a larger organizational initiative. A process of evaluating alternatives may be utilized to determine the feasibility of the new undertaking. Clear descriptions of the project objectives may be developed, including the reasons why a specific project is the best alternative to satisfy the requirements. The documentation for this decision may also contain the initial project scope statement, deliverables, project duration, and a forecast of the resources for the organization's investment analysis. As part of the Initiating processes, the project manager is given the authority to apply organizational resources to the subsequent project activities.
3.4 Planning Process Group The Planning Process Group consists of those processes performed to establish
the total scope of the effort, define and refine the objectives, and develop the course of action required to attain those objectives. The Planning processes develop the project management plan and the project documents that will be used to carry out the project. The complex nature of project management may require the use of repeated feedback loops for additional analysis. As more project information or characteristics are gathered and understood, additional planning will likely be required. Significant changes occurring throughout the project life cycle trigger a need to revisit one or more of the planning processes and possibly some of the initiating processes. This progressive detailing of the project management plan is called progressive elaboration, indicating that planning and documentation are iterative and ongoing activities. The key benefit of this Process Group is to delineate the strategy and tactics as well as the course of action or path to successfully complete the project or phase. When the Planning Process Group is well managed, it is much easier to get stakeholder buy-in and engagement. These processes express how this will be done, setting the route to the desired objective.
The project management plan and project documents developed as outputs from the Planning Process Group will explore all aspects of the scope, time, cost, quality, communications, human resources, risks, procurements, and stakeholder engagement.
Updates arising from approved changes during the project (generally during Monitoring and Controlling processes and specifically during the Direct and Manage Project Work Process) may significantly impact parts of the project management plan and the project documents. Updates to these documents provide greater precision with respect to schedule, costs, and resource requirements to meet the defined project scope.
The project team seeks input and encourages involvement from all stakeholders when planning the project and developing the project management plan and project
77
documents. While the act of collecting feedback and refining the documents cannot continue indefinitely, procedures set by the organization dictate when the initial planning ends. These procedures will be affected by the nature of the project, the established project boundaries, appropriate monitoring and controlling activities, as well as the environment in which the project will be performed.
Other interactions among the processes within the Planning Process Group are dependent upon the nature of the project. For example, for some projects there will be little or no identifiable risks until after a significant amount of planning has been done. At that time, the team might recognize that the cost and schedule targets are overly aggressive, thus involving considerably more risk than previously understood. The results of the iterations are documented as updates to the project management plan or to various project documents.
3.5 Executing Process Group The Executing Process Group consists of those processes performed to complete
the work defined in the project management plan to satisfy the project specifications. This Process Group involves coordinating people and resources, managing stakeholder expectations, as well as integrating and performing the activities of the project in accordance with the project management plan.
During project execution, results may require planning updates and rebaselining. This may include changes to expected activity durations, changes in resource productivity and availability, and unanticipated risks. Such variances may affect the project management plan or project documents and may require detailed analysis and development of appropriate project management responses. The results of the analysis can trigger change requests that, if approved, may modify the project management plan or other project documents and possibly require establishing new baselines. A large portion of the project's budget will be expended in performing the Executing Process Group processes.
3.6 Monitoring and Controlling Process Group The Monitoring and Controlling Process Group consists of those processes
required to track, review, and orchestrate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes. The key benefit of this Process Group is that project performance is measured and analyzed at regular intervals, appropriate events, or exception conditions to identify variances from the project management plan. The Monitoring and Controlling Process Group also involves:
Controlling changes and recommending corrective or preventive action in anticipation of possible problems, Monitoring the ongoing project activities against the project management
78
plan and the project performance measurement baseline, and Influencing the factors that could circumvent integrated change control or configuration management so only approved changes are implemented.
This continuous monitoring provides the project team insight into the health of the project and identifies any areas requiring additional attention. The Monitoring and Controlling Process Group not only monitors and controls the work being done within a Process Group, but also monitors and controls the entire project effort. In multiphase projects, the Monitoring and Controlling Process Group coordinates project phases in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. This review can result in recommended and approved updates to the project management plan. For example, a missed activity finish date may require adjustments and tradeoffs between budget and schedule objectives. In order to reduce control overhead, management-by-exception procedures and other techniques can be appropriately considered.
3.7 Closing Process Group The Closing Process Group consists of those processes performed to conclude
all activities across all Project Management Process Groups to formally complete the project, phase, or contractual obligations. This Process Group, when completed, verifies that the defined processes are completed within all of the Process Groups to close the project or a project phase, as appropriate, and formally establishes that the project or project phase is complete.
This Process Group also formally establishes the premature closure of the project. Prematurely closed projects may include, for example: aborted projects, cancelled projects, and projects having a critical situation. In specific cases, when some contracts cannot be formally closed (e.g. claims, termination clauses, etc.) or some activities are to be transferred to other organizational units, specific hand- over procedures may be arranged and finalized.
At project or phase closure, the following may occur:
Obtain acceptance by the customer or sponsor to formally close the project or phase, Conduct post-project or phase-end review, Record impacts of tailoring to any process, Document lessons learned, Apply appropriate updates to organizational process assets, Archive all relevant project documents in the project management information system (PMIS) to be used as historical data, Close out all procurement activities ensuring termination of all relevant
79
agreements, and Perform team members’ assessments and release project resources.
3.8 Project Information Throughout the life cycle of the project, a significant amount of data and
information is collected, analyzed, transformed, and distributed in various formats to project team members and other stakeholders. Project data are collected as a result of various Executing processes and are shared within the project team. The collected data are analyzed in context, and aggregated and transformed to become project information during various Controlling processes. The information may then be communicated verbally or stored and distributed as reports in various formats.
The project data are continuously collected and analyzed during the dynamic context of the project execution. As a result, the terms data and information are often used interchangeably in practice. The indiscriminate use of these terms can lead to confusion and misunderstandings by the various project stakeholders. The following guidelines help minimize miscommunication and help the project team use appropriate terminology:
Work performance data. The raw observations and measurements identified during activities performed to carry out the project work. Examples include reported percent of work physically completed, quality and technical performance measures, start and finish dates of schedule activities, number of change requests, number of defects, actual costs, actual durations, etc. Work performance information. The performance data collected from various controlling processes, analyzed in context and integrated based on relationships across areas. Examples of performance information are status of deliverables, implementation status for change requests, and forecasted estimates to complete. Work performance reports. The physical or electronic representation of work performance information compiled in project documents, intended to generate decisions or raise issues, actions, or awareness. Examples include status reports, memos, justifications, information notes, electronic dashboards, recommendations, and updates.
Figure 3-5 illustrates the flow of project information across the various processes used to manage the project.
80
3.9 Role of the Knowledge Areas The 47 project management processes identified in the PMBOK® Guide are
further grouped into ten separate Knowledge Areas. A Knowledge Area represents a complete set of concepts, terms, and activities that make up a professional field, project management field, or area of specialization. These ten Knowledge Areas are used on most projects most of the time. Project teams should utilize these ten Knowledge Areas and other Knowledge Areas, as appropriate, for their specific project. The Knowledge Areas are: Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management, Project Procurement Management and Project Stakeholder Management. Each Knowledge Area within the PMBOK® Guide is contained in a separate section.
The PMBOK® Guide defines the important aspects of each Knowledge Area and how it integrates with the five Process Groups. As supporting elements, the Knowledge Areas provide a detailed description of the process inputs and outputs
81
along with a descriptive explanation of tools and techniques most frequently used within the project management processes to produce each outcome. A data flow diagram is provided in each Knowledge Area (Sections 4 through 13). The data flow diagram is a summary level depiction of the process inputs and process outputs that flow down through all the processes within a specific Knowledge Area (see Figure 3-6 for data flow diagram legend). Although the processes are presented here as discrete elements with well-defined interfaces, in practice they are iterative and can overlap and interact in ways not detailed here.
Table 3-1 reflects the mapping of the 47 project management processes within the 5 Project Management Process Groups and the 10 Knowledge Areas.
82
83
4
PROJECT INTEGRATION MANAGEMENT Project Integration Management includes the processes and activities to identify,
define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups. In the project management context, integration includes characteristics of unification, consolidation, communication, and integrative actions that are crucial to controlled project execution through completion, successfully managing stakeholder expectations, and meeting requirements. Project Integration Management includes making choices about resource allocation, making trade-offs among competing objectives and alternatives, and managing the interdependencies among the project management Knowledge Areas. The project management processes are usually presented as discrete processes with defined interfaces while, in practice, they overlap and interact in ways that cannot be completely detailed in the PMBOK® Guide.
Figure 4-1 provides an overview of the Project Integration Management processes, which are as follows:
4.1 Develop Project Charter—The process of developing a document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.
4.2 Develop Project Management Plan—The process of defining, preparing, and coordinating all subsidiary plans and integrating them into a comprehensive project management plan. The project's integrated baselines and subsidiary plans may be included within the project management plan.
4.3 Direct and Manage Project Work—The process of leading and performing the work defined in the project management plan and implementing approved changes to achieve the project's objectives.
4.4 Monitor and Control Project Work—The process of tracking, reviewing, and reporting project progress against the performance objectives defined in the project management plan.
4.5 Perform Integrated Change Control—The process of reviewing all change requests; approving changes and managing changes to deliverables, organizational process assets, project documents, and the project management plan; and communicating their disposition.
84
4.6 Close Project or Phase—The process of finalizing all activities across all of the Project Management Process Groups to formally complete the phase or project.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
The need for Project Integration Management is necessary in situations where individual processes interact. For example, a cost estimate needed for a contingency plan involves integrating the processes in the Project Cost, Time, and Risk Management Knowledge Areas. When additional risks associated with various staffing alternatives are identified, then one or more of those processes may be revisited. The project deliverables may also need integrating with ongoing operations of the performing organization, the requesting organization, and with the long-term strategic planning that takes future problems and opportunities into consideration. Project Integration Management also includes the activities needed to manage project documents to ensure consistency with the project management plan and product, service, or capability deliverables.
Most experienced project management practitioners know there is no single way to manage a project. They apply project management knowledge, skills, and required processes in a preferred order and with varying rigor to achieve the desired project performance. However, the determination that a particular process is not required does not mean that it should not be addressed. The project manager and project team need to address every process and the project environment to determine the level of implementation for each process within the project. If a project has more than one phase, the level of rigor applied within each of the project phases should be appropriate for each phase. This determination is also addressed by the project manager and project team.
The integrative nature of projects and project management can be understood by thinking of other types of activities performed while completing a project. Examples of some activities performed by the project management team are:
Develop, review, analyze, and understand the scope. This includes the project and product requirements, criteria, assumptions, constraints, and other influences related to a project, and how each will be managed or addressed within the project; Transform the collected project information into a project management plan using a structured approach as described in the PMBOK® Guide; Perform activities to produce project deliverables; and Measure and monitor the project's progress and take appropriate action to meet project objectives.
The links among the processes in the Project Management Process Groups are
85
often iterative in nature. For example, the Planning Process Group provides the Executing Process Group with a documented project management plan early in the project and then updates the project management plan if changes occur as the project progresses.
4.1 Develop Project Charter Develop Project Charter is the process of developing a document that formally
authorizes the existence of a project and provides the project manager with the
86
authority to apply organizational resources to project activities. The key benefit of this process is a well-defined project start and project boundaries, creation of a formal record of the project, and a direct way for senior management to formally accept and commit to the project. The inputs, tools and techniques, and outputs for this process are shown in Figure 4-2. Figure 4-3 depicts the data flow diagram of the process.
87
The project charter establishes a partnership between the performing and requesting organizations. In the case of external projects, a formal contract is typically the preferred way to establish an agreement. In this case, the project team becomes the seller responding to conditions of an offer to buy from an outside entity. A project charter is still used to establish internal agreements within an organization to assure proper delivery under the contract. The approved project charter formally initiates the project. A project manager is identified and assigned as early in the project as is feasible, preferably while the project charter is being developed and always prior to the start of planning. The project charter should be authored by the sponsoring entity. The project charter provides the project manager with the authority to plan and execute the project. It is recommended that the project manager participate in the development of the project charter to obtain a foundational understanding of the project requirements. This understanding will better allow for efficient resources allocation to project activities.
Projects are initiated by an entity external to the project such as a sponsor, program or project management office (PMO) staff person, or a portfolio governing body chairperson or authorized representative. The project initiator or sponsor should be at the level that is appropriate to procure funding and commit resources to the project. Projects are initiated due to internal business needs or external influences. These needs or influences often trigger the creation of a needs analysis, feasibility study, business case, or description of the situation that the project will address. Chartering a project validates alignment of the project to the strategy and ongoing work of the organization. A project charter is not considered to be a contract, because there is no consideration or money promised or exchanged in its creation.
4.1.1 Develop Project Charter: Inputs
4.1.1.1 Project Statement of Work The project statement of work (SOW) is a narrative description of products,
services, or results to be delivered by a project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document, (e.g., a request for proposal, request for information, or request for bid) or as part of a contract. The SOW references the following:
Business need. An organization's business need may be based on a market demand, technological advance, legal requirement, government regulation, or environmental consideration. Typically, the business need and the cost- benefit analysis are contained in the business case to justify the project. Product scope description. The product scope description documents the characteristics of the product, service, or results that the project will be
88
undertaken to create. The description should also document the relationship between the products, services, or results being created and the business need that the project will address. Strategic plan. The strategic plan documents the organization's strategic vision, goals, and objectives and may contain a high-level mission statement. All projects should be aligned with their organization's strategic plan. Strategic plan alignment ensures that each project contributes to the overall objectives of the organization.
4.1.1.2 Business Case The business case or similar document describes the necessary information from
a business standpoint to determine whether or not the project is worth the required investment. It is commonly used for decision making by managers or executives above the project level. Typically, the business need and the cost-benefit analysis are contained in the business case to justify and establish boundaries for the project, and such analysis is usually completed by a business analyst using various stakeholder inputs. The sponsor should agree to the scope and limitations of the business case. The business case is created as a result of one or more of the following:
Market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response to gasoline shortages), Organizational need (e.g., due to high overhead costs a company may combine staff functions and streamline processes to reduce costs.), Customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park), Technological advance (e.g., an airline authorizing a new project to develop electronic tickets instead of paper tickets based on technological advances), Legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials), Ecological impacts (e.g., a company authorizing a project to lessen its environmental impact), or Social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera).
Each of the examples in this list may contain elements of risk that should be addressed. In the case of multiphase projects, the business case may be periodically reviewed to ensure that the project is on track to deliver the business benefits. In the early stages of the project life cycle, periodic review of the business case by the sponsoring organization also helps to confirm that the project is still aligned with the business case. The project manager is responsible for
89
ensuring that the project effectively and efficiently meets the goals of the organization and those requirements of a broad set of stakeholders, as defined in the business case.
4.1.1.3 Agreements Agreements are used to define initial intentions for a project. Agreements may
take the form of contracts, memorandums of understanding (MOUs), service level agreement (SLA), letters of agreement, letters of intent, verbal agreements, email, or other written agreements. Typically, a contract is used when a project is being performed for an external customer.
4.1.1.4 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
influence the Develop Project Charter process include, but are not limited to:
Governmental standards, industry standards, or regulations (e.g. codes of conduct, quality standards, or worker protection standards), Organizational culture and structure, and Marketplace conditions.
4.1.1.5 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Develop Project Charter process include, but are not limited to:
Organizational standard processes, policies, and process definitions, Templates (e.g., project charter template), and Historical information and lessons learned knowledge base (e.g., projects, records, and documents; all project closure information and documentation; information about both the results of previous project selection decisions and previous project performance information; and information from the risk management activity).
4.1.2 Develop Project Charter: Tools and Techniques 4.1.2.1 Expert Judgment
Expert judgment is often used to assess the inputs used to develop the project charter. Expert judgment is applied to all technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training and is available from many sources, including:
Other units within the organization, Consultants, Stakeholders, including customers or sponsors,
90
Professional and technical associations, Industry groups, Subject matter experts (SME), and Project management office (PMO).
4.1.2.2 Facilitation Techniques Facilitation techniques have broad application within project management
processes and guide the development of the project charter. Brainstorming, conflict resolution, problem solving, and meeting management are examples of key techniques used by facilitators to help teams and individuals accomplish project activities.
4.1.3 Develop Project Charter: Outputs 4.1.3.1 Project Charter
The project charter is the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. It documents the business needs, assumptions, constraints, the understanding of the customer's needs and high-level requirements, and the new product, service, or result that it is intended to satisfy, such as:
Project purpose or justification, Measurable project objectives and related success criteria, High-level requirements, Assumptions and constraints, High-level project description and boundaries, High-level risks, Summary milestone schedule, Summary budget, Stakeholder list, Project approval requirements (i.e., what constitutes project success, who decides the project is successful, and who signs off on the project), Assigned project manager, responsibility, and authority level, and Name and authority of the sponsor or other person(s) authorizing the project charter.
4.2 Develop Project Management Plan Develop Project Management Plan is the process of defining, preparing, and
91
coordinating all subsidiary plans and integrating them into a comprehensive project management plan. The key benefit of this process is a central document that defines the basis of all project work. The inputs, tools and techniques, and outputs for this process are depicted in Figure 4-4. Figure 4-5 depicts the data flow diagram of the process.
92
93
The project management plan defines how the project is executed, monitored and controlled, and closed. The project management plan's content varies depending upon the application area and complexity of the project. It is developed through a series of integrated processes extending through project closure. This process results in a project management plan that is progressively elaborated by updates, and controlled and approved through the Perform Integrated Change Control (Section 4.5) process. Projects that exist in the context of a program should develop a project management plan that is consistent with the program management plan. For example, if the program management plan indicates all changes exceeding a specified cost need to be reviewed by the change control board (CCB), then this process and cost threshold needs to be defined in the project management plan.
4.2.1 Develop Project Management Plan: Inputs
4.2.1.1 Project Charter Described in Section 4.1.3.1. The size of the project charter varies depending on
the complexity of the project and the information known at the time of its creation. At a minimum, the project charter should define the high-level boundaries of the project. The project team uses the project charter as the starting point for initial project planning.
4.2.1.2 Outputs from Other Processes Outputs from many of the other processes described in Sections 5 through 13 are
integrated to create the project management plan. Any baselines and subsidiary plans that are an output from other planning processes are inputs to this process. In addition, changes to these documents may necessitate updates to the project management plan.
4.2.1.3 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
influence the Develop Project Management Plan process include, but are not limited to:
Governmental or industry standards; Project management body of knowledge for vertical market (e.g., construction) and/or focus area (e.g. environmental, safety, risk, or agile software development); Project management information system (e.g., an automated tool, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems); Organizational structure, culture, management practices, and sustainability;
94
Infrastructure (e.g., existing facilities and capital equipment); and Personnel administration (e.g., hiring and termination guidelines, employee performance reviews, and employee development and training records).
4.2.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Develop Project Management Plan process include, but are not limited to:
Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria; Project management plan template, including:
Guidelines and criteria for tailoring the organization's set of standard processes to satisfy the specific needs of the project, and Project closure guidelines or requirements such as the product validation and acceptance criteria;
Change control procedures, including the steps by which official organization standards, policies, plans, and procedures, or any project documents will be modified and how any changes will be approved and validated; Project files from previous projects (e.g., scope, cost, schedule and performance measurement baselines, project calendars, project schedule network diagrams, and risk registers); Historical information and lessons learned knowledge base; and Configuration management knowledge base containing the versions and baselines of all official organization standards, policies, procedures, and any project documents.
4.2.2 Develop Project Management Plan: Tools and Techniques 4.2.2.1 Expert Judgment
When developing the project management plan, expert judgment is utilized to:
Tailor the process to meet the project needs, Develop technical and management details to be included in the project management plan, Determine resources and skill levels needed to perform project work, Define the level of configuration management to apply on the project, Determine which project documents will be subject to the formal change control process, and Prioritize the work on the project to ensure the project resources are
95
allocated to the appropriate work at the appropriate time.
4.2.2.2 Facilitation Techniques Described in Section 4.1.2.2. Facilitation techniques have broad application
within project management processes and are used to guide the development of the project management plan. Brainstorming, conflict resolution, problem solving, and meeting management are key techniques used by facilitators to help teams and individuals achieve agreement to accomplish project activities.
4.2.3 Develop Project Management Plan: Outputs 4.2.3.1 Project Management Plan
The project management plan is the document that describes how the project will be executed, monitored, and controlled. It integrates and consolidates all of the subsidiary plans and baselines from the planning processes.
Project baselines include, but are not limited to:
Scope baseline (Section 5.4.3.1), Schedule baseline (Section 6.6.3.1), and Cost baseline (Section 7.3.3.1).
Subsidiary plans include, but are not limited to:
Scope management plan (Section 5.1.3.1), Requirements management plan (Section 5.1.3.2), Schedule management plan (Section 6.1.3.1), Cost management plan (Section 7.1.3.1), Quality management plan (Section 8.1.3.1), Process improvement plan (Section 8.1.3.2), Human resource management plan (Section 9.1.3.1), Communications management plan (Section 10.1.3.1), Risk management plan (Section 11.1.3.1), Procurement management plan (Section 12.1.3.1), and Stakeholder management plan (Section 13.2.3.1).
Among other things, the project management plan may also include the following:
Life cycle selected for the project and the processes that will be applied to each phase; Details of the tailoring decisions specified by the project management team as follows:
Project management processes selected by the project management
96
team, Level of implementation for each selected process, Descriptions of the tools and techniques to be used for accomplishing those processes, and Description of how the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes and the essential inputs and outputs.
Description of how work will be executed to accomplish the project objectives; Change management plan that documents how changes will be monitored and controlled; Configuration management plan that documents how configuration management will be performed; Description of how the integrity of the project baselines will be maintained; Requirements and techniques for communication among stakeholders; and Key management reviews for content, the extent of, and timing to address, open issues and pending decisions.
The project management plan may be either summary level or detailed, and may be composed of one or more subsidiary plans. Each of the subsidiary plans is detailed to the extent required by the specific project. Once the project management plan is baselined, it may only be changed when a change request is generated and approved through the Perform Integrated Change Control process.
While the project management plan is one of the primary documents used to manage the project, other project documents are also used. These other documents are not part of the project management plan. Table 4-1 is a representative list of the project management plan components and project documents.
Table 4-1. Differentiation Between the Project Management Plan and Project Documents
Project Management Plan Project Documents Change management plan Activity attributes Project staff assignments
Communications management plan Activity cost estimates Project statement of work
Configuration management plan Activity duration estimates Quality checklists
Cost baseline Activity list Quality control measurements
Cost management plan Activity resourcerequirements Quality metrics
Human resource management plan Agreements Requirements documentation
Process improvement plan Basis of estimates Requirements traceability matrix
97
Procurement management plan Change log Resource breakdown structure
Scope baseline Project scope statement WBS WBS dictionary
Change requests Resource calendars
Quality management plan Forecasts
Cost forecast Schedule forecast
Risk register
Requirements management plan Issue log Schedule data
Risk management plan Milestone list Seller proposals
Schedule baseline Procurement documents Source selection criteria
Schedule management plan Procurement statement ofwork Stakeholder register
Scope management plan Project calendars Team performance assessments
Stakeholder management plan
Project charter Project funding requirements Project schedule Project schedule network diagrams
Work performance data Work performance information Work performance reports
4.3 Direct and Manage Project Work Direct and Manage Project Work is the process of leading and performing the
work defined in the project management plan and implementing approved changes to achieve the project's objectives. The key benefit of this process is that it provides overall management of the project work. The inputs, tools and techniques, and outputs of this process are depicted in Figure 4-6. Figure 4-7 depicts the data flow diagram of the process.
98
Direct and Manage Project Work activities include, but are not limited to:
Perform activities to accomplish project objectives; Create project deliverables to meet the planned project work; Provide, train, and manage the team members assigned to the project; Obtain, manage, and use resources including materials, tools, equipment, and facilities; Implement the planned methods and standards; Establish and manage project communication channels, both external and internal to the project team; Generate work performance data, such as cost, schedule, technical and quality progress, and status to facilitate forecasting; Issue change requests and implement approved changes into the project's scope, plans, and environment;
99
Manage risks and implement risk response activities; Manage sellers and suppliers; Manage stakeholders and their engagement; and Collect and document lessons learned and implement approved process improvement activities.
The project manager, along with the project management team, directs the performance of the planned project activities and manages the various technical and organizational interfaces that exist within the project. The project manager should also manage any unplanned activities and determine the appropriate course of action. The Direct and Manage Project Work process is directly affected by the project application area. Deliverables are produced as outputs from processes performed to accomplish the project work as planned and scheduled in the project management plan.
During project execution, the work performance data is collected and appropriately actioned and communicated. Work performance data includes information about the completion status of deliverables and other relevant details about project performance. The work performance data will also be used as an input to the Monitoring and Controlling Process Group.
Direct and Manage Project Work also requires review of the impact of all project changes and the implementation of approved changes:
Corrective action—An intentional activity that realigns the performance of the project work with the project management plan; Preventive action—An intentional activity that ensures the future performance of the project work is aligned with the project management plan; and/or Defect repair—An intentional activity to modify a nonconforming product or product component.
4.3.1 Direct and Manage Project Work: Inputs
4.3.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan contains subsidiary
plans concerning all aspects of the project. Those subsidiary plans related to project work include, but are not limited to:
Scope management plan (Section 5.1.3.1), Requirements management plan (Section 5.1.3.2), Schedule management plan (Section 6.1.3.1), Cost management plan (Section 7.1.3.1), and Stakeholder management plan (Section 13.2.3.1).
100
4.3.1.2 Approved Change Requests Approved change requests are an output of the Perform Integrated Change
Control process, and include those requests reviewed and approved for implementation by the change control board (CCB). The approved change request may be a corrective action, a preventive action, or a defect repair. Approved change requests are scheduled and implemented by the project team, and can impact any area of the project or project management plan. The approved change requests can also modify the policies, project management plan, procedures, costs, or budgets or revise the schedules. Approved change requests may require implementation of preventive or corrective actions.
4.3.1.3 Enterprise Environmental Factors Described in Section 2.1.5. The Direct and Manage Project Work process is
influenced by enterprise environmental factors that include, but are not limited to:
Organizational, company, or customer culture and structure of the performing or sponsor organizations; Infrastructure (e.g., existing facilities and capital equipment); Personnel administration (e.g., hiring and firing guidelines, employee performance reviews, and training records); Stakeholder risk tolerances, for example allowable cost overrun percentage; and Project management information system (e.g., an automated tool suite, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems).
4.3.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Direct and Manage Project Work process include, but are not limited to:
Standardized guidelines and work instructions; Communication requirements defining allowed communication media, record retention, and security requirements; Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking; Process measurement database used to collect and make available measurement data on processes and products; Project files from previous projects (e.g., scope, cost, schedule, performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, defined risk
101
impact, and documented lessons learned); and Issue and defect management database(s) containing historical issue and defect status, control information, issue and defect resolution, and action item results.
4.3.2 Direct and Manage Project Work: Tools and Techniques
4.3.2.1 Expert Judgment Expert judgment is used to assess the inputs needed to direct and manage
execution of the project management plan. Such judgment and expertise are applied to all technical and management details during this process. This expertise is provided by the project manager and the project management team using specialized knowledge or training. Additional expertise is available from many sources, including:
Other units within the organization; Consultants and other subject matter experts (internal and external); Stakeholders, including customers, suppliers, or sponsors; and Professional and technical associations.
4.3.2.2 Project Management Information System The project management information system, which is part of the enterprise
environmental factors, provides access to tools, such as a scheduling tool, a work authorization system, a configuration management system, an information collection and distribution system, or interfaces to other online automated systems. Automated gathering and reporting on key performance indicators (KPI) can be part of this system.
4.3.2.3 Meetings Meetings are used to discuss and address pertinent topics of the project when
directing and managing project work. Attendees at the meetings may include the project manager, the project team and appropriate stakeholders involved or affected by the topics addressed. Each attendee should have a defined role to ensure appropriate participation. Meetings tend to be one of three types:
Information exchange; Brainstorming, option evaluation, or design; or Decision making.
Meeting types should not be mixed as a best practice. Meetings should be prepared with a well-defined agenda, purpose, objective, and time frame and should be appropriately documented with meeting minutes and action items. Meeting minutes should be stored as defined in the project management plan.
102
Meetings are most effective when all participants can be face-to-face in the same location. Virtual meetings can be held using audio and/or video conferencing tools, but generally require additional preparation and organization to achieve the same effectiveness of a face-to-face meeting.
4.3.3 Direct and Manage Project Work: Outputs
4.3.3.1 Deliverables A deliverable is any unique and verifiable product, result or capability to
perform a service that is required to be produced to complete a process, phase, or project. Deliverables are typically tangible components completed to meet the project objectives and can include elements of the project management plan.
4.3.3.2 Work Performance Data Work performance data are the raw observations and measurements identified
during activities being performed to carry out the project work. Data are often viewed as the lowest level of detail from which information is derived by other processes. Data is gathered through work execution and passed to the controlling processes for further analysis.
Examples of work performance data include work completed, key performance indicators, technical performance measures, start and finish dates of schedule activities, number of change requests, number of defects, actual costs, and actual durations, etc.
4.3.3.3 Change Requests A change request is a formal proposal to modify any document, deliverable, or
baseline. An approved change request will replace the associated document, deliverable, or baseline and may result in an update to other parts of the project management plan. When issues are found while project work is being performed, change requests are submitted, which may modify project policies or procedures, project scope, project cost or budget, project schedule, or project quality. Other change requests cover the needed preventive or corrective actions to forestall negative impact later in the project. Requests for a change can be direct or indirect, externally or internally initiated, and can be optional or legally/contractually mandated, and may include:
Corrective action—An intentional activity that realigns the performance of the project work with the project management plan; Preventive action—An intentional activity that ensures the future performance of the project work is aligned with the project management plan; Defect repair—An intentional activity to modify a nonconforming product
103
or product component; Updates—Changes to formally controlled project documents, plans, etc., to reflect modified or additional ideas or content.
4.3.3.4 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to:
Scope management plan, Requirements management plan, Schedule management plan, Cost management plan, Quality management plan, Process improvement plan, Human resource management plan, Communications management plan, Risk management plan, Procurement management plan, Stakeholder management plan, and Project baselines.
4.3.3.5 Project Documents Updates Project documents that may be updated include, but are not limited to:
Requirements documentation, Project logs (issues, assumptions, etc.), Risk register, and Stakeholder register.
4.4 Monitor and Control Project Work Monitor and Control Project Work is the process of tracking, reviewing, and
reporting the progress to meet the performance objectives defined in the project management plan. The key benefit of this process is that it allows stakeholders to understand the current state of the project, the steps taken, and budget, schedule, and scope forecasts. The inputs, tools and techniques, and outputs for this process are depicted in Figure 4-8. Figure 4-9 depicts the data flow diagram of the process.
104
105
Monitoring is an aspect of project management performed throughout the project. Monitoring includes collecting, measuring, and distributing performance information, and assessing measurements and trends to effect process improvements. Continuous monitoring gives the project management team insight into the health of the project and identifies any areas that may require special attention. Control includes determining corrective or preventive actions or
106
replanning and following up on action plans to determine whether the actions taken resolved the performance issue. The Monitor and Control Project Work process is concerned with:
Comparing actual project performance against the project management plan; Assessing performance to determine whether any corrective or preventive actions are indicated, and then recommending those actions as necessary; Identifying new risks and analyzing, tracking, and monitoring existing project risks to make sure the risks are identified, their status is reported, and that appropriate risk response plans are being executed; Maintaining an accurate, timely information base concerning the project's product(s) and their associated documentation through project completion; Providing information to support status reporting, progress measurement, and forecasting; Providing forecasts to update current cost and current schedule information; Monitoring implementation of approved changes as they occur; and Providing appropriate reporting on project progress and status to program management when the project is part of an overall program.
4.4.1 Monitor and Control Project Work: Inputs
4.4.1.1 Project Management Plan Described in Section 4.2.3.1. Monitoring and controlling project work involves
looking at all aspects of the project. Subsidiary plans within the project management plan form the basis for controlling the project. Subsidiary plans and baselines include, but are not limited to:
Scope management plan (Section 5.1.3.1), Requirements management plan (Section 5.1.3.2), Schedule management plan (Section 6.1.3.1), Cost management plan (Section 7.1.3.1), Quality management plan (Section 8.1.3.1), Process improvement plan (Section 8.1.3.2), Human resource management plan (Section 9.1.3.1), Communications management plan (Section 10.1.3.1), Risk management plan (Section 11.1.3.1), Procurement management plan (Section 12.1.3.1), Stakeholder management plan (Section 13.2.3.1), Scope baseline (Section 5.4.3.1), Schedule baseline (Section 6.6.3.1), and
107
Cost baseline (Section 7.3.3.1).
4.4.1.2 Schedule Forecasts Described in Section 6.7.3.2. The schedule forecasts are derived from progress
against the schedule baseline and computed time estimate to complete (ETC). This is typically expressed in terms of schedule variance (SV) and schedule performance index (SPI). For projects not using earned value management, variances against the planned finish dates and forecasted finish dates are provided.
The forecast may be used to determine if the project is still within defined tolerance ranges and identify any necessary change requests.
4.4.1.3 Cost Forecasts Described in Section 7.4.3.2. The cost forecasts are derived from progress
against the cost baseline and computed estimates to complete (ETC). This is typically expressed in terms of cost variance (CV) and cost performance index (CPI). An estimate at completion (EAC) can be compared to the budget at completion (BAC) to see if the project is still within tolerance ranges or if a change request is required. For projects not using earned value management, variances against the planned versus actual expenditures and forecasted final costs are provided.
4.4.1.4 Validated Changes Described in Section 8.3.3.2. Approved changes that result from the Perform
Integrated Change Control process require validation to ensure that the change was appropriately implemented. A validated change provides the necessary data to confirm that the change was appropriately executed.
4.4.1.5 Work Performance Information Work performance information is the performance data collected from various
controlling processes, analyzed in context, and integrated based on relationships across areas. Thus work performance data has been transformed into work performance information. Data in itself cannot be used in the decision-making process as it has only out-of-context meaning. Work performance information, however, is correlated and contextualized, and provides a sound foundation for project decisions.
Work performance information is circulated through communication processes. Examples of performance information are status of deliverables, implementation status for change requests, and forecasted estimates to complete.
4.4.1.6 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
108
influence the Monitor and Control Project Work process include, but are not limited to:
Governmental or industry standards (e.g., regulatory agency regulations, codes of conduct, product standards, quality standards, and workmanship standards), Organization work authorization systems, Stakeholder risk tolerances, and Project management information system (e.g., an automated tool suite, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems).
4.4.1.7 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Monitor and Control Project Work process include, but are not limited to:
Organizational communication requirements; Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions); Issue and defect management procedures defining issue and defect controls, issue and defect identification, and resolution and action item tracking; Change control procedures, including those for scope, schedule, cost, and quality variances; Risk control procedures including risk categories, probability and impact definitions, and probability and impact matrix; Process measurement database used to make available measurement data on processes and products; and Lessons learned database.
4.4.2 Monitor and Control Project Work: Tools and Techniques 4.4.2.1 Expert Judgment
Expert judgment is used by the project management team to interpret the information provided by the monitor and control processes. The project manager, in collaboration with the team, determines the actions required to ensure that project performance matches expectations.
4.4.2.2 Analytical Techniques Analytical techniques are applied in project management to forecast potential
outcomes based on possible variations of project or environmental variables and
109
their relationships with other variables. Examples of analytical techniques used in projects are:
Regression analysis, Grouping methods, Causal analysis, Root cause analysis, Forecasting methods (e.g., time series, scenario building, simulation, etc.), Failure mode and effect analysis (FMEA), Fault tree analysis (FTA), Reserve analysis, Trend analysis, Earned value management, and Variance analysis.
4.4.2.3 Project Management Information System The project management information system, which is part of enterprise
environmental factors, provides access to automated tools, such as scheduling, cost, and resourcing tools, performance indicators, databases, project records, and financials used during the Monitor and Control Project Work process.
4.4.2.4 Meetings Described in Section 4.3.2.3. Meetings may be face-to-face, virtual, formal, or
informal. They may include project team members, stakeholders, and others involved in or affected by the project. Types of meetings include, but are not limited to, user groups and review meetings.
4.4.3 Monitor and Control Project Work: Outputs
4.4.3.1 Change Requests As a result of comparing planned results to actual results, change requests may
be issued to expand, adjust, or reduce project scope, product scope, or quality requirements and schedule or cost baselines. Change requests may necessitate the collection and documentation of new requirements. Changes can impact the project management plan, project documents, or product deliverables. Changes that meet the project's change control criteria should go through the integrated change control process established for the project. Changes may include, but are not limited to, the following:
Corrective action—An intentional activity that realigns the performance of the project work with the project management plan;
110
Preventive action—An intentional activity that ensures the future performance of the project work is aligned with the project management plan; and Defect repair—An intentional activity to modify a nonconforming product or product component.
4.4.3.2 Work Performance Reports Work performance reports are the physical or electronic representation of work
performance information compiled in project documents, intended to generate decisions, actions, or awareness. Project information may be communicated verbally from person to person. However, in order to record, store, and sometimes distribute work performance information, a physical or electronic representation in the form of project documents is required. Work performance reports are a subset of project documents, which are intended to create awareness and generate decisions or actions. Specific work performance metrics may be defined at the start of the project and included in the normal work performance reports provided to key stakeholders.
Examples of work performance reports include status reports, memos, justifications, information notes, recommendations, and updates.
4.4.3.3 Project Management Plan Updates Changes identified during the Monitor and Control Project Work process may
affect the overall project management plan. These changes, after being processed through the appropriate change control process can lead to project management plan updates. Project management plan elements that may be updated include, but are not limited to:
Scope management plan (Section 5.1.3.1), Requirements management plan (Section 5.1.3.2), Schedule management plan (Section 6.1.3.1), Cost management plan (Section 7.1.3.1), Quality management plan (Section 8.1.3.1), Scope baseline (Section 5.4.3.1), Schedule baseline (Section 6.6.3.1), and Cost baseline (Section 7.3.3.1).
4.4.3.4 Project Documents Updates Project documents that may be updated include, but are not limited to:
Schedule and cost forecasts, Work performance reports, and
111
Issue log.
4.5 Perform Integrated Change Control Perform Integrated Change Control is the process of reviewing all change
requests; approving changes and managing changes to deliverables, organizational process assets, project documents, and the project management plan; and communicating their disposition. It reviews all requests for changes or modifications to project documents, deliverables, baselines, or the project management plan and approves or rejects the changes. The key benefit of this process is that it allows for documented changes within the project to be considered in an integrated fashion while reducing project risk, which often arises from changes made without consideration to the overall project objectives or plans. The inputs, tools and techniques, and outputs of this process are depicted in Figure 4-10. Figure 4-11 depicts the data flow diagram of the process.
112
113
The Perform Integrated Change Control process is conducted from project inception through completion and is the ultimate responsibility of the project manager. The project management plan, the project scope statement, and other deliverables are maintained by carefully and continuously managing changes, either by rejecting changes or by approving changes, thereby assuring that only approved changes are incorporated into a revised baseline.
Changes may be requested by any stakeholder involved with the project. Although changes may be initiated verbally, they should be recorded in written form and entered into the change management and/or configuration management system. Change requests are subject to the process specified in the change control and configuration control systems. Those change request processes may require information on estimated time impacts and estimated cost impacts.
Every documented change request needs to be either approved or rejected by a responsible individual, usually the project sponsor or project manager. The responsible individual will be identified in the project management plan or by organizational procedures. When required, the Perform Integrated Change Control process includes a change control board (CCB), which is a formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions. Approved change requests can require new or revised cost estimates, activity sequences, schedule dates, resource requirements, and analysis of risk response alternatives. These changes can require adjustments to the project management plan and other project documents. The applied level of change control is dependent upon the application area, complexity of the specific project, contract requirements, and the context and environment in which the project is performed. Customer or sponsor approval may be required for certain change requests after CCB approval, unless they are part of the CCB.
Configuration control is focused on the specification of both the deliverables and the processes; while change control is focused on identifying, documenting, and approving or rejecting changes to the project documents, deliverables, or baselines.
Some of the configuration management activities included in the Perform Integrated Change Control process are as follows:
Configuration identification. Identification and selection of a configuration item to provide the basis for which the product configuration is defined and verified, products and documents are labeled, changes are managed, and accountability is maintained. Configuration status accounting. Information is recorded and reported as to when appropriate data about the configuration item should be provided. This information includes a listing of approved configuration identification, status of proposed changes to the configuration, and the implementation
114
status of approved changes. Configuration verification and audit. Configuration verification and configuration audits ensure the composition of a project's configuration items is correct and that corresponding changes are registered, assessed, approved, tracked, and correctly implemented. This ensures the functional requirements defined in the configuration documentation have been met.
4.5.1 Perform Integrated Change Control: Inputs
4.5.1.1 Project Management Plan Described in Section 4.2.3.1. Elements of the project management plan that may
be used include, but are not limited to:
Scope management plan, which contains the procedures for scope changes; Scope baseline, which provides product definition; and Change management plan, which provides the direction for managing the change control process and documents the formal change control board (CCB).
Changes are documented and updated within the project management plan as part of the change and configuration management processes.
4.5.1.2 Work Performance Reports Described in Section 4.4.3.2. Work performance reports of particular interest to
the Perform Integrated Change Control process include resource availability, schedule and cost data, earned value management (EVM) reports, and burnup or burndown charts.
4.5.1.3 Change Requests All of the Monitoring and Controlling processes and many of the Executing
processes produce change requests as an output. Change requests may include corrective action, preventive action, or defect repairs. However, corrective and preventive actions do not normally affect the project baselines—only the performance against the baselines.
4.5.1.4 Enterprise Environmental Factors Described in Section 2.1.5. The following enterprise environmental factor can
influence the Perform Integrated Change Control process: project management information system. The project management information system may include the scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems.
115
4.5.1.5 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Perform Integrated Change Control process include, but are not limited to:
Change control procedures, including the steps by which official organization standards, policies, plans, and other project documents will be modified, and how any changes will be approved, validated, and implemented; Procedures for approving and issuing change authorizations; Process measurement database used to collect and make available measurement data on processes and products; Project documents (e.g., scope, cost, and schedule baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact); and Configuration management knowledge base containing the versions and baselines of all official organization standards, policies, procedures, and any project documents.
4.5.2 Perform Integrated Change Control: Tools and Techniques 4.5.2.1 Expert Judgment
In addition to the project management team's expert judgment, stakeholders may be asked to provide their expertise and may be asked to sit on the change control board (CCB). Such judgment and expertise are applied to any technical and management details during this process and may be provided by various sources, for example:
Consultants, Stakeholders, including customers or sponsors, Professional and technical associations, Industry groups, Subject matter experts (SMEs), and Project management office (PMO).
4.5.2.2 Meetings In this case, these meetings are usually referred to as change control meetings.
When needed for the project, a change control board (CCB) is responsible for meeting and reviewing the change requests and approving, rejecting, or other disposition of those changes. The CCB may also review configuration management activities. The roles and responsibilities of these boards are clearly defined and agreed upon by appropriate stakeholders and documented in the change
116
management plan. CCB decisions are documented and communicated to the stakeholders for information and follow-up actions.
4.5.2.3 Change Control Tools In order to facilitate configuration and change management, manual or automated
tools may be used. Tool selection should be based on the needs of the project stakeholders including organizational and environmental considerations and/or constraints.
Tools are used to manage the change requests and the resulting decisions. Additional considerations should be made for communication to assist the CCB members in their duties as well as distribute the decisions to the appropriate stakeholders.
4.5.3 Perform Integrated Change Control: Outputs 4.5.3.1 Approved Change Requests
Change requests are processed according to the change control system by the project manager, CCB, or by an assigned team member. Approved change requests will be implemented through the Direct and Manage Project Work process. The disposition of all change requests, approved or not, will be updated in the change log as part of updates to the project documents.
4.5.3.2 Change Log A change log is used to document changes that occur during a project. These
changes and their impact to the project in terms of time, cost, and risk, are communicated to the appropriate stakeholders. Rejected change requests are also captured in the change log.
4.5.3.3 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to:
Any subsidiary plans, and Baselines that are subject to the formal change control process.
Changes to baselines should only show the changes from the current time forward. Past performance may not be changed. This protects the integrity of the baselines and the historical data of past performance.
4.5.3.4 Project Documents Updates Project documents that may be updated as a result of the Perform Integrated
Change Control process include all documents specified as being subject to the project's formal change control process.
117
4.6 Close Project or Phase Close Project or Phase is the process of finalizing all activities across all of the
Project Management Process Groups to formally complete the project or phase. The key benefit of this process is that it provides lessons learned, the formal ending of project work, and the release of organization resources to pursue new endeavors. The inputs, tools and techniques, and outputs of this process are depicted in Figure 4-12. Figure 4-13 depicts the data flow diagram of the process.
When closing the project, the project manager reviews all prior information from the previous phase closures to ensure that all project work is completed and that the project has met its objectives. Since project scope is measured against the project management plan, the project manager reviews the scope baseline to ensure completion before considering the project closed. The Close Project or Phase process also establishes the procedures to investigate and document the reasons for
118
actions taken if a project is terminated before completion. In order to successfully achieve this, the project manager needs to engage all the proper stakeholders in the process.
This includes all planned activities necessary for administrative closure of the project or phase, including step-by-step methodologies that address:
Actions and activities necessary to satisfy completion or exit criteria for the phase or project; Actions and activities necessary to transfer the project's products, services, or results to the next phase or to production and/or operations; and Activities needed to collect project or phase records, audit project success or failure, gather lessons learned and archive project information for future use by the organization.
4.6.1 Close Project or Phase: Inputs
4.6.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan becomes the
agreement between the project manager and project sponsor, defining what constitutes project completion.
4.6.1.2 Accepted Deliverables Described in Section 5.5. Accepted deliverables may include approved product
specifications, delivery receipts, and work performance documents. Partial or interim deliverables may also be included for phased or cancelled projects.
4.6.1.3 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Close Project or Phase process include, but are not limited to:
Project or phase closure guidelines or requirements (e.g., administrative procedures, project audits, project evaluations, and transition criteria); and Historical information and lessons learned knowledge base (e.g., project records and documents, all project closure information and documentation, information about both the results of previous project selection decisions and previous project performance information, and information from risk management activities).
4.6.2 Close Project or Phase: Tools and Techniques 4.6.2.1 Expert Judgment
Expert judgment is applied when performing administrative closure activities. These experts ensure the project or phase closure is performed to the appropriate
119
standards. Expertise is available from many sources, including but not limited to Other project managers within the organization, Project management office (PMO), and Professional and technical associations.
4.6.2.2 Analytical Techniques Described in Section 4.4.2.2. Examples of analytical techniques used in project
closeout are:
Regression analysis, and Trend analysis.
4.6.2.3 Meetings Described in Section 4.3.2.3. Meetings may be face-to-face, virtual, formal, or
informal. This may include project team members and other stakeholders, involved in or affected by the project. Types of meetings include, but are not limited to lessons learned, closeout, user group, and review meetings.
4.6.3 Close Project or Phase: Outputs
4.6.3.1 Final Product, Service, or Result Transition This output refers to the transition of the final product, service, or result that the
project was authorized to produce (or in the case of phase closure, the intermediate product, service, or result of that phase).
4.6.3.2 Organizational Process Assets Updates The organizational process assets that are updated as a result of the Close
Project or Phase process include, but are not limited to:
Project files—Documentation resulting from the project's activities, for example, project management plan; scope, cost, schedule, and project calendars; risk registers and other registers; change management documentation; planned risk response actions; and risk impact. Project or phase closure documents—Project or phase closure documents, consisting of formal documentation that indicates completion of the project or phase and the transfer of the completed project or phase deliverables to others, such as an operations group or to the next phase. During project closure, the project manager reviews prior phase documentation, customer acceptance documentation from the Validate Scope process (Section 5.5), and the contract (if applicable), to ensure that all project requirements are completed prior to finalizing the closure of the project. If the project was terminated prior to completion, the formal
120
documentation indicates why the project was terminated and formalizes the procedures for the transfer of the finished and unfinished deliverables of the cancelled project to others. Historical information—Historical information and lessons learned information are transferred to the lessons learned knowledge base for use by future projects or phases. This can include information on issues and risks as well as techniques that worked well that can be applied to future projects.
121
5
PROJECT SCOPE MANAGEMENT Project Scope Management includes the processes required to ensure that the
project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.
Figure 5-1 provides an overview of the Project Scope Management processes, which include the following:
5.1 Plan Scope Management—The process of creating a scope management plan that documents how the project scope will be defined, validated, and controlled.
5.2 Collect Requirements—The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
5.3 Define Scope—The process of developing a detailed description of the project and product.
5.4 Create WBS—The process of subdividing project deliverables and project work into smaller, more manageable components.
5.5 Validate Scope—The process of formalizing acceptance of the completed project deliverables.
5.6 Control Scope—The process of monitoring the status of the project and product scope and managing changes to the scope baseline.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
In the project context, the term scope can refer to:
Product scope. The features and functions that characterize a product, service, or result; and/or Project scope. The work performed to deliver a product, service, or result with the specified features and functions. The term project scope is sometimes viewed as including product scope.
The processes used to manage project scope, as well as the supporting tools and techniques, can vary by project. The scope baseline for the project is the approved version of the project scope statement, work breakdown structure (WBS), and its associated WBS dictionary. A baseline can be changed only through formal change control procedures and is used as a basis for comparison while performing
122
Validate Scope and Control Scope processes as well as other controlling processes.
Completion of the project scope is measured against the project management plan (Section 4.2.3.1). Completion of the product scope is measured against the product requirements (Section 5.2). The Project Scope Management processes need to be well integrated with the other Knowledge Area processes, so that the work of the project will result in delivery of the specified product scope.
123
5.1 Plan Scope Management Plan Scope Management is the process of creating a scope management plan that
documents how the project scope will be defined, validated, and controlled. The key benefit of this process is that it provides guidance and direction on how scope
124
will be managed throughout the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-2. Figure 5-3 depicts the data flow diagram of the process.
The scope management plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and verified. The development of the scope management plan and the detailing of the project scope begin with the analysis of information contained in the project charter (Section 4.1.3.1), the latest approved subsidiary plans of the project management plan (Section 4.2.3.1), historical information contained in the organizational process assets (Section 2.1.4), and any other
125
relevant enterprise environmental factors (Section 2.1.5). This plan helps reduce the risk of project scope creep.
5.1.1 Plan Scope Management: Inputs
5.1.1.1 Project Management Plan Described in Section 4.2.3.1. Approved subsidiary plans of the project
management plan are used to create the scope management plan and influence the approach taken for planning scope and managing project scope.
5.1.1.2 Project Charter Described in Section 4.1.3.1. The project charter is used to provide the project
context needed to plan the scope management processes. It provides the high-level project description and product characteristics from the project statement of work.
5.1.1.3 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
influence the Plan Scope Management process include, but are not limited to:
Organization's culture, Infrastructure, Personnel administration, and Marketplace conditions.
5.1.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Plan Scope Management process include, but are not limited to:
Policies and procedures, and Historical information and lessons learned knowledge base.
5.1.2 Plan Scope Management: Tools and Techniques 5.1.2.1 Expert Judgment
Expert judgment refers to input received from knowledgeable and experienced parties. Expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training in developing scope management plans.
5.1.2.2 Meetings Project teams may attend project meetings to develop the scope management
plan. Attendees at these meetings may include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with
126
responsibility for any of the scope management processes, and others as needed.
5.1.3 Plan Scope Management: Outputs
5.1.3.1 Scope Management Plan The scope management plan is a component of the project or program
management plan that describes how the scope will be defined, developed, monitored, controlled, and verified. The scope management plan is a major input into the Develop Project Management Plan process, and the other scope management processes. The components of a scope management plan include:
Process for preparing a detailed project scope statement; Process that enables the creation of the WBS from the detailed project scope statement; Process that establishes how the WBS will be maintained and approved; Process that specifies how formal acceptance of the completed project deliverables will be obtained; and Process to control how requests for changes to the detailed project scope statement will be processed. This process is directly linked to the Perform Integrated Change Control process (Section 4.5).
The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.
5.1.3.2 Requirements Management Plan The requirements management plan is a component of the project management
plan that describes how requirements will be analyzed, documented, and managed. The phase-to-phase relationship, described in Section 2.4.2.1, strongly influences how requirements are managed. The project manager chooses the most effective relationship for the project and documents this approach in the requirements management plan. Many of the requirements management plan components are based on that relationship.
Components of the requirements management plan can include, but are not limited to:
How requirements activities will be planned, tracked, and reported; Configuration management activities such as: how changes to the product will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, as well as the authorization levels required to approve these changes; Requirements prioritization process; Product metrics that will be used and the rationale for using them; and
127
Traceability structure to reflect which requirement attributes will be captured on the traceability matrix.
5.2 Collect Requirements Collect Requirements is the process of determining, documenting, and managing
stakeholder needs and requirements to meet project objectives. The key benefit of this process is that it provides the basis for defining and managing the project scope including product scope. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-4. Figure 5-5 depicts the data flow diagram of the process.
128
The project's success is directly influenced by active stakeholder involvement in the discovery and decomposition of needs into requirements and by the care taken in determining, documenting, and managing the requirements of the product, service, or result of the project. Requirements include conditions or capabilities that are to be met by the project or present in the product, service, or result to satisfy an agreement or other formally imposed specification. Requirements include the quantified and documented needs and expectations of the sponsor, customer, and other stakeholders. These requirements need to be elicited, analyzed, and recorded in enough detail to be included in the scope baseline and to be measured once project execution begins. Requirements become the foundation of the WBS. Cost, schedule, quality planning, and sometimes procurement are all based upon these requirements. The development of requirements begins with an analysis of the information contained in the project charter (Section 4.1.3.1), the stakeholder register (Section 13.1.3.1) and the stakeholder management plan (Section 13.2.3.1).
Many organizations categorize requirements into different types, such as business
129
and technical solutions, the former referring to stakeholder needs and the latter as to how those needs will be implemented. Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated. These classifications include:
Business requirements, which describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken. Stakeholder requirements, which describe needs of a stakeholder or stakeholder group. Solution requirements, which describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements:
Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product. Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.
Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state. Project requirements, which describe the actions, processes, or other conditions the project needs to meet. Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.
5.2.1 Collect Requirements: Inputs
5.2.1.1 Scope Management Plan Described in Section 5.1.3.1. The scope management plan provides clarity as to
how project teams will determine which type of requirements need to be collected for the project.
5.2.1.2 Requirements Management Plan Described in Section 5.1.3.2. The requirements management plan provides the
processes that will be used throughout the Collect Requirements process to define and document the stakeholder needs.
130
5.2.1.3 Stakeholder Management Plan Described in Section 13.2.3.1. The stakeholder management plan is used to
understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities.
5.2.1.4 Project Charter Described in Section 4.1.3.1. The project charter is used to provide the high-
level description of the product, service, or result of the project so that detailed requirements can be developed.
5.2.1.5 Stakeholder Register Described in Section 13.1.3.1. The stakeholder register is used to identify
stakeholders who can provide information on the requirements. The stakeholder register also captures major requirements and main expectations stakeholders may have for the project.
5.2.2 Collect Requirements: Tools and Techniques 5.2.2.1 Interviews
An interview is a formal or informal approach to elicit information from stakeholders by talking to them directly. It is typically performed by asking prepared and spontaneous questions and recording the responses. Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees. Interviewing experienced project participants, sponsors and other executives, and subject matter experts can aid in identifying and defining the features and functions of the desired product deliverables. Interviews are also useful for obtaining confidential information.
5.2.2.2 Focus Groups Focus groups bring together prequalified stakeholders and subject matter experts
to learn about their expectations and attitudes about a proposed product, service, or result. A trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-on-one interview.
5.2.2.3 Facilitated Workshops Facilitated workshops are focused sessions that bring key stakeholders together
to define product requirements. Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the
131
participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.
For example, facilitated workshops called joint application design/development (JAD) sessions are used in the software development industry. These facilitated sessions focus on bringing business subject matter experts and the development team together to improve the software development process. In the manufacturing industry, quality function deployment (QFD) is another example of a facilitated workshop technique that helps determine critical characteristics for new product development. QFD starts by collecting customer needs, also known as voice of the customer (VOC). These needs are then objectively sorted and prioritized, and goals are set for achieving them. User stories, which are short, textual descriptions of required functionality, are often developed during a requirements workshop. User stories describe the stakeholder who benefits from the feature (role), what the stakeholder needs to accomplish (goal), and the benefit to the stakeholder (motivation). User stories are widely used with agile methods.
5.2.2.4 Group Creativity Techniques Several group activities can be organized to identify project and product
requirements. Some of the group creativity techniques that can be used are:
Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do. Nominal group technique. A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas. Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for review and analysis. Multicriteria decision analysis. A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.
5.2.2.5 Group Decision-Making Techniques A group decision-making technique is an assessment process having multiple
alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product requirements.
There are various methods of reaching a group decision, such as:
132
Unanimity. A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity. Majority. A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie. Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two. Dictatorship. In this method, one individual makes the decision for the group.
All of these group decision-making techniques can be applied to the group creativity techniques used in the Collect Requirements process.
5.2.2.6 Questionnaires and Surveys Questionnaires and surveys are written sets of questions designed to quickly
accumulate information from a large number of respondents. Questionnaires and/or surveys are most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis is appropriate.
5.2.2.7 Observations Observations provide a direct way of viewing individuals in their environment
and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements. Observation is also known as “job shadowing.” It is usually done externally by an observer viewing a business expert performing a job. It can also be done by a “participant observer” who actually performs a process or procedure to experience how it is done to uncover hidden requirements.
5.2.2.8 Prototypes Prototyping is a method of obtaining early feedback on requirements by
providing a working model of the expected product before actually building it. Since a prototype is tangible, it allows stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements. Prototypes support the concept of progressive elaboration in
133
iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision. When enough feedback cycles have been performed, the requirements obtained from the prototype are sufficiently complete to move to a design or build phase. Storyboarding is a prototyping technique showing sequence or navigation through a series of images or illustrations. Storyboards are used on a variety of projects in a variety of industries, such as film, advertising, instructional design, and on agile and other software development projects. In software development, storyboards use mock-ups to show navigation paths through webpages, screens, or other user interfaces.
5.2.2.9 Benchmarking Benchmarking involves comparing actual or planned practices, such as
processes and operations, to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during benchmarking can be internal or external.
5.2.2.10 Context Diagrams The context diagram is an example of a scope model. Context diagrams visually
depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it. Context diagrams show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output.
5.2.2.11 Document Analysis Document analysis is used to elicit requirements by analyzing existing
documentation and identifying information relevant to the requirements. There are a wide range of documents that may be analyzed to help elicit relevant requirements. Examples of documents that may be analyzed include, but are not limited to: business plans, marketing literature, agreements, requests for proposal, current process flows, logical data models, business rules repositories, application software documentation, business process or interface documentation, use cases, other requirements documentation, problem/issue logs, policies, procedures, and regulatory documentation such as laws, codes, or ordinances, etc.
5.2.3 Collect Requirements: Outputs 5.2.3.1 Requirements Documentation
Requirements documentation describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and
134
testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of a requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.
Components of requirements documentation can include, but, are not limited to:
Business requirements, including:
Business and project objectives for traceability; Business rules for the performing organization; and Guiding principles of the organization.
Stakeholder requirements, including:
Impacts to other organizational areas; Impacts to other entities inside or outside the performing organization; and Stakeholder communication and reporting requirements.
Solution requirements, including:
Functional and nonfunctional requirements; Technology and standard compliance requirements; Support and training requirements; Quality requirements; and Reporting requirements, etc. (solution requirements can be documented textually, in models, or both).
Project requirements, such as:
Levels of service, performance, safety, compliance, etc.; and Acceptance criteria.
Transition requirements. Requirements assumptions, dependencies, and constraints.
5.2.3.2 Requirements Traceability Matrix The requirements traceability matrix is a grid that links product requirements
from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.
135
Tracing includes, but is not limited to, tracing requirements for the following:
Business needs, opportunities, goals, and objectives; Project objectives; Project scope/WBS deliverables; Product design; Product development; Test strategy and test scenarios; and High-level requirements to more detailed requirements.
Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes help to define key information about the requirement. Typical attributes used in the requirements traceability matrix may include: a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved, assigned, completed), and status date. Additional attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria. Figure 5-6 provides an example of a requirements traceability matrix with its associated attributes.
5.3 Define Scope Define Scope is the process of developing a detailed description of the project
136
and product. The key benefit of this process is that it describes the product, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-7. Figure 5-8 depicts the data flow diagram of the process.
Since all of the requirements identified in Collect Requirements may not be included in the project, the Define Scope process selects the final project requirements from the requirements documentation delivered during the Collect Requirements process. It then develops a detailed description of the project and product, service, or result.
137
The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During project planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness and added or updated as necessary. The Define Scope process can be highly iterative. In iterative life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.
5.3.1 Define Scope: Inputs
5.3.1.1 Scope Management Plan Described in Section 5.1.3.1. The scope management plan is a component of the
project management plan that establishes the activities for developing, monitoring, and controlling the project scope.
5.3.1.2 Project Charter Described in Section 4.1.3.1. The project charter provides the high-level project
description and product characteristics. It also contains project approval requirements. If a project charter is not used in the performing organization, then comparable information needs to be acquired or developed, and used as a basis for the detailed project scope statement. Organizations that do not produce a formal project charter will usually perform an informal analysis to identify the content necessary for further scope planning.
5.3.1.3 Requirements Documentation Described in Section 5.2.3.1. This documentation will be used to select the
requirements that will be included in the project.
5.3.1.4 Organizational Process Assets Described in Section 2.1.4. Organizational process assets can influence how
scope is defined. Examples include, but are not limited to:
Policies, procedures, and templates for a project scope statement; Project files from previous projects; and Lessons learned from previous phases or projects.
5.3.2 Define Scope: Tools and Techniques 5.3.2.1 Expert Judgment
Expert judgment is often used to analyze the information needed to develop the
138
project scope statement. Such judgment and expertise is applied to any technical detail. Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including but not limited to:
Other units within the organization; Consultants; Stakeholders, including customers or sponsors; Professional and technical associations; Industry groups; and Subject matter experts.
5.3.2.2 Product Analysis For projects that have a product as a deliverable, as opposed to a service or
result, product analysis can be an effective tool. Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis.
5.3.2.3 Alternatives Generation Alternatives generation is a technique used to develop as many potential options
as possible in order to identify different approaches to execute and perform the work of the project. A variety of general management techniques can be used, such as brainstorming, lateral thinking, analysis of alternatives, etc.
5.3.2.4 Facilitated Workshops Described in Section 5.2.2.3. The participation of key players with a variety of
expectations and/or fields of expertise in these intensive working sessions helps to reach a cross-functional and common understanding of the project objectives and its limits.
5.3.3 Define Scope: Outputs 5.3.3.1 Project Scope Statement
The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes, in detail, the project's deliverables and the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team to perform more detailed planning, guides
139
the project team's work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project's boundaries.
The degree and level of detail to which the project scope statement defines the work that will be performed and the work that is excluded can help determine how well the project management team can control the overall project scope. The detailed project scope statement, either directly, or by reference to other documents, includes the following:
Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation. Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted. Deliverable. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such as project management reports and documentation. These deliverables may be described at a summary level or in great detail. Project exclusion. Generally identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations. Constraints. A limiting factor that affects the execution of a project or process. Constraints identified with the project scope statement list and describe the specific internal or external restrictions or limitations associated with the project scope that affect the execution of the project, for example, a predefined budget or any imposed dates or schedule milestones that are issued by the customer or performing organization. When a project is performed under an agreement, contractual provisions will generally be constraints. Information on constraints may be listed in the project scope statement or in a separate log. Assumptions. A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration. Also describes the potential impact of those factors if they prove to be false. Project teams frequently identify, document, and validate assumptions as part of their planning process. Information on assumptions may be listed in the project scope statement or in a separate log.
Although the project charter and the project scope statement are sometimes perceived as containing a certain degree of redundancy, they are different in the level of detail contained in each. The project charter contains high-level information, while the project scope statement contains a detailed description of the
140
scope elements. These elements are progressively elaborated throughout the project. Table 5-1 describes some of the key elements for each document.
5.3.3.2 Project Documents Updates Project documents that may be updated include, but are not limited to:
Stakeholder register, Requirements documentation, and Requirements traceability matrix.
5.4 Create WBS Create WBS is the process of subdividing project deliverables and project work
into smaller, more manageable components. The key benefit of this process is that it provides a structured vision of what has to be delivered. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-9. Figure 5-10
141
depicts the data flow diagram of the process.
The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the
142
required deliverables. The WBS organizes and defines the total scope of the project, and represents the work specified in the current approved project scope statement.
The planned work is contained within the lowest level of WBS components, which are called work packages. A work package can be used to group the activities where work is scheduled and estimated, monitored, and controlled. In the context of the WBS, work refers to work products or deliverables that are the result of activity and not to the activity itself.
5.4.1 Create WBS: Inputs
5.4.1.1 Scope Management Plan Described in Section 5.1.3.1. The scope management plan specifies how to
create the WBS from the detailed project scope statement and how the WBS will be maintained and approved.
5.4.1.2 Project Scope Statement Described in Section 5.3.3.1. The project scope statement describes the work
that will be performed and the work that is excluded. It also lists and describes the specific internal or external restrictions or limitations that may affect the execution of the project.
5.4.1.3 Requirements Documentation Described in Section 5.2.3.1. Detailed requirements documentation is essential
for understanding what needs to be produced as the result of the project and what needs to be done to deliver the project and its final products.
5.4.1.4 Enterprise Environmental Factors Described in Section 2.1.5. Industry-specific WBS standards, relevant to the
nature of the project, may serve as external reference sources for creation of the WBS. For example, engineering projects may reference ISO/IEC 15288 on Systems Engineering – System Life Cycle Processes [6], to create a WBS for a new project.
5.4.1.5 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Create WBS process include, but are not limited to:
Policies, procedures, and templates for the WBS; Project files from previous projects; and Lessons learned from previous projects.
5.4.2 Create WBS: Tools and Techniques
143
5.4.2.1 Decomposition Decomposition is a technique used for dividing and subdividing the project
scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of decomposition is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project. Decomposition of the total project work into work packages generally involves the following activities:
Identifying and analyzing the deliverables and related work; Structuring and organizing the WBS; Decomposing the upper WBS levels into lower-level detailed components; Developing and assigning identification codes to the WBS components; and Verifying that the degree of decomposition of the deliverables is appropriate.
A portion of a WBS with some branches of the WBS decomposed down through the work package level is shown in Figure 5-11.
5.4.2.2 Expert Judgment Expert judgment is often used to analyze the information needed to decompose
the project deliverables down into smaller component parts in order to create an effective WBS. Such judgment and expertise is applied to technical details of the project's scope and used to reconcile differences in opinion on how to best break down the overall scope of the project. This level of expertise is provided by any group or individual with relevant training, knowledge, or experience with similar projects or business areas. Expert judgment can also come in the form of predefined templates that provide guidance on how to effectively break down common deliverables. Such templates may be industry or discipline specific or may come from experience gained in similar projects. The project manager, in collaboration with the project team, then determines the final decomposition of the project scope into the discrete work packages that will be used to effectively manage the work of the project.
144
A WBS structure may be created through various approaches. Some of the popular methods include the top-down approach, the use of organization-specific guidelines, and the use of WBS templates. A bottom-up approach can be used during the integration of subcomponents. The WBS structure can be represented in a number of forms, such as:
Using phases of the project life cycle as the second level of decomposition, with the product and project deliverables inserted at the third level, as shown in Figure 5-12; Using major deliverables as the second level of decomposition, as shown in Figure 5-13; and Incorporating subcomponents which may be developed by organizations outside the project team, such as contracted work. The seller then develops the supporting contract WBS as part of the contracted work.
145
Decomposition of the upper-level WBS components requires subdividing the work for each of the deliverables or subcomponents into its most fundamental elements, where the WBS components represent verifiable products, services, or results. The WBS may be structured as an outline, an organizational chart, or other method that identifies a hierarchical breakdown. Verifying the correctness of the
146
decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher- level deliverables. Different deliverables can have different levels of decomposition. To arrive at a work package, the work for some deliverables needs to be decomposed only to the next level, while others need additional levels of decomposition. As the work is decomposed to greater levels of detail, the ability to plan, manage, and control the work is enhanced. However, excessive decomposition can lead to nonproductive management effort, inefficient use of resources, decreased efficiency in performing the work, and difficulty aggregating data over different levels of the WBS.
Decomposition may not be possible for a deliverable or subcomponent that will be accomplished far into the future. The project management team usually waits until the deliverable or subcomponent is agreed on, so the details of the WBS can be developed. This technique is sometimes referred to as rolling wave planning.
The WBS represents all product and project work, including the project management work. The total of the work at the lowest levels should roll up to the higher levels so that nothing is left out and no extra work is performed. This is sometimes called the 100 percent rule.
For specific information regarding the WBS, refer to the Practice Standard for Work Breakdown Structures – Second Edition [7]. This standard contains industry- specific examples of WBS templates that can be tailored to specific projects in a particular application area.
5.4.3 Create WBS: Outputs
5.4.3.1 Scope Baseline The scope baseline is the approved version of a scope statement, work
breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan. Components of the scope baseline include:
Project scope statement. The project scope statement includes the description of the project scope, major deliverables, assumptions, and constraints. WBS. The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the WBS represents an increasingly detailed definition of the project work. The WBS is finalized by assigning each work package to a control account and establishing a unique identifier for that work package from a code of accounts. These identifiers provide a structure for hierarchical summation
147
of costs, schedule, and resource information. A control account is a management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account with known work content but without detailed schedule activities. WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Information in the WBS dictionary may include, but is not limited to:
Code of account identifier, Description of work, Assumptions and constraints, Responsible organization, Schedule milestones, Associated schedule activities, Resources required, Cost estimates, Quality requirements, Acceptance criteria, Technical references, and Agreement information.
5.4.3.2 Project Documents Updates Project documents that may be updated include, but are not limited to,
requirements documentation, which may need to be updated to include approved changes. If approved change requests result from the Create WBS process, then the requirements documentation may need to be updated to include approved changes.
5.5 Validate Scope Validate Scope is the process of formalizing acceptance of the completed project
deliverables. The key benefit of this process is that it brings objectivity to the acceptance process and increases the chance of final product, service, or result acceptance by validating each deliverable. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5-14. Figure 5-15 depicts the data
148
flow diagram of the process.
The verified deliverables obtained from the Control Quality process are reviewed with the customer or sponsor to ensure that they are completed satisfactorily and have received formal acceptance of the deliverables by the customer or sponsor. In this process, the outputs obtained as a result of the Planning processes in the Project Scope Management Knowledge Area, such as the requirements documentation or the scope baseline, as well as the work performance data obtained from the Execution processes in other Knowledge Areas, are the basis for performing the validation and for final acceptance.
The Validate Scope process differs from the Control Quality process in that the
149
former is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables. Control Quality is generally performed before Validate Scope, although the two processes may be performed in parallel.
5.5.1 Validate Scope: Inputs
5.5.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan contains the scope
management plan and the scope baseline. As described in Section 5.1.3.1, the scope management plan specifies how formal acceptance of the completed project deliverables will be obtained. The scope baseline (Section 5.4.3.1) includes the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison.
5.5.1.2 Requirements Documentation Described in Section 5.2.3.1. The requirements documentation lists all the
project, product, and other types of requirements for the project and product, along with their acceptance criteria.
5.5.1.3 Requirements Traceability Matrix Described in Section 5.2.3.2. The requirements traceability matrix links
requirements to their origin and tracks them throughout the project life cycle.
5.5.1.4 Verified Deliverables Described in Section 8.3.3.3. Verified deliverables are project deliverables that
are completed and checked for correctness through the Control Quality process.
5.5.1.5 Work Performance Data Described in Section 4.3.3.2. Work performance data can include the degree of
compliance with requirements, number of nonconformities, severity of the nonconformities, or the number of validation cycles performed in a period of time.
5.5.2 Validate Scope: Tools and Techniques 5.5.2.1 Inspection
Inspection includes activities such as measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, audits, and walkthroughs. In some application areas, these different terms have
150
unique and specific meanings.
5.5.2.2 Group Decision-Making Techniques Described in Section 5.2.2.5. These techniques are used to reach a conclusion
when the validation is performed by the project team and other stakeholders.
5.5.3 Validate Scope: Outputs 5.5.3.1 Accepted Deliverables
Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor. Formal documentation received from the customer or sponsor acknowledging formal stakeholder acceptance of the project's deliverables is forwarded to the Close Project or Phase process (Section 4.6).
5.5.3.2 Change Requests The completed deliverables that have not been formally accepted are
documented, along with the reasons for nonacceptance of those deliverables. Those deliverables may require a change request for defect repair. The change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.5).
5.5.3.3 Work Performance Information Work performance information includes information about project progress, such
as which deliverables have started, their progress, which deliverables have finished, or which have been accepted. This information is documented as described in Section 10.3.3.1 and communicated to stakeholders.
5.5.3.4 Project Documents Updates Project documents that may be updated as a result of the Validate Scope process
include any documents that define the product or report status on product completion. Verified project documents may require approvals from the customer or sponsor in the form of signatures or signoffs.
5.6 Control Scope Control Scope is the process of monitoring the status of the project and product
scope and managing changes to the scope baseline. The key benefit of this process is that it allows the scope baseline to be maintained throughout the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 5- 16. Figure 5-17 depicts the data flow diagram of the process.
151
Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the Perform Integrated Change Control process (see Section 4.5). Control Scope is also used to manage the actual changes when they occur and is integrated with the other control processes. The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources is referred to as scope creep. Change is
152
inevitable; therefore some type of change control process is mandatory for every project.
5.6.1 Control Scope: Inputs
5.6.1.1 Project Management Plan Described in Section 4.2.3.1. The following information from the project
management plan is used to control scope:
Scope baseline. The scope baseline is compared to actual results to determine if a change, corrective action, or preventive action is necessary. Scope management plan. Sections from the scope management plan describe how the project scope will be monitored and controlled. Change management plan. The change management plan defines the process for managing change on the project. Configuration management plan. The configuration management plan defines those items that are configurable, those items that require formal change control, and the process for controlling changes to such items. Requirements management plan. This plan is a component of the project management plan and describes how the project requirements will be analyzed, documented, and managed.
5.6.1.2 Requirements Documentation Described in Section 5.2.3.1. Requirements should be unambiguous (measurable
and testable), traceable, complete, consistent, and acceptable to key stakeholders. Well-documented requirements make it easier to detect any deviation in the scope agreed for the project or product.
5.6.1.3 Requirements Traceability Matrix Described in Section 5.2.3.2. The requirements traceability matrix helps to
detect the impact of any change or deviation from the scope baseline on the project objectives.
5.6.1.4 Work Performance Data Described in Section 4.3.3.2. Work performance data can include the number of
change requests received, the number of requests accepted or the number of deliverables completed, etc.
5.6.1.5 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Control Scope process include, but are not limited to:
153
Existing formal and informal scope, control-related policies, procedures, guidelines; and Monitoring and reporting methods and templates to be used.
5.6.2 Control Scope: Tools and Techniques
5.6.2.1 Variance Analysis Variance analysis is a technique for determining the cause and degree of
difference between the baseline and actual performance. Project performance measurements are used to assess the magnitude of variation from the original scope baseline. Important aspects of project scope control include determining the cause and degree of variance relative to the scope baseline (Section 5.4.3.1) and deciding whether corrective or preventive action is required.
5.6.3 Control Scope: Outputs 5.6.3.1 Work Performance Information
Work performance information produced includes correlated and contextualized information on how the project scope is performing compared to the scope baseline. It can include the categories of the changes received, the identified scope variances and their causes, how they impact schedule or cost, and the forecast of the future scope performance. This information provides a foundation for making scope decisions.
5.6.3.2 Change Requests Analysis of scope performance can result in a change request to the scope
baseline or other components of the project management plan. Change requests can include preventive or corrective actions, defect repairs, or enhancement requests. Change requests are processed for review and disposition according to the Perform Integrated Change Control process (Section 4.5).
5.6.3.3 Project Management Plan Updates Project management plan updates may include, but are not limited to:
Scope Baseline Updates. If the approved change requests have an effect on the project scope, then the scope statement, the WBS, and the WBS dictionary are revised and reissued to reflect the approved changes through Perform Integrated Change Control process. Other Baseline Updates. If the approved change requests have an effect on the project besides the project scope, then the corresponding cost baseline and schedule baselines are revised and reissued to reflect the approved changes.
154
5.6.3.4 Project Documents Updates Project documents that may be updated include, but are not limited to:
Requirements documentation, and Requirements traceability matrix.
5.6.3.5 Organizational Process Assets Updates Organizational process assets that may be updated include, but are not limited to:
Causes of variances, Corrective action chosen and the reasons, and Other types of lessons learned from project scope control.
155
6
PROJECT TIME MANAGEMENT Project Time Management includes the processes required to manage the timely
completion of the project.
Figure 6-1 provides an overview of the Project Time Management processes, which are as follows:
6.1 Plan Schedule Management—The process of establishing the policies, procedures, and documentation for planning, developing, managing, executing, and controlling the project schedule.
6.2 Define Activities—The process of identifying and documenting the specific actions to be performed to produce the project deliverables.
6.3 Sequence Activities—The process of identifying and documenting relationships among the project activities.
6.4 Estimate Activity Resources—The process of estimating the type and quantities of material, human resources, equipment, or supplies required to perform each activity.
6.5 Estimate Activity Durations—The process of estimating the number of work periods needed to complete individual activities with estimated resources.
6.6 Develop Schedule—The process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create the project schedule model.
6.7 Control Schedule—The process of monitoring the status of project activities to update project progress and manage changes to the schedule baseline to achieve the plan.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
Distinguishing the project schedule presentation (schedule) from the schedule data (Section 6.6.3.3) and calculations that produce the project schedule (Section 6.6.3.2) is practiced by referring to the scheduling tool populated with project data as the schedule model. A schedule model is a representation of the plan for executing the project's activities including durations, dependencies, and other planning information, used to produce project schedules along with other scheduling artifacts. For specific information regarding the schedule model, refer to
156
the Practice Standard for Scheduling. [8] On some projects, especially those of smaller scope, defining activities,
sequencing activities, estimating activity resources, estimating activity durations, and developing the schedule model are so tightly linked that they are viewed as a single process that can be performed by a person over a relatively short period of time. These processes are presented here as distinct elements because the tools and techniques for each process are different.
The Project Time Management processes and their associated tools and techniques are documented in the schedule management plan. The schedule management plan is a subsidiary plan of, and integrated with, the project management plan through the Develop Project Management Plan process (Section 4.2), The schedule management plan identifies a scheduling method and scheduling tool (Figure 6-2), and sets the format and establishes criteria for developing and controlling the project schedule. The selected scheduling method defines the framework and algorithms used in the scheduling tool to create the schedule model. Some of the better known scheduling methods include critical path method (CPM) and critical chain method (CCM).
Project schedule development uses the outputs from the processes to define activities, sequence activities, estimate activity resources, and estimate activity durations in combination with the scheduling tool to produce the schedule model. The finalized and approved schedule is the baseline that will be used in the Control Schedule process (Section 6.7). As the project activities are being performed, the majority of effort in the Project Time Management Knowledge Area will occur in the Control Schedule process to ensure completion of project work in a timely manner. Figure 6-2 provides a scheduling overview that shows how the scheduling method, scheduling tool, and outputs from the Project Time Management processes interact to create a project schedule.
157
158
6.1 Plan Schedule Management
159
Plan Schedule Management is the process of establishing the policies, procedures, and documentation for planning, developing, managing, executing, and controlling the project schedule. The key benefit of this process is that it provides guidance and direction on how the project schedule will be managed throughout the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 6-3. Figure 6-4 depicts the data flow diagram of the process.
The schedule management plan is a component of the project management plan. The schedule management plan may be formal or informal, highly detailed or broadly framed, based upon the needs of the project, and includes appropriate
160
control thresholds. The schedule management plan defines how schedule contingencies will be reported and assessed. The schedule management plan may be updated to reflect a change in the way the schedule is managed. The schedule management plan is a major input into the Develop Project Management Plan process, as referenced in Section 6.1.3.1.
6.1.1 Plan Schedule Management: Inputs
6.1.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan contains information
used to develop the schedule management plan which includes, but is not limited to:
Scope baseline. The scope baseline includes the project scope statement and the work breakdown structure (WBS) details used for defining activities, duration estimation, and schedule management; and Other information. Other scheduling related cost, risk, and communications decisions from the project management plan are used to develop the schedule.
6.1.1.2 Project Charter Described in Section 4.1.3.1. The project charter defines the summary milestone
schedule and project approval requirements that will influence the management of the project schedule.
6.1.1.3 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that influence
the Plan Schedule Management process include, but are not limited to:
Organizational culture and structure can all influence schedule management; Resource availability and skills that may influence schedule planning; Project management software provides the scheduling tool and alternative possibilities for managing the schedule; Published commercial information, such as resource productivity information, is often available from commercial databases; and Organizational work authorization systems.
6.1.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Plan Schedule Management process include, but are not limited to:
Monitoring and reporting tools to be used; Historical information;
161
Schedule control tools; Existing formal and informal schedule control related policies, procedures, and guidelines; Templates; Project closure guidelines; Change control procedures; and Risk control procedures including risk categories, probability and impact definitions, and probability and impact matrix.
6.1.2 Plan Schedule Management: Tools and Techniques
6.1.2.1 Expert Judgment Expert judgment, guided by historical information, provides valuable insight
about the environment and information from prior similar projects. Expert judgment can also suggest whether to combine methods and how to reconcile differences between them.
Judgment based upon expertise in an application area, Knowledge Area, discipline, industry, etc., as appropriate for the activity being performed, should be used in developing the schedule management plan.
6.1.2.2 Analytical Techniques The Plan Schedule Management process may involve choosing strategic options
to estimate and schedule the project such as: scheduling methodology, scheduling tools and techniques, estimating approaches, formats, and project management software. The schedule management plan may also detail ways to fast track or crash (Section 6.6.2.7) the project schedule such as undertaking work in parallel. These decisions, like other schedule decisions affecting the project, may affect project risks.
Organizational policies and procedures may influence which scheduling techniques are employed in these decisions. Techniques may include, but are not limited to, rolling wave planning (Section 6.2.2.2), leads and lags (Section 6.3.2.3), alternatives analysis (Section 6.4.2.2), and methods for reviewing schedule performance (Section 6.7.2.1).
6.1.2.3 Meetings Project teams may hold planning meetings to develop the schedule management
plan. Participants at these meetings may include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with responsibility for schedule planning or execution, and others as needed.
6.1.3 Plan Schedule Management: Outputs
162
6.1.3.1 Schedule Management Plan A component of the project management plan that establishes the criteria and the
activities for developing, monitoring, and controlling the schedule. The schedule management plan may be formal or informal, highly detailed or broadly framed, based upon the needs of the project, and includes appropriate control thresholds.
For example, the schedule management plan can establish the following:
Project schedule model development. The scheduling methodology and the scheduling tool to be used in the development of the project schedule model are specified. Level of accuracy. The acceptable range used in determining realistic activity duration estimates is specified and may include an amount for contingencies. Units of measure. Each unit used in measurements (such as staff hours, staff days, or weeks for time measures, or meters, liters, tons, kilometers, or cubic yards for quantity measures) is defined for each of the resources. Organizational procedures links. The WBS (Section 5.4) provides the framework for the schedule management plan, allowing for consistency with the estimates and resulting schedules. Project schedule model maintenance. The process used to update the status and record progress of the project in the schedule model during the execution of the project is defined. Control thresholds. Variance thresholds for monitoring schedule performance may be specified to indicate an agreed-upon amount of variation to be allowed before some action needs to be taken. Thresholds are typically expressed as percentage deviations from the parameters established in the baseline plan. Rules of performance measurement. Earned value management (EVM) rules or other physical measurement rules of performance measurement are set. For example, the schedule management plan may specify:
Rules for establishing percent complete, Control accounts at which management of progress and schedule will be measured, Earned value measurement techniques (e.g., baselines, fixed- formula, percent complete, etc.) to be employed (for more specific information, refer to the Practice Standard for Earned Value Management) [9], Schedule performance measurements such as schedule variance (SV) and schedule performance index (SPI) used to assess the magnitude of variation to the original schedule baseline.
163
Reporting formats. The formats and frequency for the various schedule reports are defined. Process descriptions. Descriptions of each of the schedule management processes are documented.
6.2 Define Activities Define Activities is the process of identifying and documenting the specific
actions to be performed to produce the project deliverables. The key benefit of this process is to break down work packages into activities that provide a basis for estimating, scheduling, executing, monitoring, and controlling the project work. The inputs, tools and techniques, and outputs of this process are depicted in Figure 6-5. Figure 6-6 depicts the data flow diagram of the process.
164
Implicit in this process are defining and planning the schedule activities such that the project objectives will be met. The Create WBS process identifies the deliverables at the lowest level in the WBS—the work package. Work packages are typically decomposed into smaller components called activities that represent the work effort required to complete the work package.
6.2.1 Define Activities: Inputs
6.2.1.1 Schedule Management Plan Described in Section 6.1.3.1. A key input from the schedule management plan is
the prescribed level of detail necessary to manage the work.
6.2.1.2 Scope Baseline Described in Section 5.4.3.1. The project WBS, deliverables, constraints, and
assumptions documented in the scope baseline are considered explicitly while defining activities.
6.2.1.3 Enterprise Environmental Factors
165
Described in Section 2.1.5. Enterprise environmental factors that influence the Define Activities process include, but are not limited to:
Organizational cultures and structure, Published commercial information from commercial databases, and Project management information system (PMIS).
6.2.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Define Activities process include, but are not limited to:
Lessons learned knowledge base containing historical information regarding activity lists used by previous similar projects, Standardized processes, Templates that contain a standard activity list or a portion of an activity list from a previous project, and Existing formal and informal activity planning-related policies, procedures, and guidelines, such as the scheduling methodology, that are considered in developing the activity definitions.
6.2.2 Define Activities: Tools and Techniques 6.2.2.1 Decomposition
Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. Activities represent the effort needed to complete a work package. The Define Activities process defines the final outputs as activities rather than deliverables, as done in the Create WBS process (Section 5.4).
The activity list, WBS, and WBS dictionary can be developed either sequentially or concurrently, with the WBS and WBS dictionary as the basis for development of the final activity list. Each work package within the WBS is decomposed into the activities required to produce the work package deliverables. Involving team members in the decomposition can lead to better and more accurate results.
6.2.2.2 Rolling Wave Planning Rolling wave planning is an iterative planning technique in which the work to be
accomplished in the near term is planned in detail, while the work in the future is planned at a higher level. It is a form of progressive elaboration. Therefore, work can exist at various levels of detail depending on where it is in the project life cycle. During early strategic planning, when information is less defined, work packages may be decomposed to the known level of detail. As more is known about the upcoming events in the near term, work packages can be decomposed into
166
activities.
6.2.2.3 Expert Judgment Project team members or other experts, who are experienced and skilled in
developing detailed project scope statements, the WBS, and project schedules, can provide expertise in defining activities.
6.2.3 Define Activities: Outputs 6.2.3.1 Activity List
The activity list is a comprehensive list that includes all schedule activities required on the project. The activity list also includes the activity identifier and a scope of work description for each activity in sufficient detail to ensure that project team members understand what work is required to be completed. Each activity should have a unique title that describes its place in the schedule, even if that activity title is displayed outside the context of the project schedule.
6.2.3.2 Activity Attributes Activities, distinct from milestones, have durations, during which the work of
that activity is performed, and may have resources and costs associated with that work. Activity attributes extend the description of the activity by identifying the multiple components associated with each activity. The components for each activity evolve over time. During the initial stages of the project, they include the activity identifier (ID), WBS ID, and activity label or name, and when completed, may include activity codes, activity description, predecessor activities, successor activities, logical relationships, leads and lags (Section 6.3.2.3), resource requirements, imposed dates, constraints, and assumptions. Activity attributes can be used to identify the person responsible for executing the work, geographic area, or place where the work has to be performed, the project calendar the activity is assigned to, and activity type such as level of effort (often abbreviated as LOE), discrete effort, and apportioned effort. Activity attributes are used for schedule development and for selecting, ordering, and sorting the planned schedule activities in various ways within reports. The number of attributes varies by application area.
6.2.3.3 Milestone List A milestone is a significant point or event in a project. A milestone list is a list
identifying all project milestones and indicates whether the milestone is mandatory, such as those required by contract, or optional, such as those based upon historical information. Milestones are similar to regular schedule activities, with the same structure and attributes, but they have zero duration because milestones represent a moment in time.
167
6.3 Sequence Activities Sequence Activities is the process of identifying and documenting relationships
among the project activities. The key benefit of this process is that it defines the logical sequence of work to obtain the greatest efficiency given all project constraints. The inputs, tools and techniques, and outputs of this process are depicted in Figure 6-7. Figure 6-8 depicts the data flow diagram of the process.
Every activity and milestone except the first and last should be connected to at
168
least one predecessor with a finish-to-start or start-to-start logical relationship and at least one successor with a finish-to-start or finish-to-finish logical relationship. Logical relationships should be designed to create a realistic project schedule. It may be necessary to use lead or lag time between activities to support a realistic and achievable project schedule. Sequencing can be performed by using project management software or by using manual or automated techniques.
6.3.1 Sequence Activities: Inputs
6.3.1.1 Schedule Management Plan Described in Section 6.1.3.1. The schedule management plan identifies the
scheduling method and tool to be used for the project, which will guide how the activities may be sequenced.
6.3.1.2 Activity List Described in Section 6.2.3.1. The activity list contains all schedule activities
required on the project, which are to be sequenced. Dependencies and other constraints for these activities can influence the sequencing of the activities.
6.3.1.3 Activity Attributes Described in Section 6.2.3.2. Activity attributes may describe a necessary
sequence of events or defined predecessor or successor relationships.
6.3.1.4 Milestone List Described in Section 6.2.3.3. The milestone list may have scheduled dates for
specific milestones, which may influence the way activities are sequenced.
6.3.1.5 Project Scope Statement Described in Section 5.3.3.1. The project scope statement contains the product
scope description, which includes product characteristics that may affect activity sequencing, such as the physical layout of a plant to be constructed or subsystem interfaces on a software project. Other information from the project scope statement including project deliverables, project constraints, and project assumptions may also affect activity sequencing. While these effects are often apparent in the activity list, the product scope description is generally reviewed to ensure accuracy.
6.3.1.6 Enterprise Environmental Factors Described in Section 2.1.5. Enterprise environmental factors that influence the
Sequence Activities process include, but are not limited to:
Government or industry standards, Project management information system (PMIS),
169
Scheduling tool, and Company work authorization systems.
6.3.1.7 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Sequence Activities process include, but are not limited to: project files from the corporate knowledge base used for scheduling methodology, existing formal and informal activity planning-related policies, procedures, and guidelines, such as the scheduling methodology that are considered in developing logical relationships, and templates that can be used to expedite the preparation of networks of project activities. Related activity attributes information in templates can also contain additional descriptive information useful in sequencing activities.
6.3.2 Sequence Activities: Tools and Techniques 6.3.2.1 Precedence Diagramming Method
The precedence diagramming method (PDM) is a technique used for constructing a schedule model in which activities are represented by nodes and are graphically linked by one or more logical relationships to show the sequence in which the activities are to be performed. Activity-on-node (AON) is one method of representing a precedence diagram. This is the method used by most project management software packages.
PDM includes four types of dependencies or logical relationships. A predecessor activity is an activity that logically comes before a dependent activity in a schedule. A successor activity is a dependent activity that logically comes after another activity in a schedule. These relationships are defined below and are illustrated in Figure 6-9:
Finish-to-start (FS). A logical relationship in which a successor activity cannot start until a predecessor activity has finished. Example: The awards ceremony (successor) cannot start until the race (predecessor) has finished. Finish-to-finish (FF). A logical relationship in which a successor activity cannot finish until a predecessor activity has finished. Example: Writing a document (predecessor) is required to finish before editing the document (successor) can finish. Start-to-start (SS). A logical relationship in which a successor activity cannot start until a predecessor activity has started. Example: Level concrete (successor) cannot begin until pour foundation (predecessor) begins. Start-to-finish (SF). A logical relationship in which a successor activity cannot finish until a predecessor activity has started. Example: The first security guard shift (successor) cannot finish until the second security guard
170
shift (predecessor) starts.
In PDM, finish-to-start is the most commonly used type of precedence relationship. The start-to-finish relationship is very rarely used but is included to present a complete list of the PDM relationship types.
6.3.2.2 Dependency Determination Dependencies may be characterized by the following attributes: mandatory or
discretionary, internal or external, as described below. Dependency has four attributes, but two can be applicable at the same time in following ways: mandatory external dependencies, mandatory internal dependencies, discretionary external dependencies, or discretionary internal dependencies.
Mandatory dependencies. Mandatory dependencies are those that are legally or contractually required or inherent in the nature of the work. Mandatory dependencies often involve physical limitations, such as on a construction project, where it is impossible to erect the superstructure until after the foundation has been built, or on an electronics project, where a prototype has to be built before it can be tested. Mandatory dependencies are also sometimes referred to as hard logic or hard dependencies. Technical dependencies may not be mandatory. The project team determines which dependencies are mandatory during the process of sequencing the activities. Mandatory dependencies should not be confused with assigning schedule constraints in the scheduling tool. Discretionary dependencies. Discretionary dependencies are sometimes
171
referred to as preferred logic, preferential logic, or soft logic. Discretionary dependencies are established based on knowledge of best practices within a particular application area or some unusual aspect of the project where a specific sequence is desired, even though there may be other acceptable sequences. Discretionary dependencies should be fully documented since they can create arbitrary total float values and can limit later scheduling options. When fast tracking techniques are employed, these discretionary dependencies should be reviewed and considered for modification or removal. The project team determines which dependencies are discretionary during the process of sequencing the activities. External dependencies. External dependencies involve a relationship between project activities and non-project activities. These dependencies are usually outside the project team's control. For example, the testing activity in a software project may be dependent on the delivery of hardware from an external source, or governmental environmental hearings may need to be held before site preparation can begin on a construction project. The project management team determines which dependencies are external during the process of sequencing the activities. Internal dependencies. Internal dependencies involve a precedence relationship between project activities and are generally inside the project team's control. For example, if the team cannot test a machine until they assemble it, this is an internal mandatory dependency. The project management team determines which dependencies are internal during the process of sequencing the activities.
6.3.2.3 Leads and Lags A lead is the amount of time whereby a successor activity can be advanced with
respect to a predecessor activity. For example, on a project to construct a new office building, the landscaping could be scheduled to start two weeks prior to the scheduled punch list completion. This would be shown as a finish-to-start with a two-week lead as shown in Figure 6-10. Lead is often represented as a negative value for lag in scheduling software.
172
A lag is the amount of time whereby a successor activity will be delayed with respect to a predecessor activity. For example, a technical writing team may begin editing the draft of a large document 15 days after they begin writing it. This can be shown as a start-to-start relationship with a 15-day lag as shown in Figure 6-10. Lag can also be represented in project schedule network diagrams as shown in Figure 6-11 in the relationship between activities H and I, as indicated by the nomenclature SS+10 (start-to-start plus 10 days lag) even though offset is not shown relative to a timescale.
The project management team determines the dependencies that may require a lead or a lag to accurately define the logical relationship. The use of leads and lags should not replace schedule logic. Activities and their related assumptions should be documented.
6.3.3 Sequence Activities: Outputs
6.3.3.1 Project Schedule Network Diagrams A project schedule network diagram is a graphical representation of the logical
relationships, also referred to as dependencies, among the project schedule activities. Figure 6-11 illustrates a project schedule network diagram. A project schedule network diagram is produced manually or by using project management software. It can include full project details, or have one or more summary activities. A summary narrative can accompany the diagram and describe the basic approach used to sequence the activities. Any unusual activity sequences within the network should be fully described within the narrative.
173
6.3.3.2 Project Documents Updates Project documents that may be updated include, but are not limited to:
Activity lists, Activity attributes, Milestone list, and Risk register.
6.4 Estimate Activity Resources Estimate Activity Resources is the process of estimating the type and quantities
of material, human resources, equipment, or supplies required to perform each activity. The key benefit of this process is that it identifies the type, quantity, and characteristics of resources required to complete the activity which allows more accurate cost and duration estimates. The inputs, tools and techniques, and outputs of this process are depicted in Figure 6-12. Figure 6-13 depicts the data flow diagram of the process.
174
The Estimate Activity Resources process is closely coordinated with the Estimate Costs process (Section 7.2). For example:
A construction project team will need to be familiar with local building codes. Such knowledge is often readily available from local sellers. However, if the local labor pool lacks experience with unusual or specialized construction techniques, the additional cost for a consultant may
175
be the most effective way to secure knowledge of the local building codes. An automotive design team will need to be familiar with the latest in automated assembly techniques. The requisite knowledge might be obtained by hiring a consultant, by sending a designer to a seminar on robotics, or by including someone from manufacturing as a member of the project team.
6.4.1 Estimate Activity Resources: Inputs
6.4.1.1 Schedule Management Plan Described in Section 6.1.3.1. The schedule management plan identifies the level
of accuracy and the units of measure for the resources to be estimated.
6.4.1.2 Activity List Described in Section 6.2.3.1. The activity list identifies the activities which will
need resources.
6.4.1.3 Activity Attributes Described in Section 6.2.3.2. The activity attributes provide the primary data
input for use in estimating those resources required for each activity in the activity list.
6.4.1.4 Resource Calendars Described in Sections 9.2.3.2 and 12.2.3.3. A resource calendar is a calendar
that identifies the working days and shifts on which each specific resource is available. Information on which resources (such as human resources, equipment, and material) are potentially available during a planned activity period, is used for estimating resource utilization. Resource calendars specify when and how long identified project resources will be available during the project. This information may be at the activity or project level. This knowledge includes consideration of attributes such as resource experience and/or skill level, as well as various geographical locations from which the resources originate and when they may be available.
6.4.1.5 Risk Register Described in Section 11.2.3.1. Risk events may impact resource selection and
availability. Updates to the risk register are included with project documents updates, described in Section 11.5.3.2, from Plan Risk Responses.
6.4.1.6 Activity Cost Estimates Described in Section 7.2.3.1. The cost of resources may impact resource
selection.
176
6.4.1.7 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
influence the Estimate Activity Resources process include, but are not limited to, resource location, availability, and skills.
6.4.1.8 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Estimate Activity Resources process include, but are not limited to:
Policies and procedures regarding staffing, Policies and procedures relating to rental and purchase of supplies and equipment, and Historical information regarding types of resources used for similar work on previous projects.
6.4.2 Estimate Activity Resources: Tools and Techniques 6.4.2.1 Expert Judgment
Expert judgment is often required to assess the resource-related inputs to this process. Any group or person with specialized knowledge in resource planning and estimating can provide such expertise.
6.4.2.2 Alternative Analysis Many schedule activities have alternative methods of accomplishment. They
include using various levels of resource capability or skills, different size or type of machines, different tools (hand versus automated), and make-rent-or-buy decisions regarding the resource (Section 12.1.3.5).
6.4.2.3 Published Estimating Data Several organizations routinely publish updated production rates and unit costs
of resources for an extensive array of labor trades, material, and equipment for different countries and geographical locations within countries.
6.4.2.4 Bottom-Up Estimating Bottom-up estimating is a method of estimating project duration or cost by
aggregating the estimates of the lower-level components of the WBS. When an activity cannot be estimated with a reasonable degree of confidence, the work within the activity is decomposed into more detail. The resource needs are estimated. These estimates are then aggregated into a total quantity for each of the activity's resources. Activities may or may not have dependencies between them that can affect the application and use of resources. If there are dependencies, this pattern of resource usage is reflected and documented in the estimated requirements
177
of the activity.
6.4.2.5 Project Management Software Project management software, such as a scheduling software tool, has the
capability to help plan, organize, and manage resource pools and develop resource estimates. Depending on the sophistication of the software, resource breakdown structures, resource availability, resource rates, and various resource calendars can be defined to assist in optimizing resource utilization.
6.4.3 Estimate Activity Resources: Outputs 6.4.3.1 Activity Resource Requirements
Activity resource requirements identify the types and quantities of resources required for each activity in a work package. These requirements then can be aggregated to determine the estimated resources for each work package and each work period. The amount of detail and the level of specificity of the resource requirement descriptions can vary by application area. The resource requirements documentation for each activity can include the basis of estimate for each resource, as well as the assumptions that were made in determining which types of resources are applied, their availability, and what quantities are used.
6.4.3.2 Resource Breakdown Structure The resource breakdown structure is a hierarchical representation of resources
by category and type. Examples of resource categories include labor, material, equipment, and supplies. Resource types may include the skill level, grade level, or other information as appropriate to the project. The resource breakdown structure is useful for organizing and reporting project schedule data with resource utilization information.
6.4.3.3 Project Documents Updates Project documents that may be updated include, but are not limited to:
Activity list, Activity attributes, and Resource calendars.
6.5 Estimate Activity Durations Estimate Activity Durations is the process of estimating the number of work
periods needed to complete individual activities with estimated resources. The key benefit of this process is that it provides the amount of time each activity will take to complete, which is a major input into the Develop Schedule process. The inputs, tools and techniques, and outputs of this process are depicted in Figure 6-14.
178
Figure 6-15 depicts the data flow diagram of the process.
Estimating activity durations uses information on activity scope of work,
179
required resource types, estimated resource quantities, and resource calendars. The inputs of the estimates of activity duration originate from the person or group on the project team who is most familiar with the nature of the work in the specific activity. The duration estimate is progressively elaborated, and the process considers the quality and availability of the input data. For example, as more detailed and precise data is available about the project engineering and design work, the accuracy of the duration estimates improves. Thus, the duration estimate can be assumed to be progressively more accurate and of better quality.
The Estimate Activity Durations process requires an estimation of the amount of work effort required to complete the activity and the amount of available resources estimated to complete the activity. These estimates are used to approximate the number of work periods (activity duration) needed to complete the activity using the appropriate project and resource calendars. All data and assumptions that support duration estimating are documented for each estimate of activity duration.
6.5.1 Estimate Activity Durations: Inputs
6.5.1.1 Schedule Management Plan Described in Section 6.1.3.1. The schedule management plan defines the method
used and the level of accuracy along with other criteria required to estimate activity durations including the project update cycle.
6.5.1.2 Activity List Described in Section 6.2.3.1. The activity list identifies the activities that will
need duration estimates.
6.5.1.3 Activity Attributes Described in Section 6.2.3.2. The activity attributes provide the primary data
input for use in estimating durations required for each activity in the activity list.
6.5.1.4 Activity Resource Requirements Described in Section 6.4.3.1. The estimated activity resource requirements will
have an effect on the duration of the activity, since the level to which the resources assigned to the activity meet the requirements will significantly influence the duration of most activities. For example, if additional or lower-skilled resources are assigned to an activity, there may be reduced efficiency or productivity due to increased communication, training, and coordination needs leading to a longer duration estimate.
6.5.1.5 Resource Calendars Described in Section 6.4.1.4. The resource calendars influence the duration of
schedule activities due to the availability of specific resources, type of resources,
180
and resources with specific attributes. For example, when staff members are assigned to an activity on a full-time basis, in general, a skilled staff member can be expected to complete a given activity in less time than a relatively less-skilled staff member.
6.5.1.6 Project Scope Statement Described in Section 5.3.3.1. The assumptions and constraints from the project
scope statement are considered when estimating the activity durations. Examples of assumptions include, but are not limited to:
Existing conditions, Availability of information, and Length of the reporting periods.
Examples of constraints include, but are not limited to:
Available skilled resources, and Contract terms and requirements.
6.5.1.7 Risk Register Described in Section 11.2.3.1. The risk register provides the list of risks, along
with the results of risk analysis and risk response planning. Updates to the risk register are included with project documents updates described in Section 11.5.3.2.
6.5.1.8 Resource Breakdown Structure Described in Section 6.4.3.2. The resource breakdown structure provides a
hierarchical structure of the identified resources by resource category and resource type.
6.5.1.9 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
influence the Estimate Activity Durations process include, but are not limited to:
Duration estimating databases and other reference data, Productivity metrics, Published commercial information, and Location of team members.
6.5.1.10 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Estimate Activity Durations process include, but are not limited to:
Historical duration information,
181
Project calendars, Scheduling methodology, and Lessons learned.
6.5.2 Estimate Activity Durations: Tools and Techniques
6.5.2.1 Expert Judgment Expert judgment, guided by historical information, can provide duration estimate
information or recommended maximum activity durations from prior similar projects. Expert judgment can also be used to determine whether to combine methods of estimating and how to reconcile differences between them.
6.5.2.2 Analogous Estimating Analogous estimating is a technique for estimating the duration or cost of an
activity or a project using historical data from a similar activity or project. Analogous estimating uses parameters from a previous, similar project, such as duration, budget, size, weight, and complexity, as the basis for estimating the same parameter or measure for a future project. When estimating durations, this technique relies on the actual duration of previous, similar projects as the basis for estimating the duration of the current project. It is a gross value estimating approach, sometimes adjusted for known differences in project complexity. Analogous duration estimating is frequently used to estimate project duration when there is a limited amount of detailed information about the project.
Analogous estimating is generally less costly and less time consuming than other techniques, but it is also less accurate. Analogous duration estimates can be applied to a total project or to segments of a project and may be used in conjunction with other estimating methods. Analogous estimating is most reliable when the previous activities are similar in fact and not just in appearance, and the project team members preparing the estimates have the needed expertise.
6.5.2.3 Parametric Estimating Parametric estimating is an estimating technique in which an algorithm is used to
calculate cost or duration based on historical data and project parameters. Parametric estimating uses a statistical relationship between historical data and other variables (e.g., square footage in construction) to calculate an estimate for activity parameters, such as cost, budget, and duration.
Activity durations can be quantitatively determined by multiplying the quantity of work to be performed by labor hours per unit of work. For example, activity duration on a design project is estimated by the number of drawings multiplied by the number of labor hours per drawing, or on a cable installation, the meters of cable multiplied by the number of labor hours per meter. For example, if the
182
assigned resource is capable of installing 25 meters of cable per hour, the duration required to install 1,000 meters is 40 hours. (1,000 meters divided by 25 meters per hour).
This technique can produce higher levels of accuracy depending upon the sophistication and underlying data built into the model. Parametric time estimates can be applied to a total project or to segments of a project, in conjunction with other estimating methods.
6.5.2.4 Three-Point Estimating The accuracy of single-point activity duration estimates may be improved by
considering estimation uncertainty and risk. This concept originated with the program evaluation and review technique (PERT). PERT uses three estimates to define an approximate range for an activity's duration:
Most likely (tM). This estimate is based on the duration of the activity, given the resources likely to be assigned, their productivity, realistic expectations of availability for the activity, dependencies on other participants, and interruptions. Optimistic (tO). The activity duration based on analysis of the best-case scenario for the activity. Pessimistic (tP). The activity duration based on analysis of the worst-case scenario for the activity.
Depending on the assumed distribution of values within the range of the three estimates the expected duration, tE, can be calculated using a formula. Two commonly used formulas are triangular and beta distributions. The formulas are:
Triangular Distribution. tE = (tO + tM + tP) / 3 Beta Distribution (from the traditional PERT technique). tE = (tO + 4tM + tP) / 6
Duration estimates based on three points with an assumed distribution provide an expected duration and clarify the range of uncertainty around the expected duration.
6.5.2.5 Group Decision-Making Techniques A group decision-making technique is an assessment process having multiple
alternatives with an expected outcome in the form of future actions. These techniques are useful for engaging team members to improve estimate accuracy and commitment to the emerging estimates. By involving a structured group of people who are close to the technical execution of work in the estimation process, additional information is gained and more accurate estimates are obtained. Additionally, when people are involved in the estimation process, their commitment towards meeting the resulting estimates increases.
183
6.5.2.6 Reserve Analysis Duration estimates may include contingency reserves, sometimes referred to as
time reserves or buffers, into the project schedule to account for schedule uncertainty. Contingency reserves are the estimated duration within the schedule baseline, which is allocated for identified risks that are accepted and for which contingent or mitigation responses are developed. Contingency reserves are associated with the “known-unknowns,” which may be estimated to account for this unknown amount of rework. The contingency reserve may be a percentage of the estimated activity duration, a fixed number of work periods, or may be developed by using quantitative analysis methods such as Monte Carlo simulation (Section 11.4.2.2). Contingency reserves may be separated from the individual activities and aggregated into buffers as shown in Figure 6-19.
As more precise information about the project becomes available, the contingency reserve may be used, reduced, or eliminated. Contingency should be clearly identified in schedule documentation.
Estimates may also be produced for the amount of management reserve of time for the project. Management reserves are a specified amount of the project duration withheld for management control purposes and are reserved for unforeseen work that is within scope of the project. Management reserves are intended to address the “unknown-unknowns” that can affect a project. Management reserve is not included in the schedule baseline, but it is part of the overall project duration requirements. Depending on contract terms, use of management reserves may require a change to the schedule baseline.
6.5.3 Estimate Activity Durations: Outputs 6.5.3.1 Activity Duration Estimates
Activity duration estimates are quantitative assessments of the likely number of time periods that are required to complete an activity. Duration estimates do not include any lags as described in Section 6.3.2.3. Activity duration estimates may include some indication of the range of possible results. For example:
2 weeks ± 2 days, which indicates that the activity will take at least eight days and not more than twelve (assuming a five-day workweek); and 15 % probability of exceeding three weeks, which indicates a high probability—85 %—that the activity will take three weeks or less.
6.5.3.2 Project Documents Updates Project documents that may be updated include, but are not limited to:
Activity attributes; and Assumptions made in developing the activity duration estimate, such as skill
184
levels and availability, as well as a basis of estimates for durations.
6.6 Develop Schedule Develop Schedule is the process of analyzing activity sequences, durations,
resource requirements, and schedule constraints to create the project schedule model. The key benefit of this process is that by entering schedule activities, durations, resources, resource availabilities, and logical relationships into the scheduling tool, it generates a schedule model with planned dates for completing project activities. The inputs, tools and techniques, and outputs of this process are depicted in Figure 6-16. Figure 6-17 depicts the data flow diagram of the process.
185
Developing an acceptable project schedule is often an iterative process. The schedule model is used to determine the planned start and finish dates for project activities and milestones based on the accuracy of the inputs. Schedule development can require the review and revision of duration estimates and resource estimates to create the project schedule model to establish an approved project schedule that can serve as a baseline to track progress. Once the activity start and finish dates have been determined, it is common to have project staff assigned to the activities review their assigned activities and confirm that the start and finish dates present no conflict with resource calendars or assigned activities
186
in other projects or tasks and thus are still valid. As work progresses, revising and maintaining the project schedule model to sustain a realistic schedule continues throughout the duration of the project, as described in Section 6.7.
For more specific information regarding scheduling, refer to the Practice Standard for Scheduling.
6.6.1 Develop Schedule: Inputs
6.6.1.1 Schedule Management Plan Described in Section 6.1.3.1. The schedule management plan identifies the
scheduling method and tool used to create the schedule, and how the schedule is to be calculated.
6.6.1.2 Activity List Described in Section 6.2.3.1. The activity list identifies the activities that will be
included in the schedule model.
6.6.1.3 Activity Attributes Described in Section 6.2.3.2. The activity attributes provide the details used to
build the schedule model.
6.6.1.4 Project Schedule Network Diagrams Described in Section 6.3.3.1. The project schedule network diagrams contain the
logical relationships of predecessors and successors that will be used to calculate the schedule.
6.6.1.5 Activity Resource Requirements Described in Section 6.4.3.1. The activity resource requirements identify the
types and quantities of resources required for each activity used to create the schedule model.
6.6.1.6 Resource Calendars Described in Sections 9.2.3.2 and 12.2.3.3. The resource calendars contain
information on the availability of resources during the project.
6.6.1.7 Activity Duration Estimates Described in Section 6.5.3.1. The activity duration estimates contain the
quantitative assessments of the likely number of work periods that will be required to complete an activity that will be used to calculate the schedule.
6.6.1.8 Project Scope Statement
187
Described in Section 5.3.3.1. The project scope statement contains assumptions and constraints that can impact the development of the project schedule.
6.6.1.9 Risk Register Described in Section 11.2.3.1. The risk register provides the details of all
identified risks and their characteristics that affect the schedule model.
6.6.1.10 Project Staff Assignments Described in Section 9.2.3.1. The project staff assignments specify which
resources are assigned to each activity.
6.6.1.11 Resource Breakdown Structure Described in Section 6.4.3.2. The resource breakdown structure provides the
details by which resource analysis and organizational reporting can be done.
6.6.1.12 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors include, but are
not limited to:
Standards, Communication channels, and Scheduling tool to be used in developing the schedule model.
6.6.1.13 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Develop Schedule process include, but are not limited to: scheduling methodology and project calendar(s).
6.6.2 Develop Schedule: Tools and Techniques 6.6.2.1 Schedule Network Analysis
Schedule network analysis is a technique that generates the project schedule model. It employs various analytical techniques, such as critical path method, critical chain method, what-if analysis, and resource optimization techniques to calculate the early and late start and finish dates for the uncompleted portions of project activities. Some network paths may have points of path convergence or path divergence that can be identified and used in schedule compression analysis or other analyses.
6.6.2.2 Critical Path Method The critical path method, which is a method used to estimate the minimum
project duration and determine the amount of scheduling flexibility on the logical
188
network paths within the schedule model. This schedule network analysis technique calculates the early start, early finish, late start, and late finish dates for all activities without regard for any resource limitations by performing a forward and backward pass analysis through the schedule network, as shown in Figure 6-18. In this example the longest path includes activities A, C, and D, and, therefore, the sequence of A-C-D is the critical path. The critical path is the sequence of activities that represents the longest path through a project, which determines the shortest possible project duration. The resulting early and late start and finish dates are not necessarily the project schedule, rather they indicate the time periods within which the activity could be executed, using the parameters entered in the schedule model for activity durations, logical relationships, leads, lags, and other known constraints. The critical path method is used to calculate the amount of scheduling flexibility on the logical network paths within the schedule model.
On any network path, the schedule flexibility is measured by the amount of time that a schedule activity can be delayed or extended from its early start date without delaying the project finish date or violating a schedule constraint, and is termed “total float.” A CPM critical path is normally characterized by zero total float on the critical path. As implemented with PDM sequencing, critical paths may have positive, zero, or negative total float depending on constraints applied. Any activity on the critical path is called a critical path activity. Positive total float is caused when the backward pass is calculated from a schedule constraint that is later than the early finish date that has been calculated during forward pass calculation. Negative total float is caused when a constraint on the late dates is violated by duration and logic. Schedule networks may have multiple near-critical paths. Many software packages allow the user to define the parameters used to determine the critical path(s). Adjustments to activity durations (if more resources or less scope can be arranged), logical relationships (if the relationships were discretionary to begin with), leads and lags, or other schedule constraints may be necessary to produce network paths with a zero or positive total float. Once the total float for a network path has been calculated, then the free float—the amount of time that a schedule activity can be delayed without delaying the early start date of any successor or violating a schedule constraint—can also be determined. For example the free float for Activity B, in Figure 6-18, is 5 days.
189
6.6.2.3 Critical Chain Method The critical chain method (CCM) is a schedule method that allows the project
team to place buffers on any project schedule path to account for limited resources and project uncertainties. It is developed from the critical path method approach and considers the effects of resource allocation, resource optimization, resource leveling, and activity duration uncertainty on the critical path determined using the critical path method. To do so, the critical chain method introduces the concept of buffers and buffer management. The critical chain method uses activities with durations that do not include safety margins, logical relationships, and resource availability with statistically determined buffers composed of the aggregated safety margins of activities at specified points on the project schedule path to account for limited resources and project uncertainties. The resource-constrained critical path is known as the critical chain.
The critical chain method adds duration buffers that are non-work schedule activities to manage uncertainty. One buffer, placed at the end of the critical chain, as shown in Figure 6-19, is known as the project buffer and protects the target finish date from slippage along the critical chain. Additional buffers, known as feeding buffers, are placed at each point where a chain of dependent activities that are not on the critical chain feeds into the critical chain. Feeding buffers thus protect the critical chain from slippage along the feeding chains. The size of each buffer should account for the uncertainty in the duration of the chain of dependent
190
activities leading up to that buffer. Once the buffer schedule activities are determined, the planned activities are scheduled to their latest possible planned start and finish dates. Consequently, instead of managing the total float of network paths, the critical chain method focuses on managing the remaining buffer durations against the remaining durations of chains of activities.
6.6.2.4 Resource Optimization Techniques Examples of resource optimization techniques that can be used to adjust the
schedule model due to demand and supply of resources include, but are not limited to:
Resource leveling. A technique in which start and finish dates are adjusted based on resource constraints with the goal of balancing demand for resources with the available supply. Resource leveling can be used when shared or critically required resources are only available at certain times, or in limited quantities, or over-allocated, such as when a resource has been assigned to two or more activities during the same time period, as shown in Figure 6-20, or to keep resource usage at a constant level. Resource leveling can often cause the original critical path to change, usually to increase.
191
Resource Smoothing. A technique that adjusts the activities of a schedule model such that the requirements for resources on the project do not exceed certain predefined resource limits. In resource smoothing, as opposed to resource leveling, the project's critical path is not changed and the completion date may not be delayed. In other words, activities may only be delayed within their free and total float. Thus resource smoothing may not be able to optimize all resources.
6.6.2.5 Modeling Techniques Examples of modeling techniques include, but are not limited to:
What-If Scenario Analysis. What-if scenario analysis is the process of evaluating scenarios in order to predict their effect, positively or negatively, on project objectives. This is an analysis of the question, “What if the situation represented by scenario ‘X’ happens?” A schedule network
192
analysis is performed using the schedule to compute the different scenarios, such as delaying a major component delivery, extending specific engineering durations, or introducing external factors, such as a strike or a change in the permitting process. The outcome of the what-if scenario analysis can be used to assess the feasibility of the project schedule under adverse conditions, and in preparing contingency and response plans to overcome or mitigate the impact of unexpected situations. Simulation. Simulation involves calculating multiple project durations with different sets of activity assumptions, usually using probability distributions constructed from the three-point estimates (described in Section 6.5.2.4) to account for uncertainty. The most common simulation technique is Monte Carlo analysis (Section 11.4.2.2), in which a distribution of possible activity durations is defined for each activity and used to calculate a distribution of possible outcomes for the total project.
6.6.2.6 Leads and Lags Described in Section 6.3.2.3. Leads and lags are refinements applied during
network analysis to develop a viable schedule by adjusting the start time of the successor activities. Leads are used in limited circumstances to advance a successor activity with respect to the predecessor activity, and lags are used in limited circumstances where processes require a set period of time to elapse between the predecessors and successors without work or resource impact.
6.6.2.7 Schedule Compression Schedule compression techniques are used to shorten the schedule duration
without reducing the project scope, in order to meet schedule constraints, imposed dates, or other schedule objectives. Schedule compression techniques include, but are not limited to:
Crashing. A technique used to shorten the schedule duration for the least incremental cost by adding resources. Examples of crashing include approving overtime, bringing in additional resources, or paying to expedite delivery to activities on the critical path. Crashing works only for activities on the critical path where additional resources will shorten the activity's duration. Crashing does not always produce a viable alternative and may result in increased risk and/or cost. Fast tracking. A schedule compression technique in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration. An example is constructing the foundation for a building before completing all of the architectural drawings. Fast tracking may result in rework and increased risk. Fast tracking only works if activities can be overlapped to shorten the project duration.
193
6.6.2.8 Scheduling Tool Automated scheduling tools contain the schedule model and expedite the
scheduling process by generating start and finish dates based on the inputs of activities, network diagrams, resources and activity durations using schedule network analysis. A scheduling tool can be used in conjunction with other project management software applications as well as manual methods.
6.6.3 Develop Schedule: Outputs 6.6.3.1 Schedule Baseline
A schedule baseline is the approved version of a schedule model that can be changed only through formal change control procedures and is used as a basis for comparison to actual results. It is accepted and approved by the appropriate stakeholders as the schedule baseline with baseline start dates and baseline finish dates. During monitoring and controlling, the approved baseline dates are compared to the actual start and finish dates to determine whether variances have occurred. The schedule baseline is a component of the project management plan.
6.6.3.2 Project Schedule The outputs from a schedule model are schedule presentations. The project
schedule is an output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources. At a minimum, the project schedule includes a planned start date and planned finish date for each activity. If resource planning is done at an early stage, then the project schedule remains preliminary until resource assignments have been confirmed and scheduled start and finish dates are established. This process usually occurs no later than the completion of the project management plan (Section 4.2.3.1). A target project schedule model may also be developed with a defined target start and target finish for each activity. The project schedule presentation may be presented in summary form, sometimes referred to as the master schedule or milestone schedule, or presented in detail. Although a project schedule model can be presented in tabular form, it is more often presented graphically, using one or more of the following formats, which are classified as presentations:
Bar charts. These charts, also known as Gantt charts, represent schedule information where activities are listed on the vertical axis, dates are shown on the horizontal axis, and activity durations are shown as horizontal bars placed according to start and finish dates. Bar charts are relatively easy to read, and are frequently used in management presentations. For control and management communications, the broader, more comprehensive summary activity, sometimes referred to as a hammock activity, is used between milestones or across multiple interdependent work packages, and is
194
displayed in bar chart reports. An example is the summary schedule portion of Figure 6-21 that is presented in a WBS-structured format. Milestone charts. These charts are similar to bar charts, but only identify the scheduled start or completion of major deliverables and key external interfaces. An example is the milestone schedule portion of Figure 6-21. Project schedule network diagrams. These diagrams are commonly presented in the activity-on-node diagram format showing activities and relationships without a time scale, sometimes referred to as a pure logic diagram, as shown in Figure 6-11, or presented in a timescaled schedule network diagram format that is sometimes called a logic bar chart, as shown for the detailed schedule in Figure 6-21. These diagrams, with activity date information, usually show both the project network logic and the project's critical path schedule activities. This example also shows how each work package is planned as a series of related activities. Another presentation of the project schedule network diagram is a timescaled logic diagram. These diagrams include a time scale and bars that represent the duration of activities with the logical relationships. It is optimized to show the relationships between activities where any number of activities may appear on the same line of the diagram in sequence.
195
196
Figure 6-21 shows schedule presentations for a sample project being executed, with the work in progress reported through the data date, a point in time when the status of the project is recorded, which is sometimes also called the as-of date or status date. For a simple project schedule model, Figure 6-21 reflects schedule presentations in the forms of (1) a milestone schedule as a milestone chart, (2) a summary schedule as a bar chart, and (3) a detailed schedule as a project schedule network diagram. Figure 6-21 also visually shows the relationships among the three different levels of schedule presentation.
6.6.3.3 Schedule Data The schedule data for the project schedule model is the collection of information
for describing and controlling the schedule. The schedule data includes at least the schedule milestones, schedule activities, activity attributes, and documentation of all identified assumptions and constraints. The amount of additional data varies by application area. Information frequently supplied as supporting detail includes, but is not limited to:
Resource requirements by time period, often in the form of a resource histogram; Alternative schedules, such as best-case or worst-case, not resource- leveled, or resource-leveled, with or without imposed dates; and Scheduling of contingency reserves.
Schedule data could also include such items as resource histograms, cash-flow projections, and order and delivery schedules.
6.6.3.4 Project Calendars A project calendar identifies working days and shifts that are available for
scheduled activities. It distinguishes time periods in days or parts of days that are available to complete scheduled activities from time periods that are not available. A schedule model may require more than one project calendar to allow for different work periods for some activities to calculate the project schedule. The project calendars may be updated.
6.6.3.5 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to:
Schedule baseline (Section 6.6.3.1), Schedule management plan (Section 6.1.3.1).
6.6.3.6 Project Documents Updates Project documents that may be updated include, but are not limited to:
197
Activity resource requirements. Resource leveling can have a significant effect on preliminary estimates for the types and quantities of resources required. If the resource-leveling analysis changes the project resource requirements, then the project resource requirements are updated. Activity attributes. Activity attributes (Section 6.2.3.2) are updated to include any revised resource requirements and any other revisions generated by the Develop Schedule process. Calendars. The calendar for each project may consist of multiple calendars, project calendars, individual resource calendars etc., as the basis for scheduling the project. Risk register. The risk register may need to be updated to reflect opportunities or threats perceived through scheduling assumptions.
6.7 Control Schedule Control Schedule is the process of monitoring the status of project activities to
update project progress and manage changes to the schedule baseline to achieve the plan. The key benefit of this process is that it provides the means to recognize deviation from the plan and take corrective and preventive actions and thus minimize risk. The inputs, tools and techniques, and outputs of this process are depicted in Figure 6-22. Figure 6-23 depicts the data flow diagram of the process.
198
Updating the schedule model requires knowing the actual performance to date. Any change to the schedule baseline can only be approved through the Perform Integrated Change Control process (Section 4.5). Control Schedule, as a component of the Perform Integrated Change Control process, is concerned with:
Determining the current status of the project schedule, Influencing the factors that create schedule changes, Determining if the project schedule has changed, and Managing the actual changes as they occur.
If any agile approach is utilized, control schedule is concerned with:
Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against the estimates of work completed for the elapsed time cycle, Conducting retrospective reviews (scheduled reviews to record lessons learned) for correcting processes and improving, if required, Reprioritizing the remaining work plan (backlog), Determining the rate at which the deliverables are produced, validated, and
199
accepted (velocity) in given time per iteration (agreed work cycle duration, typically two weeks or one month), Determining that the project schedule has changed, and Managing the actual changes as they occur.
6.7.1 Control Schedule: Inputs
6.7.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan contains the schedule
management plan and the schedule baseline. The schedule management plan describes how the schedule will be managed and controlled. The schedule baseline is used as a reference to compare with actual results to determine if a change, corrective action, or preventive action is necessary.
6.7.1.2 Project Schedule Described in Section 6.6.3.2. Project schedule refers to the most recent version
with notations to indicate updates, completed activities, and started activities as of the indicated data date.
6.7.1.3 Work Performance Data Described in Section 4.3.3.2. Work performance data refers to information about
project progress such as which activities have started, their progress (e.g., actual duration, remaining duration, and physical percent complete), and which activities have finished.
6.7.1.4 Project Calendars Described in Section 6.6.3.4. A schedule model may require more than one
project calendar to allow for different work periods for some activities to calculate the schedule forecasts.
6.7.1.5 Schedule Data Described in Section 6.6.3.3. Schedule data will be reviewed and updated in the
Control Schedule process.
6.7.1.6 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Control Schedule process include, but are not limited to:
Existing formal and informal schedule control-related policies, procedures, and guidelines; Schedule control tools; and Monitoring and reporting methods to be used.
200
6.7.2 Control Schedule: Tools and Techniques 6.7.2.1 Performance Reviews
Performance reviews measure, compare, and analyze schedule performance such as actual start and finish dates, percent complete, and remaining duration for work in progress. Various techniques may be used, among them:
Trend analysis. Trend analysis examines project performance over time to determine whether performance is improving or deteriorating. Graphical analysis techniques are valuable for understanding performance to date and for comparison to future performance goals in the form of completion dates. Critical path method (Section 6.6.2.2). Comparing the progress along the critical path can help determine schedule status. The variance on the critical path will have a direct impact on the project end date. Evaluating the progress of activities on near critical paths can identify schedule risk. Critical chain method (Section 6.6.2.3). Comparing the amount of buffer remaining to the amount of buffer needed to protect the delivery date can help determine schedule status. The difference between the buffer needed and the buffer remaining can determine whether corrective action is appropriate. Earned value management (Section 7.4.2.1). Schedule performance measurements such as schedule variance (SV) and schedule performance index (SPI), are used to assess the magnitude of variation to the original schedule baseline. The total float and early finish variances are also essential planning components to evaluate project time performance. Important aspects of schedule control include determining the cause and degree of variance relative to the schedule baseline (Section 6.6.3.1), estimating the implications of those variances for future work to completion, and deciding whether corrective or preventive action is required. For example, a major delay on any activity not on the critical path may have little effect on the overall project schedule, while a much shorter delay on a critical or near-critical activity may require immediate action. For projects not using earned value management, similar variance analysis can be performed by comparing planned activity start or finish dates against actual start or finish dates to identify variances between the schedule baseline and actual project performance. Further analysis can be performed to determine the cause and degree of variance relative to the schedule baseline and any corrective or preventative actions needed.
6.7.2.2 Project Management Software Project management software for scheduling provides the ability to track planned
dates versus actual dates, to report variances to and progress made against the
201
schedule baseline, and to forecast the effects of changes to the project schedule model.
6.7.2.3 Resource Optimization Techniques Described in Section 6.6.2.4. Resource optimization techniques involve the
scheduling of activities and the resources required by those activities while taking into consideration both the resource availability and the project time.
6.7.2.4 Modeling Techniques Described in Section 6.6.2.5. Modeling techniques are used to review various
scenarios guided by risk monitoring to bring the schedule model into alignment with the project management plan and approved baseline.
6.7.2.5 Leads and Lags Adjusting leads and lags is applied during network analysis to find ways to bring
project activities that are behind into alignment with the plan. For example, on a project to construct a new office building, the landscaping can be adjusted to start before the exterior work of the building is complete by increasing the lead time in the relationship. Or, a technical writing team can adjust the start of editing the draft of a large document immediately after the document is completed by eliminating or decreasing lag time.
6.7.2.6 Schedule Compression Described in Section 6.6.2.7. Schedule compression techniques are used to find
ways to bring project activities that are behind into alignment with the plan by fast tracking or crashing schedule for the remaining work.
6.7.2.7 Scheduling Tool Schedule data is updated and compiled into the schedule model to reflect actual
progress of the project and remaining work to be completed. The scheduling tool (Section 6.6.2.8) and the supporting schedule data are used in conjunction with manual methods or other project management software to perform schedule network analysis to generate an updated project schedule.
6.7.3 Control Schedule: Outputs 6.7.3.1 Work Performance Information
The calculated SV and SPI time performance indicators for WBS components, in particular the work packages and control accounts, are documented and communicated to stakeholders.
6.7.3.2 Schedule Forecasts
202
Schedule forecasts are estimates or predictions of conditions and events in the project's future based on information and knowledge available at the time of the forecast. Forecasts are updated and reissued based on work performance information provided as the project is executed. The information is based on the project's past performance and expected future performance, and includes earned value performance indicators that could impact the project in the future.
6.7.3.3 Change Requests Schedule variance analysis, along with review of progress reports, results of
performance measures, and modifications to the project scope or project schedule may result in change requests to the schedule baseline, scope baseline, and/or other components of the project management plan. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.5). Preventive actions may include recommended changes to eliminate or reduce the probability of negative schedule variances.
6.7.3.4 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to:
Schedule baseline. Changes to the schedule baseline are incorporated in response to approved change requests (Section 4.4.3.1) related to project scope changes, activity resources, or activity duration estimates. The schedule baseline may be updated to reflect changes caused by schedule compression techniques. Schedule management plan. The schedule management plan may be updated to reflect a change in the way the schedule is managed. Cost baseline. The cost baseline may be updated to reflect approved change requests or changes caused by compression techniques.
6.7.3.5 Project Documents Updates Project documents that may be updated include, but are not limited to:
Schedule Data. New project schedule network diagrams may be developed to display approved remaining durations and approved modifications to the schedule. In some cases, project schedule delays can be so severe that development of a new target schedule with forecasted start and finish dates is needed to provide realistic data for directing the work, measuring performance, and measuring progress. Project Schedule. An updated project schedule will be generated from the schedule model populated with updated schedule data to reflect the schedule changes and manage the project.
203
Risk Register. The risk register, and risk response plans within it, may also be updated based on the risks that may arise due to schedule compression techniques.
6.7.3.6 Organizational Process Assets Updates Organizational process assets that may be updated include, but are not limited to:
Causes of variances, Corrective action chosen and the reasons, and Other types of lessons learned from project schedule control.
204
7
PROJECT COST MANAGEMENT Project Cost Management includes the processes involved in planning,
estimating, budgeting, financing, funding, managing, and controlling costs so that the project can be completed within the approved budget.
Figure 7-1 provides an overview of the following Project Cost Management processes:
7.1 Plan Cost Management—The process that establishes the policies, procedures, and documentation for planning, managing, expending, and controlling project costs.
7.2 Estimate Costs—The process of developing an approximation of the monetary resources needed to complete project activities.
7.3 Determine Budget—The process of aggregating the estimated costs of individual activities or work packages to establish an authorized cost baseline.
7.4 Control Costs—The process of monitoring the status of the project to update the project costs and managing changes to the cost baseline.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
On some projects, especially those of smaller scope, cost estimating and cost budgeting are tightly linked and can be viewed as a single process that can be performed by a single person over a relatively short period of time. These are presented here as distinct processes because the tools and techniques for each are different. The ability to influence cost is greatest at the early stages of the project, making early scope definition critical (Section 5.3).
205
Project Cost Management should consider the stakeholder requirements for managing costs. Different stakeholders will measure project costs in different ways and at different times. For example, the cost of an acquired item may be measured when the acquisition decision is made or committed, the order is placed, the item is delivered, or the actual cost is incurred or recorded for project accounting purposes.
Project Cost Management is primarily concerned with the cost of the resources
206
needed to complete project activities. Project Cost Management should also consider the effect of project decisions on the subsequent recurring cost of using, maintaining, and supporting the product, service, or result of the project. For example, limiting the number of design reviews can reduce the cost of the project but could increase the resulting product's operating costs.
In many organizations, predicting and analyzing the prospective financial performance of the project's product is performed outside of the project. In others, such as a capital facilities project, Project Cost Management can include this work. When such predictions and analyses are included, Project Cost Management may address additional processes and numerous general financial management techniques such as return on investment, discounted cash flow, and investment payback analysis.
The cost management planning effort occurs early in project planning and sets the framework for each of the cost management processes so that performance of the processes will be efficient and coordinated.
7.1 Plan Cost Management Plan Cost Management is the process that establishes the policies, procedures,
and documentation for planning, managing, expending, and controlling project costs. The key benefit of this process is that it provides guidance and direction on how the project costs will be managed throughout the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 7-2. Figure 7-3 depicts the data flow diagram of the process.
207
The cost management processes and their associated tools and techniques are documented in the cost management plan. The cost management plan is a component of the project management plan.
7.1.1 Plan Cost Management: Inputs
7.1.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan contains information
used to develop the cost management plan, which contains, but is not limited to:
Scope baseline. The scope baseline includes the project scope statement and WBS details for cost estimation and management. Schedule baseline. The schedule baseline defines when the project costs will be incurred. Other information. Other cost-related scheduling, risk, and communications decisions from the project management plan.
7.1.1.2 Project Charter Described in Section 4.1.3.1. The project charter provides the summary budget
from which the detailed project costs are developed. The project charter also defines the project approval requirements that will influence the management of the
208
project costs.
7.1.1.3 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that influence
the Plan Cost Management process include, but are not limited to:
Organizational culture and structure can all influence cost management; Market conditions describe what products, services, and results are available in the regional and global market; Currency exchange rates for project costs sourced from more than one country; Published commercial information such as resource cost rate information is often available from commercial databases that track skills and human resource costs, and provide standard costs for material and equipment. Published seller price lists are another source of information; and Project management information system, which provides alternative possibilities for managing cost.
7.1.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Plan Cost Management process include, but are not limited to:
Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions); Historical information and lessons learned knowledge bases; Financial databases; and Existing formal and informal cost estimating and budgeting-related policies, procedures, and guidelines.
7.1.2 Plan Cost Management: Tools and Techniques
7.1.2.1 Expert Judgment Expert judgment, guided by historical information, provides valuable insight
about the environment and information from prior similar projects. Expert judgment can also suggest whether to combine methods and how to reconcile differences between them.
Judgment based upon expertise in an application area, Knowledge Area, discipline, industry, etc., as appropriate for the activity being performed should be used in developing the cost management plan.
7.1.2.2 Analytical Techniques
209
Developing the cost management plan may involve choosing strategic options to fund the project such as: self-funding, funding with equity, or funding with debt. The cost management plan may also detail ways to finance project resources such as making, purchasing, renting, or leasing. These decisions, like other financial decisions affecting the project, may affect project schedule and/or risks.
Organizational policies and procedures may influence which financial techniques are employed in these decisions. Techniques may include (but are not limited to): payback period, return on investment, internal rate of return, discounted cash flow, and net present value.
7.1.2.3 Meetings Project teams may hold planning meetings to develop the cost management plan.
Attendees at these meetings may include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with responsibility for project costs, and others as needed.
7.1.3 Plan Cost Management: Outputs 7.1.3.1 Cost Management Plan
The cost management plan is a component of the project management plan and describes how the project costs will be planned, structured, and controlled. The cost management processes and their associated tools and techniques are documented in the cost management plan.
For example, the cost management plan can establish the following:
Units of measure. Each unit used in measurements (such as staff hours, staff days, weeks for time measures; or meters, liters, tons, kilometers, or cubic yards for quantity measures; or lump sum in currency form) is defined for each of the resources. Level of precision. The degree to which activity cost estimates will be rounded up or down (e.g., US$100.49 to US$100, or US$995.59 to US$1,000), based on the scope of the activities and magnitude of the project. Level of accuracy. The acceptable range (e.g., ±10%) used in determining realistic activity cost estimates is specified, and may include an amount for contingencies; Organizational procedures links. The work breakdown structure (WBS) (Section 5.4) provides the framework for the cost management plan, allowing for consistency with the estimates, budgets, and control of costs. The WBS component used for the project cost accounting is called the control account. Each control account is assigned a unique code or account
210
number(s) that links directly to the performing organization's accounting system. Control thresholds. Variance thresholds for monitoring cost performance may be specified to indicate an agreed-upon amount of variation to be allowed before some action needs to be taken. Thresholds are typically expressed as percentage deviations from the baseline plan. Rules of performance measurement. Earned value management (EVM) rules of performance measurement are set. For example, the cost management plan may:
Define the points in the WBS at which measurement of control accounts will be performed; Establish the earned value measurement techniques (e.g., weighted milestones, fixed-formula, percent complete, etc.) to be employed; and Specify tracking methodologies and the earned value management computation equations for calculating projected estimate at completion (EAC) forecasts to provide a validity check on the bottom-up EAC.
For more specific information regarding earned value management, refer to the Practice Standard for Earned Value Management – Second Edition.
Reporting formats. The formats and frequency for the various cost reports are defined. Process descriptions. Descriptions of each of the other cost management processes are documented. Additional details. Additional details about cost management activities include, but are not limited to:
Description of strategic funding choices, Procedure to account for fluctuations in currency exchange rates, and Procedure for project cost recording.
7.2 Estimate Costs Estimate Costs is the process of developing an approximation of the monetary
resources needed to complete project activities. The key benefit of this process is that it determines the amount of cost required to complete project work. The inputs, tools and techniques, and outputs of this process are depicted in Figure 7-4. Figure 7-5 depicts the data flow diagram of the process.
211
Cost estimates are a prediction that is based on the information known at a given point in time. Cost estimates include the identification and consideration of costing alternatives to initiate and complete the project. Cost trade-offs and risks should be considered, such as make versus buy, buy versus lease, and the sharing of resources in order to achieve optimal costs for the project.
212
Cost estimates are generally expressed in units of some currency (i.e., dollars, euros, yen, etc.), although in some instances other units of measure, such as staff hours or staff days, are used to facilitate comparisons by eliminating the effects of currency fluctuations.
Cost estimates should be reviewed and refined during the course of the project to reflect additional detail as it becomes available and assumptions are tested. The accuracy of a project estimate will increase as the project progresses through the project life cycle. For example, a project in the initiation phase may have a rough order of magnitude (ROM) estimate in the range of -25% to +75%. Later in the project, as more information is known, definitive estimates could narrow the range of accuracy to -5% to +10%. In some organizations, there are guidelines for when such refinements can be made and the degree of confidence or accuracy that is expected.
Sources of input information are derived from the outputs of processes in other Knowledge Areas. Once received, all of this information will remain available as inputs to all of the cost management processes.
Costs are estimated for all resources that will be charged to the project. This includes, but is not limited to, labor, materials, equipment, services, and facilities, as well as special categories such as an inflation allowance, cost of financing, or contingency costs. A cost estimate is a quantitative assessment of the likely costs for resources required to complete the activity. Cost estimates may be presented at the activity level or in summary form.
7.2.1 Estimate Costs: Inputs
7.2.1.1 Cost Management Plan Described in Section 7.1.3.1. The cost management plan defines how project
costs will be managed and controlled. It includes the method used and the level of accuracy required to estimate activity cost.
7.2.1.2 Human Resource Management Plan Described in Section 9.1.3.1. The human resource management plan provides
project staffing attributes, personnel rates, and related rewards/recognition, which are necessary components for developing the project cost estimates.
7.2.1.3 Scope Baseline The scope baseline is comprised of the following:
Project scope statement. The project scope statement (Section 5.3.3.1) provides the product description, acceptance criteria, key deliverables, project boundaries, assumptions, and constraints about the project. One basic assumption that needs to be made when estimating project costs is
213
whether the estimates will be limited to direct project costs only or whether the estimates will also include indirect costs. Indirect costs are those costs that cannot be directly traced to a specific project and therefore will be accumulated and allocated equitably over multiple projects by some approved and documented accounting procedure. One of the most common constraints for many projects is a limited project budget. Examples of other constraints are required delivery dates, available skilled resources, and organizational policies. Work breakdown structure. The WBS (Section 5.4) provides the relationships among all the components of the project and the project deliverables. WBS dictionary. The WBS dictionary (Section 5.4.3.1) provides detailed information about the deliverables and a description of the work for each component in the WBS required to produce each deliverable.
Additional information that may be found in the scope baseline includes contractual and legal implications, such as health, safety, security, performance, environmental, insurance, intellectual property rights, licenses, and permits. All of this information should be considered when developing the cost estimates.
7.2.1.4 Project Schedule Described in Section 6.6.3.2. The type and quantity of resources and the amount
of time which those resources are applied to complete the work of the project are major factors in determining the project cost. Schedule activity resources and their respective durations are used as key inputs to this process. Estimate Activity Resources (Section 6.4) involves determining the availability of staff, the number of staff hours required, and quantities of material and equipment needed to perform schedule activities. It is closely coordinated with cost estimating. Activity duration estimates (Section 6.5.3.1) will affect cost estimates on any project where the project budget includes an allowance for the cost of financing (including interest charges) and where resources are applied per unit of time for the duration of the activity. Activity duration estimates can also affect cost estimates that have time- sensitive costs included in them, such as union labor with regularly expiring collective bargaining agreements or materials with seasonal cost variations.
7.2.1.5 Risk Register Described in Section 11.2.3.1. The risk register should be reviewed to consider
risk response costs. Risks, which can be either threats or opportunities, typically have an impact on both activity and overall project costs. As a general rule, when the project experiences a negative risk event, the near-term cost of the project will usually increase, and there will sometimes be a delay in the project schedule. In a similar way, the project team should be sensitive to potential opportunities that can
214
benefit the business either by directly reducing activity costs or by accelerating the schedule.
7.2.1.6 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that influence
the Estimate Costs process include, but are not limited to:
Market conditions. These conditions describe what products, services, and results are available in the market, from whom, and under what terms and conditions. Regional and/or global supply and demand conditions greatly influence resource costs.
Published commercial information. Resource cost rate information is often available from commercial databases that track skills and human resource costs, and provide standard costs for material and equipment. Published seller price lists are another source of information.
7.2.1.7 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Estimate Costs process include, but are not limited to:
Cost estimating policies, Cost estimating templates, Historical information, and Lessons learned.
7.2.2 Estimate Costs: Tools and Techniques
7.2.2.1 Expert Judgment Expert judgment, guided by historical information, provides valuable insight
about the environment and information from prior similar projects. Expert judgment can also be used to determine whether to combine methods of estimating and how to reconcile differences between them.
7.2.2.2 Analogous Estimating Analogous cost estimating uses the values such as scope, cost, budget, and
duration or measures of scale such as size, weight, and complexity from a previous, similar project as the basis for estimating the same parameter or measurement for a current project. When estimating costs, this technique relies on the actual cost of previous, similar projects as the basis for estimating the cost of the current project. It is a gross value estimating approach, sometimes adjusted for known differences in project complexity.
Analogous cost estimating is frequently used to estimate a value when there is a
215
limited amount of detailed information about the project, for example, in the early phases of a project. Analogous cost estimating uses historical information and expert judgment.
Analogous cost estimating is generally less costly and less time consuming than other techniques, but it is also generally less accurate. Analogous cost estimates can be applied to a total project or to segments of a project, in conjunction with other estimating methods. Analogous estimating is most reliable when the previous projects are similar in fact and not just in appearance, and the project team members preparing the estimates have the needed expertise.
7.2.2.3 Parametric Estimating Parametric estimating uses a statistical relationship between relevant historical
data and other variables (e.g., square footage in construction) to calculate a cost estimate for project work. This technique can produce higher levels of accuracy depending upon the sophistication and underlying data built into the model. Parametric cost estimates can be applied to a total project or to segments of a project, in conjunction with other estimating methods.
7.2.2.4 Bottom-Up Estimating Bottom-up estimating is a method of estimating a component of work. The cost of
individual work packages or activities is estimated to the greatest level of specified detail. The detailed cost is then summarized or “rolled up” to higher levels for subsequent reporting and tracking purposes. The cost and accuracy of bottom-up cost estimating are typically influenced by the size and complexity of the individual activity or work package.
7.2.2.5 Three-Point Estimating The accuracy of single-point activity cost estimates may be improved by
considering estimation uncertainty and risk and using three estimates to define an approximate range for an activity's cost:
Most likely (cM). The cost of the activity, based on realistic effort assessment for the required work and any predicted expenses. Optimistic (cO). The activity cost based on analysis of the best-case scenario for the activity. Pessimistic (cP). The activity cost based on analysis of the worst-case scenario for the activity.
Depending on the assumed distribution of values within the range of the three estimates the expected cost, cE, can be calculated using a formula. Two commonly used formulas are triangular and beta distributions. The formulas are:
Triangular Distribution. cE = (cO + cM + cP) / 3
216
Beta Distribution (from a traditional PERT analysis). cE = (cO + 4cM + cP) / 6
Cost estimates based on three points with an assumed distribution provide an expected cost and clarify the range of uncertainty around the expected cost.
7.2.2.6 Reserve Analysis Cost estimates may include contingency reserves (sometimes called contingency
allowances) to account for cost uncertainty. Contingency reserves are the budget within the cost baseline that is allocated for identified risks, which are accepted and for which contingent or mitigating responses are developed. Contingency reserves are often viewed as the part of the budget intended to address the “known- unknowns” that can affect a project. For example, rework for some project deliverables could be anticipated, while the amount of this rework is unknown. Contingency reserves may be estimated to account for this unknown amount of rework. Contingency reserves can be provided for a specific activity, for the whole project, or both. The contingency reserve may be a percentage of the estimated cost, a fixed number, or may be developed by using quantitative analysis methods.
As more precise information about the project becomes available, the contingency reserve may be used, reduced, or eliminated. Contingency should be clearly identified in cost documentation. Contingency reserves are part of the cost baseline and the overall funding requirements for the project.
Estimates may also be produced for the amount of management reserve to be funded for the project. Management reserves are an amount of the project budget withheld for management control purposes and are reserved for unforeseen work that is within scope of the project. Management reserves are intended to address the “unknown unknowns” that can affect a project. The management reserve is not included in the cost baseline but is part of the overall project budget and funding requirements. When an amount of management reserves is used to fund unforeseen work, the amount of management reserve used is added to the cost baseline, thus requiring an approved change to the cost baseline.
7.2.2.7 Cost of Quality (COQ) Assumptions about costs of quality (Section 8.1.2.2) may be used to prepare the
activity cost estimate.
7.2.2.8 Project Management Software Project management software applications, computerized spreadsheets,
simulation, and statistical tools are used to assist with cost estimating. Such tools can simplify the use of some cost-estimating techniques and thereby facilitate rapid consideration of cost estimate alternatives.
217
7.2.2.9 Vendor Bid Analysis Cost estimating methods may include analysis of what the project should cost,
based on the responsive bids from qualified vendors. When projects are awarded to a vendor under competitive processes, additional cost estimating work may be required of the project team to examine the price of individual deliverables and to derive a cost that supports the final total project cost.
7.2.2.10 Group Decision-Making Techniques A group decision-making technique is an assessment process having multiple
alternatives with an expected outcome in the form of future actions. These techniques are useful for engaging team members to improve estimate accuracy and commitment to the emerging estimates. By involving a structured group of people who are close to the technical execution of work in the estimation process, additional information is gained and more accurate estimates are obtained. Additionally, when people are involved in the estimation process, their commitment towards meeting the resulting estimates increases.
7.2.3 Estimate Costs: Outputs 7.2.3.1 Activity Cost Estimates
Activity cost estimates are quantitative assessments of the probable costs required to complete project work. Cost estimates can be presented in summary form or in detail. Costs are estimated for all resources that are applied to the activity cost estimate. This includes, but is not limited to, direct labor, materials, equipment, services, facilities, information technology, and special categories such as cost of financing (including interest charges), an inflation allowance, exchange rates, or a cost contingency reserve. Indirect costs, if they are included in the project estimate, can be included at the activity level or at higher levels.
7.2.3.2 Basis of Estimates The amount and type of additional details supporting the cost estimate vary by
application area. Regardless of the level of detail, the supporting documentation should provide a clear and complete understanding of how the cost estimate was derived.
Supporting detail for activity cost estimates may include:
Documentation of the basis of the estimate (i.e., how it was developed), Documentation of all assumptions made, Documentation of any known constraints, Indication of the range of possible estimates (e.g., €10,000 (±10%) to indicate that the item is expected to cost between a range of values), and
218
Indication of the confidence level of the final estimate.
7.2.3.3 Project Documents Updates Project documents that may be updated include, but are not limited to, the risk
register.
7.3 Determine Budget Determine Budget is the process of aggregating the estimated costs of individual
activities or work packages to establish an authorized cost baseline. The key benefit of this process is that it determines the cost baseline against which project performance can be monitored and controlled. The inputs, tools and techniques, and outputs of this process are depicted in Figure 7-6. Figure 7-7 depicts the data flow diagram of the process.
219
A project budget includes all the funds authorized to execute the project. The cost baseline is the approved version of the time-phased project budget, but excludes management reserves.
7.3.1 Determine Budget: Inputs
7.3.1.1 Cost Management Plan Described in Section 7.1.3.1. The cost management plan describes how the
project costs will be managed and controlled.
7.3.1.2 Scope Baseline Project scope statement. Formal limitations by period for the expenditure of project funds can be mandated by the organization, by agreement (Section 12.2.3.2), or by other entities such as government agencies. These funding constraints are reflected in the project scope statement. Work breakdown structure. The WBS (Section 5.4) provides the
220
relationships among all the project deliverables and their various components. WBS dictionary. The WBS dictionary (Section 5.4.3.1) and related detailed statements of work provide an identification of the deliverables and a description of the work in each WBS component required to produce each deliverable.
7.3.1.3 Activity Cost Estimates Described in Section 7.2.3.1. Cost estimates for each activity within a work
package are aggregated to obtain a cost estimate for each work package.
7.3.1.4 Basis of Estimates Described in Section 7.2.3.2. Supporting detail for cost estimates contained in
the basis for estimates should specify any basic assumptions dealing with the inclusion or exclusion of indirect or other costs in the project budget.
7.3.1.5 Project Schedule Described in Section 6.6.3.2. The project schedule includes planned start and
finish dates for the project's activities, milestones, work packages, and control accounts. This information can be used to aggregate costs to the calendar periods in which the costs are planned to be incurred.
7.3.1.6 Resource Calendars Described in Sections 9.2.3.2 and 12.2.3.3. Resource calendars provide
information on which resources are assigned to the project and when they are assigned. This information can be used to indicate resource costs over the duration of the project.
7.3.1.7 Risk Register Described in Section 11.2.3.1. The risk register should be reviewed to consider
how to aggregate the risk response costs. Updates to the risk register are included with project documents updates described in Section 11.5.3.2.
7.3.1.8 Agreements Described in Section 12.2.3.2. Applicable agreement information and costs
relating to products, services, or results that have been or will be purchased are included when determining the budget.
7.3.1.9 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Determine Budget process include, but are not limited to:
221
Existing formal and informal cost budgeting-related policies, procedures, and guidelines; Cost budgeting tools; and Reporting methods.
7.3.2 Determine Budget: Tools and Techniques
7.3.2.1 Cost Aggregation Cost estimates are aggregated by work packages in accordance with the WBS.
The work package cost estimates are then aggregated for the higher component levels of the WBS (such as control accounts) and ultimately for the entire project.
7.3.2.2 Reserve Analysis Budget reserve analysis can establish both the contingency reserves and the
management reserves for the project. Management and contingency reserves are addressed in more detail in Section 7.2.2.6.
7.3.2.3 Expert Judgment Expert judgment, guided by experience in an application area, Knowledge Area,
discipline, industry, or similar project, aids in determining the budget. Such expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training. Expert judgment is available from many sources, including, but not limited to:
Other units within the performing organization, Consultants, Stakeholders, including customers, Professional and technical associations, and Industry groups.
7.3.2.4 Historical Relationships Any historical relationships that result in parametric estimates or analogous
estimates involve the use of project characteristics (parameters) to develop mathematical models to predict total project costs. Such models may be simple (e.g., residential home construction is based on a certain cost per square foot of space) or complex (e.g., one model of software development costing uses multiple separate adjustment factors, each of which has numerous points within it).
Both the cost and accuracy of analogous and parametric models can vary widely. They are most likely to be reliable when:
Historical information used to develop the model is accurate,
222
Parameters used in the model are readily quantifiable, and Models are scalable, such that they work for large projects, small projects, and phases of a project.
7.3.2.5 Funding Limit Reconciliation The expenditure of funds should be reconciled with any funding limits on the
commitment of funds for the project. A variance between the funding limits and the planned expenditures will sometimes necessitate the rescheduling of work to level out the rate of expenditures. This is accomplished by placing imposed date constraints for work into the project schedule.
7.3.3 Determine Budget: Outputs 7.3.3.1 Cost Baseline
The cost baseline is the approved version of the time-phased project budget, excluding any management reserves, which can only be changed through formal change control procedures and is used as a basis for comparison to actual results. It is developed as a summation of the approved budgets for the different schedule activities.
Figure 7-8 illustrates the various components of the project budget and cost baseline. Activity cost estimates for the various project activities along with any contingency reserves (Section 7.2.2.6) for these activities are aggregated into their associated work package costs. The work package cost estimates, along with any contingency reserves estimated for the work packages, are aggregated into control accounts. The summation of the control accounts make up the cost baseline. Since the cost estimates that make up the cost baseline are directly tied to the schedule activities, this enables a time-phased view of the cost baseline, which is typically displayed in the form of an S-curve, as is illustrated in Figure 7-9.
Management reserves (Section 7.2.2.6) are added to the cost baseline to produce the project budget. As changes warranting the use of management reserves arise, the change control process is used to obtain approval to move the applicable management reserve funds into the cost baseline.
223
7.3.3.2 Project Funding Requirements Total funding requirements and periodic funding requirements (e.g., quarterly,
annually) are derived from the cost baseline. The cost baseline will include projected expenditures plus anticipated liabilities. Funding often occurs in incremental amounts that are not continuous, and may not be evenly distributed, which appear as steps as shown in Figure 7-9. The total funds required are those
224
included in the cost baseline, plus management reserves, if any. Funding requirements may include the source(s) of the funding.
7.3.3.3 Project Documents Updates Project documents that may be updated include, but are not limited to:
Risk register, Activity cost estimates, and Project schedule.
7.4 Control Costs Control Costs is the process of monitoring the status of the project to update the
project costs and managing changes to the cost baseline. The key benefit of this process is that it provides the means to recognize variance from the plan in order to take corrective action and minimize risk. The inputs, tools and techniques, and outputs of this process are depicted in Figure 7-10. Figure 7-11 depicts the data flow diagram of the process.
225
Updating the budget requires knowledge of the actual costs spent to date. Any increase to the authorized budget can only be approved through the Perform Integrated Change Control process (Section 4.5). Monitoring the expenditure of funds without regard to the value of work being accomplished for such expenditures has little value to the project, other than to allow the project team to stay within the authorized funding. Much of the effort of cost control involves analyzing the relationship between the consumption of project funds to the physical work being accomplished for such expenditures. The key to effective cost control is the management of the approved cost baseline and the changes to that baseline.
Project cost control includes:
Influencing the factors that create changes to the authorized cost baseline; Ensuring that all change requests are acted on in a timely manner; Managing the actual changes when and as they occur; Ensuring that cost expenditures do not exceed the authorized funding by period, by WBS component, by activity, and in total for the project; Monitoring cost performance to isolate and understand variances from the approved cost baseline; Monitoring work performance against funds expended;
226
Preventing unapproved changes from being included in the reported cost or resource usage; Informing appropriate stakeholders of all approved changes and associated cost; and Bringing expected cost overruns within acceptable limits.
7.4.1 Control Costs: Inputs
7.4.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan contains the
following information that is used to control cost:
Cost baseline. The cost baseline is compared with actual results to determine if a change, corrective action, or preventive action is necessary. Cost management plan. The cost management plan describes how the project costs will be managed and controlled (Section 7.1.3.1).
7.4.1.2 Project Funding Requirements Described in Section 7.3.3.2. The project funding requirements include projected expenditures plus anticipated liabilities.
7.4.1.3 Work Performance Data Described in Section 4.3.3.2. Work performance data includes information about
project progress, such as which activities have started, their progress, and which deliverables have finished. Information also includes costs that have been authorized and incurred.
7.4.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Control Costs process include, but are not limited to:
Existing formal and informal cost control-related policies, procedures, and guidelines; Cost control tools; and Monitoring and reporting methods to be used.
7.4.2 Control Costs: Tools and Techniques 7.4.2.1 Earned Value Management
Earned value management (EVM) is a methodology that combines scope, schedule, and resource measurements to assess project performance and progress. It is a commonly used method of performance measurement for projects. It
227
integrates the scope baseline with the cost baseline, along with the schedule baseline, to form the performance measurement baseline, which helps the project management team assess and measure project performance and progress. It is a project management technique that requires the formation of an integrated baseline against which performance can be measured for the duration of the project. The principles of EVM can be applied to all projects in any industry. EVM develops and monitors three key dimensions for each work package and control account:
Planned value. Planned value (PV) is the authorized budget assigned to scheduled work. It is the authorized budget planned for the work to be accomplished for an activity or work breakdown structure component, not including management reserve. This budget is allocated by phase over the life of the project, but at a given moment, planned value defines the physical work that should have been accomplished. The total of the PV is sometimes referred to as the performance measurement baseline (PMB). The total planned value for the project is also known as budget at completion (BAC). Earned value. Earned value (EV) is a measure of work performed expressed in terms of the budget authorized for that work. It is the budget associated with the authorized work that has been completed. The EV being measured needs to be related to the PMB, and the EV measured cannot be greater than the authorized PV budget for a component. The EV is often used to calculate the percent complete of a project. Progress measurement criteria should be established for each WBS component to measure work in progress. Project managers monitor EV, both incrementally to determine current status and cumulatively to determine the long-term performance trends. Actual cost. Actual cost (AC) is the realized cost incurred for the work performed on an activity during a specific time period. It is the total cost incurred in accomplishing the work that the EV measured. The AC needs to correspond in definition to what was budgeted in the PV and measured in the EV (e.g., direct hours only, direct costs only, or all costs including indirect costs). The AC will have no upper limit; whatever is spent to achieve the EV will be measured.
Variances from the approved baseline will also be monitored:
Schedule variance. Schedule variance (SV) is a measure of schedule performance expressed as the difference between the earned value and the planned value. It is the amount by which the project is ahead or behind the planned delivery date, at a given point in time. It is a measure of schedule performance on a project. It is equal to the earned value (EV) minus the planned value (PV). The EVM schedule variance is a useful metric in that it can indicate when a project is falling behind or is ahead of its baseline schedule. The EVM schedule variance will ultimately equal zero when the
228
project is completed because all of the planned values will have been earned. Schedule variance is best used in conjunction with critical path method (CPM) scheduling and risk management. Equation: SV = EV – PV Cost variance. Cost variance (CV) is the amount of budget deficit or surplus at a given point in time, expressed as the difference between earned value and the actual cost. It is a measure of cost performance on a project. It is equal to the earned value (EV) minus the actual cost (AC). The cost variance at the end of the project will be the difference between the budget at completion (BAC) and the actual amount spent. The CV is particularly critical because it indicates the relationship of physical performance to the costs spent. Negative CV is often difficult for the project to recover. Equation: CV= EV − AC. The SV and CV values can be converted to efficiency indicators to reflect the cost and schedule performance of any project for comparison against all other projects or within a portfolio of projects. The variances are useful for determining project status.
Schedule performance index. The schedule performance index (SPI) is a measure of schedule efficiency expressed as the ratio of earned value to planned value. It measures how efficiently the project team is using its time. It is sometimes used in conjunction with the cost performance index (CPI) to forecast the final project completion estimates. An SPI value less than 1.0 indicates less work was completed than was planned. An SPI greater than 1.0 indicates that more work was completed than was planned. Since the SPI measures all project work, the performance on the critical path also needs to be analyzed to determine whether the project will finish ahead of or behind its planned finish date. The SPI is equal to the ratio of the EV to the PV. Equation: SPI = EV/PV Cost performance index. The cost performance index (CPI) is a measure of the cost efficiency of budgeted resources, expressed as a ratio of earned value to actual cost. It is considered the most critical EVM metric and measures the cost efficiency for the work completed. A CPI value of less than 1.0 indicates a cost overrun for work completed. A CPI value greater than 1.0 indicates a cost underrun of performance to date. The CPI is equal to the ratio of the EV to the AC. The indices are useful for determining project status and providing a basis for estimating project cost and schedule outcome. Equation: CPI = EV/AC
The three parameters of planned value, earned value, and actual cost can be monitored and reported on both a period-by-period basis (typically weekly or monthly) and on a cumulative basis. Figure 7-12 uses S-curves to display EV data for a project that is performing over budget and behind the schedule.
229
7.4.2.2 Forecasting As the project progresses, the project team may develop a forecast for the
estimate at completion (EAC) that may differ from the budget at completion (BAC) based on the project performance. If it becomes obvious that the BAC is no longer viable, the project manager should consider the forecasted EAC. Forecasting the EAC involves making projections of conditions and events in the project's future based on current performance information and other knowledge available at the time of the forecast. Forecasts are generated, updated, and reissued based on work performance data (Section 4.3.3.2) that is provided as the project is executed. The work performance information covers the project's past performance and any information that could impact the project in the future.
EACs are typically based on the actual costs incurred for work completed, plus an estimate to complete (ETC) the remaining work. It is incumbent on the project team to predict what it may encounter to perform the ETC, based on its experience to date. The EVM method works well in conjunction with manual forecasts of the required EAC costs. The most common EAC forecasting approach is a manual, bottom-up summation by the project manager and project team.
The project manager's bottom-up EAC method builds upon the actual costs and experience incurred for the work completed, and requires a new estimate to complete the remaining project work. Equation: EAC = AC + Bottom-up ETC.
The project manager's manual EAC is quickly compared with a range of calculated EACs representing various risk scenarios. When calculating EAC
230
values, the cumulative CPI and SPI values are typically used. While EVM data quickly provide many statistical EACs, only three of the more common methods are described as follows:
EAC forecast for ETC work performed at the budgeted rate. This EAC method accepts the actual project performance to date (whether favorable or unfavorable) as represented by the actual costs, and predicts that all future ETC work will be accomplished at the budgeted rate. When actual performance is unfavorable, the assumption that future performance will improve should be accepted only when supported by project risk analysis. Equation: EAC = AC + (BAC – EV) EAC forecast for ETC work performed at the present CPI. This method assumes what the project has experienced to date can be expected to continue in the future. The ETC work is assumed to be performed at the same cumulative cost performance index (CPI) as that incurred by the project to date. Equation: EAC = BAC / CPI
EAC forecast for ETC work considering both SPI and CPI factors. In this forecast, the ETC work will be performed at an efficiency rate that considers both the cost and schedule performance indices. This method is most useful when the project schedule is a factor impacting the ETC effort. Variations of this method weight the CPI and SPI at different values (e.g., 80/20, 50/50, or some other ratio) according to the project manager's judgment. Equation: EAC = AC + [(BAC – EV) / (CPI × SPI)]
Each of these approaches is applicable for any given project and will provide the project management team with an “early warning” signal if the EAC forecasts are not within acceptable tolerances.
7.4.2.3 To-Complete Performance Index (TCPI) The to-complete performance index (TCPI) is a measure of the cost performance
that is required to be achieved with the remaining resources in order to meet a specified management goal, expressed as the ratio of the cost to finish the outstanding work to the remaining budget. TCPI is the calculated cost performance index that is achieved on the remaining work to meet a specified management goal, such as the BAC or the EAC. If it becomes obvious that the BAC is no longer viable, the project manager should consider the forecasted EAC. Once approved, the EAC may replace the BAC in the TCPI calculation. The equation for the TCPI based on the BAC: (BAC – EV) / (BAC – AC).
The TCPI is conceptually displayed in Figure 7-13. The equation for the TCPI is shown in the lower left as the work remaining (defined as the BAC minus the EV) divided by the funds remaining (which can be either the BAC minus the AC, or the EAC minus the AC).
231
If the cumulative CPI falls below the baseline (as shown in Figure 7-13), all future work of the project will need to be performed immediately in the range of the TCPI (BAC) (as reflected in the top line of Figure 7-13) to stay within the authorized BAC. Whether this level of performance is achievable is a judgment call based on a number of considerations, including risk, schedule, and technical performance. This level of performance is displayed as the TCPI (EAC) line. The equation for the TCPI based on the EAC: (BAC – EV) / (EAC – AC). The EVM formulas are provided in Table 7-1.
7.4.2.4 Performance Reviews Performance reviews compare cost performance over time, schedule activities
or work packages overrunning and underrunning the budget, and estimated funds needed to complete work in progress. If EVM is being used, the following information is determined:
Variance analysis. Variance analysis, as used in EVM, is the explanation (cause, impact, and corrective actions) for cost (CV = EV – AC), schedule (SV = EV – PV), and variance at completion (VAC = BAC – EAC) variances. Cost and schedule variances are the most frequently analyzed measurements. For projects not using earned value management, similar variance analyses can be performed by comparing planned activity cost against actual activity cost to identify variances between the cost baseline and actual project performance. Further analysis can be performed to determine the cause and degree of variance relative to the schedule baseline and any corrective or preventive actions needed. Cost performance
232
measurements are used to assess the magnitude of variation to the original cost baseline. An important aspect of project cost control includes determining the cause and degree of variance relative to the cost baseline (Section 7.3.3.1) and deciding whether corrective or preventive action is required. The percentage range of acceptable variances will tend to decrease as more work is accomplished.
Trend analysis. Trend analysis examines project performance over time to determine if performance is improving or deteriorating. Graphical analysis techniques are valuable for understanding performance to date and for comparison to future performance goals in the form of BAC versus EAC and completion dates. Earned value performance. Earned value performance compares the performance measurement baseline to actual schedule and cost performance. If EVM is not being used, then the analysis of the cost baseline against actual costs for the work performed is used for cost performance comparisons.
233
7.4.2.5 Project Management Software
234
Project management software is often used to monitor the three EVM dimensions (PV, EV, and AC), to display graphical trends, and to forecast a range of possible final project results.
7.4.2.6 Reserve Analysis During cost control, reserve analysis is used to monitor the status of contingency
and management reserves for the project to determine if these reserves are still needed or if additional reserves need to be requested. As work on the project progresses, these reserves may be used as planned to cover the cost of risk mitigation events or other contingencies. Or, if the probable risk events do not occur, the unused contingency reserves may be removed from the project budget to free up resources for other projects or operations. Additional risk analysis during the project may reveal a need to request that additional reserves be added to the project budget. Management and contingency reserves are addressed in more detail in Section 7.2.2.6.
7.4.3 Control Costs: Outputs 7.4.3.1 Work Performance Information
The calculated CV, SV, CPI, SPI, TCPI, and VAC values for WBS components, in particular the work packages and control accounts, are documented and communicated to stakeholders.
7.4.3.2 Cost Forecasts Either a calculated EAC value or a bottom-up EAC value is documented and
communicated to stakeholders.
7.4.3.3 Change Requests Analysis of project performance may result in a change request to the cost
baseline or other components of the project management plan. Change requests may include preventive or corrective actions, and are processed for review and disposition through the Perform Integrated Change Control process (Section 4.5).
7.4.3.4 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to:
Cost baseline. Changes to the cost baseline are incorporated in response to approved changes in scope, activity resources, or cost estimates. In some cases, cost variances can be so severe that a revised cost baseline is needed to provide a realistic basis for performance measurement. Cost management plan. Changes to the cost management plan, such as
235
changes to control thresholds or specified levels of accuracy required in managing the project's cost, are incorporated in response to feedback from relevant stakeholders.
7.4.3.5 Project Documents Updates Project documents that may be updated include, but are not limited to:
Activity cost estimates, and Basis of estimates.
7.4.3.6 Organizational Process Assets Updates Organizational process assets that may be updated include, but are not limited to:
Causes of variances, Corrective action chosen and the reasons, Financial databases, and Other types of lessons learned from project cost control.
236
8
PROJECT QUALITY MANAGEMENT Project Quality Management includes the processes and activities of the
performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. Project Quality Management uses policies and procedures to implement, within the project's context, the organization's quality management system and, as appropriate, it supports continuous process improvement activities as undertaken on behalf of the performing organization. Project Quality Management works to ensure that the project requirements, including product requirements, are met and validated.
Figure 8-1 provides an overview of the Project Quality Management processes, which include:
8.1 Plan Quality Management—The process of identifying quality requirements and/or standards for the project and its deliverables and documenting how the project will demonstrate compliance with quality requirements and/or standards.
8.2 Perform Quality Assurance—The process of auditing the quality requirements and the results from quality control measurements to ensure that appropriate quality standards and operational definitions are used.
8.3 Control Quality—The process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
Project Quality Management addresses the management of the project and the deliverables of the project. It applies to all projects, regardless of the nature of their deliverables. Quality measures and techniques are specific to the type of deliverables being produced by the project. For example, the project quality management of software deliverables may use different approaches and measures from those used when building a nuclear power plant. In either case, failure to meet the quality requirements can have serious, negative consequences for any or all of the project's stakeholders. For example:
Meeting customer requirements by overworking the project team may result in decreased profits and increased project risks, employee attrition, errors, or rework.
237
Meeting project schedule objectives by rushing planned quality inspections may result in undetected errors, decreased profits, and increased post- implementation risks.
Quality and grade are not the same concepts. Quality as a delivered performance or result is “the degree to which a set of inherent characteristics fulfill requirements” (ISO 9000) [10]. Grade as a design intent is a category assigned to deliverables having the same functional use but different technical characteristics. The project manager and the project management team are responsible for managing the tradeoffs associated with delivering the required levels of both quality and grade. While a quality level that fails to meet quality requirements is always a problem, a low grade of quality may not be a problem. For example:
It may not be a problem if a suitable low-grade software product (one with a limited number of features) is of high quality (no obvious defects, readable manual). In this example, the product would be appropriate for its general purpose of use. It may be a problem if a high-grade software product (one with numerous features) is of low quality (many defects, poorly organized user documentation). In essence, its high-grade feature set would prove ineffective and/or inefficient due to its low quality.
The project management team should determine the appropriate levels of accuracy and precision for use in the quality management plan. Precision is a measure of exactness. For example, the magnitude for each increment on the measurement's number line is the interval that determines the measurement's precision—the greater the number of increments, the greater the precision. Accuracy is an assessment of correctness. For example, if the measured value of an item is very close to the true value of the characteristic being measured, the measurement is more accurate. An illustration of this concept is the comparison of archery targets. Arrows clustered tightly in one area of the target, even if they are not clustered in the bull's-eye, are considered to have high precision. Targets where the arrows are more spread out but equidistant from the bull's-eye are considered to have the same degree of accuracy. Targets where the arrows are both tightly grouped and within the bull's-eye are considered to be both accurate and precise. Precise measurements are not necessarily accurate measurements, and accurate measurements are not necessarily precise measurements.
The basic approach to project quality management as described in this section is intended to be compatible with International Organization for Standardization (ISO) quality standards. Every project should have a quality management plan. Project teams should follow the quality management plan and should have data to demonstrate compliance with the plan.
In the context of achieving ISO compatibility, modern quality management
238
approaches seek to minimize variation and to deliver results that meet defined requirements. These approaches recognize the importance of:
Customer satisfaction. Understanding, evaluating, defining, and managing requirements so that customer expectations are met. This requires a combination of conformance to requirements (to ensure the project produces what it was created to produce) and fitness for use (the product or service needs to satisfy the real needs). Prevention over inspection. Quality should be planned, designed, and built into—not inspected into the project's management or the project's deliverables. The cost of preventing mistakes is generally much less than the cost of correcting mistakes when they are found by inspection or during usage. Continuous improvement. The PDCA (plan-do-check-act) cycle is the basis for quality improvement as defined by Shewhart and modified by Deming. In addition, quality improvement initiatives such as Total Quality Management (TQM), Six Sigma, and Lean Six Sigma could improve the quality of the project's management as well as the quality of the project's product. Commonly used process improvement models include Malcolm Baldrige, Organizational Project Management Maturity Model (OPM3®), and Capability Maturity Model Integration (CMMI®). Management Responsibility. Success requires the participation of all members of the project team. Nevertheless, management retains, within its responsibility for quality, a related responsibility to provide suitable resources at adequate capacities. Cost of quality (COQ). Cost of quality refers to the total cost of the conformance work and the nonconformance work that should be done as a compensatory effort because, on the first attempt to perform that work, the potential exists that some portion of the required work effort may be done or has been done incorrectly. The costs for quality work may be incurred throughout the deliverable's life cycle. For example, decisions made by the project team can impact the operational costs associated with using a completed deliverable. Post-project quality costs may be incurred because of product returns, warranty claims, and recall campaigns. Therefore, because of the temporary nature of projects and the potential benefits that may be derived from reducing the post-project cost of quality, sponsoring organizations may choose to invest in product quality improvement. These investments generally are made in the areas of conformance work that act to prevent defects or act to mitigate the costs of defects by inspecting out nonconforming units. Refer to Figure 8-2 and Section 8.1.2.2. Moreover, the issues related to post-project COQ should be the concern of program management and portfolio management such that project, program, and
239
portfolio management offices should apply appropriate reviews, templates, and funding allocations for this purpose.
240
8.1 Plan Quality Management Plan Quality Management is the process of identifying quality requirements
and/or standards for the project and its deliverables, and documenting how the project will demonstrate compliance with relevant quality requirements and/or standards. The key benefit of this process is that it provides guidance and direction on how quality will be managed and validated throughout the project. The inputs, tools and techniques, and outputs of this process are depicted in Figure 8-3. Figure 8-4 depicts the data flow diagram of the process.
241
Quality planning should be performed in parallel with the other planning processes. For example, proposed changes in the deliverables to meet identified quality standards may require cost or schedule adjustments and a detailed risk analysis of the impact to plans.
The quality planning techniques discussed here are those used most frequently on projects. There are many others that may be useful on certain projects or in some application areas.
8.1.1 Plan Quality Management: Inputs
8.1.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan is used to develop
the quality management plan. The information used for the development of the quality management plan includes, but is not limited to:
Scope baseline. The scope baseline (Section 5.4.3.1) includes: Project scope statement. The project scope statement contains the project description, major project deliverables, and acceptance criteria. The product scope often contains details of technical issues and other concerns that can affect quality planning and that should
242
have been identified as a result of the planning processes in Project Scope Management. The definition of acceptance criteria may significantly increase or decrease quality costs and therefore, project costs. Satisfying all acceptance criteria implies that the needs of the sponsor and/or customer have been met. Work breakdown structure (WBS). The WBS identifies the deliverables and the work packages used to measure project performance. WBS dictionary. The WBS dictionary provides detailed information for WBS elements.
Schedule baseline. The schedule baseline documents the accepted schedule performance measures, including start and finish dates (Section 6.6.3.1). Cost baseline. The cost baseline documents the accepted time interval being used to measure cost performance (Section 7.3.3.1). Other management plans. These plans contribute to the overall project quality and may highlight actionable areas of concern with regard to the project's quality.
8.1.1.2 Stakeholder Register Described in Section 13.1.3.1. The stakeholder register aids in identifying those
stakeholders possessing a particular interest in, or having an impact on, quality.
8.1.1.3 Risk Register Described in Section 11.2.3.1. The risk register contains information on threats
and opportunities that may impact quality requirements.
8.1.1.4 Requirements Documentation Described in Section 5.2.3.1. Requirements documentation captures the
requirements that the project shall meet pertaining to stakeholder expectations. The components of the requirements documentation include, but are not limited to, project (including product) and quality requirements. The requirements are used by the project team to help plan how quality control will be implemented on the project.
8.1.1.5 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that influence
the Plan Quality Management process include, but are not limited to:
Governmental agency regulations; Rules, standards, and guidelines specific to the application area; Working or operating conditions of the project or its deliverables that may
243
affect project quality; and Cultural perceptions that may influence expectations about quality.
8.1.1.6 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Plan Quality Management process include, but are not limited to:
Organizational quality policies, procedures, and guidelines. The performing organization's quality policy, as endorsed by senior management, sets the organization's intended direction on implementing its quality management approach; Historical databases; and Lessons learned from previous phases or projects.
8.1.2 Plan Quality Management: Tools and Techniques 8.1.2.1 Cost-Benefit Analysis
The primary benefits of meeting quality requirements include less rework, higher productivity, lower costs, increased stakeholder satisfaction, and increased profitability. A cost-benefit analysis for each quality activity compares the cost of the quality step to the expected benefit.
8.1.2.2 Cost of Quality (COQ) Cost of quality includes all costs incurred over the life of the product by
investment in preventing nonconformance to requirements, appraising the product or service for conformance to requirements, and failing to meet requirements (rework). Failure costs are often categorized into internal (found by the project) and external (found by the customer). Failure costs are also called cost of poor quality. Figure 8-5 provides some examples to consider in each area.
244
8.1.2.3 Seven Basic Quality Tools The seven basic quality tools, also known in the industry as 7QC Tools, are used
within the context of the PDCA Cycle to solve quality-related problems. As conceptually illustrated in Figure 8-7, the seven basic quality tools are:
Cause-and-effect diagrams, which are also known as fishbone diagrams or as Ishikawa diagrams. The problem statement placed at the head of the fishbone is used as a starting point to trace the problem's source back to its actionable root cause. The problem statement typically describes the problem as a gap to be closed or as an objective to be achieved. The causes are found by looking at the problem statement and asking “why” until the actionable root cause has been identified or until the reasonable possibilities on each fishbone have been exhausted. Fishbone diagrams often prove useful in linking the undesirable effects seen as special variation to the assignable cause upon which project teams should implement corrective actions to eliminate the special variation detected in a control chart. Flowcharts, which are also referred to as process maps because they display the sequence of steps and the branching possibilities that exist for a process that transforms one or more inputs into one or more outputs. Flowcharts show the activities, decision points, branching loops, parallel paths, and the overall order of processing by mapping the operational details of procedures that exist within a horizontal value chain of a SIPOC model (Figure 8-6). Flowcharts may prove useful in understanding and
245
estimating the cost of quality in a process. This is obtained by using the workflow branching logic and associated relative frequencies to estimate expected monetary value for the conformance and nonconformance work required to deliver the expected conforming output.
Checksheets, which are also known as tally sheets and may be used as a checklist when gathering data. Checksheets are used to organize facts in a manner that will facilitate the effective collection of useful data about a potential quality problem. They are especially useful for gathering attributes data while performing inspections to identify defects. For example, data about the frequencies or consequences of defects collected in checksheets are often displayed using Pareto diagrams. Pareto diagrams, exist as a special form of vertical bar chart and are used to identify the vital few sources that are responsible for causing most of a problem's effects. The categories shown on the horizontal axis exist as a valid probability distribution that accounts for 100% of the possible observations. The relative frequencies of each specified cause listed on the horizontal axis decrease in magnitude until the default source named “other” accounts for any nonspecified causes. Typically, the Pareto diagram
246
will be organized into categories that measure either frequencies or consequences. Histograms, are a special form of bar chart and are used to describe the central tendency, dispersion, and shape of a statistical distribution. Unlike the control chart, the histogram does not consider the influence of time on the variation that exists within a distribution. Control charts, are used to determine whether or not a process is stable or has predictable performance. Upper and lower specification limits are based on requirements of the agreement. They reflect the maximum and minimum values allowed. There may be penalties associated with exceeding the specification limits. Upper and lower control limits are different from specification limits. The control limits are determined using standard statistical calculations and principles to ultimately establish the natural capability for a stable process. The project manager and appropriate stakeholders may use the statistically calculated control limits to identify the points at which corrective action will be taken to prevent unnatural performance. The corrective action typically seeks to maintain the natural stability of a stable and capable process. For repetitive processes, the control limits are generally set at ±3 s around a process mean that has been set at 0 s. A process is considered out of control when: (1) a data point exceeds a control limit; (2) seven consecutive plot points are above the mean; or (3) seven consecutive plot points are below the mean. Control charts can be used to monitor various types of output variables. Although used most frequently to track repetitive activities required for producing manufactured lots, control charts may also be used to monitor cost and schedule variances, volume, and frequency of scope changes, or other management results to help determine if the project management processes are in control. Scatter diagrams, plot ordered pairs (X, Y) and are sometimes called correlation charts because they seek to explain a change in the dependent variable, Y, in relationship to a change observed in the corresponding independent variable, X. The direction of correlation may be proportional (positive correlation), inverse (negative correlation), or a pattern of correlation may not exist (zero correlation). If correlation can be established, a regression line can be calculated and used to estimate how a change to the independent variable will influence the value of the dependent variable.
247
8.1.2.4 Benchmarking Benchmarking involves comparing actual or planned project practices to those of
comparable projects to identify best practices, generate ideas for improvement, and provide a basis for measuring performance.
Benchmarked projects may exist within the performing organization or outside of it, or can be within the same application area. Benchmarking allows for analogies from projects in a different application area to be made.
8.1.2.5 Design of Experiments Design of experiments (DOE) is a statistical method for identifying which factors
may influence specific variables of a product or process under development or in production. DOE may be used during the Plan Quality Management process to determine the number and type of tests and their impact on cost of quality.
DOE also plays a role in optimizing products or processes. DOE is used to reduce the sensitivity of product performance to sources of variations caused by environmental or manufacturing differences. One important aspect of this technique is that it provides a statistical framework for systematically changing all of the
248
important factors, rather than changing the factors one at a time. Analysis of the experimental data should provide the optimal conditions for the product or process, highlight the factors that influence the results, and reveal the presence of interactions and synergy among the factors. For example, automotive designers use this technique to determine which combination of suspension and tires will produce the most desirable ride characteristics at a reasonable cost.
8.1.2.6 Statistical Sampling Statistical sampling involves choosing part of a population of interest for
inspection (for example, selecting ten engineering drawings at random from a list of seventy-five). Sample frequency and sizes should be determined during the Plan Quality Management process so the cost of quality will include the number of tests, expected scrap, etc.
There is a substantial body of knowledge on statistical sampling. In some application areas, it may be necessary for the project management team to be familiar with a variety of sampling techniques to assure the sample selected represents the population of interest.
8.1.2.7 Additional Quality Planning Tools Other quality planning tools are used to define the quality requirements and to
plan effective quality management activities. These include, but are not limited to:
Brainstorming. This technique is used to generate ideas (defined in Section 11.2.2.2). Force field analysis. These are diagrams of the forces for and against change. Nominal group technique. This technique is used to allow ideas to be brainstormed in small groups and then reviewed by a larger group. Quality management and control tools. These tools are used to link and sequence the activities identified (defined in Section 8.2.2.1).
8.1.2.8 Meetings Project teams may hold planning meetings to develop the quality management
plan. Attendees at these meetings may include the project manager; the project sponsor; selected project team members; selected stakeholders; anyone with responsibility for Project Quality Management activities namely Plan Quality Management, Perform Quality Assurance, or Control Quality; and others as needed.
8.1.3 Plan Quality Management: Outputs 8.1.3.1 Quality Management Plan
The quality management plan is a component of the project management plan that
249
describes how the organization's quality policies will be implemented. It describes how the project management team plans to meet the quality requirements set for the project.
The quality management plan may be formal or informal, detailed, or broadly framed. The style and detail of the quality management plan are determined by the requirements of the project. The quality management plan should be reviewed early in the project to ensure that decisions are based on accurate information. The benefits of this review can include a sharper focus on the project's value proposition and reductions in costs and in the frequency of schedule overruns that were caused by rework.
8.1.3.2 Process Improvement Plan The process improvement plan is a subsidiary or component of the project
management plan (Section 4.2.3.1). The process improvement plan details the steps for analyzing project management and product development processes to identify activities that enhance their value. Areas to consider include:
Process boundaries. Describe the purpose of the process, the start and end of the process, its inputs and outputs, the process owner, and the stakeholders of the process. Process configuration. Provides a graphic depiction of processes, with interfaces identified, used to facilitate analysis. Process metrics. Along with control limits, allows analysis of process efficiency. Targets for improved performance. Guide the process improvement activities.
8.1.3.3 Quality Metrics A quality metric specifically describes a project or product attribute and how the
control quality process will measure it. A measurement is an actual value. The tolerance defines the allowable variations to the metric. For example, if the quality objective is to stay within the approved budget by ± 10%, the specific quality metric is used to measure the cost of every deliverable and determine the percent variance from the approved budget for that deliverable. Quality metrics are used in the perform quality assurance and control quality processes. Some examples of quality metrics include on-time performance, cost control, defect frequency, failure rate, availability, reliability, and test coverage.
8.1.3.4 Quality Checklists A checklist is a structured tool, usually component-specific, used to verify that a
set of required steps has been performed. Based on the project's requirements and
250
practices, checklists may be simple or complex. Many organizations have standardized checklists available to ensure consistency in frequently performed tasks. In some application areas, checklists are also available from professional associations or commercial service providers. Quality checklists should incorporate the acceptance criteria included in the scope baseline.
8.1.3.5 Project Documents Updates Project documents that may be updated include, but are not limited to:
Stakeholder register (Section 13.1.3.1); and Responsibility assignment matrix (Section 9.1.2.1); and WBS and WBS Dictionary.
8.2 Perform Quality Assurance Perform Quality Assurance is the process of auditing the quality requirements
and the results from quality control measurements to ensure that appropriate quality standards and operational definitions are used. The key benefit of this process is that it facilitates the improvement of quality processes. The inputs, tools and techniques, and outputs of this process are depicted in Figure 8-8. Figure 8-9 depicts the data flow diagram of the process.
251
The quality assurance process implements a set of planned and systematic acts and processes defined within the project's quality management plan. Quality assurance seeks to build confidence that a future output or an unfinished output, also known as work in progress, will be completed in a manner that meets the specified requirements and expectations. Quality assurance contributes to the state of being certain about quality by preventing defects through the planning processes or by inspecting out defects during the work-in-progress stage of implementation. Perform Quality Assurance is an execution process that uses data created during Plan Quality Management (Section 8.1) and Control Quality (Section 8.3) processes.
In project management, the prevention and inspection aspects of quality assurance should have a demonstrable influence on the project. Quality assurance work will fall under the conformance work category in the cost of quality framework.
A quality assurance department, or similar organization, often oversees quality assurance activities. Quality assurance support, regardless of the unit's title, may be provided to the project team, the management of the performing organization, the customer or sponsor, as well as other stakeholders not actively involved in the work of the project.
Perform Quality Assurance also provides an umbrella for continuous process
252
improvement, which is an iterative means for improving the quality of all processes. Continuous process improvement reduces waste and eliminates activities that do not add value. This allows processes to operate at increased levels of efficiency and effectiveness.
8.2.1 Perform Quality Assurance: Inputs
8.2.1.1 Quality Management Plan Described in Section 8.1.3.1. The quality management plan describes the quality
assurance and continuous process improvement approaches for the project.
8.2.1.2 Process Improvement Plan Described in Section 8.1.3.2. The project's quality assurance activities should be
supportive of and consistent with the performing organization's process improvement plans.
8.2.1.3 Quality Metrics Described in Section 8.1.3.3. The quality metrics provide the attributes that
should be measured and the allowable variations.
8.2.1.4 Quality Control Measurements Described in Section 8.3.3.1. Quality control measurements are the results of
control quality activities. They are used to analyze and evaluate the quality of the processes of the project against the standards of the performing organization or the requirements specified. Quality control measurements can also compare the processes used to create the measurements, and validate actual measurements to determine their level of correctness.
8.2.1.5 Project Documents Project documents may influence quality assurance work and should be
monitored within the context of a system for configuration management.
8.2.2 Perform Quality Assurance: Tools and Techniques 8.2.2.1 Quality Management and Control Tools
The Perform Quality Assurance process uses the tools and techniques of the Plan Quality Management and Control Quality processes. In addition, other tools that are available include (see also Figure 8-10):
Affinity diagrams. The affinity diagram is similar to mind-mapping techniques in that they are used to generate ideas that can be linked to form organized patterns of thought about a problem. In project management, the creation of the WBS may be enhanced by using the affinity diagram to give
253
structure to the decomposition of scope. Process decision program charts (PDPC). Used to understand a goal in relation to the steps for getting to the goal. The PDPC is useful as a method for contingency planning because it aids teams in anticipating intermediate steps that could derail achievement of the goal. Interrelationship digraphs. An adaptation of relationship diagrams. The interrelationship digraphs provide a process for creative problem solving in moderately complex scenarios that possess intertwined logical relationships for up to 50 relevant items. The interrelationship digraph may be developed from data generated in other tools such as the affinity diagram, the tree diagram, or the fishbone diagram. Tree diagrams. Also known as systematic diagrams and may be used to represent decomposition hierarchies such as the WBS, RBS (risk breakdown structure), and OBS (organizational breakdown structure). In project management, tree diagrams are useful in visualizing the parent-to- child relationships in any decomposition hierarchy that uses a systematic set of rules that define a nesting relationship. Tree diagrams can be depicted horizontally (such as a risk breakdown structure) or vertically (such as a team hierarchy or OBS). Because tree diagrams permit the creation of nested branches that terminate into a single decision point, they are useful as decision trees for establishing an expected value for a limited number of dependent relationships that have been diagramed systematically. Prioritization matrices. Identify the key issues and the suitable alternatives to be prioritized as a set of decisions for implementation. Criteria are prioritized and weighted before being applied to all available alternatives to obtain a mathematical score that ranks the options. Activity network diagrams. Previously known as arrow diagrams. They include both the AOA (Activity on Arrow) and, most commonly used, AON (Activity on Node) formats of a network diagram. Activity network diagrams are used with project scheduling methodologies such as program evaluation and review technique (PERT), critical path method (CPM), and precedence diagramming method (PDM). Matrix diagrams. A quality management and control tool used to perform data analysis within the organizational structure created in the matrix. The matrix diagram seeks to show the strength of relationships between factors, causes, and objectives that exist between the rows and columns that form the matrix.
254
8.2.2.2 Quality Audits A quality audit is a structured, independent process to determine if project
activities comply with organizational and project policies, processes, and procedures. The objectives of a quality audit may include:
Identify all good and best practices being implemented; Identify all nonconformity, gaps, and shortcomings; Share good practices introduced or implemented in similar projects in the organization and/or industry; Proactively offer assistance in a positive manner to improve implementation of processes to help the team raise productivity; and Highlight contributions of each audit in the lessons learned repository of the organization.
The subsequent effort to correct any deficiencies should result in a reduced cost of quality and an increase in sponsor or customer acceptance of the project's product. Quality audits may be scheduled or random, and may be conducted by internal or external auditors.
255
Quality audits can confirm the implementation of approved change requests including updates, corrective actions, defect repairs, and preventive actions.
8.2.2.3 Process Analysis Process analysis follows the steps outlined in the process improvement plan to
identify needed improvements. This analysis also examines problems experienced, constraints experienced, and non-value-added activities identified during process operation. Process analysis includes root cause analysis—a specific technique used to identify a problem, discover the underlying causes that lead to it, and develop preventive actions.
8.2.3 Perform Quality Assurance: Outputs 8.2.3.1 Change Requests
Change requests are created and used as input into the Perform Integrated Change Control process (Section 4.5) to allow full consideration of the recommended improvements. Change requests are used to take corrective action, preventive action, or to perform defect repair.
8.2.3.2 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to:
Quality management plan (Section 8.1.3.1), Scope management plan (Section 5.1.3.1), Schedule management plan (Section 6.1.3.1), and Cost management plan (7.1.3.1).
8.2.3.3 Project Documents Updates Project documents that may be updated include, but are not limited to:
Quality audit reports, Training plans, and Process documentation.
8.2.3.4 Organizational Process Assets Updates Elements of the organizational process assets that may be updated include, but
are not limited to, the organization's quality standards and the quality management system.
8.3 Control Quality Control Quality is the process of monitoring and recording results of executing
256
the quality activities to assess performance and recommend necessary changes. The key benefits of this process include: (1) identifying the causes of poor process or product quality and recommending and/or taking action to eliminate them; and (2) validating that project deliverables and work meet the requirements specified by key stakeholders necessary for final acceptance. The inputs, tools and techniques, and outputs of this process are depicted in Figure 8-11. Figure 8-12 depicts the data flow diagram of the process.
257
The Control Quality process uses a set of operational techniques and tasks to verify that the delivered output will meet the requirements. Quality assurance should be used during the project's planning and executing phases to provide confidence that the stakeholder's requirements will be met and quality control should be used during the project executing and closing phases to formally demonstrate, with reliable data, that the sponsor and/or customer's acceptance criteria have been met.
The project management team may have a working knowledge of statistical control processes to evaluate data contained in the control quality outputs. Among other subjects, the team may find it useful to know the differences between the following pairs of terms:
Prevention (keeping errors out of the process) and inspection (keeping errors out of the hands of the customer). Attribute sampling (the result either conforms or does not conform) and variables sampling (the result is rated on a continuous scale that measures the degree of conformity).
258
Tolerances (specified range of acceptable results) and control limits (that identify the boundaries of common variation in a statistically stable process or process performance).
8.3.1 Control Quality: Inputs
8.3.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan contains the quality
management plan, which is used to control quality. The quality management plan describes how quality control will be performed within the project.
8.3.1.2 Quality Metrics Described in Section 8.1.3.3. A quality metric describes a project or product
attribute and how it will be measured. Some examples of quality metrics include: function points, mean time between failure (MTBF), and mean time to repair (MTTR).
8.3.1.3 Quality Checklists Described in Section 8.1.3.4. Quality checklists are structured lists that help to
verify that the work of the project and its deliverables fulfill a set of requirements.
8.3.1.4 Work Performance Data Described in Section 4.3.3.2. Work performance data can include:
Planned vs. actual technical performance, Planned vs. actual schedule performance, and Planned vs. actual cost performance.
8.3.1.5 Approved Change Requests As part of the Perform Integrated Change Control process, a change log update
indicates that some changes are approved and some are not. Approved change requests may include modifications such as defect repairs, revised work methods, and revised schedule. The timely implementation of approved changes needs to be verified.
8.3.1.6 Deliverables Described in Section 4.3.3.1. A deliverable is any unique and verifiable product,
result, or capability that results in a validated deliverable required by the project.
8.3.1.7 Project Documents Project documents may include, but are not limited to:
Agreements,
259
Quality audit reports and change logs supported with corrective action plans, Training plans and assessments of effectiveness, and Process documentation such as those obtained using either the seven basic quality tools or the quality management and control tools shown in Figures 8-7 and 8-10.
8.3.1.8 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Control Quality process include, but are not limited to:
The organization's quality standards and policies, Standard work guidelines, and Issue and defect reporting procedures and communication policies.
8.3.2 Control Quality: Tools and Techniques 8.3.2.1 Seven Basic Quality Tools
Described in Section 8.1.2.3. The seven basic quality tools are illustrated conceptually in Figure 8-7.
8.3.2.2 Statistical Sampling Described in Section 8.1.2.6. Samples are selected and tested as defined in the
quality management plan.
8.3.2.3 Inspection An inspection is the examination of a work product to determine if it conforms to
documented standards. The results of an inspection generally include measurements and may be conducted at any level. For example, the results of a single activity can be inspected, or the final product of the project can be inspected. Inspections may be called reviews, peer reviews, audits, or walkthroughs. In some application areas, these terms have narrow and specific meanings. Inspections also are used to validate defect repairs.
8.3.2.4 Approved Change Requests Review All approved change requests should be reviewed to verify that they were
implemented as approved.
8.3.3 Control Quality: Outputs 8.3.3.1 Quality Control Measurements
Quality control measurements are the documented results of control quality
260
activities. They should be captured in the format that was specified through the Plan Quality Management process (Section 8.1).
8.3.3.2 Validated Changes Any changed or repaired items are inspected and will be either accepted or
rejected before notification of the decision is provided. Rejected items may require rework.
8.3.3.3 Verified Deliverables A goal of the Control Quality process is to determine the correctness of
deliverables. The results of performing the Control Quality process are verified deliverables. Verified deliverables are an input to Validate Scope (5.5.1.4) for formalized acceptance.
8.3.3.4 Work Performance Information Work performance information is the performance data collected from various
controlling processes, analyzed in context and integrated based on relationships across areas. Examples include information about the project requirements fulfillment such as causes for rejections, rework required, or the need for process adjustments.
8.3.3.5 Change Requests If the recommended corrective or preventive actions or a defect repair requires a
change to the project management plan, a change request (Section 4.4.3.1) should be initiated in accordance with the defined Perform Integrated Change Control (4.5) process.
8.3.3.6 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to:
Quality management plan (Section 8.1.3.1), and Process improvement plan (Section 8.1.3.2).
8.3.3.7 Project Documents Updates Project documents that may be updated include, but are not limited to,
Quality standards; Agreements; Quality audit reports and change logs supported with corrective action plans; Training plans and assessments of effectiveness; and
261
Process documentation, such as information obtained using the seven basic quality tools or the quality management and control tools.
8.3.3.8 Organizational Process Assets Updates Elements of the organizational process assets that may be updated include, but
are not limited to:
Completed checklists. When checklists are used, the completed checklists become part of the project documents and organizational process assets (Section 4.1.1.5). Lessons learned documentation. The causes of variances, the reasoning behind the corrective action chosen, and other types of lessons learned from control quality are documented so they become part of the historical database for both the project and the performing organization.
262
9
PROJECT HUMAN RESOURCE MANAGEMENT Project Human Resource Management includes the processes that organize,
manage, and lead the project team. The project team is comprised of the people with assigned roles and responsibilities for completing the project. Project team members may have varied skill sets, may be assigned full or part-time, and may be added or removed from the team as the project progresses. Project team members may also be referred to as the project's staff. Although specific roles and responsibilities for the project team members are assigned, the involvement of all team members in project planning and decision making is beneficial. Participation of team members during planning adds their expertise to the process and strengthens their commitment to the project.
Figure 9-1 provides an overview of the Project Human Resource Management processes, which are as follows:
9.1 Plan Human Resource Management—The process of identifying and documenting project roles, responsibilities, required skills, reporting relationships, and creating a staffing management plan.
9.2 Acquire Project Team—The process of confirming human resource availability and obtaining the team necessary to complete project activities.
9.3 Develop Project Team—The process of improving competencies, team member interaction, and overall team environment to enhance project performance.
9.4 Manage Project Team—The process of tracking team member performance, providing feedback, resolving issues, and managing changes to optimize project performance.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
As a result of these interactions additional planning may be required throughout the project. For example:
After initial team members create a work breakdown structure, additional team members may need to be added to the team. As additional team members are added to the team, their experience levels, or lack thereof, could decrease or increase project risk, creating the need for additional risk planning.
263
When activity durations are estimated, budgeted, scoped, or planned prior to identifying all project team members and their competency levels, the activity durations may change.
The project management team is a subset of the project team and is responsible for the project management and leadership activities such as initiating, planning, executing, monitoring, controlling, and closing the various project phases. This group can also be referred to as the core, executive, or leadership team. For smaller projects, the project management responsibilities may be shared by the entire team or administered solely by the project manager. The project sponsor works with the project management team, typically assisting with matters such as project funding, clarifying scope, monitoring progress, and influencing stakeholders in both the requesting and performing organization for the project benefit.
Managing and leading the project team includes, but is not limited to:
Influencing the project team. The project manager needs to be aware of and influence, when possible, human resource factors that may impact the project. These factors include team environment, geographical locations of team members, communications among stakeholders, internal and external politics, cultural issues, organizational uniqueness, and others factors that may alter project performance. Professional and ethical behavior. The project management team should be aware of, subscribe to, and ensure that all team members follow professional and ethical behavior.
264
9.1 Plan Human Resource Management Plan Human Resource Management is the process of identifying and documenting
project roles, responsibilities, required skills, reporting relationships, and creating
265
a staffing management plan. The key benefit of this process is that it establishes project roles and responsibilities, project organization charts, and the staffing management plan including the timetable for staff acquisition and release. The inputs, tools and techniques, and outputs of this process are depicted in Figure 9-2. Figure 9-3 depicts the data flow diagram of the process.
Human resource planning is used to determine and identify human resources with the necessary skills required for project success. The human resource management plan describes how the roles and responsibilities, reporting relationships, and staffing management will be addressed and structured within a project. It also contains the staffing management plan including timetables for staff acquisition and
266
release, identification of training needs, team-building strategies, plans for recognition and rewards programs, compliance considerations, safety issues, and the impact of the staffing management plan on the organization.
Effective human resource planning should consider and plan for the availability of or competition for scarce resources. Project roles can be designated for teams or team members. Those teams or team members can be from inside or outside the organization performing the project. Other projects may be competing for human resources with the same competencies or skill sets. Given these factors, project costs, schedules, risks, quality, and other project areas may be significantly affected.
9.1.1 Plan Human Resource Management: Inputs
9.1.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan is used to develop
the human resource management plan as described in Section 9.1.3.1. The information used for the development of the human resource management plan includes, but is not limited to:
The project life cycle and the processes that will be applied to each phase, How work will be executed to accomplish the project objectives, A change management plan that documents how changes will be monitored and controlled, A configuration management plan that documents how configuration management will be performed, How integrity of the project baselines will be maintained, and Needs and methods of communication among stakeholders.
9.1.1.2 Activity Resource Requirements Described in Section 6.4.3.1. Human resource planning uses activity resource
requirements to determine the human resource needs for the project. The preliminary requirements regarding the required project team members and their competencies are progressively elaborated as part of the Plan Human Resource Management process.
9.1.1.3 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
influence the Plan Human Resource Management process include, but are not limited to:
Organizational culture and structure, Existing human resources,
267
Geographical dispersion of team members, Personnel administration policies, and Marketplace conditions.
9.1.1.4 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Plan Human Resource Management process include, but are not limited to:
Organizational standard processes, policies, and role descriptions; Templates for organizational charts and position descriptions; Lessons learned on organizational structures that have worked in previous projects; and Escalation procedures for handling issues within the team and within the performing organization.
9.1.2 Plan Human Resource Management: Tools and Techniques 9.1.2.1 Organization Charts and Position Descriptions
Various formats exist to document team member roles and responsibilities. Most of the formats fall into one of three types (Figure 9-4): hierarchical, matrix, and text-oriented. Additionally, some project assignments are listed in subsidiary plans, such as the risk, quality, or communications management plans. Regardless of the method utilized, the objective is to ensure that each work package has an unambiguous owner and that all team members have a clear understanding of their roles and responsibilities. For example, a hierarchical format may be used to represent high-level roles, while a text-based format may be better suited to document the detailed responsibilities.
Hierarchical-type charts. The traditional organization chart structure can be used to show positions and relationships in a graphical, top-down format. Work breakdown structures (WBS) designed to show how project
268
deliverables are broken down into work packages provide a way of showing high-level areas of responsibility. While the WBS shows a breakdown of project deliverables, the organizational breakdown structure (OBS) is arranged according to an organization's existing departments, units, or teams with the project activities or work packages listed under each department. An operational department such as information technology or purchasing can see all of its project responsibilities by looking at its portion of the OBS. The resource breakdown structure (RBS) is a hierarchical list of resources related by category and resource type that is used to facilitate planning and controlling of project work. Each descending (lower) level represents an increasingly detailed description of the resource until small enough to be used in conjunction with the work breakdown structure (WBS) to allow the work to be planned, monitored and controlled. The resource breakdown structure is helpful in tracking project costs and can be aligned with the organization's accounting system. It can contain resource categories other than human resources. Matrix-based charts. A responsibility assignment matrix (RAM) is a grid that shows the project resources assigned to each work package. It is used to illustrate the connections between work packages or activities and project team members. On larger projects, RAMs can be developed at various levels. For example, a high-level RAM can define what a project team group or unit is responsible for within each component of the WBS, while lower-level RAMs are used within the group to designate roles, responsibilities, and levels of authority for specific activities. The matrix format shows all activities associated with one person and all people associated with one activity. This also ensures that there is only one person accountable for any one task to avoid confusion of who is ultimately in charge or has authority for the work. One example of a RAM is a RACI (responsible, accountable, consult, and inform) chart, shown in Figure 9-5. The sample chart shows the work to be done in the left column as activities. The assigned resources can be shown as individuals or groups. The project manager can select other options such as “lead” and “resource” designations or others, as appropriate for the project. A RACI chart is a useful tool to use when the team consists of internal and external resources in order to ensure clear divisions of roles and expectations.
269
Text-oriented formats. Team member responsibilities that require detailed descriptions can be specified in text-oriented formats. Usually in outline form, the documents provide information such as responsibilities, authority, competencies, and qualifications. The documents are known by various names including position descriptions and role-responsibility-authority forms. These documents can be used as templates for future projects, especially when the information is updated throughout the current project by applying lessons learned.
9.1.2.2 Networking Networking is the formal and informal interaction with others in an organization,
industry, or professional environment. It is a constructive way to understand political and interpersonal factors that will impact the effectiveness of various staffing management options. Human resource management benefits from successful networking by improving knowledge of and access to human resource assets such as strong competencies, specialized experience, and external partnership opportunities. Examples of human resources networking activities include proactive correspondence, luncheon meetings, informal conversations including meetings and events, trade conferences, and symposia. Networking can be a useful technique at the beginning of a project. It can also be an effective way to enhance project management professional development during the project and after the project ends.
9.1.2.3 Organizational Theory Organizational theory provides information regarding the way in which people,
teams, and organizational units behave. Effective use of common themes identified in organizational theory can shorten the amount of time, cost, and effort needed to create the Plan Human Resource Management process outputs and improve
270
planning efficiency. It is important to recognize that different organizational structures have different individual response, individual performance, and personal relationship characteristics. Also, applicable organizational theories may recommend exercising a flexible leadership style that adapts to the changes in a team's maturity level throughout the project life cycle.
9.1.2.4 Expert Judgment When developing the human resource management plan, expert judgment is used
to:
List the preliminary requirements for the required skills; Assess the roles required for the project based on standardized role descriptions within the organization; Determine the preliminary effort level and number of resources needed to meet project objectives; Determine reporting relationships needed based on the organizational culture; Provide guidelines on lead time required for staffing, based on lessons learned and market conditions; Identify risks associated with staff acquisition, retention, and release plans; and Identify and recommend programs for complying with applicable government and union contracts.
9.1.2.5 Meetings When planning human resource management of the project, the project
management team will hold planning meetings. These meetings leverage a combination of other tools and techniques to allow for all project management team members to reach consensus on the human resource management plan.
9.1.3 Plan Human Resource Management: Outputs
9.1.3.1 Human Resource Management Plan The human resource management plan, a part of the project management plan,
provides guidance on how project human resources should be defined, staffed, managed, and eventually released. The human resource management plan and any subsequent revisions are also inputs into the Develop Project Management Plan process.
The human resource management plan includes, but is not limited to, the following:
Roles and responsibilities. The following should be addressed when listing
271
the roles and responsibilities needed to complete a project: Role. The function assumed by or assigned to a person in the project. Examples of project roles are civil engineer, business analyst, and testing coordinator. Role clarity concerning authority, responsibilities, and boundaries should also be documented. Authority. The right to apply project resources, make decisions, sign approvals, accept deliverables, and influence others to carry out the work of the project. Examples of decisions that need clear authority include the selection of a method for completing an activity, quality acceptance, and how to respond to project variances. Team members operate best when their individual levels of authority match their individual responsibilities. Responsibility. The assigned duties and work that a project team member is expected to perform in order to complete the project's activities. Competency. The skill and capacity required to complete assigned activities within the project constraints. If project team members do not possess required competencies, performance can be jeopardized. When such mismatches are identified, proactive responses such as training, hiring, schedule changes, or scope changes are initiated.
Project organization charts. A project organization chart is a graphic display of project team members and their reporting relationships. It can be formal or informal, highly detailed or broadly framed, based on the needs of the project. For example, the project organization chart for a 3,000-person disaster response team will have greater detail than a project organization chart for an internal, twenty-person project. Staffing management plan. The staffing management plan is a component of the human resource management plan that describes when and how project team members will be acquired and how long they will be needed. It describes how human resource requirements will be met. The staffing management plan can be formal or informal, highly detailed, or broadly framed, depending upon the needs of the project. The plan is updated continually during the project to direct ongoing team member acquisition and development actions. Information in the staffing management plan varies by application area and project size, but items to consider include:
Staff acquisition. A number of questions arise when planning the acquisition of project team members. For example, whether the human resources come from within the organization or from external, contracted sources; whether the team members need to work in a central location or may work from distant locations; costs associated
272
with each level of expertise needed for the project; and level of assistance that the organization's human resource department and functional managers are able to provide to the project management team. Resource calendars. Calendars that identify the working days and shifts on which each specific resource is available. The staffing management plan describes necessary time frames for project team members, either individually or collectively, as well as when acquisition activities such as recruiting should start. One tool for charting human resources is a resource histogram, used by the project management team as a means of providing a visual representation or resources allocation to all interested parties. This chart illustrates the number of hours a person, department, or entire project team that will be needed each week or month over the course of the project. The chart can include a horizontal line that represents the maximum number of hours available from a particular resource. Bars that extend beyond the maximum available hours identify the need for a resource optimization strategy (Section 6.6.2.4), such as adding more resources or modifying the schedule. An example of a resource histogram is illustrated in Figure 9-6.
Staff release plan. Determining the method and timing of releasing team members benefits both the project and team members. When
273
team members are released from a project, the costs associated with those resources are no longer charged to the project, thus reducing project costs. Morale is improved when smooth transitions to upcoming projects are already planned. A staff release plan also helps mitigate human resource risks that may occur during or at the end of a project. Training needs. If it is expected that the team members to be assigned will not have the required competencies, a training plan can be developed as part of the project. The plan can also include ways to help team members obtain certifications that would support their ability to benefit the project. Recognition and rewards. Clear criteria for rewards and a planned system for their use help promote and reinforce desired behaviors. To be effective, recognition and rewards should be based on activities and performance under a person's control. For example, a team member who is to be rewarded for meeting cost objectives should have an appropriate level of control over decisions that affect expenses. Creating a plan with established times for distribution of rewards ensures that recognition takes place and is not forgotten. Recognition and rewards are part of the Develop Project Team process (Section 9.3). Compliance. The staffing management plan can include strategies for complying with applicable government regulations, union contracts, and other established human resource policies. Safety. Policies and procedures that protect team members from safety hazards can be included in the staffing management plan as well as in the risk register.
9.2 Acquire Project Team Acquire Project Team is the process of confirming human resource availability
and obtaining the team necessary to complete project activities. The key benefit of this process consists of outlining and guiding the team selection and responsibility assignment to obtain a successful team. The inputs, tools and techniques, and outputs of this process are depicted in Figure 9-7. Figure 9-8 depicts the data flow diagram of the process.
274
The project management team may or may not have direct control over team member selection because of collective bargaining agreements, use of subcontractor personnel, matrix project environment, internal or external reporting relationships, or other various reasons. It is important that the following factors are considered during the process of acquiring the project team:
The project manager or project management team should effectively negotiate and influence others who are in a position to provide the required human resources for the project. Failure to acquire the necessary human resources for the project may affect project schedules, budgets, customer satisfaction, quality, and risks.
275
Insufficient human resources or capabilities decrease the probability of success and, in a worst case scenario, could result in project cancellation. If the human resources are not available due to constraints, such as economic factors or previous assignments to other projects, the project manager or project team may be required to assign alternative resources, perhaps with lower competencies, provided there is no violation of legal, regulatory, mandatory, or other specific criteria.
These factors should be considered and planned for in the planning stages of the project. The project manager or project management team will be required to reflect the impact of any unavailability of required human resources in the project schedule, project budget, project risks, project quality, training plans, and the other project management plans.
9.2.1 Acquire Project Team: Inputs
9.2.1.1 Human Resource Management Plan Described in Section 9.1.3.1. The human resource management plan provides
guidance on how project human resources should be identified, staffed, managed, and eventually released. It includes:
Roles and responsibilities defining the positions, skills, and competencies that the project demands; Project organization charts indicating the number of people needed for the project; and Staffing management plan delineating the time periods each project team member will be needed and other information important to engage the project team.
9.2.1.2 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that influence
the Acquire Project Team process include, but are not limited to:
Existing information on human resources including availability, competency levels, prior experience, interest in working on the project and their cost rate; Personnel administration policies such as those that affect outsourcing; Organizational structure as described in Section 2.3.1; and Colocation or multiple locations.
9.2.1.3 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that influence the
Acquire Project Team process include, but are not limited to, organizational
276
standard policies, processes, and procedures.
9.2.2 Acquire Project Team: Tools and Techniques
9.2.2.1 Pre-assignment When project team members are selected in advance, they are considered pre-
assigned. This situation can occur if the project is the result of specific people being identified as part of a competitive proposal, if the project is dependent upon the expertise of particular persons, or if some staff assignments are defined within the project charter.
9.2.2.2 Negotiation Staff assignments are negotiated on many projects. For example, the project
management team may need to negotiate with:
Functional managers, to ensure that the project receives appropriately competent staff in the required time frame and that the project team members will be able, willing, and authorized to work on the project until their responsibilities are completed; Other project management teams within the performing organization, to appropriately assign scarce or specialized human resources; and External organizations, vendors, suppliers, contractors, etc., for appropriate, scarce, specialized, qualified, certified, or other such specified human resources. Special consideration should be given to external negotiating policies, practices, processes, guidelines, legal, and other such criteria.
The project management team's ability to influence others plays an important role in negotiating staff assignments, as do the politics of the organizations involved. For example, a functional manager will weigh the benefits and visibility of competing projects when determining where to assign exceptional performers requested by various project teams.
9.2.2.3 Acquisition When the performing organization is unable to provide the staff needed to
complete a project, the required services may be acquired from outside sources. This can involve hiring individual consultants or subcontracting work to another organization.
9.2.2.4 Virtual Teams The use of virtual teams creates new possibilities when acquiring project team
members. Virtual teams can be defined as groups of people with a shared goal who fulfill their roles with little or no time spent meeting face to face. The availability
277
of communication technology such as e-mail, audio conferencing, social media, web-based meetings and video conferencing has made virtual teams feasible. The virtual team model makes it possible to:
Form teams of people from the same organization who live in widespread geographic areas; Add special expertise to a project team even though the expert is not in the same geographic area; Incorporate employees who work from home offices; Form teams of people who work different shifts, hours, or days; Include people with mobility limitations or disabilities; and Move forward with projects that would have been ignored due to travel expenses.
There are some disadvantages related to virtual teams, such as possibility for misunderstandings, feeling of isolation, difficulties in sharing knowledge and experience between team members, and cost of appropriate technology. Communication planning becomes increasingly important in a virtual team environment. Additional time may be needed to set clear expectations, facilitate communications, develop protocols for resolving conflict, include people in decision making, understand cultural differences, and share credit in successes.
9.2.2.5 Multi-Criteria Decision Analysis Selection criteria are often used as a part of acquiring the project team. By use of
a multi-criteria decision analysis tool, criteria are developed and used to rate or score potential team members. The criteria are weighted according to the relative importance of the needs within the team. Some examples of selection criteria that can be used to score team members are shown as follows:
Availability. Identify whether the team member is available to work on the project within the time period needed when there are any concerns for availability during the project timeline. Cost. Verify if the cost of adding the team member is within the prescribed budget. Experience. Verify that the team member has the relevant experience that will contribute to the project success. Ability. Verify that the team member has the competencies needed by the project. Knowledge. Consider if the team member has relevant knowledge of the customer, similar implemented projects, and nuances of the project environment. Skills. Determine whether the member has the relevant skills to use a
278
project tool, implementation, or training. Attitude. Determine whether the member has the ability to work with others as a cohesive team. International factors. Consider team member location, time zone and communication capabilities.
9.2.3 Acquire Project Team: Outputs
9.2.3.1 Project Staff Assignments The project is staffed when appropriate people have been assigned to the team.
The documentation of these assignments can include a project team directory, memos to team members, and names inserted into other parts of the project management plan, such as project organization charts and schedules.
9.2.3.2 Resource Calendars Resource calendars document the time periods that each project team member is
available to work on the project. Creating a reliable schedule (Section 6.6.3.1) depends on having a good understanding of each person's availability and schedule constraints, including time zones, work hours, vacation time, local holidays, and commitments to other projects.
9.2.3.3 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to, the human resource management plan. For example, the person assigned to a predefined role may not fulfill all staffing requirements outlined in the human resource management plan. When gaps occur, the project management plan needs to be updated to change the team structure, roles, or responsibilities.
9.3 Develop Project Team Develop Project Team is the process of improving competencies, team member
interaction, and overall team environment to enhance project performance. The key benefit of this process is that it results in improved teamwork, enhanced people skills and competencies, motivated employees, reduced staff turnover rates, and improved overall project performance. The inputs, tools and techniques, and outputs of this process are depicted in Figure 9-9. Figure 9-10 depicts the data flow diagram of the process.
279
Project managers should acquire skills to identify, build, maintain, motivate, lead, and inspire project teams to achieve high team performance and to meet the project's objectives. Teamwork is a critical factor for project success, and developing effective project teams is one of the primary responsibilities of the project manager. Project managers should create an environment that facilitates teamwork. Project managers should continually motivate their team by providing challenges and opportunities, by providing timely feedback and support as needed, and by recognizing and rewarding good performance. High team performance can be achieved by using open and effective communication, creating team building opportunities, developing trust among team members, managing conflicts in a
280
constructive manner, and encouraging collaborative problem solving and decision making. The project manager should request management support and/or influence the appropriate stakeholders to acquire the resources needed to develop effective project teams.
Project managers operate in a global environment and work on projects characterized by cultural diversity. Team members often have diverse industry experience, know multiple languages, and sometimes operate in the “team language” that may be a different language or norm than their native one. The project management team should capitalize on cultural differences, focus on developing and sustaining the project team throughout the project life cycle, and promote working together interdependently in a climate of mutual trust. Developing the project team improves the people skills, technical competencies, and overall team environment and project performance. It requires clear, timely, effective, and efficient communication between team members throughout the life of the project. Objectives of developing a project team include, but are not limited to:
Improving knowledge and skills of team members to increase their ability to complete project deliverables, while lowering costs, reducing schedules, and improving quality; Improving feelings of trust and agreement among team members to raise morale, lower conflict, and increase team work; and Creating a dynamic, cohesive, and collaborative team culture to (1) improve individual and team productivity, team spirit, and cooperation and (2) allow cross training and mentoring between team members to share knowledge and expertise.
9.3.1 Develop Project Team: Inputs
9.3.1.1 Human Resource Management Plan Described in Section 9.1.3.1. The human resource management plan provides
guidance on how project human resources should be defined, staffed, managed, controlled, and eventually released. It identifies training strategies and plans for developing the project team. Items such as rewards, feedback, additional training, and disciplinary actions can be added to the plan as a result of ongoing team performance assessments and other forms of project team management.
9.3.1.2 Project Staff Assignments Described in Section 9.2.3.1. Team development starts with a list of the project
team members. Project staff assignment documents identify the people who are on the team.
9.3.1.3 Resource Calendars
281
Described in Section 9.2.3.2. Resource calendars identify times when the project team members can participate in team development activities.
9.3.2 Develop Project Team: Tools and Techniques
9.3.2.1 Interpersonal Skills Interpersonal skills, sometimes known as “soft skills,” are behavioral
competencies that include proficiencies such as communication skills, emotional intelligence, conflict resolution, negotiation, influence, team building, and group facilitation. These soft skills are valuable assets when developing the project team. For example, the project management team can use emotional intelligence to reduce tension and increase cooperation by identifying, assessing, and controlling the sentiments of project team members, anticipating their actions, acknowledging their concerns, and following up on their issues.
9.3.2.2 Training Training includes all activities designed to enhance the competencies of the
project team members. Training can be formal or informal. Examples of training methods include classroom, online, computer-based, on-the-job training from another project team member, mentoring, and coaching. If project team members lack the necessary management or technical skills, such skills can be developed as part of the project work. Scheduled training takes place as stated in the human resource management plan. Unplanned training takes place as a result of observation, conversation, and project performance appraisals conducted during the controlling process of managing the project team. Training costs could be included in the project budget, or supported by the performing organization if the added skills may be useful for future projects. It could be performed by in-house or external trainers.
9.3.2.3 Team-Building Activities Team-building activities can vary from a 5-minute agenda item in a status review
meeting to an off-site, professionally facilitated experience designed to improve interpersonal relationships. The objective of team-building activities is to help individual team members work together effectively. Team-building strategies are particularly valuable when team members operate from remote locations without the benefit of face-to-face contact. Informal communication and activities can help in building trust and establishing good working relationships.
As an ongoing process, team building is crucial to project success. While team building is essential during the initial stages of a project, it is a never-ending process. Changes in a project environment are inevitable, and to manage them effectively, a continued or a renewed team-building effort should be applied. The project manager should continually monitor team functionality and performance to
282
determine if any actions are needed to prevent or correct various team problems. One of the models used to describe team development is the Tuckman ladder
(Tuckman, 1965; Tuckman & Jensen, 1977), which includes five stages of development that teams may go through. Although it's common for these stages to occur in order, it's not uncommon for a team to get stuck in a particular stage or slip to an earlier stage. Projects with team members who worked together in the past may skip a stage.
Forming. This phase is where the team meets and learns about the project and their formal roles and responsibilities. Team members tend to be independent and not as open in this phase. Storming. During this phase, the team begins to address the project work, technical decisions, and the project management approach. If team members are not collaborative and open to differing ideas and perspectives, the environment can become counterproductive. Norming. In the norming phase, team members begin to work together and adjust their work habits and behaviors to support the team. The team learns to trust each other. Performing. Teams that reach the performing stage function as a well- organized unit. They are interdependent and work through issues smoothly and effectively. Adjourning. In the adjourning phase, the team completes the work and moves on from the project. This typically occurs when staff is released from the project as deliverables are completed or as part of carrying out the Close Project or Phase process (Section 4.6).
The duration of a particular stage depends upon team dynamics, team size, and team leadership. Project managers should have a good understanding of team dynamics in order to move their team members through all stages in an effective manner.
9.3.2.4 Ground Rules Ground rules establish clear expectations regarding acceptable behavior by
project team members. Early commitment to clear guidelines decreases misunderstandings and increases productivity. Discussing ground rules in areas such as code of conduct, communication, working together, or meeting etiquette allows team members to discover values that are important to one another. All project team members share responsibility for enforcing the rules once they are established.
9.3.2.5 Colocation Colocation, also referred to as “tight matrix,” involves placing many or all of the
283
most active project team members in the same physical location to enhance their ability to perform as a team. Colocation can be temporary, such as at strategically important times during the project, or for the entire project. Colocation strategies can include a team meeting room (sometimes called “war room”), places to post schedules, and other conveniences that enhance communication and a sense of community. While colocation is considered a good strategy, the use of virtual teams can bring benefits such as the use of more skilled resources, reduced costs, less travel, and relocation expenses and the proximity of team members to suppliers, customers, or other key stakeholders.
9.3.2.6 Recognition and Rewards Part of the team development process involves recognizing and rewarding
desirable behavior. The original plans concerning ways in which to reward people are developed during the Plan Human Resource Management process. It is important to recognize that a particular reward given to any individual will be effective only if it satisfies a need which is valued by that individual. Award decisions are made, formally or informally, during the process of managing the project team through project performance appraisals (Section 9.4.2.2). Cultural differences should be considered when determining recognition and rewards.
People are motivated if they feel they are valued in the organization and this value is demonstrated by the rewards given to them. Generally, money is viewed as a tangible aspect of any reward system, but intangible rewards could be equally or even more effective. Most project team members are motivated by an opportunity to grow, accomplish, and apply their professional skills to meet new challenges. A good strategy for project managers is to give the team recognition throughout the life cycle of the project rather than waiting until the project is completed.
9.3.2.7 Personnel Assessment Tools Personnel assessment tools give the project manager and the project team insight
into areas of strength and weakness. These tools help project managers assess the team preferences, aspirations, how they process and organize information, how they tend to make decisions, and how they prefer to interact with people.
Various tools are available such as attitudinal surveys, specific assessments, structured interviews, ability tests, and focus groups. These tools can provide improved understanding, trust, commitment, and communications among team members and facilitate more productive teams throughout the project.
9.3.3 Develop Project Team: Outputs
9.3.3.1 Team Performance Assessments As project team development efforts such as training, team building, and
colocation are implemented, the project management team makes formal or
284
informal assessments of the project team's effectiveness. Effective team development strategies and activities are expected to increase the team's performance, which increases the likelihood of meeting project objectives. Team performance assessment criteria should be determined by all appropriate parties and incorporated in the Develop Project Team inputs.
The performance of a successful team is measured in terms of technical success according to agreed-upon project objectives (including quality levels), performance on project schedule (finished on time), and performance on budget (finished within financial constraints). High-performance teams are characterized by these task-oriented and results-oriented outcomes.
The evaluation of a team's effectiveness may include indicators such as:
Improvements in skills that allow individuals to perform assignments more effectively, Improvements in competencies that help the team perform better as a team, Reduced staff turnover rate, and Increased team cohesiveness where team members share information and experiences openly and help each other to improve the overall project performance.
As a result of conducting an evaluation of the team's overall performance, the project management team can identify the specific training, coaching, mentoring, assistance, or changes required to improve the team's performance. This should also include identification of the appropriate or required resources necessary to achieve and implement the improvements identified in the assessment. These resources and recommendations for team improvement should be well documented and forwarded to the relevant parties.
9.3.3.2 Enterprise Environmental Factors Updates The enterprise environmental factors that may be updated as a result of the
Develop Project Team process include, but are not limited to, personnel administration, employee training records, and skill assessments.
9.4 Manage Project Team Manage Project Team is the process of tracking team member performance,
providing feedback, resolving issues, and managing team changes to optimize project performance. The key benefit of this process is that it influences team behavior, manages conflict, resolves issues, and appraises team member performance. The inputs, tools and techniques, and outputs of this process are depicted in Figure 9-11. Figure 9-12 depicts the data flow diagram of the process.
285
As a result of managing the project team, change requests are submitted, the human resource management plan is updated, issues are resolved, input is provided for performance appraisals, and lessons learned are added to the organization's database.
Managing the project team requires a variety of management skills for fostering
286
teamwork and integrating the efforts of team members to create high-performance teams. Team management involves a combination of skills with special emphasis on communication, conflict management, negotiation, and leadership. Project managers should provide challenging assignments to team members and provide recognition for high performance.
9.4.1 Manage Project Team: Inputs
9.4.1.1 Human Resource Management Plan Described in Section 9.1.3.1. The human resource management plan provides
guidance on how project human resources should be defined, staffed, managed, controlled, and eventually released. It includes, but is not limited to:
Roles and responsibilities, Project organization, and Staffing management plan.
9.4.1.2 Project Staff Assignments Described in Section 9.2.3.1. Project staff assignments provide documentation,
which includes the list of project team members.
9.4.1.3 Team Performance Assessments Described in Section 9.3.3.1. The project management team makes ongoing
formal or informal assessments of the project team's performance. By continually assessing the project team's performance, actions can be taken to resolve issues, modify communication, address conflict, and improve team interaction.
9.4.1.4 Issue Log Issues arise in the course of managing the project team. An issue log can be used
to document and monitor who is responsible for resolving specific issues by a target date.
9.4.1.5 Work Performance Reports Described in Section 4.4.3.2. Work performance reports provide documentation
about the current project status compared to project forecasts. Performance areas that can help with project team management include results from schedule control, cost control, quality control, and scope validation. The information from performance reports and related forecasts assists in determining future human resource requirements, recognition and rewards, and updates to the staffing management plan.
9.4.1.6 Organizational Process Assets
287
Described in Section 2.1.4. The organizational process assets that can influence the Manage Project Team process include, but are not limited to:
Certificates of appreciation, Newsletters, Websites, Bonus structures, Corporate apparel, and Other organizational perquisites.
9.4.2 Manage Project Team: Tools and Techniques
9.4.2.1 Observation and Conversation Observation and conversation are used to stay in touch with the work and
attitudes of project team members. The project management team monitors progress toward project deliverables, accomplishments that are a source of pride for team members, and interpersonal issues.
9.4.2.2 Project Performance Appraisals Objectives for conducting performance appraisals during the course of a project
can include clarification of roles and responsibilities, constructive feedback to team members, discovery of unknown or unresolved issues, development of individual training plans, and the establishment of specific goals for future time periods.
The need for formal or informal project performance appraisals depends on the length of the project, complexity of the project, organizational policy, labor contract requirements, and the amount and quality of regular communication.
9.4.2.3 Conflict Management Conflict is inevitable in a project environment. Sources of conflict include
scarce resources, scheduling priorities, and personal work styles. Team ground rules, group norms, and solid project management practices, like communication planning and role definition, reduce the amount of conflict.
Successful conflict management results in greater productivity and positive working relationships. When managed properly, differences of opinion can lead to increased creativity and better decision making. If the differences become a negative factor, project team members are initially responsible for their resolution. If conflict escalates, the project manager should help facilitate a satisfactory resolution. Conflict should be addressed early and usually in private, using a direct, collaborative approach. If disruptive conflict continues, formal procedures may be used, including disciplinary actions.
288
The success of project managers in managing their project teams often depends a great deal on their ability to resolve conflict. Different project managers may utilize different conflict resolution methods. Factors that influence conflict resolution methods include:
Relative importance and intensity of the conflict, Time pressure for resolving the conflict, Position taken by persons involved, and Motivation to resolve conflict on a long-term or a short-term basis.
There are five general techniques for resolving conflict. As each one has its place and use, these are not given in any particular order:
Withdraw/Avoid. Retreating from an actual or potential conflict situation; postponing the issue to be better prepared or to be resolved by others. Smooth/Accommodate. Emphasizing areas of agreement rather than areas of difference; conceding one's position to the needs of others to maintain harmony and relationships. Compromise/Reconcile. Searching for solutions that bring some degree of satisfaction to all parties in order to temporarily or partially resolve the conflict. Force/Direct. Pushing one's viewpoint at the expense of others; offering only win-lose solutions, usually enforced through a power position to resolve an emergency. Collaborate/Problem Solve. Incorporating multiple viewpoints and insights from differing perspectives; requires a cooperative attitude and open dialogue that typically leads to consensus and commitment.
9.4.2.4 Interpersonal Skills Project managers use a combination of technical, personal, and conceptual skills
to analyze situations and interact appropriately with team members. Using appropriate interpersonal skills allows project managers to capitalize on the strengths of all team members.
Examples of interpersonal skills that a project manager uses most often include:
Leadership. Successful projects require strong leadership skills. Leadership is important through all phases of the project life cycle. There are multiple leadership theories defining leadership styles that should be used as needed for each situation or team. It is especially important to communicate the vision and inspire the project team to achieve high performance. Influencing. Because project managers often have little or no direct
289
authority over team members in a matrix environment, their ability to influence stakeholders on a timely basis is critical to project success. Key influencing skills include:
Ability to be persuasive and clearly articulate points and positions; High levels of active and effective listening skills; Awareness of, and consideration for, the various perspectives in any situation; and Gathering relevant and critical information to address important issues and reach agreements while maintaining mutual trust.
Effective decision making. This involves the ability to negotiate and influence the organization and the project management team. Some guidelines for decision making include:
Focus on goals to be served, Follow a decision-making process, Study the environmental factors, Analyze available information, Develop personal qualities of the team members, Stimulate team creativity, and Manage risk.
9.4.3 Manage Project Team: Outputs
9.4.3.1 Change Requests Staffing changes, whether by choice or by uncontrollable events, can affect the
rest of the project management plan. When staffing issues disrupt the project team from adhering to the project management plan such as causing the schedule to be extended or the budget to be exceeded, a change request can be processed through the Perform Integrated Change Control process. Staffing changes may include moving people to different assignments, outsourcing some of the work, and replacing team members who leave.
Preventive actions are those actions that are developed to reduce the probability and/or impact of problems before they occur. These actions may include cross training to reduce problems during project team member absences and additional role clarification to ensure all responsibilities are fulfilled.
9.4.3.2 Project Management Plan Updates Elements of the project management plan that may be updated include, but are not
limited to, the human resource management plan.
290
9.4.3.3 Project Documents Updates Project documents that may indirectly be updated include, but are not limited to:
Issue log, Role descriptions, and Project staff assignments.
9.4.3.4 Enterprise Environmental Factors Updates Enterprise environmental factors that may require updates as a result of the
Manage Project Team process include, but are not limited to:
Input to organizational performance appraisals, and Personnel skill updates.
9.4.3.5 Organizational Process Assets Updates Organizational process assets that may require updates as a result of the Manage
Project Team process include, but are not limited to:
Historical information and lessons learned documentation, Templates, and Organizational standard processes.
291
10
PROJECT COMMUNICATIONS MANAGEMENT Project Communications Management includes the processes that are required to
ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and the ultimate disposition of project information. Project managers spend most of their time communicating with team members and other project stakeholders, whether they are internal (at all organizational levels) or external to the organization. Effective communication creates a bridge between diverse stakeholders who may have different cultural and organizational backgrounds, different levels of expertise, and different perspectives and interests, which impact or have an influence upon the project execution or outcome.
Figure 10-1 provides an overview of the Project Communications Management processes, which are as follows:
10.1 Plan Communications Management—The process of developing an appropriate approach and plan for project communications based on stakeholder's information needs and requirements, and available organizational assets.
10.2 Manage Communications—The process of creating, collecting, distributing, storing, retrieving and the ultimate disposition of project information in accordance with the communications management plan.
10.3 Control Communications—The process of monitoring and controlling communications throughout the entire project life cycle to ensure the information needs of the project stakeholders are met.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
The communication activities involved in these processes may often have many potential dimensions that need to be considered, including, but not limited to:
Internal (within the project) and external (customer, vendors, other projects, organizations, the public); Formal (reports, minutes, briefings) and informal (emails, memos, ad-hoc discussions); Vertical (up and down the organization) and horizontal (with peers); Official (newsletters, annual report) and unofficial (off the record communications); and
292
Written and oral, and verbal (voice inflections) and nonverbal (body language).
Most communication skills are common for both general management and project management, such as, but not limited to:
Listening actively and effectively; Questioning and probing ideas and situations to ensure better understanding; Educating to increase team's knowledge so that they can be more effective; Fact-finding to identify or confirm information; Setting and managing expectations; Persuading a person, a team, or an organization to perform an action; Motivating to provide encouragement or reassurance; Coaching to improve performance and achieve desired results; Negotiating to achieve mutually acceptable agreements between parties; Resolving conflict to prevent disruptive impacts; and Summarizing, recapping, and identifying the next steps.
10.1 Plan Communications Management
293
Plan Communications Management is the process of developing an appropriate approach and plan for project communications based on stakeholder's information needs and requirements, and available organizational assets. The key benefit of this process is that it identifies and documents the approach to communicate most effectively and efficiently with stakeholders. The inputs, tools and techniques, and outputs of this process are depicted in Figure 10-2. Figure 10-3 depicts the data flow diagram of the Plan Communications Management process.
Planning the project communications is important to the ultimate success of any project. Inadequate communications planning may lead to problems such as delay in message delivery, communication of information to the wrong audience, or insufficient communication to the stakeholders and misunderstanding or misinterpretation of the message communicated.
On most projects, communication planning is performed very early, such as
294
during project management plan development. This allows appropriate resources, such as time and budget, to be allocated to communication activities. Effective communication means that the information is provided in the right format, at the right time, to the right audience, and with the right impact. Efficient communication means providing only the information that is needed.
While all projects share the need to communicate project information, the information needs and methods of distribution may vary widely. In addition, the methods of storage, retrieval, and ultimate disposition of the project information need to be considered and appropriately documented during this process. Important considerations that may need to be taken into account include, but are not limited to:
Who needs what information, and who is authorized to access that information; When they will need the information; Where the information should be stored; What format the information should be stored in; How the information can be retrieved; and Whether time zone, language barriers, and cross-cultural considerations need to be taken into account.
The results of the Plan Communications Management process should be reviewed regularly throughout the project and revised as needed to ensure continued applicability.
10.1.1 Plan Communications Management: Inputs
10.1.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan provides information
on how the project will be executed, monitored, controlled, and closed.
10.1.1.2 Stakeholder Register Described in Section 13.1.3.1. The stakeholder register provides the information
needed to plan the communication with project stakeholders.
10.1.1.3 Enterprise Environmental Factors Described in Section 2.1.5. The Plan Communications Management process is
tightly linked with enterprise environmental factors, since the structure of an organization will have a major effect on the project's communication requirements. All enterprise environmental factors described in Section 2.1.5 are used as inputs for this process, since communications need to be adapted to the project environment.
295
10.1.1.4 Organizational Process Assets Described in Section 2.1.4. All organizational process assets described in
Section 2.1.4 are used as inputs to the Plan Communications Management process. Of these, lessons learned and historical information are of particular importance because they can provide insights on both the decisions taken regarding communications issues and the results of those decisions in previous similar projects. These can be used as guiding information to plan the communication activities for the current project.
10.1.2 Plan Communications Management: Tools and Techniques 10.1.2.1 Communication Requirements Analysis
The analysis of the communication requirements determines the information needs of the project stakeholders. These requirements are defined by combining the type and format of information needed with an analysis of the value of that information. Project resources should be expended only on communicating information that contributes to the success of the project or where a lack of communication can lead to failure.
The project manager should also consider the number of potential communication channels or paths as an indicator of the complexity of a project's communications. The total number of potential communication channels is n(n – 1)/2, where n represents the number of stakeholders. For example, a project with 10 stakeholders has 10(10 – 1)/2 = 45 potential communication channels. As a result, a key component of planning the project's actual communications is to determine and limit who will communicate with whom and who will receive what information.
Sources of information typically used to identify and define project communication requirements include, but are not limited to:
Organizational charts; Project organization and stakeholder responsibility relationships; Disciplines, departments, and specialties involved in the project; Logistics of how many persons will be involved with the project and at which locations; Internal information needs (e.g., when communicating within organizations); External information needs (e.g., when communicating with the media, public, or contractors); and Stakeholder information and communication requirements from within the stakeholder register.
10.1.2.2 Communication Technology
296
The methods used to transfer information among project stakeholders may vary significantly. For example, a project team may use techniques from brief conversations to extended meetings, or from simple written documents to extensive materials (e.g., schedules, databases, and websites), which are accessible online as methods of communication.
Factors that can affect the choice of communication technology include:
Urgency of the need for information. There is a need to consider the urgency, frequency, and format of the information to be communicated as they may vary from project to project and also within different stages of a project. Availability of technology. There is a need to ensure that the technology that is required to facilitate communication is compatible, available, and accessible for all stakeholders throughout the life of the project. Ease of Use. There is a need to ensure that the choice of communication technologies is suitable for project participants and that appropriate training events are planned for, where appropriate. Project environment. There is a need to determine if the team will meet and operate on a face-to-face basis or in a virtual environment; whether they will be located in one or multiple time zones; whether they will use multiple languages for communication; and finally, whether there are any other project environmental factors, such as culture, which may affect communications. Sensitivity and confidentiality of the information. There is a need to determine if the information to be communicated is sensitive or confidential and whether or not additional security measures need to be taken. Also, the most appropriate way to communicate the information should be considered.
10.1.2.3 Communication Models The communication models used to facilitate communications and the exchange
of information may vary from project to project and also within different stages of the same project. A basic communication model, shown in Figure 10-4, consists of two parties, defined as the sender and receiver. Medium is the technology medium and includes the mode of communication while noise includes any interference or barriers that might compromise the delivery of the message. The sequence of steps in a basic communication model is:
Encode. Thoughts or ideas are translated (encoded) into language by the sender. Transmit Message. This information is then sent by the sender using communication channel (medium). The transmission of this message may be
297
compromised by various factors (e.g., distance, unfamiliar technology, inadequate infrastructure, cultural difference, and lack of background information). These factors are collectively termed as noise. Decode. The message is translated by the receiver back into meaningful thoughts or ideas. Acknowledge. Upon receipt of a message, the receiver may signal (acknowledge) receipt of the message but this does not necessarily mean agreement with or comprehension of the message. Feedback/Response. When the received message has been decoded and understood, the receiver encodes thoughts and ideas into a message and then transmits this message to the original sender.
The components of the basic communication model need to be considered when project communications are discussed. As part of the communications process, the sender is responsible for the transmission of the message, ensuring the information being communicated is clear and complete, and confirming the communication is correctly understood. The receiver is responsible for ensuring that the information is received in its entirety, understood correctly, and acknowledged or responded to appropriately.
There are many challenges in using these components to effectively communicate with project stakeholders, such as in a highly technical, multinational project team. Successful communication of a technical concept from one team member to another team member in a different country could involve encoding the message in the appropriate language, sending the message using a variety of technologies, and
298
having the receiver decode the message into his or her native language and then reply or provide feedback. Any noise introduced along the way may compromise the original meaning of the message. In this example, there are multiple factors that may lead to the intended meaning of the message being misunderstood or misinterpreted.
10.1.2.4 Communication Methods There are several communication methods that are used to share information
among project stakeholders. These methods are broadly classified as follows:
Interactive communication. Between two or more parties performing a multidirectional exchange of information. It is the most efficient way to ensure a common understanding by all participants on specified topics, and includes meetings, phone calls, instant messaging, video conferencing, etc. Push communication. Sent to specific recipients who need to receive the information. This ensures that the information is distributed but does not ensure that it actually reached or was understood by the intended audience. Push communications include letters, memos, reports, emails, faxes, voice mails, blogs, press releases, etc. Pull communication. Used for very large volumes of information, or for very large audiences, and requires the recipients to access the communication content at their own discretion. These methods include intranet sites, e-learning, lessons learned databases, knowledge repositories, etc.
The choices of communication methods that are used for a project may need to be discussed and agreed upon by the project stakeholders based on communication requirements; cost and time constraints; and familiarity and availability of the required tools and resources that may be applicable to the communications process.
10.1.2.5 Meetings Described in Section 4.3.2.3. The Plan Communications Management process
requires discussion and dialogue with the project team to determine the most appropriate way to update and communicate project information, and to respond to requests from various stakeholders for that information. These discussions and dialogue are commonly facilitated through meetings, which may be conducted face to face or online and in different locations, such as the project site or the customer's site.
There are several types of project-related meetings where project communications may occur. Most project meetings consist of stakeholders coming together for the purpose of resolving problems or making decisions. Although casual discussions may be construed as a meeting, most project meetings are more
299
formal with a prearranged time, place, and agenda. Typical meetings begin with a defined list of issues to be discussed, which are circulated in advance with minutes and other information documented specifically for the meeting. This information is then disseminated to other appropriate stakeholders on an as-needed basis.
10.1.3 Plan Communications Management: Outputs
10.1.3.1 Communications Management Plan The communications management plan is a component of the project management
plan that describes how project communications will be planned, structured, monitored, and controlled. The plan contains the following information:
Stakeholder communication requirements; Information to be communicated, including language, format, content, and level of detail; Reason for the distribution of that information; Time frame and frequency for the distribution of required information and receipt of acknowledgment or response, if applicable; Person responsible for communicating the information; Person responsible for authorizing release of confidential information; Person or groups who will receive the information; Methods or technologies used to convey the information, such as memos, e- mail, and/or press releases; Resources allocated for communication activities, including time and budget; Escalation process identifying time frames and the management chain (names) for escalation of issues that cannot be resolved at a lower staff level; Method for updating and refining the communications management plan as the project progresses and develops; Glossary of common terminology; Flow charts of the information flow in the project, workflows with possible sequence of authorization, list of reports, and meeting plans, etc.; and Communication constraints usually derived from a specific legislation or regulation, technology, and organizational policies, etc.
The communications management plan can also include guidelines and templates for project status meetings, project team meetings, e-meetings, and e-mail messages. The use of a project website and project management software can also be included if these are to be used in the project.
300
10.1.3.2 Project Documents Updates Project documents that may be updated include, but are not limited to:
Project schedule, and Stakeholder register.
10.2 Manage Communications Manage Communications is the process of creating, collecting, distributing,
storing, retrieving, and the ultimate disposition of project information in accordance to the communications management plan. The key benefit of this process is that it enables an efficient and effective communications flow between project stakeholders. The inputs, tools and techniques, and outputs of this process are depicted in Figure 10-5. Figure 10-6 depicts the data flow diagram of the Manage Communications process.
301
This process goes beyond the distribution of relevant information and seeks to ensure that the information being communicated to project stakeholders has been appropriately generated, as well as received and understood. It also provides opportunities for stakeholders to make requests for further information, clarification, and discussion. Techniques and considerations for effective communications management include, but are not limited to, the following:
Sender-receiver models. Incorporating feedback loops to provide opportunities for interaction/participation and remove barriers to communication. Choice of media. Situation specifics as to when to communicate in writing versus orally, when to prepare an informal memo versus a formal report, and when to communicate face to face versus by e-mail. Writing style. Appropriate use of active versus passive voice, sentence structure, and word choice. Meeting management techniques. Preparing an agenda and dealing with conflicts. Presentation techniques. Awareness of the impact of body language and
302
design of visual aids. Facilitation techniques. Building consensus and overcoming obstacles. Listening techniques. Listening actively (acknowledging, clarifying, and confirming understanding) and removal of barriers that adversely affect comprehension.
10.2.1 Manage Communications: Inputs
10.2.1.1 Communications Management Plan Described in Section 10.1.3.1. The communications management plan describes
how project communications will be planned, structured, monitored, and controlled.
10.2.1.2 Work Performance Reports Described in Section 4.4.3.2. Work performance reports are a collection of
project performance and status information that may be used to facilitate discussion and to create communications. To optimize this process, it is important that reports be comprehensive, accurate, and available in a timely manner.
10.2.1.3 Enterprise Environmental Factors Described in Section 2.1.5. Specific enterprise environmental factors that can
influence the Manage Communications process include, but are not limited to:
Organizational culture and structure, Government or industry standards and regulations, and Project management information system.
10.2.1.4 Organizational Process Assets Described in Section 2.1.4. Organizational process assets that can influence the
Manage Communications process include, but are not limited to:
Policies, procedures, processes, and guidelines regarding communications management; Templates; and Historical information and lessons learned.
10.2.2 Manage Communications: Tools and Techniques 10.2.2.1 Communication Technology
Described in Section 10.1.2.2. The choice of communication technology is an important consideration in the Manage Communications process. As this can vary significantly from project to project and also throughout the life of a project, the
303
focus is to ensure that the choice is appropriate for the information that is being communicated.
10.2.2.2 Communication Models Described in Section 10.1.2.3. The choice of communication models is an
important consideration in this process. As the components in the communications all contribute toward an effective and efficient communications process, the focus is to ensure that the choice of the communication model is appropriate for the project that is undertaken and that any barriers (noise) are identified and managed.
10.2.2.3 Communication Methods Described in Section 10.1.2.4. The choice of communication methods is an
important consideration in this process. As there can be many potential barriers and challenges during this process, the focus is to ensure that the information that has been created and distributed has been received and understood to enable response and feedback.
10.2.2.4 Information Management Systems Project information is managed and distributed using a variety of tools,
including:
Hard-copy document management: letters, memos, reports, and press releases; Electronic communications management: e-mail, fax, voice mail, telephone, video and web conferencing, websites, and web publishing; and Electronic project management tools: web interfaces to scheduling and project management software, meeting and virtual office support software, portals, and collaborative work management tools.
10.2.2.5 Performance Reporting Performance reporting is the act of collecting and distributing performance
information, including status reports, progress measurements, and forecasts. Performance reporting involves the periodic collection and analysis of baseline versus actual data to understand and communicate the project progress and performance as well as to forecast the project results.
Performance reporting needs to provide information at an appropriate level for each audience. The format may range from a simple status report to more elaborate reports and may be prepared regularly or on an exception basis. A simple status report might show performance information, such as percent complete or status dashboards for each area (i.e., scope, schedule, cost, and quality). More elaborate reports may include:
304
Analysis of past performance, Analysis of project forecasts (including time and cost), Current status of risks and issues, Work completed during the period, Work to be completed in the next period, Summary of changes approved in the period, and Other relevant information, which is reviewed and discussed.
10.2.3 Manage Communications: Outputs
10.2.3.1 Project Communications The Manage Communications process involves the activities that are required
for information to be created, distributed, received, acknowledged, and understood. Project communications may include but are not limited to: performance reports, deliverables status, schedule progress, and cost incurred. Project communications can vary significantly and are influenced by factors such as, but not limited to, the urgency and impact of the message, its method of delivery, and level of confidentiality.
10.2.3.2 Project Management Plan Updates The project management plan provides information on project baselines,
communications management, and stakeholder management. Each of these areas may require updates based upon the current performance of the project against the performance measurement baseline (PMB). The performance measurement baseline is an approved plan for the project work to which the project execution is compared, and deviations are measured for management control. The performance measurement baseline typically integrates scope, schedule, and cost parameters of a project, but may also include technical and quality parameters.
10.2.3.3 Project Documents Updates Project documents that may be updated include, but are not limited to:
Issue log, Project schedule, and Project funding requirements.
10.2.3.4 Organizational Process Assets Updates The organizational process assets, which may be updated include, but are not
limited to:
Stakeholder notifications. Information may be provided to stakeholders about resolved issues, approved changes, and general project status.
305
Project reports. Formal and informal project reports describe project status and include lessons learned, issue logs, project closure reports, and outputs from other Knowledge Areas (Sections 4-13). Project presentations. The project team provides information formally or informally to any or all of the project stakeholders. The information and presentation method should be relevant to the needs of the audience. Project records. Project records may include correspondence, memos, meeting minutes, and other documents describing the project. This information should, to the extent possible and appropriate, be maintained in an organized manner. Project team members can also maintain records in a project notebook or register, which could be physical or electronic. Feedback from stakeholders. Information received from stakeholders concerning project operations is distributed and used to modify or improve future performance of the project. Lessons learned documentation. Documentation includes the causes of issues, reasoning behind the corrective action chosen, and other types of lessons learned about communications management. Lessons learned need to be documented and distributed so that it becomes part of the historical database for both the project and the performing organization.
10.3 Control Communications Control Communications is the process of monitoring and controlling
communications throughout the entire project life cycle to ensure the information needs of the project stakeholders are met. The key benefit of this process is that it ensures an optimal information flow among all communication participants, at any moment in time. The inputs, tools and techniques, and outputs of this process are depicted in Figure 10-7. Figure 10-8 depicts the data flow diagram of the Control Communications process.
306
The Control Communications process can trigger an iteration of the Plan Communications Management and/or Manage Communications processes. This iteration illustrates the continuous nature of the Project Communications Management processes. Specific communication elements, such as issues or key performance indicators (e.g., actual vs. planned schedule, cost, and quality), may trigger an immediate revision, while others may not. The impact and repercussions of project communications should be carefully evaluated and controlled to ensure that the right message is delivered to the right audience at the right time.
10.3.1 Control Communications: Inputs
10.3.1.1 Project Management Plan Described in Section 4.2.3.1. The project management plan describes how the
project will be executed, monitored, controlled, and closed. It provides valuable information for the Control Communications process such as, but not limited to:
Stakeholder communication requirements, Reason for the distribution of the information, Timeframe and frequency for the distribution of required information, Individual or group responsible for communication of the information, and
307
Individual or group receiving the information.
10.3.1.2 Project Communications Described in Section 10.2.3.1. The Control Communications process involves
the activities that are required for information and communications to be monitored, acted upon, and released to stakeholders. Project communications come from multiple sources and may vary significantly in their format, level of detail, degree of formality and confidentiality. Project communications may include but are not limited to:
Deliverables status, Schedule progress, and Costs incurred.
10.3.1.3 Issue Log Described in Section 13.3.3.1. An issue log is used to document and monitor the
resolution of issues. It may be used to facilitate communication and ensure a common understanding of issues. A written log documents and helps to monitor who is responsible for resolving specific issues by a target date. Issue resolution addresses obstacles that can block the team from achieving its goals. This information is important to the Control Communications process as it provides both a repository for what has already happened in the project and a platform for subsequent communications to be delivered.
10.3.1.4 Work Performance Data Described in Section 4.3.3.2. Work performance data can include details about
which communications have actually been distributed, feedback on communications, survey results on communication effectiveness, or other raw observations identified during communication activities.
10.3.1.5 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that may influence
the Control Communications process include, but are not limited to:
Report templates; Policies, standards, and procedures that define communications; Specific communication technologies available; Allowed communication media; Record retention policies; and Security requirements.
10.3.2 Control Communications: Tools and Techniques
308
10.3.2.1 Information Management Systems An information management system provides a set of standard tools for the
project manager to capture, store, and distribute information to stakeholders about the project's costs, schedule progress, and performance. Some software packages allow the project manager to consolidate reports from several systems and facilitate report distribution to the project stakeholders. Examples of distribution formats may include table reporting, spreadsheet analysis, and presentations. Graphic capabilities can be used to create visual representations of project performance information.
10.3.2.2 Expert Judgment Expert judgment is often relied upon by the project team to assess the impact of
the project communications, need for action or intervention, actions that should be taken, responsibility for taking such actions, and the timeframe for taking action. Expert judgment may need to be applied to technical and/or management details and may be provided by any group or individual with specialized knowledge or training, such as:
Other units within the organization, Consultants, Stakeholders, including customers or sponsors, Professional and technical associations, Industry groups, Subject matter experts, and Project management office (PMO).
The project manager, in collaboration with the project team, then determines the actions required to ensure that the right message is communicated to the right audience at the right time.
10.3.2.3 Meetings The Control Communications process requires discussion and dialogue with the
project team to determine the most appropriate way to update and communicate project performance, and to respond to requests from stakeholders for information. These discussions and dialogues are commonly facilitated through meetings, which may be conducted face to face or online and in different locations, such as the project site or the client's site. Project meetings also include discussions and dialog with suppliers, vendors, and other project stakeholders.
10.3.3 Control Communications: Outputs 10.3.3.1 Work Performance Information
309
Described in Section 4.4.1.5. Work performance information organizes and summarizes the performance data gathered. This performance data typically provides status and progress information on the project at the level of detail required by the various stakeholders. This information is then communicated to the appropriate stakeholders.
10.3.3.2 Change Requests Described in Section 4.3.3.3. The Control Communications process often results
in the need for adjustment, action, and intervention. As a result, change requests will be generated as an output. These change requests are processed through the Perform Integrated Change Control process (Section 4.5) and may result in:
New or revised cost estimates, activity sequences, schedule dates, resource requirements, and analysis of risk response alternatives; Adjustments to the project management plan and documents; Recommendations of corrective actions that may bring the expected future performance of the project back in line with the project management plan; and Recommendations of preventive actions that may reduce the probability of incurring future negative project performance.
10.3.3.3 Project Management Plan Updates Control Communications process may trigger updates to the communications
management plan as well as other components of the project management plan (e.g. stakeholders and human resource management plans).
10.3.3.4 Project Documents Updates Project documents may be updated as a result of the Control Communications
process. These updates may include, but are not limited to:
Forecasts, Work performance reports, and Issue log.
10.3.3.5 Organizational Process Assets Updates The organizational process assets that may be updated include, but are not
limited to, report formats and lessons learned documentation. This documentation may become part of the historical database for both this project and the performing organization and may include the causes of issues, reasons behind the corrective action chosen, and other types of lessons learned during the project.
310
11
PROJECT RISK MANAGEMENT Project Risk Management includes the processes of conducting risk management
planning, identification, analysis, response planning, and controlling risk on a project. The objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project.
Figure 11-1 provides an overview of the Project Risk Management processes, which are as follows:
11.1 Plan Risk Management—The process of defining how to conduct risk management activities for a project.
11.2 Identify Risks—The process of determining which risks may affect the project and documenting their characteristics.
11.3 Perform Qualitative Risk Analysis—The process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact.
11.4 Perform Quantitative Risk Analysis—The process of numerically analyzing the effect of identified risks on overall project objectives.
11.5 Plan Risk Responses—The process of developing options and actions to enhance opportunities and to reduce threats to project objectives.
11.6 Control Risks—The process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout the project.
These processes interact with each other and with processes in other Knowledge Areas as described in detail in Section 3 and Annex A1.
Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality. A risk may have one or more causes and, if it occurs, it may have one or more impacts. A cause may be a given or potential requirement, assumption, constraint, or condition that creates the possibility of negative or positive outcomes. For example, causes could include the requirement of an environmental permit to do work, or having limited personnel assigned to design the project. The risk is that the permitting agency may take longer than planned to issue a permit; or, in the case of an opportunity, additional development personnel may become available who can participate in design, and they can be assigned to the project. If
311
either of these uncertain events occurs, there may be an impact on the project, scope, cost, schedule, quality, or performance. Risk conditions may include aspects of the project's or organization's environment that contribute to project risk, such as immature project management practices, lack of integrated management systems, concurrent multiple projects, or dependency on external participants who are outside the project's direct control.
Project risk has its origins in the uncertainty present in all projects. Known risks are those that have been identified and analyzed, making it possible to plan responses for those risks. Known risks that cannot be managed proactively, should be assigned a contingency reserve. Unknown risks cannot be managed proactively and therefore may be assigned a management reserve. A negative project risk that has occurred is considered an issue.
Individual project risks are different from overall project risk. Overall project risk represents the effect of uncertainty on the project as a whole. It is more than the sum of the individual risks within a project, since it includes all sources of project uncertainty. It represents the exposure of stakeholders to the implications of variations in project outcome, both positive and negative.
Organizations perceive risk as the effect of uncertainty on projects and organizational objectives. Organizations and stakeholders are willing to accept varying degrees of risk depending on their risk attitude. The risk attitudes of both the organization and the stakeholders may be influenced by a number of factors, which are broadly classified into three themes:
Risk appetite, which is the degree of uncertainty an entity is willing to take on in anticipation of a reward. Risk tolerance, which is the degree, amount, or volume of risk that an organization or individual will withstand. Risk threshold, which refers to measures along the level of uncertainty or the level of impact at which a stakeholder may have a specific interest. Below that risk threshold, the organization will accept the risk. Above that risk threshold, the organization will not tolerate the risk.
For example, an organization's risk attitude may include its appetite for uncertainty, its threshold for risk levels that are unacceptable, or its risk tolerance at which point the organization may select a different risk response.
Positive and negative risks are commonly referred to as opportunities and threats. The project may be accepted if the risks are within tolerances and are in balance with the rewards that may be gained by taking the risks. Positive risks that offer opportunities within the limits of risk tolerances may be pursued in order to generate enhanced value. For example, adopting an aggressive resource optimization technique is a risk taken in anticipation of a reward for using fewer resources.
312
Individuals and groups adopt attitudes toward risk that influence the way they respond. These risk attitudes are driven by perception, tolerances, and other biases, which should be made explicit wherever possible. A consistent approach to risk should be developed for each project, and communication about risk and its handling should be open and honest. Risk responses reflect an organization's perceived balance between risk taking and risk avoidance.
To be successful, an organization should be committed to address risk management proactively and consistently throughout the project. A conscious choice should be made at all levels of the organization to actively identify and pursue effective risk management during the life of the project. Project risk could exist at the moment a project is initiated. Moving forward on a project without a proactive focus on risk management is likely to lead to more problems arising from unmanaged threats.
313
11.1 Plan Risk Management Plan Risk Management is the process of defining how to conduct risk
314
management activities for a project. The key benefit of this process is it ensures that the degree, type, and visibility of risk management are commensurate with both the risks and the importance of the project to the organization. The risk management plan is vital to communicate with and obtain agreement and support from all stakeholders to ensure the risk management process is supported and performed effectively over the project life cycle. The inputs, tools and techniques, and outputs of this process are depicted in Figure 11-2. Figure 11-3 depicts the data flow diagram of the process.
Careful and explicit planning enhances the probability of success for other risk management processes. Planning is also important to provide sufficient resources and time for risk management activities and to establish an agreed-upon basis for
315
evaluating risks. The Plan Risk Management process should begin when a project is conceived and should be completed early during project planning.
11.1.1 Plan Risk Management: Inputs
11.1.1.1 Project Management Plan In planning risk management, all approved subsidiary management plans and
baselines should be taken into consideration in order to make the risk management plan consistent with them. The risk management plan is also a component of the project management plan. The project management plan provides baseline or current state of risk-affected areas including scope, schedule, and cost.
11.1.1.2 Project Charter Described in Section 4.1.3.1. The project charter can provide various inputs
such as high-level risks, high-level project descriptions, and high-level requirements.
11.1.1.3 Stakeholder Register Described in Section 13.1.3.1. The stakeholder register, which contains all
details related to the project's stakeholders, provides an overview of their roles.
11.1.1.4 Enterprise Environmental Factors Described in Section 2.1.5. The enterprise environmental factors that can
influence the Plan Risk Management process include, but are not limited to, risk attitudes, thresholds, and tolerances that describe the degree of risk that an organization will withstand.
11.1.1.5 Organizational Process Assets Described in Section 2.1.4. The organizational process assets that can influence
the Plan Risk Management process include, but are not limited to:
Risk categories, Common definitions of concepts and terms, Risk statement formats, Standard templates, Roles and responsibilities, Authority levels for decision making, and Lessons learned.
11.1.2 Plan Risk Management: Tools and Techniques 11.1.2.1 Analytical Techniques
316
Analytical techniques are used to understand and define the overall risk management context of the project. Risk management context is a combination of stakeholder risk attitudes and the strategic risk exposure of a given project based on the overall project context. For example, a stakeholder risk profile analysis may be performed to grade and qualify the project stakeholder risk appetite and tolerance. Other techniques, such as the use of strategic risk scoring sheets, are used to provide a high-level assessment of the risk exposure of the project based on the overall project context. Depending on these assessments, the project team can allocate appropriate resources and focus on the risk management activities.
11.1.2.2 Expert Judgment To ensure a comprehensive establishment of the risk management plan, judgment,
and expertise should be considered from groups or individuals with specialized training or knowledge in the subject area, such as:
Senior management, Project stakeholders, Project managers who have worked on projects in the same area (directly or through lessons learned), Subject matter experts (SMEs) in business or project area, Industry groups and consultants, and Professional and technical associations.
11.1.2.3 Meetings Project teams hold planning meetings to develop the risk management plan.
Attendees at these meetings may include the project manager, selected project team members and stakeholders, anyone in the organization with responsibility to manage the risk planning and execution activities, and others, as needed.
High-level plans for conducting the risk management activities are defined in these meetings. Risk management cost elements and schedule activities should be developed for inclusion in the project budget and schedule, respectively. Risk contingency reserve application approaches may be established or reviewed. Risk management responsibilities should be assigned. General organizational templates for risk categories and definitions of terms such as levels of risk, probability by type of risk, impact by type of objectives, and the probability and impact matrix will be tailored to the specific project. If templates for other steps in the process do not exist, they may be generated in these meetings. The outputs of these activities are summarized in the risk management plan.
11.1.3 Plan Risk Management: Outputs
11.1.3.1 Risk Management Plan
317
The risk management plan is a component of the project management plan and describes how risk management activities will be structured and performed. The risk management plan includes the following:
Methodology. Defines the approaches, tools, and data sources that will be used to perform risk management on the project. Roles and responsibilities. Defines the lead, support, and risk management team members for each type of activity in the risk management plan, and clarifies their responsibilities. Budgeting. Estimates funds needed, based on assigned resources, for inclusion in the cost baseline and establishes protocols for application of contingency and management reserves. Timing. Defines when and how often the risk management processes will be performed throughout the project life cycle, establishes protocols for application of schedule contingency reserves, and establishes risk management activities for inclusion in the project schedule. Risk categories. Provide a means for grouping potential causes of risk. Several approaches can be used, for example, a structure based on project objectives by category. A risk breakdown structure (RBS) helps the project team to look at many sources from which project risk may arise in a risk identification exercise. Different RBS structures will be appropriate for different types of projects. An organization can use a previously prepared custom categorization framework, which may take the form of a simple list of categories or may be structured into an RBS. The RBS is a hierarchical representation of risks according to their risk categories. An example is shown in Figure 11-4.
318
Definitions of risk probability and impact. The quality and credibility of the risk analysis requires that different levels of risk probability and impact be defined that are specific to the project context. General definitions of probability levels and impact levels are tailored to the individual project during the Plan Risk Management process for use in subsequent processes. Table 11-1 is an example of definitions of negative impacts that could be used in evaluating risk impacts related to four project objectives. (Similar tables may be established with a positive impact perspective). Table 11-1 illustrates both relative and numerical (in this case, nonlinear) approaches.
319
Probability and impact matrix. A probability and impact matrix is a grid for mapping the probability of each risk occurrence and its impact on project objectives if that risk occurs. Risks are prioritized according to their potential implications for having an effect on the project's objectives. A typical approach to prioritizing risks is to use a look-up table or a probability and impact matrix. The specific combinations of probability and impact that lead to a risk being rated as “high,” “moderate,” or “low” importance are usually set by the organization. Revised stakeholders’ tolerances. Stakeholders’ tolerances, as they apply to the specific project, may be revised in the Plan Risk Management process. Reporting formats. Reporting formats define how the outcomes of the risk management process will be documented, analyzed, and communicated. It describes the content and format of the risk register as well as any other risk reports required. Tracking. Tracking documents how risk activities will be recorded for the benefit of the current project and how risk management processes will be audited.
11.2 Identify Risks Identify Risks is the process of determining which risks may affect the project
and documenting their characteristics. The key benefit of this process is the documentation of existing risks and the knowledge and ability it provides to the
320
project team to anticipate events. The inputs, tools and techniques, and outputs of this process are depicted in Figure 11-5. Figure 11-6 depicts the data flow diagram of the process.
321
322
Participants in risk identification activities may include the following: project manager, project team members, risk management team (if assigned), customers, subject matter experts from outside the project team, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify potential risks.
Identify risks is an iterative process, because new risks may evolve or become known as the project progresses through its life cycle. The frequency of iteration and participation in each cycle will vary by situation. The format of the risk statements should be consistent to ensure that each risk is understood clearly and unambiguously in order to support effective analysis and response development. The risk statement should support the ability to compare the relative effect of one risk against others on the project. The process should involve the project team so they can develop and maintain a sense of ownership and responsibility for the risks and associated risk response actions. Stakeholders outside the project team may provide additional objective information.
11.2.1 Identify Risks: Inputs
11.2.1.1 Risk Management Plan Described in Section 11.1.3.1. Key elements of the risk management plan that
contribute to the Identify Risks process are the assignments of roles and responsibilities, provision for risk management activities in the budget and schedule, and categories of risk, which are sometimes expressed as a risk breakdown structure (Figure 11-4).
11.2.1.2 Cost Management Plan Described in Section 7.1.3.1. The cost management plan provides processes and
controls that can be used to help identify risks across the project.
11.2.1.3 Schedule Management Plan Described in Section 6.1.3.1. The schedule management plan provides insight to
project time/schedule objectives and expectations which may be impacted by risks (known and unknown).
11.2.1.4 Quality Management Plan Described in Section 8.1.3.1. The quality management plan provides a baseline
of quality measures and metrics for use in identifying risks.
11.2.1.5 Human Resource Management Plan Described in Section 9.1.3.1. The human resource management plan provides
323
guidance on how project human resources should be defined, staffed, managed, and eventually released. It can also contain roles and responsibilities, project organization charts, and the staffing management plan, which form a key input to identify risk process.
11.2.1.6 Scope Baseline Described in Section 5.4.3.1. Project assumptions are found in the project scope
statement. Uncertainty in project assumptions should be evaluated as potential causes of project risk.
The WBS is a critical input to identifying risks as it facilitates an understanding of the potential risks at both the micro and macro levels. Risks can be identified and subsequently tracked at summary, control account, and/or work package levels.
11.2.1.7 Activity Cost Estimates Described in Section 7.2.3.1. Activity cost estimate reviews are useful in
identifying risks as they provide a quantitative assessment of the likely cost to complete scheduled activities and ideally are expressed as a range, with the width of the range indicating the degree(s) of risk. The review may result in projections indicating the estimate is either sufficient or insufficient to complete the activity (i.e., pose a risk to the project).
11.2.1.8 Activity Duration Estimates Described in Section 6.5.3.1. Activity duration estimate reviews are useful in
identifying risks related to the time allowances for the activities or project as a whole, again with the width of the range of such estimates indicating the relative degree(s) of risk.
11.2.1.9 Stakeholder Register Described in Section 13.1.3.1. Information about the stakeholders is useful for
soliciting inputs to identify risks, as this will ensure that key stakeholders, especially the sponsor and customer, are interviewed or otherwise participate during the Identify Risks process.
11.2.1.10 Project Documents Project documents provide the project team with information about decisions that
help better identify project risks. Project documents improve cross-team and stakeholder communications and include, but are not limited to:
Project charter, Project schedule, Project schedule network diagrams,
324
Issue log, Quality checklists, and Other information proven to be valuable in identifying risks.
11.2.1.11 Procurement Documents Defined in Section 12.1.3.3. If the project requires external procurement of
resources, procurement documents become a key input to the Identify Risks process. The complexity and the level of detail of the procurement documents should be consistent with the value of, and risks associated with, planned procurement.
11.2.1.12 Enterprise Environmental Factors Described in Section 2.1.5. Enterprise environmental factors that can influence
the Identify Risks process include, but are not limited to:
Published information, including commercial databases, Academic studies, Published checklists, Benchmarking, Industry studies, and Risk attitudes.
11.2.1.13 Organizational Process Assets Described in Section 2.1.4. Organizational process assets that can influence the
Identify Risks process include, but are not limited to:
Project files, including actual data, Organizational and project process controls, Risk statement formats or templates, and Lessons learned.
11.2.2 Identify Risks: Tools and Techniques 11.2.2.1 Documentation Reviews
A structured review of the project documentation may be performed, including plans, assumptions, previous project files, agreements, and other information. The quality of the plans, as well as consistency between those plans and the project requirements and assumptions, may be indicators of risk in the project.
11.2.2.2 Information Gathering Techniques Examples of information gathering techniques used in identifying risks can
325
include:
Brainstorming. The goal of brainstorming is to obtain a comprehensive list of project risks. The project team usually performs brainstorming, often with a multidisciplinary set of experts who are not part of the team. Ideas about project risk are generated under the leadership of a facilitator, either in a traditional free-form brainstorm session or structured mass interviewing techniques. Categories of risk, such as in a risk breakdown structure, can be used as a framework. Risks are then identified and categorized by type of risk and their definitions are refined. Delphi technique. The Delphi technique is a way to reach a consensus of experts. Project risk experts participate in this technique anonymously. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are summarized and are then recirculated to the experts for further comment. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and keeps any one person from having undue influence on the outcome. Interviewing. Interviewing experienced project participants, stakeholders, and subject matter experts helps to identify risks. Root cause analysis. Root-cause analysis is a specific technique used to identify a problem, discover the underlying causes that lead to it, and develop preventive action.
11.2.2.3 Checklist Analysis Risk identification checklists are developed based on historical information and
knowledge that has been accumulated from previous similar projects and from other sources of information. The lowest level of the RBS can also be used as a risk checklist. While a checklist may be quick and simple, it is impossible to build an exhaustive one, and care should be taken to ensure the checklist is not used to avoid the effort of proper risk identification. The team should also explore items that do not appear on the checklist. Additionally, the checklist should be pruned from time to time to remove or archive related items. The checklist should be reviewed during project closure to incorporate new lessons learned and improve it for use on future projects.
11.2.2.4 Assumptions Analysis Every project and its plan is conceived and developed based on a set of
hypotheses, scenarios, or assumptions. Assumptions analysis explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, instability, inconsistency, or incompleteness of assumptions.
11.2.2.5 Diagramming Techniques
326
Risk diagramming techniques may include:
Cause and effect diagrams. These are also known as Ishikawa or fishbone diagrams and are useful for identifying causes of risks. System or process flow charts. These show how various elements of a system interrelate and the mechanism of causation. Influence diagrams. These are graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes, as shown in Figure 11-7.
11.2.2.6 SWOT Analysis This technique examines the project from each of the strengths, weaknesses,
opportunities, and threats (SWOT) perspectives to increase the breadth of identified risks by including internally generated risks. The technique starts with identification of strengths and weaknesses of the organization, focusing on either the project, organization, or the business area in general. SWOT analysis then identifies any opportunities for the project that arise from organizational strengths, and any threats arising from organizational weaknesses. The analysis also examines the degree to which organizational strengths offset threats, as well as identifying
327
opportunities that may serve to overcome weaknesses.
11.2.2.7 Expert Judgment Risks may be identified directly by experts with relevant experience with similar
projects or business areas. Such experts should be identified by the project manager and invited to consider all aspects of the project and suggest possible risks based on their previous experience and areas of expertise. The experts’ bias should be taken into account in this process.
11.2.3 Identify Risks: Outputs 11.2.3.1 Risk Register
The primary output from Identify Risks is the initial entry into the risk register. The risk register is a document in which the results of risk analysis and risk response planning are recorded. It contains the outcomes of the other risk management processes as they are conducted, resulting in an increase in the level and type of information contained in the risk register over time. The preparation of the risk register begins in the Identify Risks process with the following information, and then becomes available to other project management and risk management processes:
List of identified risks. The identified risks are described in as much detail as is reasonable. A structure for describing risks using risk statements may be applied, for example, EVENT may occur causing IMPACT, or If CAUSE exists, EVENT may occur leading to EFFECT. In addition to the list of identified risks, the root causes of those risks may become more evident. These are the fundamental conditions or events that may give rise to one or more identified risks. They should be recorded and used to support future risk identification for this and other projects. List of potential responses. Potential responses to a risk may sometimes be identified during the Identify Risks process. These responses, if identified in this process, should be used as inputs to the Plan Risk Responses process.
11.3 Perform Qualitative Risk Analysis Perform Qualitative Risk Analysis is the process of prioritizing risks for further
analysis or action by assessing and combining their probability of occurrence and impact. The key benefit of this process is that it enables project managers to reduce the level of uncertainty an
