Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Pmbok 8th edition professional project management, Study notes of Project Management

Professional project management

Typology: Study notes

2017/2018

Uploaded on 04/09/2018

Surajparitala
Surajparitala 🇮🇳

5

(1)

1 document

1 / 211

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
m START m CHAPTER 7
m CONTENTS m CHAPTER 8
m LIST OF FIGURES m CHAPTER 9
m PREFACE m CHAPTER 10
m CHAPTER 1 m CHAPTER 11
m CHAPTER 2 m CHAPTER 12
m CHAPTER 3 m APPENDICES
m CHAPTER 4 m GLOSSARY
m CHAPTER 5 m INDEX
m CHAPTER 6
EXIT
A Guide to the
Project
Management
Body of
Knowledge
(PMBOK®Guide)
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f
pf50
pf51
pf52
pf53
pf54
pf55
pf56
pf57
pf58
pf59
pf5a
pf5b
pf5c
pf5d
pf5e
pf5f
pf60
pf61
pf62
pf63
pf64

Partial preview of the text

Download Pmbok 8th edition professional project management and more Study notes Project Management in PDF only on Docsity!

m START m CHAPTER 7

m CONTENTS m CHAPTER 8

m LIST OF FIGURES m CHAPTER 9

m PREFACE m CHAPTER 10

m CHAPTER 1 m CHAPTER 11

m CHAPTER 2 m CHAPTER 12

m CHAPTER 3 m APPENDICES

m CHAPTER 4 m GLOSSARY

m CHAPTER 5 m INDEX

m CHAPTER 6

EXIT

A Guide to the

Project

Management

Body of

Knowledge

(PMBOK

®

Guide)

A Guide to the

Project

Management

Body of

Knowledge

(PMBOK

®

Guide)

2000 Edition

Project Management Institute

Newtown Square, Pennsylvania USA

Contents

