Abstract
Based on generally accepted practices, I will analyse and compare the three leading program management “standards”: “MSP-Managing Successful Programmes” commonly referred to as MSP™, which originated in the UK by the Office of Government Commerce (formerly CCTA); PMI’s The Standard for Program Management”; and the “Project & Program Management for Enterprise Innovation,” known as “P2M,” promoted by the Project Management Association of Japan (formerly PMCC). The MSP standard was the first to be published in 1999, since then P2M was published in 2001 and then PMI’s Standard in 2006. A revised version of MSP was published in 2007, P2M was last revised in 2005, and PMI has just published its 2008 version. These latest versions are the ones I will compare. I will focus on four areas of comparison: the structure of the standards, their scope, the organizational structures they promote, and the roles and responsibilities they acknowledge and describe.
Introduction
Background of “Standards”
The first point I need to make is that only PMI calls its guide a “Standard,” the others are identified as “guides,” which in fact they all are because none of them are recognised by an official standardisation body. In the late 90s and early 2000s many different definitions of program and program management (PgM) co-existed and were often contradictory, ranging from a collection of similar projects, mega-projects, the combination of projects and operations, a top-down realisation of strategic processes to the bottom-up tactical grouping of actions. Since then, professional associations have aimed to clarify, if not unify, this view.
The UK (CCTA, 1999) was the first to issue a guide. “Managing Successful Programmes” has always promoted the view that program management’s objective was “…to achieve benefits that are of strategic importance” (CCTA, 1999). PMI, on the other hand, was the first to acknowledge the fact that “programs also include elements of ongoing operations” (PMI, 1996). The Japanese standard has always focused on the complexity and systemic aspects of the program.
Today, authors and professional bodies generally agree that programs deliver multiple deliverables through projects and other actions which, together, produce business benefits. They are generally complex with frequent realignments required during their life cycle. Their alignment is with the business strategy and they are benefits-focused, not product-focused.
Structure of the Standards
The three standards display a fairly different structure. The structure for PMI’s Standard (PMI, 2008a) is very close to that of the PMBOK® Guide (PMI, 2008b). It starts with an introduction and definitions, it then overviews the life cycle of the program, outlines the program processes, which are directly replicated from the project processes, and, finally, describes 10 knowledge areas (the nine project management knowledge areas, minus quality and human resources, plus three new ones: financial management, stakeholders management and governance management). One of the underlying assumptions of the PMI Standard 2006 version (PMI, 2006) was that projects existed before the program; there was therefore very little emphasis on the definition of the program from strategic objectives, but rather an emphasis on the benefits delivered by individual projects; this has changed in the 2008 version where projects are initiated during the benefits delivery phase (PMI, 2008a, chap. 2.2.4). Though PMI still talks about the “program’s end product, service, results and/or benefits” (PMI, 2008a, chap. 1.6) rather than project products and program benefits. The PMI Standard stays very close to the PMBOK® Guide and the focus is still on the description of processes, tools, and techniques rather than the management approach (more than 200 pages out of 231), the standard definitely addresses a project manager audience and takes a technical approach in its structure. This might not appeal as much to managers, although the 2008 version is a notable improvement on the 2006 version in this regard.
The P2M is exactly at the opposite end of the spectrum; it is almost a philosophy of program management rather than a practical guide, although many practical ideas are offered throughout the guide. The actual program management part of the guide is only 42 pages, although many sections cover program management through the rest of the guide, which promotes an integrated view of project management approaches. Volume 1 (87 pages) covers concepts of project, program, and a summary of what the authors have called “domain management,” the equivalent of PMI’s “knowledge areas.” In Volume 2 (214 pages) the authors cover 11 domains in detail, from strategy, finance, risk, and value to communications. P2M identifies programs as third generation project management; the program management section (Vol. 1, Part III) defines programs through its attributes and principles then outlines the concepts of a common view and a program platform: mission, assessment, community, and architecture; finally it defines integration management through profiling, strategy, architecture, platform, life cycle, and value indicator management. Most of these sections describe concepts rather than tools and techniques, which may frustrate readers who are looking for a clear process as the concepts and their relationship are sometimes confusing, at least in the English translation.
Finally, MSP demonstrates that it is the more mature standard as it offers a clear view of what a program is, clearly defining themes such as organization, vision, leadership and stakeholder management, benefits realisation management, blueprint design and delivery, planning and control, business case, risk management and issue resolution, and quality management. In each of these areas, which could be compared to PMI’s knowledge areas, it clearly distinguishes projects from programs and there is no confusion concerning the tasks required at one level or the other. For example, there are a section on project control and a distinct section on program control. The role and responsibilities of each of the main stakeholders is also clearly outlined in each section. The third part of MSP is dedicated to the transformational flow—the actual program management process. It takes the reader from the identification of the program, based on strategic objectives to the realisation of benefits and the closing of the program. Each section starts with a definition and characteristics, then outlines the process, reinforces it with a methodology, and displays a responsibility assignment matrix for each process groups. MSP uses lots of graphical representations beyond simple process flowcharts. MSP can be appealing to both project managers and managers although the sheer amount of concepts and methods included can be a bit daunting and it may lack some examples and templates, sometimes staying at too much of a conceptual level.
Comparison of Standards’ Scope
Each of these standards covers a slightly different area of the whole range of endeavours that businesses undertake to realise change. In recent years, there have been a few attempts at program classification. Most of those classifications use two scales: they typically relate to uncertainty—the ability to predict outcomes based on identified objectives—and ambiguity—the likelihood of objectives to change over time. For example, a breakthrough program with a technical focus would have high uncertainty but low ambiguity whereas a program that addresses a societal change within known boundaries, like a governmental education program, would have high ambiguity but low uncertainty. Finally, the program of forming the new government in the U.S., for example, would be considered to have both high uncertainty and high ambiguity. Exhibit 1 displays the mapping of the three standards based on these scales.
Projects, even so-called “complex projects,” cover an area that requires fairly high stability of objectives. The whole concept of project management is based on the capability to predict the outputs of the project and ensure that the project will be realised within set parameters. When the situation becomes less predictable or involves a greater ambiguity, traditional project management cannot be used to manage the process because the outputs cannot be clearly defined from the start. This is the domain of program management.
As can be seen in Exhibit 1, the PMI Standard currently covers an area that is an extension of projects and could include complex projects. PMI states: “Programs are means of achieving organizational goals and objectives that are so large scale that they cannot be achieved by single projects” (PMI, 2008a, chap. 2). The assumption is that objectives, a plan, and sometimes projects, exist before the program is initiated and that the program is brought about to “obtain benefits and control not available from managing individually” (PMI, 2008a, chap. 1.2). Although this view is very sound from a performance point of view, it does not fully reflect the complexity of program management and links it more to projects than to strategy. Additionally, the PMI Standard uses project rhetoric, which sometimes can be confusing when trying to distinguish project from program and does not entice its understanding by executives. This is the area P2M calls “second generation project management,” which applies to a variety of business solutions and work process solutions that help build an agile organizational structure (PMAJ, 2005).
Exhibit 1: Comparison between PgM Standards Coverage Areas
When program management focuses on the coordination of related projects, project management methodologies are applicable to the management of a program. On the other hand, when the focus of change is on business or society, or when complexity increases, program managers need to have a good understanding of strategic management and organisational change. In cases where multiplicity, accommodating multiple purposes and objectives, or complexity, the interface between multiple projects or stakeholder, increase, PMAJ advocates a shift from second generation to third generation project management, which they call program management. Their authors argue that: “The philosophy of project management embodied in P2M lies in deciphering complex issues, developing or interpreting missions for breakthroughs, and paving roads to optimal solutions through programs, which in turn consist of organically interrelated projects” (PMAJ, 2005, p. 8).
For the P2M standard, traditional project management can contribute very little to raising the probability of success for complex projects. In fact, it is ineffective to guide the mission and strategy formulation and to manage interrelated components. In terms of focus and predictability of outcome, PMAJ states that: “This requires the solution of complex issues involving various concepts in various ways and typically includes rich contents and context. […] This complexity necessitates integrated consideration of various factors such as politics, economy, society, technology and ethics” (PMAJ, 2005, p. 29).
As such, programs focus mostly on low predictability business issues or medium predictability societal issues. For P2M, medium- to low-range business issues and complex technical issues are dealt with what they define as second generation project management, which applies to business solution projects, work process innovation projects, and for building agile organizational structures. This is roughly equivalent to the type of program covered by the PMI Standard.
Finally, its authors claim that MSP can deal with all these types of programs but is better suited for business transformation. It may be used in a “scaled down” form for technical or low unpredictability projects/programs and may become “less appropriate” for high unpredictability societal programs (OGC, 2007). MSP is probably the most complete guide to manage programs; first, because it recognises that there are a range of programs and they need to be managed in different ways; second, because it covers a wider area than the two other standards, although one could claim that the P2M covers them under second generation projects. MSP is also the more complete in terms of methodologies aimed at delivering business benefits, covering issues like governance, leadership and stakeholder engagement, benefits realisation, transformational change, and capability improvement. Whereas the PMI Standard focuses more on the control aspect of governance and the traditional project-based tools and techniques, including planning, execution, control, and monitoring, and P2M focuses more on patterns and relationships.
Program Life-Cycle and Processes Comparison
The program life cycle, or process groups, is a good point of comparison point between the standards. The current view of program management could be summarised through five phases or processes (Thiry, 2004):
1. The Formulation phase, which consists of the definition of the program’s expected benefits through a stakeholder analysis and the agreement on the program purpose and objectives. This process is iterative.
| 2. The Organization phase, which consists of the development of the program's detailed business case and
technical blueprint as well as operational procedures and structures. This process is linked to formulation.
| 3. The Deployment phase, which consists of the delivery of capabilities through its constituent projects and other actions, including the transition into the business. This is a cyclical process.
| 4. The Appraisal phase, which consists of a program-level assessment of the benefits realization and evaluation of the success of the transition to operational benefits. This is a cyclical process.
| 5. Finally, the Dissolution phase, which consists of the agreement on the timing and grounds for dissolution and implementation of the closing process, which includes long-term benefits measurement processes.
In Exhibit 2, I have used the life cycle described in Section 2 of the PMI Standard (PMI, 2008a). MSP outlines what it calls the “transformational flow: a series of iterative and interrelated steps” (OGC, 2007, p. 143). Finally, P2M describes a series of steps that “represents continuous program transition from the beginning to the end and consists of recognizable phases” (PMAJ, 2005, p. 63). I have also added PMI’s PgMP® certification specification’s process and the current practice described above for comparison.
Exhibit 2: Comparison between PgM Standards Life Cycles
The phases outlined in the three standards, although their names differ, are relatively consistent. Every standard agrees on a formulation phase, which is completely distinct from project management. This phase is meant to identify the needs, “understand the program’s basic attributes” (PMAJ, 2005, p. 34) and prepare the business case for the program. The standards also agree that there will be phase-gates between each of the phases.
The difference starts with the organization phase where PMI splits the phase into two clearly distinct phases whereas the other standards encompass initiating and planning in one single phase: Defining (MSP) and Common View (P2M). This is a minor difference that emphasises the PMI Standard’s alignment with the PMBOK® Guide. A more important difference lies in the fact that both the PMI Standard and MSP include the appraisal of the program benefits in the deployment phase, “delivering” or “realizing” the benefits. In comparison, P2M and the PgMP®, which is based on a delineation study, include only the control and monitoring of projects in the deployment phase and identify a distinct program appraisal process/phase where the value of the program and the realisation of benefits are assessed.
Finally, all the standards include a dissolution phase where the program is wound down, feedback is collected, and resources reallocated. P2M does not explicitly identify a dissolution phase, but it is implied that, when value is achieved, the program resources will be reallocated and post-program assessment will be carried out.
Comparison of Organizational Structures
Traditional View
As more and more organizations are adopting project and program management as a way to do business, organizational structures are evolving to accommodate a combined program-project approach. Most organizations though have maintained a traditional approach and still clearly separate the project functions from the operations and focus on the management of a “handover” period to integrate the capabilities that projects deliver. These organizations typically use an emergent program perspective where projects are defined before the program is formulated, therefore losing the capability to fully integrate the program outcomes and the project outputs with the business objectives. The integration is achieved at the program board level, which is an executive level body. This is the underlying view that the PMI Standard takes in the 2006 version. The 2008 version states: “The components within the program can begin at any time after the program begins” (section 2.1), but is still very much product-focused (section 2.1.2). One of the key aspects of this type of organization is that most decisions are made at a board level and that there is little integration between the program and operations; for the PMI Standard, the transition is mostly seen as formal contract-based activities (PMI, 2008a, chap. 4.2.3.3, 4.4.1.4, 4.4.3.3). Exhibit 3 is adapted from Figure 1.7 in the 2006 version of the PMI Standard and displays such a structure.
Exhibit 3: Programs in Traditional Organizations: The PMI Standard’s View
Integrated View
Organizations that have adopted an integrated program-project approach have a more coherent view of the strategy-to-delivery process. The program board will be responsible for clarifying the vision and comprise a “decision management” team that has the power to make decisions and the means to implement them. The program board, which fosters close collaboration between the program and the business, will be responsible for the realisation of the benefits. The business change manager, in particular, will make sure the business is prepared for the new capabilities that will be delivered and will give constructive feedback to the program team. This approach is most effective when the program is derived from the strategy and projects are set as part of the program formulation and organization processes, but it is also effective for programs where projects exist beforehand. This is the view promoted by MSP. Exhibit 4 displays this organizational structure.
Exhibit 4: Programs in Integrated Organization
Network View
Finally, some organizations take a very progressive view and consider the program as a network-type organization where roles and responsibilities are dictated by the functions and relationships required to implement and end-to-end process, rather than by the existing organizational hierarchy. P2M insists on the need for shared decision-making and advocates the “flexible and modular development of programs or projects, and ongoing projectized management of operation and maintenance” (PMAJ, 2005, p. 8). This type of organization is the best response to complex environments, but requires a cultural leap that many organizations are not ready to make. Contrarily to the PMI Standard and MSP who display a typically Western culture approach, P2M promotes the concept of “community” over “organization.”
“Organizations place high value on achievement of duties while community focuses on demonstration of creativity. […] With programs, human resources are released from an organizations’ vertical pools and are re-formed into a flat community without hierarchy […] The community is based on the concept of combining individuals into a team to capitalize on professional ability, create learning opportunities, achieve work satisfaction and stimulate creativity by reaping the benefits of combining the strengths of these professionals” (PMAJ, 2005, p. 39).
Program Roles and Responsibilities
Best practice, as well as all the standards, recognises that the responsibility for managing the program cannot be exercised by a single individual. Although the program manager has the main responsibility for facilitating the management of the program, it is essential to acknowledge the full range of interests of stakeholders in the success (or failure) of the program. The successful conclusion a program, or its realistic termination, is highly dependent on negotiations between those interested stakeholders, especially when changes are necessary. This is where the role of the program manager mainly lies. A significant amount of the stakeholders’ interactions will take place at the interfaces and in the interdependencies between projects; therefore the recognition of their roles and responsibilities at these points becomes particularly significant.
P2M, MSP, and the PMI Standard define a number of program stakeholders. I have extracted eight roles from these standards. Except for the mission planner, which is rarely identified as a distinct role, these correspond to roles that I and my colleagues have encountered in our practice. Exhibit 5 defines these roles as well as their main responsibilities.
It is worth mentioning that P2M defines a formal role for only four individuals but mention a much greater number of stakeholders that influence the program as part of their “community” concept. “In program profiling, recognition of the total range of interests is indispensable for the development of the program” (PMAJ, 2005, p. 46).
Exhibit 5: Main Program Stakeholders and their Roles
The shared roles are similarly described in the standards, albeit with different designations. Whereas the PMI Standard and MSP attribute more of an endorsement role to the sponsor, P2M insists on their responsibility to clarify the concept and fundamental requirements of the program: the vision and purpose. Again, with the director or SRO, the PMI Standard, and MSP insist on the role of ensuring that the program meets its objectives and delivers the projected benefits whereas P2M focuses on the architect’s ability to develop a program into a tangible architecture: “the grand design of the overall program structure, the overall functions and basic operability” (PMAJ, 2005, p. 40). To achieve this, they need to possess a comprehensive understanding of the society, technology, and culture and the power to influence implementation. The program manager’s role is similar in all three standards, although, interestingly, it is mentioned only once in the P2M.
The PMI Standard attributes the responsibility of ensuring that program goals are achieved to the Program Governance Board, whereas MSP attributes it to the Senior Responsible Owner, and P2M to the Program Architect. The reality shows that both are applied and that the choice of one or the other depends on the delegation of authority in the organization and the seniority of the SRO/Director. In MSP, the Programme Board is appointed by the SRO who has full authority over it. In MSP, the BCM has the role of an internal customer, including needs definition, whereas the PMI Standard sees the customer more as external, whose role is to approve the program’s outcomes.
Finally, project managers are described as stakeholders only in the PMI Standard. P2M mentions the role of the architect and planner as those who will define a series of meaningfully grouped projects that form the program. MSP attributes the responsibility of appointing the project managers and the authority over them to the program manager, which I agree with. If this authority does not clearly exist, it becomes impossible to run the program.
Conclusions
PgM is still defined in many ways. Typical uses of the word program are quite varied. But all these definitions point toward the description of a larger undertaking consisting of multiple actions of smaller scale.
There are currently three program(me) management “standards” that are promoted worldwide: The PMI Standard currently covers an area that is still close to that of projects, including complex projects. For P2M, the Japanese Standard, programs focus mostly on the resolution of “societal” situations. MSP authors claim that MSP can deal with all these types of programs but is better suited for business transformation.
I have compared these standards in four major areas: the scope of organizational activities they cover; their respective life cycle; the organizational structure they promote or support; and finally, the roles and responsibilities of program actors. Whereas the PMI Standard, even in its 2008 version, seems mainly pitched at detailed process level and at the project management community, MSP is aiming to address business change management through programs, whereas P2M clearly means to deal with situations of high complexity, and, in that sense may be too much “ahead of the game” to be practical in a “Western Culture” environment.