Project Management Institute

The new PMI standard for program management


Since 1996, project managers and organizations have recognized the standard for one project: Project Management Institute's (PMI®) A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Then in 2003, PMI introduced its first standard for organizations called the Organizational Project Management Maturity Model (OPM3®). Overlapping the publication of OPM3®, the Program and Portfolio Management Standard (PPMS) program was chartered, followed by the development of two separate standards. Building a PMI standard embraces open participation of the project management profession. More than 400 volunteers worldwide devoted their time and energy to the development of these standards. PMI conducted the exposure draft reviews of both standards in 2005, with the final standards published in spring 2006.

This paper summarizes how the standard for program management evolved and outlines its key process characteristics.

Preliminary Work

In the summer of 2003, the PPMS Team formed, eventually including 416 PMI volunteers representing 36 countries under the leadership of David Ross, Project Manager, and Paul Shaltry, Deputy Project Manager.

One of the first challenges was the need to establish common agreement on the key definitions, in this case, “program,” “program management,” “portfolio,” and “portfolio management.” The PMI Standards Manager brought together all of the active standards teams to achieve consensus on these definitions. The involved team leaders agreed in time for common definitions to be included in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Third Edition and form the foundation for the program and portfolio management standards.

Next, the PPMS Team looked at whether the two subjects should be combined as one standard or treated separately. A sub-team was formed to perform a literature survey and poll the PM community to determine the differences and similarities between program and portfolio management processes. The research confirmed that while program management processes provide for the management of a group of interdependent projects, portfolio management comprises continuous, repeatable, and sustainable processes designed to map business requirements and objectives to projects and programs. As a result of this investigation, the PPMS Team concluded that the profession would be best served with two standards.

Despite the differences in these processes, the PPMS Team believed that because of the relationships between the two subjects and that these were first time standards, it would be best to manage them both under one program. The PPMS Core Team proposed this approach to the SPT, which approved the recommendation. In kind, the PPMS Team developed detailed requirements for each standard that the SPT also approved. The Core Team developed a program plan and general team orientation, which was mandatory, to help volunteers engage effectively. Development of both standards began in early 2004.

Drafting the Program Management Standard

The Program Management Architecture Team (ProgMAT), jointly led by Clarese Walker and David Whelbourn, organized into four sub teams: one for each chapter – Introduction, Program Life Cycle and Organization, and Program Management Processes - plus integration.

The team recognized early that the processes for program management closely paralleled those of project management, but were larger in scope. In addition, program management further distinguished itself by containing three broad themes that are common throughout each program: benefits management, stakeholder management and governance.

While most of the work was done virtually, the team gathered for a meeting in Philadelphia in October 2004 to finalize the document. In the last quarter of 2004, the ProgMAT's draft standard underwent separate reviews by the PPMS Edit and Quality Teams in preparation for a broader review by, potentially, the whole PPMS Team. This broader review emulated the eventual global exposure draft review that PMI would conduct. The “mini-exposure draft” process generated 400 comments from PPMS volunteers around the world.

The ProgMAT's work benefited from these comments and recommendations in the improvement or confirmation of content, even though a significant number of comments received were editorial. In general, this internal exposure draft process validated that the ProgMAT's draft was on target, as reviewers did not identify any major gaps.

Delivering the First Program Management Standard

The PPMS Core Team guided the final revisions and submitted the revised version to the general PPMS Team for a consensus vote. The overwhelming majority of those voting indicated acceptance of the proposed standard without reservation. The Core Team approved the proposed standard before turning it over to the SPT for review and approval in March 2005. The SPT engaged independent subject matter experts to augment the review process. From there, minor refinements were made and the proposed standard went on to a 90-day Exposure Draft process starting in June 2005.

The exposure draft period for the Program Management Standard ended August 19, 2005. PMI received 465 comments that the PPMS Adjudication Team reviewed. More than half of these comments were accepted, accepted with modification, or identified for review in the next version of the standard. The PPMS Core Team approved the actions of the Adjudication Team and directed the final edit and approval of the proposed standard. Only one adjudication action was appealed, and PMI's Adjudication Appeals Team subsequently resolved it.

In December 2005, the PPMS Core Team transferred the final draft for approval by the PMI Standards Consensus Body and subsequent publication.

Foundations and Processes for the Standard for Program Management

The Standard for Program Management describes generally accepted processes for managing multiple projects and non-project activities within a program environment. The terms program and program management have been in widespread use for some time and have come to mean many different things. Some organizations and industries refer to ongoing or cyclical streams of operational or functional work as programs. The recognized disciplines of operational or functional management address this type of work; therefore, the standard does not apply to these programs.