List of Figures – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – vii

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition

  • Section I—The Project Management Framework – – – – – – – – – – – Preface to the 2000 Edition – – – – – – – – – – – – – – – – – – – – – – – ix
    • Chapter 1—Introduction – – – – – – – – – – – – – – – – – – – – – – – – –
      • 1.1 Purpose of This Guide – – – – – – – – – – – – – – – – – – – – – – – – –
      • 1.2 What Is a Project? – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 1.3 What Is Project Management? – – – – – – – – – – – – – – – – – – – –
      • 1.4 Relationship to Other Management Disciplines – – – – – – – – – – – –
      • 1.5 Related Endeavors – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 2—The Project Management Context – – – – – – – – – – – – –
      • 2.1 Project Phases and the Project Life Cycle – – – – – – – – – – – – – – –
      • 2.2 Project Stakeholders – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 2.3 Organizational Influences – – – – – – – – – – – – – – – – – – – – – – –
      • 2.4 Key General Management Skills – – – – – – – – – – – – – – – – – – – –
      • 2.5 Social-Economic-Environmental Influences – – – – – – – – – – – – – –
    • Chapter 3—Project Management Processes – – – – – – – – – – – – – –
      • 3.1 Project Processes – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 3.2 Process Groups – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 3.3 Process Interactions – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 3.4 Customizing Process Interactions – – – – – – – – – – – – – – – – – – –
      • 3.5 Mapping of Project Management Processes – – – – – – – – – – – – –
  • Section II—The Project Management Knowledge Areas – – – – – – –
    • Chapter 4—Project Integration Management – – – – – – – – – – – – – –
      • 4.1 Project Plan Development – – – – – – – – – – – – – – – – – – – – – – –
      • 4.2 Project Plan Execution – – – – – – – – – – – – – – – – – – – – – – – – –
      • 4.3 Integrated Change Control – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 5—Project Scope Management – – – – – – – – – – – – – – – –
      • 5.1 Initiation – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 5.2 Scope Planning – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 5.3 Scope Definition – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 5.4 Scope Verification – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 5.5 Scope Change Control – – – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 6—Project Time Management – – – – – – – – – – – – – – – – –
      • 6.1 Activity Definition – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 6.2 Activity Sequencing – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 6.3 Activity Duration Estimating – – – – – – – – – – – – – – – – – – – – – –
      • 6.4 Schedule Development – – – – – – – – – – – – – – – – – – – – – – – –
      • 6.5 Schedule Control – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 7—Project Cost Management – – – – – – – – – – – – – – – – –
      • 7.1 Resource Planning – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 7.2 Cost Estimating – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 7.3 Cost Budgeting – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 7.4 Cost Control – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 8—Project Quality Management – – – – – – – – – – – – – – – – - 8.1 Quality Planning – – – – – – – – – – – – – – – – – – – – – – – – – – – – - 8.2 Quality Assurance – – – – – – – – – – – – – – – – – – – – – – – – – – – - 8.3 Quality Control – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 9—Project Human Resource Management – – – – – – – – – – - 9.1 Organizational Planning – – – – – – – – – – – – – – – – – – – – – – – – - 9.2 Staff Acquisition – – – – – – – – – – – – – – – – – – – – – – – – – – – – - 9.3 Team Development – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 10—Project Communications Management – – – – – – – – –
      • 10.1 Communications Planning – – – – – – – – – – – – – – – – – – – – – – –
      • 10.2 Information Distribution – – – – – – – – – – – – – – – – – – – – – – – –
      • 10.3 Performance Reporting – – – – – – – – – – – – – – – – – – – – – – – –
      • 10.4 Administrative Closure – – – – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 11—Project Risk Management – – – – – – – – – – – – – – – – –
      • 11.1 Risk Management Planning – – – – – – – – – – – – – – – – – – – – – –
      • 11.2 Risk Identification – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 11.3 Qualitative Risk Analysis – – – – – – – – – – – – – – – – – – – – – – – –
      • 11.4 Quantitative Risk Analysis – – – – – – – – – – – – – – – – – – – – – – –
      • 11.5 Risk Response Planning – – – – – – – – – – – – – – – – – – – – – – – –
      • 11.6 Risk Monitoring and Control – – – – – – – – – – – – – – – – – – – – – –
    • Chapter 12—Project Procurement Management – – – – – – – – – – – –
      • 12.1 Procurement Planning – – – – – – – – – – – – – – – – – – – – – – – – –
      • 12.2 Solicitation Planning – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 12.3 Solicitation – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 12.4 Source Selection – – – – – – – – – – – – – – – – – – – – – – – – – – –
      • 12.5 Contract Administration – – – – – – – – – – – – – – – – – – – – – – – –
      • 12.6 Contract Closeout – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Section III—Appendices – – – – – – – – – – – – – – – – – – – – – – – – – – - Standards-Setting Process – – – – – – – – – – – – – – – – Appendix A—The Project Management Institute - Project Management Body of Knowledge – – – – – – – – – – Appendix B—Evolution of PMI’s A Guide to the - PMBOK® Guide 2000 Edition – – – – – – – – – – – – – – – – Appendix C—Contributors and Reviewers of
    • Appendix D—Notes – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Appendix E—Application Area Extensions – – – – – – – – – – – – – – – – - Project Management – – – – – – – – – – – – – – – – – – – – Appendix F—Additional Sources of Information on - Knowledge Areas – – – – – – – – – – – – – – – – – – – – – – Appendix G—Summary of Project Management
  • Section IV—Glossary and Index – – – – – – – – – – – – – – – – – – – – –
    • Glossary – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Index – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 1–1. Overview of Project Management Knowledge Areas and Project Management Processes – – – List of Figures
    • Figure 1–2. Relationship of Project Management to Other Management Disciplines – – – – – – – – – – – –
    • Figure 2–1. Sample Generic Life Cycle – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 2–2. Representative Life Cycle for Defense Acquisition, per US DODI 5000.
      • (Final Coordination Draft, April 2000) – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 2–3. Representative Construction Project Life Cycle, per Morris – – – – – – – – – – – – – – – – – – –
    • Figure 2–4. Representative Life Cycle for a Pharmaceuticals Project, per Murphy – – – – – – – – – – – – –
    • Figure 2–5. Representative Software Development Life Cycle, per Muench – – – – – – – – – – – – – – – – –
    • Figure 2–6. Organizational Structure Influences on Projects – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 2–7. Functional Organization – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 2–8. Projectized Organization – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 2–9. Weak Matrix Organization – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 2–10. Balanced Matrix Organization – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 2–11. Strong Matrix Organization – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 2–12. Composite Organization – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–1. Links among Process Groups in a Phase – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–2. Overlap of Process Groups in a Phase – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–3. Interaction between Phases – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–4. Relationships among the Initiating Processes – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–5. Relationships among the Planning Processes – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–6. Relationships among the Executing Processes – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–7. Relationships among the Controlling Processes – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–8. Relationships among the Closing Processes – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 3–9. Mapping of Project Management Processes to the Process Groups and Knowledge Areas – –
    • Figure 4–1. Project Integration Management Overview – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 4–2. Coordinating Changes Across the Entire Project – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 5–1. Project Scope Management Overview – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 5–2. Sample Work Breakdown Structure for Defense Material Items – – – – – – – – – – – – – – – –
    • Figure 5–3. Sample Work Breakdown Structure Organized by Phase – – – – – – – – – – – – – – – – – – – –
    • Figure 5–4. Sample Work Breakdown Structure for Wastewater Treatment Plant – – – – – – – – – – – – – –
    • Figure 6–1. Project Time Management Overview – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 6–2. Network Logic Diagram Drawn Using the Precedence Diagramming Method – – – – – – – – – –
    • Figure 6–3. Network Logic Diagram Drawn Using the Arrow Diagramming Method – – – – – – – – – – – – –
    • Figure 6–4. PERT Duration Calculation for a Single Activity – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 6–5. Project Network Diagram with Dates – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 6–6. Bar (Gantt) Chart – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 6–7. Milestone Chart – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 7–1. Project Cost Management Overview – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 7–2. Illustrative Cost Baseline Display – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 8–1. Project Quality Management Overview – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 8–2. Cause-and-Effect Diagram – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 8–3. Sample Process Flowchart – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 8–4. Control Chart of Project Schedule Performance – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 8–5. Pareto Diagram – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 9–1. Project Human Resource Management Overview – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 9–2. Responsibility Assignment Matrix – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
    • Figure 9–3. Illustrative Resource Histogram – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 10–1. Project Communications Management Overview – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 10–2. Illustrative Graphic Performance Report – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 10–3. Illustrative Tabular Performance Report – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 11–1. Project Risk Management Overview – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 11–2. Rating Impacts for a Risk – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 11–3. Probability-Impact Matrix – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 11–4. Cost Estimates and Ranges from the Risk Interview – – – – – – – – – – – – – – – – – – – – – –
  • Figure 11–5. Examples of Commonly Used Probability Distributions – – – – – – – – – – – – – – – – – – – – –
  • Figure 11–6. Decision Tree Analysis – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 11–7. Cost Risk Simulation – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
  • Figure 12–1. Project Procurement Management Overview – – – – – – – – – – – – – – – – – – – – – – – – – –

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA ix

