(1) (PART 2) - INTRODUCTION

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: uuResolving resource constraints and/or conflicts that affect components within the program; uuAligning with the organization's strategies that impact and affect program goals and objectives uuManaging issues and employing change management within a shared governance structure; uuAddressing project and program risks that can impact one or more components; and uuManaging program benefits realization by effectively analyzing, sequencing and monitoring component interdependencies. 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.

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: uuInternal stakeholders: nuSponsor, nuResource manager, nuProject management office (PMO), nuPortfolio steering committee, nuProgram manager, nuProject managers of other projects, and nuTeam members. uuExternal stakeholders: nuCustomers, nuEnd users, nuSuppliers, nuShareholders nuRegulatory bodies, and nuCompetitors 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.

LINKING ORGANIZATIONAL GOVERNANCE AND PROJECT GOVERNANCE

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: uuMarket demand, uuStrategic opportunity/business need, uuSocial need, uuEnvironmental consideration, uuCustomer request, uuTechnological advancement, uuLegal or regulatory requirement, and uuExisting or forecasted problem. 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: uuTarget benefits. The expected tangible and intangible business value to be gained by the implementation of the product, service, or result. uuStrategic alignment. How the project benefits support and align with the business strategies of the organization. uuTimeframe for realizing benefits. Benefits by phase: short term, long term, and ongoing. uuBenefits owner. The accountable person or group that monitors, records, and reports realized benefits throughout the timeframe established in the plan. uuMetrics. The direct and indirect measurements used to show the benefits realized. uuRisks. Risks associated with achieving target benefits. 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.

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).

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: uuKnowledge about project management, the business environment, technical aspects, and other information needed to manage the project effectively; uuSkills needed to effectively lead the project team, coordinate the work, collaborate with stakeholders, solve problems, and make decisions; uuAbilities to develop and manage scope, schedules, budgets, resources, risks, plans, presentations, and reports; and uuOther attributes required to successfully manage the project, such as personality, attitude, ethics, and leadership. Project managers accomplish work through the project team and other stakeholders. Project managers rely on important interpersonal skills, including, but not limited to: uuLeadership, uuTeam building, uuMotivating, uuCommunicating, uuInfluencing, uuDecision making, uuPolitical and cultural awareness, uuNegotiating, uuFacilitating, uuManaging conflict, and uuCoaching. 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.

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. 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.

PROJECT MANAGEMENT KNOWLEDGE AREAS

This standard describes the project management processes employed to meet project objectives. Project management processes are grouped in five Project Management Process Groups: uuInitiating Process Group. The process(es) performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase. Initiating processes are described in Section 2. uuPlanning Process Group. The process(es) 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. Planning processes are described in Section 3. uuExecuting Process Group. The process(es) performed to complete the work defined in the project management plan to satisfy the project requirements. Executing processes are described in Section 4. uuMonitoring and Controlling Process Group. The process(es) 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. Monitoring and Controlling processes are described in Section 5. uuClosing Process Group. The process(es) performed to formally complete or close a project, phase, or contract. Closing processes are described in Section 6. 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: uuProcesses used once or at predefined points in the project. Developing the project charter and closing the project or phase are examples. uuProcesses that are performed periodically as needed. Acquiring resources is performed when resources are needed. Conducting procurements will be performed prior to needing the procured item. uuProcesses that are performed continuously throughout the project. Defining activities may occur throughout the project life cycle, especially when the project uses rolling wave planning or an adaptive development approach. Many of the monitoring and control processes are ongoing from the start of the project, until it is closed out. 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.

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: uuIdentifying project requirements; uuAddressing the various needs, concerns, and expectations of stakeholders; uuEstablishing and maintaining active communication with stakeholders; uuManaging resources; and uuBalancing the competing project constraints, which include but are not limited to: nuScope, nuSchedule, nuCost, nuQuality, nuResources, and nuRisk. Project circumstances will influence how each project management process is implemented and how the project constraints are prioritized.

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): uuStarting the project, uuOrganizing and preparing, uuCarrying out the work, and uuClosing the project. A generic life cycle structure typically displays the following characteristics: uuCost and staffing levels are low at the start, increase as the work is carried out, and drop rapidly as the project draws to a close. uuRisk is greatest at the start of the project as illustrated by Figure 1-3. These factors decrease over the life cycle of the project as decisions are reached and as deliverables are accepted. uuThe ability of stakeholders to influence the final characteristics of the project's product, without significantly impacting cost and schedule, is highest at the start of the project and decreases as the project progresses toward completion. Figure 1-3 illustrates the cost of making changes and correcting errors typically increases substantially as the project approaches completion.

What is a Standard?

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.