Alternatively, some organizations refer to large projects as programs. The management of large individual projects remains within the discipline of project management, and as such, is already covered in the PMBOK® Guide. If a large project is split into multiple related projects with explicit management of the benefits, then the effort becomes a program, and then that standard applies.

The standard rests on these definitions:

  1. Program: A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program.
  2. Program Management: The centralized coordinated management of a program to achieve the program's strategic objectives and benefits.

Exhibit 1 illustrates the relationships among portfolios, programs and projects. The portfolio represents the organization's set of active programs, projects, sub-portfolios, and other work at a specific point in time.

Program and Portfolio Relationships

Exhibit 1 Program and Portfolio Relationships

Programs, like projects, 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 often also contribute to a common set of benefits as defined by the program. Managing multiple projects via a program may optimize schedules across the program, deliver incremental benefits, as well as enable staffing to be optimized in the context of the overall program's needs. Projects may be interdependent because of the collective capability they deliver, or they may share a common attribute such as client, customer, vendor, technology or resource. Program management focuses on these project interdependencies and determines the optimal pacing for the program. This enables appropriate planning and scheduling of the projects within the program. In essence, all of these considerations of strategic benefits, coordinated planning, shared resources and optimized pacing contribute to determining whether multiple projects should be managed as a program.

Organizations initiate programs to deliver benefits and accomplish agreed outcomes that often affect the entire organization. The program organization must take this into account and balance stakeholder expectations, requirements, resources and timing conflicts across competing projects. There are three broad management themes that are key to the success of a program:

Benefits Management - Program benefits management assesses the value and organizational impact of the program, identifies the interdependencies of benefits being delivered among various projects within the program, ensures that targeted benefits are realistic, analyzes the potential impact of planned program changes on benefits outcome and assigns responsibilities and accountability for the actual benefits realization resulting from the program.