Preface to the 2000 Edition

This document supersedes the Project Management Institute’s (PMI®) A Guide to the Project Management Body of Knowledge (PMBOK®^ Guide) , published in 1996. The scope of the project to update the 1996 publication was to:  Add new material reflecting the growth of the knowledge and practices in the field of project management by capturing those practices, tools, techniques, and other relevant items that have become generally accepted. ( Generally accepted means being applicable to most projects most of the time and having widespread consensus about their value and usefulness.)  Add clarification to text and figures to make this document more beneficial to users.  Correct existing errors in the predecessor document. To assist users of this document, who may be familiar with its predecessor, we have summarized the major differences here.

  1. Throughout the document, we clarified that projects manage to requirements, which emerge from needs, wants, and expectations.
  2. We strengthened linkages to organizational strategy throughout the document.
  3. We provided more emphasis on progressive elaboration in Section 1.2.3.
  4. We acknowledged the role of the Project Office in Section 2.3..
  5. We added references to project management involving developing economies, as well as social, economic, and environmental impacts, in Section 2.5..
  6. We added expanded treatment of Earned Value Management in Chapter 4 (Project Integration Management), Chapter 7 (Project Cost Management), and Chapter 10 (Project Communications Management).
  7. We rewrote Chapter 11 (Project Risk Management). The chapter now contains six processes instead of the previous four processes. The six processes are Risk Man- agement Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control.
  8. We moved scope verification from an executing process to a controlling process.
  9. We changed the name of Process 4.3 from Overall Change Control to Inte- grated Change Control to emphasize the importance of change control throughout the entirety of the project.
  10. We added a chart that maps the thirty-nine Project Management processes against the five Project Management Process Groups and the nine Project Manage- ment Knowlege Areas in Figure 3-9.
  11. We standardized terminology throughout the document from “supplier” to “seller.”
  12. We added several Tools and Techniques :  Chapter 4 (Project Integration Management)  Earned Value Management (EVM)  Preventive Action

