A standard is a document established by an authority, custom, or general consent as a model or example. This standard was developed using a process based on the concepts of consensus, openness, due process, and balance. This standard describes the processes considered to be good practice on most projects most of the time. These processes are organized by Process Group. It further defines key project management concepts including the relationship of project management to organizational strategy and objectives, governance, portfolio management, program management, the project environment, and project success. It also covers information on project life cycles, project stakeholders, and the role of the project manager. Section 1 discusses key concepts and provides contextual information about project management. Sections 2 through 6 provide definitions for each of the five Process Groups and describe the processes within those Process Groups. Sections 2 through 6 also describe the key benefits, inputs, and outputs for each project management process. This standard serves as the foundation and framework for A Guide to the Project Management Body of Knowledge (PMBOK® Guide).1 PMBOK® Guide expands on the information in this standard by providing a more in-depth description of the context, environment and influences on project management. In addition, the PMBOK® Guide provides descriptions of the project management process inputs and outputs, identifies tools and techniques, and discusses key concepts and emerging trends associated with each Knowledge Area.
1.1 PROJECTS AND PROJECT MANAGEMENT
A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a definite beginning and end. Temporary does not necessarily mean a project has a short duration. A project's end is reached when the 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. The decision to terminate a project requires approval and authorization by an appropriate authority.
Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through the appropriate application and integration of the project management processes identified for the project.
Managing a project typically includes but is not limited to:
Project circumstances will influence how each project management process is implemented and how the project constraints are prioritized.
1.2 RELATIONSHIPS AMONG PORTFOLIOS, PROGRAMS, AND PROJECTS
A portfolio is defined as projects, programs, subsidiary portfolios, and operations managed in a coordinated manner to achieve strategic objectives. Portfolio management is the centralized management of one or more portfolios to achieve strategic objectives. Portfolio management focuses on ensuring the portfolio is performing consistent with the organization's objectives and evaluating portfolio components to optimize resource allocation. Portfolios may include work that is operational in nature.
A program is defined as related projects, subsidiary programs, and program activities managed in a coordinated manner to obtain benefits not available from managing them individually. Programs include program related work outside the scope of the discrete projects in the program. Program management is the application of knowledge, skills, and principles to a program to achieve the program objectives and to obtain benefits and control not available by managing related program components individually. Programs may also include work that is operational in nature.
Program management supports organizational strategies by authorizing, changing, or terminating projects and managing their interdependencies. Managing project interdependencies may include, among other actions, the following:
A project may be managed in three separate scenarios: as a stand-alone project (outside a portfolio or program); within a program; or within a portfolio. Project management has interactions with portfolio and program management when a project is within a portfolio or program.
Figure 1-1 illustrates a sample portfolio structure indicating relationships of the components, shared resources and stakeholders. The portfolio components are grouped together in order to facilitate the effective governance and management of that work and to achieve organizational strategies and priorities. Organizational and portfolio planning impact the components by means of prioritization based on risk, funding, and other considerations. This allows organizations to have an overall view of how the strategic goals are reflected in the portfolio; institute appropriate portfolio, program, and project governance; and authorize human, financial, or physical resources. These resources will be allocated based on expected performance and benefits. Figure 1-1 illustrates that organizational strategies and priorities are linked and have relationships between portfolios and programs, between portfolios and projects, and between programs and individual projects. These relationships are not always strictly hierarchical.
Organizational project management (OPM) is a strategy execution framework utilizing portfolio, program, and project management. It provides a framework that enables organizations to consistently and predictably deliver on organizational strategy, producing better performance, better results, and a sustainable competitive advantage.
1.3 LINKING ORGANIZATIONAL GOVERNANCE AND PROJECT GOVERNANCE
There are various types of governance including organizational governance; organizational project management (OPM) governance; and portfolio, program, and project governance. Organizational governance is a structured way to provide direction and control through policies, and processes, to meet strategic and operational goals. Organizational governance is typically conducted by a board of directors to ensure accountability, fairness, and transparency to its stakeholders. Organizational governance principles, decisions, and processes may influence and impact the governance of portfolios, programs, and projects in the following ways:
Project governance is the framework, functions, and processes that guide project management activities in order to create a unique product, service, or result to meet organizational, strategic, and operational goals. Governance at the project level includes:
The project governance framework provides the project stakeholders with structure, processes, roles, responsibilities, accountabilities, and decision-making models for managing the project. Elements of a project governance framework include but are not limited to principles or processes for:
1.4 PROJECT SUCCESS AND BENEFITS MANAGEMENT
Projects are initiated to realize business opportunities that are aligned with an organization's strategic goals. Prior to initiating a project, a business case is often developed to outline the project objectives, the required investment, and financial and qualitative criteria for project success. The business case provides the basis to measure success and progress throughout the project life cycle by comparing the results with the objectives and the identified success criteria.
Projects are typically initiated as a result of one or more of the following strategic considerations:
A benefits management plan describes how and when the benefits of the project will be delivered and how they will be measured. The benefits management plan may include the following:
The success of the project is measured against the project objectives and success criteria. In many cases, the success of the product, service, or result is not known until sometime after the project is complete. For example, an increase in market share, a decrease in operating expenses, or the success of a new product may not be known when the project is transitioned to operations. In these circumstances, the project management office (PMO), portfolio steering committee, or some other business function within the organization should evaluate the success at a later date to determine if the outcomes met the business objectives.
Both the business case and the benefits management plan are developed prior to the project being initiated. Additionally, both documents are referenced after the project has been completed. Therefore, they are considered business documents rather than project documents or components of the project management plan. As appropriate, these business documents may be inputs to some of the processes involved in managing the project, such as developing the project charter.
1.5 THE PROJECT LIFE CYCLE
A project life cycle is the series of phases that a project passes through from its start to its completion. A project phase is a collection of logically related project activities that culminates in the completion of one or more deliverables. The phases can be sequential, iterative, or overlapping. The names, number, and duration of the project phases are determined by the management and control needs of the organization(s) involved in the project, the nature of the project itself, and its area of application. Phases are time bound, with a start and end or control point (sometimes referred to as a phase review, phase gate, control gate, or other similar term). At the control point, the project charter and business documents are reexamined based on the current environment. At that time, the project's performance is compared to the project management plan to determine if the project should be changed, terminated, or continue as planned.
The project life cycle can be influenced by the unique aspects of the organization, industry, development method, or technology employed. While every project has a start and end, the specific deliverables and work that take place vary widely depending on the project. The life cycle provides the basic framework for managing the project, regardless of the specific work involved.
Though projects vary in size and the amount of complexity they contain, a typical project can be mapped to the following project life cycle structure (see Figure 1-2):
A generic life cycle structure typically displays the following characteristics:
1.6 PROJECT STAKEHOLDERS
A stakeholder is an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. Project stakeholders may be internal or external to the project, they may be actively involved, passively involved, or unaware of the project. Project stakeholders may have a positive or negative impact on the project, or be positively or negatively impacted by the project. Examples of stakeholders include but are not limited to:
Figure 1-4 shows examples of project stakeholders. Stakeholder involvement may range from occasional contributions in surveys and focus groups to full project sponsorship that includes the provision of financial, political, or other types of support. The type and level of project involvement can change over the course of the project's life cycle. Therefore, successfully identifying, analyzing, and engaging stakeholders and effectively managing their project expectations and participation throughout the project life cycle is critical to project success.
1.7 ROLE OF THE PROJECT MANAGER
The project manager is the person assigned by the performing organization to lead the team responsible for achieving the project objectives. The project manager's reporting relationships are based on the organizational structure and project governance.
In addition to any specific technical skills and general management proficiencies required for the project, project managers should have at least the following attributes:
Project managers accomplish work through the project team and other stakeholders. Project managers rely on important interpersonal skills, including, but not limited to:
The project manager is successful when the project objectives have been achieved. Another aspect of success is stakeholder satisfaction. The project manager should address stakeholder needs, concerns and expectations to satisfy relevant stakeholders. To be successful, the project manager should tailor the project approach, life cycle, and project management processes to meet the project and product requirements.
1.8 PROJECT MANAGEMENT KNOWLEDGE AREAS
The Project Management Knowledge Areas are fields or areas of specialization that are commonly employed when managing projects. A Knowledge Area is a set of processes associated with a particular topic in project management. These 10 Knowledge Areas are used on most projects most of the time. The needs of a specific project may require additional Knowledge Areas. The 10 Knowledge Areas are:
1.9 PROJECT MANAGEMENT PROCESS GROUPS
This standard describes the project management processes employed to meet project objectives. Project management processes are grouped in five Project Management Process Groups:
These five Process Groups are independent of the application areas, (such as marketing, information services, or accounting) or industry focus (such as construction, aerospace, telecommunications). Individual processes in the Process Groups are often iterated prior to completing a phase or a project. The number of process iterations and interactions between processes varies based on the needs of the project. Processes generally fall into one of three categories:
The output of one process generally becomes an input to another process or is a deliverable of the project or project phase. For example, the project management plan and project documents (e.g., risk register, responsibility assignment matrix, etc.) produced in the Planning Process Group are provided to the Executing Process Group where updates are made. Figure 1-4 illustrates an example of how Process Groups can overlap during a project or phase.
Process Groups are not project phases. If the project is divided into phases, the processes in the Process Groups interact within each phase. It is possible that all Process Groups could be represented within a phase, as illustrated in Figure 1-5. As projects are separated into distinct phases, such as concept development, feasibility study, design, prototype, build, or test, etc., processes in each of the Process Groups are repeated as necessary in each phase until the completion criteria for that phase have been satisfied.
Table 1-1 shows the 49 processes mapped to the Process Groups and Knowledge Areas.
1.10 ENTERPRISE ENVIRONMENTAL FACTORS AND ORGANIZATIONAL PROCESS ASSETS
Projects exist and operate in environments that may have an influence on them. These influences can have a favorable or unfavorable impact on the project. Two major categories of influences are enterprise environmental factors (EEFs) and organizational process assets (OPAs).
EEFs originate from the environment outside of the project and often outside of the enterprise. These factors refer to conditions, which are not under the control of the project team, that influence, constrain, or direct the project. EEFs may have an impact at the enterprise, portfolio, program, or project level. (Refer to Section 2.2 in the PMBOK® Guide for additional information on EEFs.) One set of such factors are the internal organizational culture, structure and governance. Examples in this area include but are not limited to: vision, mission, values, beliefs, cultural norms, hierarchy, and authority relationships.
OPAs are internal to the enterprise. These may arise from the enterprise itself, a portfolio, a program, another project, or a combination of these. OPAs are the plans, processes, policies, procedures, and knowledge bases specific to and used by the performing organization. These assets influence the management of the project. Examples include but are not limited to: change control procedures, templates, information from previous projects, and lessons learned repositories. (Refer to Section 2.3 in the PMBOK® Guide for additional information on OPAs).
1.11 TAILORING THE PROJECT ARTIFACTS
The term artifact in this context includes project management processes, inputs, tools, techniques, outputs, EEFs, and OPAs. The project manager and the project management team select and adapt the appropriate artifacts for use on their specific project. This selection and adaptation activity is known as tailoring. Tailoring is necessary because each project is unique; therefore, not every process, input, tool, technique, or output is required on every project.
The project management plan is the most prevalent artifact. It has many components, such as the subsidiary management plans, baselines, and a description of the project life cycle. Subsidiary management plans are plans associated with a specific aspect or Knowledge Area of the project, for example, a schedule management plan, risk management plan and change management plan. Part of tailoring is identifying the project management plan components needed for a particular project. The project management plan is an input and project management plan updates are an output of many processes in this standard. Rather than listing the individual project management plan components in the input/output tables, examples of the components that may be inputs or may be updated as outputs are listed beneath the input/output tables for each process. The possible components are listed as examples only. These inputs and outputs are not required and are not the only inputs or updates to the project management plan that a project manager may use in that particular process.
The project management plan is one of the primary project artifacts, but there are other documents that are not part of the project management plan that are used to manage the project. These other documents are called project documents. Similar to project management plan components, project documents needed for a process will depend on the individual project. The project manager is accountable for identifying the project documents needed for a process and the project documents that will be updated as an output of a process. The project documents listed beneath the input/output tables throughout this standard are possible examples of project documents, not a comprehensive list.
Table 1-2 is a representative list of project management plan components and project documents. It is not complete list, but it does provide a representation of the types of documents that are often used to help manage a project.
Project Management Plan | Project Documents | |
1. Scope management plan | 1. Activity attributes | 19. Quality control measurements |
2. Requirements management plan | 2. Activity list | 20. Quality metrics |
3. Schedule management plan | 3. Assumption log | 21. Quality report |
4. Cost management plan | 4. Basis of estimates | 22. Requirements documentation |
5. Quality management plan | 5. Change log | 23. Requirements traceability matrix |
6. Resource management plan | 6. Cost estimates | 24. Resource breakdown structure |
7. Communications management plan | 7. Cost forecasts | 25. Resource calendars |
8. Risk management plan | 8. Duration estimates | 26. Resource requirements |
9. Procurement management plan | 9. Issue log | 27. Risk register |
10. Stakeholder engagement plan | 10. Lessons learned register | 28. Risk report |
11. Change management plan | 11. Milestone list | 29. Schedule data |
12. Configuration management plan | 12. Physical resource assignments | 30. Schedule forecasts |
13. Scope baseline | 13. Project calendars | 31. Stakeholder register |
14. Schedule baseline | 14. Project communications | 32. Team charter |
15. Cost baseline | 15. Project schedule | 33. Test and evaluation documents |
16. Performance measurement baseline | 16. Project schedule network diagram | |
17. Project life cycle description | 17. Project scope statement | |
18. Development approach | 18. Project team assignments |
Business documents are documents that are generally originated outside of the project, and are used as inputs to the project. Examples of business documents include the business case and benefits management plan. The use of the business documents will depend on the company culture and project initiation process.
The enterprise environmental factors that influence the project and the organizational process assets available to the project will depend on the project and project environment and are not listed in this standard.
1 Project Management Institute. 2017. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: Author.