Stakeholder Management - Program stakeholder management identifies how the program will affect stakeholders (e.g., the organization's culture, current major issues, resistance or barriers to change, etc.) and then develops a communication strategy to engage the affected stakeholders, manage their expectations and improve their acceptance of the objectives of the program. Program stakeholder management extends beyond project stakeholder management to consider additional levels of stakeholders and broader interdependencies among projects.

Program Governance - Program governance is concerned with providing control of the organization's investment as well as monitoring the delivery of benefits as the program progresses. This control is achieved via monitoring progress reports and reviews at each of the different phases in the program's life cycle. These reviews are an opportunity for senior management or their representatives to assess the performance of the program before allowing the program to move to the next phase or before the initiation of another project.

There are five program management process groups required for any program. These process groups are aligned to those defined in the PMBOK® Guide, and are independent of application areas or industry focus.

In practice, within the program, these process groups are not linear, can overlap and are sometimes iterative. Interaction occurs both within a process group and between process groups. As with projects, these process groups do not bear any direct relationship to phases of a program's life cycle. In fact, one or more processes from each group will normally be executed at least once in every phase of a program life cycle. The five process groups are:

  • Initiating Process Group - defines and authorizes the program or a project within the program, and produces the program benefits statement and benefits realization plan for the program. The processes associated with this group are:
    1. Initiate Program – defining the scope and benefit expectations of the program. This also ensures that authorization and initiation of the program are linked to the organization's ongoing work and strategic priorities.
    2. Authorize Projects - the program management activities that initiate a project within the program.
    3. Initiate Team - getting needed human resources assigned to and working on the program.
  • Planning Process Group - plans the best alternative courses of action to deliver the benefits and scope that the program was undertaken to address. The processes associated with this group are:
    1. Develop Program Management Plan - the process of consolidating the outputs of the other planning processes, including strategic planning, to create a consistent, coherent set of documents that can be used to guide both program execution and program control.
    2. Scope Definition – the process of developing a detailed program scope statement.
    3. Create Program WBS - the process of producing a program WBS that communicates from the program-level perspective a clear understanding and statement of the technical objectives and the end item(s) or end product(s), service(s), or result(s) of the work to be performed.
    4. Schedule Development - defining the program components needed to produce the program deliverables, determining the order in which the components should be executed, estimating the amount of time required to accomplish each one, identifying significant milestones during the performance period of the program, and documenting the outcome.
    5. Cost Estimating and Budgeting - the process of aggregating all costs at the program level into a program estimate. This includes all program activity, project and non-project activity.
    6. Quality Planning - identifying the standards that are relevant to the program and specifying how to satisfy them.
    7. Human Resource Planning - identifying, documenting, and assigning program roles, responsibilities, and reporting relationships.
    8. Communications Planning - determining the information and communication needs of the program stakeholders, who needs what information, when they need it, how it will be given to them and by whom.
    9. Plan Program Purchases and Acquisitions - determining what to procure and when, validating product requirements, and developing procurement strategies.
    10. Plan Program Contracting - identifying the type and detail of documentation required to implement contracts for suppliers either external to or within the organization.
    11. Risk Management Planning and Analysis - the process of deciding how to plan and analyze risk management activities for a program, including risks identified in the individual program components.
    12. Interface Planning - the process of identifying and mapping interrelationships that exist within a program, with other programs in active portfolios, or with factors outside the program.
    13. Transition Planning - the process of identifying and planning for transitions from the program team to the recipients of on-going activities that result from the program.
    14. Resource Planning - the process of determining the people, equipment, materials and other resources that are needed, and in what quantities, in order to perform program activities and optimize the use of available resources across the program.
  • Executing Process Group - integrates people and other resources to carry out the plan for the program and deliver the program's benefits. The processes associated with this group are:
    1. Direct and Manage Program Execution - the process of delivering the program's intended benefits.
    2. Perform Quality Assurance - evaluating overall program performance on a regular basis to provide confidence that the program will comply with the relevant quality policies and standards.
    3. Acquire Program Team – providing human resources for the program through selection of internal or external candidates.
    4. Develop Program Team - the process of building individual and group competencies to enhance program performance.
    5. Information Distribution - providing timely and accurate information to program stakeholders, in useful formats and appropriate media.
    6. Request Seller Responses - the process of issuing requests for information (RFI), request for proposals (RFP), and request for quotation (RFQ), and obtaining the responses.
    7. Select Sellers - the process of reviewing offers, choosing among potential sellers, and negotiating the details of the contract, including technical terms and conditions, roles and responsibilities, deliverables, and final cost.
  • Monitoring and Controlling Process Group - requires that progress is regularly measured and monitored to identify variances from the program management plan, and coordinates corrective actions to be taken when necessary to achieve program benefits. The processes associated with this group are:
    1. Monitor and Control Program Work - the process of collecting, measuring and consolidating performance information, and assessing measurements and trends to generate improvements.
    2. Integrated Change Control - coordinating changes across the entire program, including changes to cost, quality, schedule, and scope.
    3. Scope Control - the process for controlling changes to the program scope.
    4. Schedule Control - ensuring that the program will produce its required deliverables and solutions on time.
    5. Cost Control - the process of controlling changes to, and producing information from, the program budget.
    6. Perform Quality Control - monitoring specific program deliverables and results to determine if they fulfill quality requirements.
    7. Performance Reporting - the process of consolidating performance data to provide stakeholders with information about how resources are being used to deliver program benefits.
    8. Risk Monitoring and Control - tracking identified program risks, identifying new risks to the program, executing risk response plans, and evaluating their effectiveness in reducing risk through the program life cycle.
    9. Program Contract Administration - managing the relationship with sellers and buyers at the program level, excluding such processes performed at the component level. The process includes purchases and procurement of outside resources that span the program domain and that are not covered by a specific project.
    10. Issue Management and Control - the process of identifying, tracking, and closing issues effectively to ensure that stakeholder expectations are aligned with program activities and deliverables.
    11. Communications Control - managing communications to inform the stakeholders about the program and resolve issues of interest to them.
  • Closing Process Group - formalizes acceptance of a product, service or result, brings the program or program component (e.g. project) to an orderly end. The processes associated with this group are:
    1. Close Program - the process of formalizing the acceptance of the program's outcome by the sponsor or customer.
    2. Contract Closure - the process of closing out a contract executed during the program and on behalf of the program, in accordance with the contract's terms and conditions.
    3. Component Closure - the process of performing the program management activities to close out a project or other, non-project activity within the program.


The new standards for program and portfolio management address the broader issues of managing multiple projects in organizations. By complementing PMI's Standard for Portfolio Management, the PMBOK® Guide and OPM3®, these two new standards enable managers and organizations with a comprehensive approach to managing the project environment.


Project Management Institute. (2003) The Organizational Project Management Maturity Model (OPM3®) .Newtown Square, PA: Project Management Institute.

Project Management Institute. (2004) A Guide to the Project Management Body of Knowledge (PMBOK®Guide), Third Edition. Newtown Square, PA: Project Management Institute.

Project Management Institute. (2006) The Standard for Program Management- First Edition. Newtown Square, PA: Project Management Institute.

Project Management Institute. (2006) The Standard for Portfolio Management- First Edition).Newtown Square, PA: Project Management Institute.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

©2006, David W. Ross & Paul E. Shaltry
Originally published as a part of 2006 PMI Global Congress Proceedings – Madrid, Spain



Related Content


Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.