SECTION I

THE PROJECT MANAGEMENT FRAMEWORK

1. Introduction

2. The Project Management Context

3. Project Management Processes

Chapter 1

Introduction

The Project Management Body of Knowledge (PMBOK ®^ ) is an inclusive term that describes the sum of knowledge within the profession of project management. As with other professions such as law, medicine, and accounting, the body of knowl- edge rests with the practitioners and academics that apply and advance it. The full project management body of knowledge includes knowledge of proven tra- ditional practices that are widely applied, as well as knowledge of innovative and advanced practices that have seen more limited use, and includes both published and unpublished material. This chapter defines and explains several key terms and provides an overview of the rest of the document. It includes the following major sections: 1.1 Purpose of This Guide 1.2 What Is a Project? 1.3 What Is Project Management? 1.4 Relationship to Other Management Disciplines 1.5 Related Endeavors

1.1 PURPOSE OF THIS GUIDE Project management is an emerging profession. The primary purpose of this doc- ument is to identify and describe that subset of the PMBOK ®^ that is generally accepted. Generally accepted means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness. Generally accepted does not mean that the knowledge and practices described are or should be applied uniformly on all projects; the project management team is always responsible for deter- mining what is appropriate for any given project. This document is also intended to provide a common lexicon within the pro- fession and practice for talking and writing about project management. Project management is a relatively young profession, and while there is substantial com- monality around what is done, there is relatively little commonality in the terms used. This document provides a basic reference for anyone interested in the profes- sion of project management. This includes, but is not limited to:

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 3

1.2.1 Temporary

Temporary means that every project has a definite beginning and a definite end. The end is reached when the project’s objectives have been achieved, or when it becomes clear that the project objectives will not or cannot be met, or the need for the project no longer exists and the project is terminated. Temporary does not necessarily mean short in duration; many projects last for several years. In every case, however, the duration of a project is finite; projects are not ongoing efforts. In addition, temporary does not generally apply to the product or service cre- ated by the project. Projects may often have intended and unintended social, eco- nomic, and environmental impacts that far outlast the projects themselves. Most projects are undertaken to create a lasting result. For example, a project to erect a national monument will create a result expected to last centuries. A series of projects and/or complementary projects in parallel may be required to achieve a strategic objective. The objectives of projects and operations are fundamentally different. The objective of a project is to attain the objective and close the project. The objective of an ongoing nonprojectized operation is normally to sustain the business. Proj- ects are fundamentally different because the project ceases when its declared objectives have been attained, while nonproject undertakings adopt a new set of objectives and continue to work. The temporary nature of projects may apply to other aspects of the endeavor as well:  The opportunity or market window is usually temporary—most projects have a limited time frame in which to produce their product or service.  The project team, as a team, seldom outlives the project—most projects are performed by a team created for the sole purpose of performing the project, and the team is disbanded when the project is complete.

1.2.2 Unique Product, Service, or Result

Projects involve doing something that has not been done before and which is, therefore, unique. A product or service may be unique even if the category to which it belongs is large. For example, many thousands of office buildings have been developed, but each individual facility is unique—different owner, different design, different location, different contractors, and so on. The presence of repet- itive elements does not change the fundamental uniqueness of the project work. For example:  A project to develop a new commercial airliner may require multiple proto- types.  A project to bring a new drug to market may require thousands of doses of the drug to support clinical trials.  A real estate development project may include hundreds of individual units.  A development project (e.g., water and sanitation) may be implemented in five geographic areas.

1.2.3 Progressive Elaboration

Progressive elaboration is a characteristic of projects that integrates the concepts of temporary and unique. Because the product of each project is unique, the char- acteristics that distinguish the product or service must be progressively elaborated. Progressively means “proceeding in steps; continuing steadily by increments,”

Chapter 1—Introduction

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 5

while elaborated means “worked out with care and detail; developed thoroughly” (1). These distinguishing characteristics will be broadly defined early in the project, and will be made more explicit and detailed as the project team develops a better and more complete understanding of the product. Progressive elaboration of product characteristics must be carefully coordinated with proper project scope definition, particularly if the project is performed under contract. When properly defined, the scope of the project—the work to be done— should remain constant even as the product characteristics are progressively elab- orated. The relationship between product scope and project scope is discussed further in the introduction to Chapter 5. The following two examples illustrate progressive elaboration in two different application areas. Example 1. Development of a chemical processing plant begins with process engineering to define the characteristics of the process. These characteristics are used to design the major processing units. This information becomes the basis for engineering design, which defines both the detail plant layout and the mechanical characteristics of the process units and ancillary facilities. All of these result in design drawings that are elaborated to produce fabrication drawings (construction isometrics). During construction, interpretations and adaptations are made as needed and subject to proper approval. This further elaboration of the character- istics is captured by as-built drawings. During test and turnover, further elaboration of the characteristics is often made in the form of final operating adjustments. Example 2. The product of an economic development project may initially be defined as: “Improve the quality of life of the lowest income residents of commu- nity X.” As the project proceeds, the products may be described more specifically as, for example: “Provide access to food and water to 500 low income residents in community X.” The next round of progressive elaboration might focus exclusively on increasing agriculture production and marketing, with provision of water deemed to be secondary priority to be initiated once the agriculture component is well under way.

1.3 WHAT IS PROJECT MANAGEMENT? Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accom- plished through the use of the processes such as: initiating, planning, executing, controlling, and closing. The project team manages the work of the projects, and the work typically involves:  Competing demands for: scope, time, cost, risk, and quality.  Stakeholders with differing needs and expectations.  Identified requirements. It is important to note that many of the processes within project management are iterative in nature. This is in part due to the existence of and the necessity for progressive elaboration in a project throughout the project life cycle; i.e., the more you know about your project, the better you are able to manage it. The term project management is sometimes used to describe an organizational approach to the management of ongoing operations. This approach, more prop- erly called management by projects , treats many aspects of ongoing operations as projects to apply project management techniques to them. Although an

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

Chapter 1—Introduction

6

|^

storage, and ultimate disposition of project information. It consists of commu- nications planning, information distribution, performance reporting, and admin- istrative closure. Chapter 11, Project Risk Management , describes the processes concerned with identifying, analyzing, and responding to project risk. It consists of risk man- agement planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control. Chapter 12, Project Procurement Management , describes the processes required to acquire goods and services from outside the performing organization. It consists of procurement planning, solicitation planning, solicitation, source selec- tion, contract administration, and contract closeout.

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

Chapter 1—Introduction

8

Figure 1–1. Overview of Project Management Knowledge Areas and Project Management Processes

PROJECT

MANAGEMENT

Project Plan Development Project Plan Execution Integrated Change Control

Project Integration Management Initiation Scope Planning Scope Definition Scope Verification Scope Change Control

Project Scope Management Activity Definition Activity Sequencing Activity Duration Estimating Schedule Development Schedule Control

Project Time Management

Resource Planning Cost Estimating Cost Budgeting Cost Control

Project Cost Management

Communications Planning Information Distribution Performance Reporting Administrative Closure

Project Communications Management

Quality Planning Quality Assurance Quality Control

Project Quality Management

Risk Management Planning Risk Identification Qualitative Risk Analysis Quantitative Risk Analysis Risk Response Planning Risk Monitoring and Control

Project Risk Management

Organizational Planning Staff Acquisition Team Development

Project Human Resource Management

Procurement Planning Solicitation Planning Solicitation Source Selection Contract Administration Contract Closeout

Project Procurement Management

Figure 1

–^1

|^

1.4 RELATIONSHIP TO OTHER MANAGEMENT DISCIPLINES Much of the knowledge needed to manage projects is unique to project manage- ment (e.g., critical path analysis and work breakdown structures). However, the PMBOK®^ does overlap other management disciplines, as illustrated in Figure 1-. General management encompasses planning, organizing, staffing, executing, and controlling the operations of an ongoing enterprise. General management also includes supporting disciplines such as law, strategic planning, logistics, and human resources management. The PMBOK®^ overlaps or modifies general management in many areas—organizational behavior, financial forecasting, and planning tech- niques, to name just a few. Section 2.4 provides a more detailed discussion of gen- eral management. Application areas are categories of projects that have common elements signif- icant in such projects, but are not needed or present in all projects. Application areas are usually defined in terms of:  Functional departments and supporting disciplines, such as legal, production and inventory management, marketing, logistics and personnel.  Technical elements, such as software development, pharmaceuticals, water and sanitation engineering, or construction engineering.  Management specializations, such as government contracting, community development, or new product development.  Industry groups, such as automotive, chemicals, agriculture, or financial services. Appendix E includes a more detailed discussion of project management appli- cation areas.

Chapter 1—Introduction

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 9

Figure 1–2. Relationship of Project Management to Other Management Disciplines

This figure is a conceptual view of these relationships. The overlaps shown are not proportional.

Application Area Knowledge and Practice

General Management Knowledge and Practice

The Project Management Body of Knowledge

Generally Accepted Project Management Knowledge and Practice

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 11

Chapter 2

The Project Management

Context

Projects and project management operate in an environment broader than that of the project itself. The project management team must understand this broader context—managing the day-to-day activities of the project is necessary for success but not sufficient. This chapter describes key aspects of the project management context not covered elsewhere in this document. The topics included here are: 2.1 Project Phases and the Project Life Cycle 2.2 Project Stakeholders 2.3 Organizational Influences 2.4 Key General Management Skills 2.5 Social-Economic-Environmental Influences

2.1 PROJECT PHASES AND THE PROJECT LIFE CYCLE Because projects are unique undertakings, they involve a degree of uncertainty. Organizations performing projects will usually divide each project into several project phases to improve management control and provide for links to the ongoing operations of the performing organization. Collectively, the project phases are known as the project life cycle.

2.1.1 Characteristics of Project Phases

Each project phase is marked by completion of one or more deliverables. A deliv- erable is a tangible, verifiable work product such as a feasibility study, a detail design, or a working prototype. The deliverables, and hence the phases, are part of a generally sequential logic designed to ensure proper definition of the product of the project. The conclusion of a project phase is generally marked by a review of both key deliverables and project performance to date, to a) determine if the project should continue into its next phase and b) detect and correct errors cost effectively. These phase-end reviews are often called phase exits , stage gates , or kill points.

Each project phase normally includes a set of defined deliverables designed to establish the desired level of management control. The majority of these items are related to the primary phase deliverable, and the phases typically take their names from these items: requirements, design, build, test, startup, turnover, and others, as appropriate. Several representative project life cycles are described in Section 2.1.3.

2.1.2 Characteristics of the Project Life Cycle

The project life cycle serves to define the beginning and the end of a project. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a needs assessment and/or a feasibility study to decide if it should undertake a project. The project life-cycle definition will determine whether the feasibility study is treated as the first project phase or as a separate, standalone project. The project life-cycle definition will also determine which transitional actions at the beginning and the end of the project are included and which are not. In this manner, the project life-cycle definition can be used to link the project to the ongoing operations of the performing organization. The phase sequence defined by most project life cycles generally involves some form of technology transfer or handoff such as requirements to design, construc- tion to operations, or design to manufacturing. Deliverables from the preceding phase are usually approved before work starts on the next phase. However, a sub- sequent phase is sometimes begun prior to approval of the previous phase deliv- erables when the risks involved are deemed acceptable. This practice of overlapping phases is often called fast tracking. Project life cycles generally define:  What technical work should be done in each phase (e.g., is the work of the architect part of the definition phase or part of the execution phase?).  Who should be involved in each phase (e.g., implementers who need to be involved with requirements and design). Project life-cycle descriptions may be very general or very detailed. Highly detailed descriptions may have numerous forms, charts, and checklists to provide structure and consistency. Such detailed approaches are often called project man- agement methodologies. Most project life-cycle descriptions share a number of common characteristics:  Cost and staffing levels are low at the start, higher toward the end, and drop rapidly as the project draws to a conclusion. This pattern is illustrated in Figure 2-.  The probability of successfully completing the project is lowest, and hence risk and uncertainty are highest, at the start of the project. The probability of suc- cessful completion generally gets progressively higher as the project continues.  The ability of the stakeholders to influence the final characteristics of the project’s product and the final cost of the project is highest at the start and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and error correction generally increases as the project continues. Care should be taken to distinguish the project life cycle from the product life cycle. For example, a project undertaken to bring a new desktop computer to market is but one phase or stage of the product life cycle.

A Guide to the Project Management Body of Knowledge (PMBOK ®^ Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

Chapter 2—The Project Management Context

12

|^