Deployment of Organizational Project Management Methodology

By Emad E. Aziz, PMP, PgMP, BRISK Business Inc.


What is a Methodology?

Considerations for the Deployment of OPM Methodology

Systemization versus mechanization

Deployments in small to medium-sized enterprises

Magnitude of the methodology deployment

Cultural influence

Methodology deployment as a psychological transition

Perceived negative impact or threat on stakeholders

Impact on morale and credibility

Applying the Change Management Life Cycle Framework

Step 1: Formulate the deployment

Step 2: Plan the deployment

Step 3: Implement the deployment

Step 4: Manage the transition

Step 5: Sustain the methodology





As organizations continue to discover the importance of developing organizational portfolio, program and project management methodologies, they are also recognizing the need to improve on the alignment of projects and programs to strategic objectives. While some organizations may have matured the methodology formulation process, many experience challenges in deploying it across the organization.

Issues with adoption by various stakeholders and benefits sustainment are two of the most prominent reasons why organizations fail to deploy, deeply integrate, and sustain methodologies. But, more often than not, the blame is incorrectly attributed to the methodology, its application, coherence, or relevance. What these organizations do not realize is that deployment of a methodology is a large undertaking of organizational change and is best managed through rigorous program management. By focusing attention on the organizational impact and required behavior modifications, organizations can better realize the intended business benefits through improved adoption, integration, and sustainable results.

This paper proposes an approach for organizational project management methodology deployment, integration, and sustainment based on guidance in publications such as Managing Change in Organizations: A Practice Guide (PMI, 2013a) and Implementing Organizational Project Management: A Practice Guide (PMI, 2014a).

What is a Methodology?

To address the challenges associated with the deployment of a methodology, it is essential to know the meaning and purpose of portfolio, program, and project management methodology. The term for such an organizational approach to methodology is Organizational Project Management (OPM). PMI defines OPM as, “A strategy execution framework that utilizes portfolio, program, and project management as well as organizational-enabling practices to consistently and predictably deliver organizational strategy leading to better performance, better results, and a sustainable competitive advantage” (PMI, 2013b, p. 17).

In short, OPM is the holistic management of portfolios, programs, and projects, integrated with the organization's business management framework, to deliver needed results. Therefore, a methodology is a unified approach to managing programs and projects within and across a single organization, encompassing horizontal and vertical practices within the organization, as illustrated in Figure 1.

Implementing Organizational Project Management (PMI, 2014a) states that OPM is an evolutionary process in the sense that “utilization of OPM has grown in the past 20 years, emerging from establishing good practices for a project, to establishing good practices for a program, and then to establishing portfolio, program, or project management offices (PMOs) for handling various aspects of support, coordination, and improvement” (p. 3).


Source: Adapted from Organizational Project Management Maturity Model (OPM3), Figure 1-2, p.4

Figure 1: The integration of portfolio, program, and project management with the strategy of the organization.

Confirming the definition of methodology helps avoid confusion with other models that are adopted by multiple organizations worldwide. One such model, called the “project management toolbox,” can be commonly mistaken for a methodology. This approach is when a department within the organization—typically the PMO—compiles a set of practices, tools, templates, guidelines, and other artifacts that can be freely used—or not used—by practitioners. Despite the possible sophistication of the toolbox's content, the organization is still managing projects in an ad hoc manner in contrast to one that uses a formally deployed and accepted OPM methodology.

OPM development and deployment phases are related. Some organizations develop a methodology and then seek to deploy it—the sequential approach—whereas others deploy the methodology as it is being developed—the progressive approach. The guidance in this paper is useful for both the sequential and progressive approaches. However, the progressive approach is recommended for a better-fitted, higher-adopted methodology. Whether using a sequential or progressive approach, the deployment of OPM is best managed as a program and leverages the organizational change management practices embedded within program management.

Considerations for the Deployment of OPM Methodology

Before organizations embark on the deployment of OPM methodology, it is in their best interest to address considerations that can be overlooked as a result of the urgency to get the deployment completed. Such considerations, if unattended to, may cause unanticipated risks, delays, and even the overall failure of the deployment. The primary concern with expedited deployment is the lack of adoption, belief, sensemaking, and transition, as demonstrated later in this paper. Organizational leadership needs to understand and communicate that the methodology brings about systemization of the work, not simply mechanization.

In addition, leadership needs to consider the nature and size of the organization, the magnitude of the change, and the influence of culture on any intended change. Lasting change only occurs when individuals within the organization embrace and adopt the change. Therefore, it is also important to consider the psychological transition for employees, the impact of the deployment and any perceived threat to stakeholders, as well as the potential negative impact on employee morale and credibility.

Systemization versus mechanization

When an organization begins to develop, adopt, and integrate a methodology for managing its portfolio of programs and projects, it needs to differentiate between systemization and mechanization. This differentiation must be communicated, clarified, and widely understood by stakeholders at the onset and throughout the life cycle of the deployment.

Systemization is the implementation of a set of processes for completing work. An OPM methodology includes a number of independent yet integrative parts—processes, procedures, and tools and techniques—all of which define how portfolios, programs, and projects are managed within the organization. Though many of these parts are essential to the successful delivery of benefits and alignment of projects and programs to the organization's strategy, their implementation entails a degree of contextual flexibility.

On the other hand, mechanization is synonymous with mass production. A properly calibrated machine produces predictable results with slight variation within an accepted margin of error. Mechanization cannot be effectively applied to project management given the nature of projects and programs (e.g., their unique purpose, expected benefits, stakeholder composition, high level of uncertainty, need to constantly adjust for anticipated benefits).

The misconception that OPM methodology is a form of mechanization may lead to the failure of the methodology. Stakeholders may gradually come to realize that the “mechanized” methodology is not suitable because it needs to apply to all projects, all the time, and without flexibility and malleability. Tailoring the methodology to work for different projects and programs at different times is necessary for the adoption and sustained success of the methodology.1

Organizations must be aware of and avoid the common mistake of confusing mechanization with systemization. A good approach for implementing an OPM methodology, while minimizing this confusion, is to conduct the implementation as a program and leverage active stakeholder engagement, communications, sensemaking activities, and other aspects of the change management life cycle framework put forward in Managing Change in Organizations (PMI, 2013a).

Deployments in small to medium-sized enterprises

Many small to medium-sized enterprises tend to view OPM as “unnecessary” or “too expensive.” The argument against this predisposition is simple: increased capability and strategic growth for any organization happen through projects, and a properly designed and implemented methodology will help that enterprise efficiently achieve its objectives—saving costs and decreasing time to market.

Generally, small to medium-sized enterprises feel their focus should be on what earns revenue more than anything else. All of their limited resources are normally directed to the value chain and they are mostly understaffed and overworked. OPM methodology deployment in small to medium-sized enterprises, just as in large organizations, needs to have certain characteristics. It must:

Evolve in a way that does not disrupt ongoing operations

Reduce onus and bureaucracy as opposed to increasing them

Be cost-effective, meaning that the time and money spent in compliance with the methodology constitute an investment as opposed to creating overhead

Gain the support of the individuals involved as opposed to being imposed upon them

Clearly prove its benefit to the organization and to the individual

Be deployed in morsel-sized increments that do not impede on progress with business as usual, yet demonstrate value and promote adoption as much as possible

Magnitude of the methodology deployment

OPM methodology deployment means asking stakeholders to change the way in which they operate. It involves the introduction of new, unified, and structured means of managing portfolios, programs, and projects in light of—and to deliver—organizational strategy. Stakeholders find themselves having to undertake new practices, some of which may be perceived to have limited or no value. Worse yet, stakeholders may resist the methodology due to pride of ownership should they have been involved in the development of existing practices.

Therefore, it is important to first understand the magnitude of the change and the implications for the organization. Managing Change in Organizations (PMI, 2013a) cites the work of Watzlawick, Weakland, and Fisch who proposed classifying change into first, second, or third order change. First and second order changes are synonymous with OPM methodology deployment and can be further defined as:

First order change: An evolutionary transition where incremental changes are made to existing practices and procedures.

Second order change: Change that involves significant transformation to what the organization does or how it does it. Second order change is often called transformational change in that it requires extensive modifications to practices and processes that individuals within the organization perform.

Depending on the maturity of the organization, an OPM deployment could constitute a first or second order change. In its complete form, an OPM methodology involves the implementation of new governance systems and new policies, procedures, and processes that affect every aspect of the organization. It can be argued that an organization introducing portfolio, program, and project management methodology for the first time is experiencing a second order change since it “requires new policies, new focus, new processes, new training, and possibly a more robust accountability hierarchy that drives real accountability” (PMI, 2013a, p. 15).

Cultural influence

Deploying a methodology in any organization is considered a strategic move. It is an operational strategy for how the organization goes about delivering its strategy. In that context, it is important to note the now common saying (often attributed to Peter Drucker), “culture eats strategy for breakfast.” Effectively, no matter how sophisticated, advanced, simple, or effective the methodology, organizational culture can pose the highest threat to its successful deployment.2

Managing Change in Organizations (PMI, 2013a) notes two components that make up organizational culture: “[1] an explicit way of working (formal systems and processes in place and how they operate) and [2] a tacit level of operations (the informal and semiformal networks and other activities people employ to get things done and bypass, subvert, or seek to influence the more formal processes)” (p. 18). It also notes that “culture is composed of the prevailing beliefs, behaviors, and assumptions of an organization [that] serve as a guide to what are considered appropriate or inappropriate behaviors of individuals and groups” (p. 18). There are three cultural environments that can be particularly challenging in the context of OPM methodology deployment:

Emerging businesses: This category applies to any organization that starts small with centralized control. At a certain point during its growth process, it is faced with the internal constraints posed by stresses on the limited capability to maintain the structure of that centralized control. All such organizations are synonymous with centralized decision making at the very top.

Hierarchy of technocrats: Many countries worldwide are classified as “countries in transition”—moving from the once prevalent hierarchical, technocrat-based structure to a more fluid, results-oriented structure. Today, many such organizations realize the need to transition into the practices of a free market economy; but in many such cases, both organizational and social cultures in which they exist have not matured sufficiently to accommodate such a paradigm shift. Authority is still highly regarded and is an element of social prestige and ego. Persons at the top of any organization or organizational unit are reluctant to delegate to their subordinates, and still view the relationship as akin to a parent-child relationship. What's more, in many cases, planning and monitoring reside with one group, execution with another, and reporting with a third, thus creating an environment of conflict and policing as opposed to cooperation, ownership, and delivery.

The large, strictly functional organization: There are two subsets to this category—the organization that has existed for an extended period of time in a strictly functional setup, and the organization that has grown organically in a very short period of time in a functional setup.

Functional organizations tend to operate in silos where divisions/units/functions have very clear, insurmountable boundaries. An OPM methodology will naturally require cross-functional collaboration, and challenges will inevitably arise at the boundaries. Departments that do not normally work together, or that work together on a very limited basis, tend to be both protective of their turf and rivalries. Similarly, they are often reluctant to share responsibility or allow outsiders into their domain.

Methodology deployment as a psychological transition

Psychology plays a significant, though often underestimated, role when it comes to methodology deployment, as it does with change in general. Success or failure of the deployment, the extent of integration into the organization, and the sustainability of that methodology can be largely attributed to the perceived benefit versus threat of the methodology to stakeholders. A stakeholder who thinks the new methodology will expose his or her limitations or shortcomings will become a catalyst for failure; whereas a stakeholder who perceives the methodology as a means of giving him or her better control over the projects for which he or she is responsible will support it, and will become a catalyst for success.

The Bridges’ (2004) transition model differentiates between change and transition. Change occurs regardless of whether people accommodate it or not; whereas a transition involves the actual transformation of people's psychological paradigms to accept a new situation. Deploying an OPM methodology requires active participation of all individuals in an organization—they have to consciously modify their practices and embrace these newly modified practices.

Therefore, when deploying a methodology, it is imperative that stakeholders are engaged, and that the processes and procedures of the methodology are introduced gradually. Milestones should be set at points at which consensus is best achieved. This ensures that stakeholders have consciously participated in and accepted the change (i.e., the new mode of operation) before moving on to deployment of the next change. A recommendation for the best outcome of this phased approach is to link the phases of the methodology's deployment with the phases of a newly initiated project or program. The merits of the new methodology should be demonstrated at the end of each phase. This progressive approach highlights benefits to stakeholders and the organization.

Perceived negative impact or threat on stakeholders

One of the most prominent stumbling blocks to any change is the perceived threat that change might have on any individual or group. The threat may be real—or only perceived as real—and it may also be direct or indirect.

Perceived threats stem from the fear of the unknown. Those who are furthest removed from OPM methodology may fear it the most, and hence pose the greatest risk of resistance. One normally expects such fear and resistance to come primarily from the project management staff.

Unconventional stakeholder groups may form as a result of the OPM methodology deployment. For instance, staff from the IT department and staff from the procurement department may come together as a unified opposing force. The driver of such organizational behavior is simply that they both have vested interests in aborting the deployment to fend off a perceived threat or number of threats. With this in mind, those developing the methodology should start the process by performing a comprehensive stakeholder analysis to ensure there is an appropriate approach for engagement with all stakeholder groups.

Impact on morale and credibility

People can easily lose motivation when asked to modify a familiar practice—especially if it has yielded positive results in the past. This applies to all stakeholders directly or indirectly impacted by the methodology. Stakeholders viewing the methodology as extra work or an unnecessary burden can also contribute to loss of morale.

Just as there are early adopters in any organization, there are skeptics. They may think that a methodology is just a fancy way of doing things or, even worse, is part of a hidden agenda. Skeptics can be detrimental to the success of the deployment and sustainment of the methodology. The skeptics’ perception of project management systemization can be compared to the resisters of automation in the 1980s and 1990s. These resisters were not supportive of technology, trying to hold on to their manual methods despite the clear and known disadvantage of manual processes. If left unaddressed, the skeptic's efforts can have a detrimental impact on the organization's planned change.

It is the responsibility of the program manager leading the deployment, along with the sponsor, to identify such individuals and develop strategies to influence their perceptions. Their efforts should be directed toward emphasizing value, mitigating opposing coalitions, demonstrating benefit in contrast with old practices, and both assessing and addressing elements of skepticism. Their goal should be to move skeptics and demotivated recipients to adopters and champions. When attempting to achieve this transition, early adopters may be mobilized as change agents to influence demotivated recipients and skeptics. In cases where the transition is not achievable, the management team should at least contain, minimize, or neutralize the negative impact of the skeptics.

Applying the Change Management Life Cycle Framework

A successful OPM deployment needs to cater to all of the above considerations. As a result, organizations have always experienced poor results when they resorted to the “here is the new methodology, you need to apply it as of tomorrow” presentation. The deployment of the methodology is an organizational change, and for that purpose should be deployed in a structured, methodical manner.

Managing Change in Organizations (PMI, 2013a) puts forward a Life Cycle Framework as a tool for ensuring that organizational change is managed within the domains of portfolio, program, and project management. This framework is useful to ensure all aspects of the proposed change resulting from an OPM methodology deployment program gives due attention to considerations discussed in the previous section. The framework is shown in Figure 2 and each of the following sections suggests recommendations for actions and activities to consider when planning and deploying an OPM methodology.


Figure 2: The change management life cycle framework from Managing Change in Organizations (PMI, 2013a).

Step 1: Formulate the deployment

Identify/clarify the need for the methodology

This is the key starting point. No matter how exciting it is for the program manager to dive into the deployment—or how much pressure initiators of the methodology are applying—if stakeholders do not realize the need for it, then all efforts may be expended in vain. While identifying and clarifying the need for the methodology and its deployment relies heavily on emphasizing the value of that methodology to the organization and the individuals involved, it is important to establish and demonstrate the link between methodology deployment and project success (PMI, 2014a).

An OPM methodology provides a set of practices that enhance project management within an organization, but more importantly, the decision-making processes associated with all projects. It helps ensure that the correct steps have been taken throughout the five project management Process Groups and that all of the organization's requirements and conditions have been thoroughly met throughout the project management life cycle. The result is an increased probability of project success and, consequently, the probability of achieving the organization's strategic goals and personal success of those involved.

Projects often create conflict, especially as a result of differing priorities and schedules. Disagreements on how projects are managed may also arise. An organizational project management methodology will inevitably address and resolve such issues, since it addresses how projects are managed, the approval process, and responsibilities. A solid methodology also provides support for the prioritization of tasks within a project, the prioritization of project work versus regular operations, and how resources should be allocated.

The program manager should exert all efforts to emphasize the value of methodology by providing concrete examples. By doing so, he or she will obtain the buy-in of all stakeholders. Such stakeholders include not only project managers and team members, but also resource managers, line and functional managers, and senior executives. Anyone in the organization who sees the level of conflict on projects as a nuisance will look forward to a successful methodology deployment if the value is proven.

Assess readiness for deployment

Once the need for the methodology has been established, it is necessary to measure how ready the organization is for the deployment. Below are six essential aspects of organizational readiness:

1. Executive sponsorship
Just as with any other program, executive sponsorship is a key role for the success of the methodology deployment (PMI, 2014b). Lack of engaged sponsorship may have a detrimental effect on the acceptance, adoption, and integration of the methodology, both in the near term and the sustained long term. An ideal environment is an organization whose top executives collectively support the program. The program manager should:

– Make sure the deployment program has enough support in the C-suite or equivalent organizational structure, and

– Ensure executive support is a continuous effort throughout the life cycle of the program.

If the program manager realizes at any point in time that any of the above is lacking, he or she should invoke activities and processes for obtaining and increasing executive support. Such processes may include:

– Lobbying with executives on the importance and impact of the methodology

– Raising executive awareness of the importance of their support of the deployment

– Communicating actively and clearly the impact of their support on the deployment process, and equally the impact of their lack of support

– Communicating actively and clearly the status of the deployment process and what requirements are reliant on the support of the executives

2. Assessment of needed organizational structures
This is a two-fold exercise. First, the program manager and team need to assess and verify the existence of such organizational structures. Second, once the structures are proven available, the program manager and team assess the capabilities of those structures. Table 1 lists those structures and the desired level of readiness for each.

Structure State of Readiness
PMO Autonomous; on par with other functional units; strong leadership; equipped with tools and personnel required for a successful deployment; staffed with multiple levels of credentialed members.
Program management team Centralized management and support from within the PMO; integrated roles within the organization at multiple levels.
Sponsorship structure Program sponsorship—a single individual at a minimum, but ideally a committee or group representing the recipient organization(s) and support organization(s).

Table 1: The desired levels of readiness for organizational structures.

3. Cultural assessment
As noted earlier, culture is a strong influence that can be difficult to change. It is important to assess the existing culture and, as much as possible, adapt the methodology to the culture.3 However, it is likely that some aspects of the culture will need to be changed and this will take some time and forethought. Managing Change in Organizations (PMI 2013a) provides information that can be used to help influence the culture to support change (p. 19). Table 2 suggests ways in which this guidance might be applied to the deployment of OPM methodology.

Influencing Culture to Support Change Applied to OPM Methodology Deployment
Assess stakeholder change resistance and/or support for the change and actively addressing any of the gaps. Address possible misconceptions of the deployment, tactfully manage adversity, and foster support and advocacy of others throughout the organization.
Ensure clarity of vision and values among stakeholders about the change initiative. Demonstrate the value of the methodology, what benefits it brings to the organization and what benefit it brings to the individual.
Create understanding among the various stakeholder groups about their individual and interdependent roles in meeting the goal(s) of the change initiative. Emphasize how individuals impact the success of the methodology deployment, and how they will have a positive effect on others and the organization at large by supporting the deployment.
Build strong alignment between stakeholder attitudes and strategic goals and objectives. Demonstrate how the methodology supports the organization's strategic goals and how those goals will deliver benefits to the organization and, consequently, how the individual will be positively impacted by the deployment of the methodology.

Table 2: Managing Change in Organizations (PMI, 2013a) information applied to OPM methodology deployment.

4. Policies, processes, roles, and decision-making norms
The methodology and its deployment need to integrate with the rest of the organization. If this is not the case, the organization might find itself running two sets of processes or implementing two sets of policies that would not only be redundant, but would also create conflict and frustration. The program team needs to identify and analyze the policies, processes, roles, and decision-making norms within the organization to determine whether or not those elements exist, and if not, whether they need to be created to serve the methodology. For example, a methodology may rely on performance appraisals based on key performance indicators. If such a performance management system does not exist, it may need to be created.

If such policies, processes, roles, and decision-making norms do exist, the program team needs to address these questions:

– Do they conflict with the methodology? If potential conflict exists, what is the adequate change management processes and at what level do they need to be addressed?

– Are they redundant with components of the methodology? If so, which should prevail, the methodology component or the legacy process?

– Are they supplementary or complementary to the methodology and its components (meaning that they exist, are not in conflict, and are not redundant)? What are the points of integration with the methodology (interface points)? And, what actions are required for seamless integration?

5. Deployment agenda
This is one of the inputs to the deployment planning process. The intent is to evaluate the magnitude of the deployment and assess whether the organization is ready for it. Depending on the level of disruption the deployment will cause, and the organization's ability to withstand such disruption, it may be beneficial to conduct the deployment in a condensed manner. However, it may be necessary to break down the deployment into smaller “bursts,” deploying portions of the methodology in sequential order in an attempt to reduce disruption as much as possible. It is very important that, as part of this process, the program management team takes into account:

– The organization's focus and capacity to perform its core business unencumbered; and

– The organization's focus and ability to deliver other programs and projects.

6. Resources applied to the deployment and the role of the PMO
Part of assessing the readiness for the deployment is assessing whether or not the organization possesses and can allocate the appropriate resources. One common mistake in this respect is that organizations tend to focus on deploying the methodology with a focus on the utilization of in-house resources and their ability to do so. However, the program management team should first clearly identify the needed skillsets and experience for the deployment, and then seek to fulfill those needs either from within the organization—if such resources are available—or from external parties if they are not readily available from within the organization. The assessment of resource availability needs to address these questions:

– Does the resource possess the required skill sets?

– Does he or she have the time to perform the role thoroughly?

It is important to avoid the “off the side of the desk” syndrome where resources are asked to deliver change in an organization alongside a myriad of other activities. This approach gives the deployment very little focus and time and reduces the methodology deployment to a lower priority due to conflicting goals and schedules. At this stage, the program manager needs to make sure that all such situations are eliminated and negotiate with line managers and executives for the availability and allocation of the right resources for the program from beginning to end.

The PMO, if one exists, plays a crucial role in any project or program activity. But, in this case, the significance of the role of the PMO is elevated due to the subject matter. The PMO's role can be broken down into the following:

– Providing resources that support the program and project management team with executing the change

– Piloting the methodology deployment, providing a safe environment for the initial stages of deployment of any component of the methodology, and championing the deployment at large

– Providing continuous assurance and feedback on the alignment of the methodology to the achievement of the organization's strategic benefits and benefits realization management

Delineate scope of deployment

Once the organization's readiness has been assessed at multiple levels as indicated above, and the appropriate structures and resources are secured, a detailed scope delineation and definition exercise needs to be undertaken. This process should follow in tandem with the readiness assessment to ensure that the team is not misinformed and that the scope is in alignment with the state of the organization.

Identify phases and iterations of methodology deployment
This includes both phases of product scope as well as phases of program scope; for example, the program management team may wish to deploy parts or components of the methodology in a sequential or phased manner such as “project risk management, project procurement management, etc.” as well as create a number of phases per component, for example:

– Introduction

– Training

– Partial application and coaching

– Complete application and coaching

– Monitoring and coaching

– Disengagement

Define anticipated benefits and means of realization, create benefits breakdown structure
Although this would have been done during the identification and emphasis of the need for the methodology, it is important to articulate, identify, and possibly quantify the benefits anticipated. It may be beneficial to further segregate all such benefits into categories (e.g., governance and control, resource management and allocation, increased project success rates, reduction of onus, reduction of conflict) and then create a breakdown of each category.

The second step would be to create sub-benefits by breaking down each category into individual benefits (again seeking quantification where possible) and then mapping individual benefits to specific methodology components. This would create a benefits realization map, identifying which parts of the methodology would result in the realization of which benefits in whole or in part.

Identify indicators of successful deployment
Many of the benefits anticipated from the deployment of a methodology are often intangible. To that end, quantifying benefits and their realization may prove challenging. Part of the planning process should be the identification of scope verification (i.e., Are we doing the right work?) and benefits tracking (i.e., Did we achieve the right results?) mechanisms to help the program management team and stakeholders gauge progress and success. Such indicators of success may include:

– Reduction of time to address issues on projects from 5 to 2 business days

– Increased rates of project business case approvals by 15%

– Reduction of time to conclude project procurement activities from 4 to 2 weeks

– Reduction of percentage of project budget overruns by 5%

– Increased participation in risk identification and analysis of internal stakeholders to 75%

– Increased use of the project management information system by 50%

(Note: The numbers and percentages in the list are for illustrative purposes only. They are by no means indicative of what the actual outcomes should be or may be for all OPM deployment programs.)

Step 2: Plan the deployment

Taking inputs from all the above processes, this process is the creation of the actual plan for the program. In this process, two standards play a fundamental role: The Standard for Program Management (PMI, 2013c) and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (PMI, 2013d) in their current editions at the time of the deployment.

Define the deployment approach

The defined approach takes into account the general approach of the deployment, the number of components and phases of the methodology, and the work needed to deploy the methodology. The program management team needs to agree on the sequence, intensity, work, and roles and responsibilities at each stage, and do so with the involvement of the relevant stakeholders throughout the organization.

Organizations accustomed to project and program management sometimes take internal projects and programs lightly; however, the deployment should be treated with the same level of diligence and rigor as any other program. That means a full-fledged plan developed, expanded, and regularly revisited to ensure the success of the program and its component projects. The plan should include all sub-plans, and should also allow the program manager the flexibility to create, change, modify, and terminate component projects if and when needed to realize the benefits anticipated from the methodology. This would become especially useful in cases where certain recipients (or other stakeholders) require certain work to be performed in their specific context. For example, the finance department might require additional training on the new project procurement process, or the reengineering of a specific internal process to match the requirements of the methodology.

In all cases, the program management team would need to define the leadership style that they would need to follow in each situation (i.e., directive, supportive, coaching, or laissez-faire) based on context throughout the deployment and depending on the stakeholders involved.

Plan stakeholder engagement

It cannot be assumed that just because the organization has invoked a process for the deployment of OPM methodology that members of the organization have a common understanding of the need for the methodology. Some members of the organization may be under the impression that the deployment of the methodology only affects the project management staff and that they have no role or activity during the deployment. Therefore, the program manager needs to identify and clarify the need for the deployment by:

Identifying all stakeholders. Senior management, recipients, integrators, sponsors, as well as individuals who will be affected by the methodology but are not direct recipients of it.3

Engaging all stakeholders. The intent of engaging stakeholders is to:

– Understand their perception of the methodology;

– Clarify any misconceptions they may have;

– Address and eliminate skepticism; and

– Demonstrate the need for the OPM methodology.

How the engagement is carried out depends on the politics and culture of the organization. The purpose is to render the exercise successful in light of the organization's dynamics. In some organizations, combining the CEO with junior team members in the same workshop works, whereas in other, more power-distant cultures, this would have an adverse effect on attendees. Therefore, it is necessary to gauge the organizational culture before designing these activities. Once everyone involved in the organization understands why an OPM methodology is needed, and the value it will bring to both them and the organization, the program management team can start the deployment.

This is not to say that the engagement is a one-time effort. Since methodology deployment impacts, and is impacted by, a large number of stakeholders across the organization, it is important that the program management team devises a series of communication and engagement activities at different stages of the program life cycle to involve stakeholders and address expectations. The engagement plan needs to be consistent with the status of the deployment and not too frequent or burdensome for the stakeholders.

Engagement activities are best devised in a manner that preempts situations and prepares stakeholders. For example, by telling people “as of the beginning of next month, all project business cases need to be sent to the finance department for approval before sponsor sign-off and project execution,” you will be sending the message that “in the near future you will change the way you work.” Obviously this is important, and has more positive impact than would an unanticipated de-facto command. For better impact, you would follow the message with “this is to ensure that the organization commits the required budget at the appropriate time, and avoids any delay to your project.” The latter would not only enhance stakeholder management, but would also promote buy-in for the methodology and its deployment.

One of the primary objectives of stakeholder engagement is to set expectations before starting the deployment and thoroughly manage those expectations throughout the deployment. The Project Stakeholder Management Knowledge Area in the PMBOK® Guide (PMI, 2013d) is a useful tool for engaging stakeholders of the OPM methodology deployment program as early as possible.

Just as with any program or project, it is important to establish a unified understanding of who the stakeholders are and what they expect. Accordingly, the program manager defines engagement and management tactics to positively influence perceptions. The PMBOK® Guide (PMI, 2013d) notes that good stakeholder management includes identifying “people, groups, or organizations that could impact or be impacted by the project” (p. 391).

Could impact: Refers to people, groups, or organizations that could affect the methodology deployment either positively or negatively—positively to the extent of success and negatively to the extent of premature termination.

Could be impacted by: These are people or groups whose practices will or may be changed as a result of the methodology. They can be internal or external to the organization. This category of stakeholders includes those who believe that the methodology might have an impact on their practice, although such belief might not be true.

In either case, it is important that the program management team be aware that stakeholder categorization is not mutually exclusive in that stakeholders can fall into both categories. The categorization is also not constant in that the stakeholder who falls into one category at a point in time may move into the other category later. This may even become an iterative process, whereby stakeholders fluctuate from one category to the other more than once during the deployment program. The reality is that stakeholders can fall into any of three possible groups, as shown in Table 3.

Because a methodology is a soft deliverable and should be constantly updated and improved, migration of stakeholders between the three groups may happen with little or no awareness on the part of the program management team. A savvy program management team works with stakeholders to move and then retain them in the group that best serves the interest of the program and the stakeholder.

Impact the methodology but are not impacted by it Have impact on and are impacted by the methodology Impacted by the methodology but have no impact on it
Board members and other senior executives who require reporting in a specific manner The project management office (PMO) Project team members who are tasked with the performance of project tasks under the supervision of project managers
Regulators or other external parties that have compliance requisites Program and project managers and management teams Members of departments who interact with the project, such as accounting or procurement staff

Table 3: Examples of three groups of stakeholders.

To cater to the needs of stakeholders, the program manager must first seek to understand them and their concerns. Table 4 is a summary of the typical types of stakeholders associated with an OPM methodology deployment program and gives examples of how the program manager can solicit and sustain their support.

Segment Nature of Requirements How to Secure/Address
Executive Stakeholders Demonstrated assurance that the program management team is capable of delivering the program objectives. Follow a methodical and structured approach to managing the change, adopt best practices, and use a program management framework.
Demonstrated assurance that the program management team is committed to delivering the benefits. Demonstrate perseverance and proactive management of issues and challenges that arise. The team takes responsibility for performance of the deployment, adoption, and integration. No blame is unduly attributed to others.
Program Management Team Members Capability assurance Same as above.
Leadership assurance that the program team members are in good hands Team members need to be assured that when confronted with issues, resistance, and skepticism of their colleagues, the program manager will be there to support, guide, and coach them.
Significance and appreciation That their contributions to the deployment process are significant and appreciated; that their feedback is being used to contribute to the planning, adjustment, and enhancement of both the methodology and its deployment; that their contributions are being cascaded to the recipients of the change; and that their work is in alignment with the overarching strategic objectives.
Recipients Compliance Assurance that the methodology does not violate their compliance to other standards and regulations as applicable to their roles.
Indemnity That no harm will be inflicted upon them through the deployment of the methodology. They will not be made redundant and will be trained on the needed skills to be able to deliver the methodology.
All Three Types What's in it for the organization? Communicate how the methodology will help the organization; enhance its profitability, market share, competitive advantage; or otherwise impact it in a positive way. Methodologies typically enhance resource utilization, shorten time to market, improve governance, and provide assurance.
What's in it for me? Communicate how the methodology will have a positive impact on the stakeholders’ professional lives: have more control over their projects, simplify currently tedious processes, emphasize their roles, expedite otherwise time-consuming processes, give them higher exposure or assist them with day-to-day challenges and questions on their projects, and how the methodology reduces bureaucracy.

Table 4: Suggested engagement actions for the three types of stakeholders.

Plan transition and integration

Part of the planning for transition and integration is to delineate requirements for coaching, training, and support. This occurs in synergy with the “delineate scope of deployment” step discussed earlier. The program management team identifies, lists, and measures the requirements for each member of the organization requiring coaching, training, and support at the various stages of the deployment.

Each component of the methodology would need to be “graduated” from the deployment program into the practice of the organization. Many practitioners involved in methodology deployment mistakenly assume that this will come as part of the process without the active planning and management of such processes. However, the program management team needs to plan this carefully, along with the integration life cycle of each component.

The most common manifestation of a mismanaged deployment is that once the support and coaching subside, the recipient stops using it. This is not a fault on the part of the recipient as much as it is the lack of transition processes.

Step 3: Implement the deployment

Having defined and clarified the need for an OPM methodology and developed the plan for its implementation, it is now time to execute that plan. As noted earlier, developing and deploying as a program rather than a single project allows for a progressive approach and also keeps the focus on benefits realization. The program domain is well suited to initiating multiple projects for different aspects of the methodology and measuring the contribution of benefits to the organization. It also allows for adaptive modifications as the program progresses. The framework reflects the ongoing monitoring and adjustment as feedback loops, where outcomes are analyzed and the results influence further planning and implementation.

Prepare the organization for the deployment

Preparing the organization involves various processes prior to the deployment of the methodology, or any specific component thereof. It includes the identification and announcement of activities and milestones that will occur, and their impact on the organization, stakeholders, and current practices. Preparing the organization for the deployment also includes identifying what work is required in the short, medium, and long terms. This step sets expectations and gives stakeholders enough time to prepare without risking the loss of support. It also helps to reduce resistance to the change.

Mobilize stakeholders

Before the deployment can actually take place, the required resources need to be brought on board and mobilized. The program management team needs to inform all such resources of their specific roles, when and how to perform them, what outcome is required, and how that outcome will be assessed. Stakeholders were engaged early on in the planning process. It is now time to mobilize them as agents of change as each component of the methodology is deployed across the organization.

Deliver methodology outputs

Implementation is the creation and delivery of the components of the methodology, and the performance of all activities necessary to support those components. It includes training, coaching, negotiation, and lobbying. As will be discussed in Step 4, the implementation does not end with the delivery, but must also transition the utilization of the methodology into business as usual.

Step 4: Manage the transition

Implementation is not simply creating the methodology and handing it off hoping that it will be used. Successful change for the long term is only possible when the components of the methodology deployment are embraced by every part of the organization and it becomes the ongoing, de facto practice of everyone in the organization. Therefore, it is important to plan for the transition and monitor the uptake of the methodology to ensure the change sticks.

Transition methodology into business as usual

Transitioning is the implementation of the methodology and its adoption to becoming a standard practice within the organization. It is best conducted first on a pilot project of high significance to the organization. The methodology is applied to the pilot project from implementation through close out of the project with a special focus on comprehensiveness, thoroughness, and clarity of the implementation. The process must be guided by and supported with extensive communication, training, and support of stakeholders throughout the implementation.

A continuous improvement plan should also be developed and launched to ensure that the methodology is kept current, relevant, and tailored to the needs of the organization long after the initial deployment. The plan might propose an approach to continuous improvement using the plan-do-check-act continuous improvement cycle. The inputs to this process include internal and external factors:

Internal to the organization

– Possible areas of improvement in current key performance indicators

– Possible problematic areas within the methodology causing conflict, increased burden, or decline in adoption

– Probable enhancements to reduce work, remove redundancy, or fill gaps that arise

External to the organization

– New standards and best practices

– Industry-specific best practices

– New technologies that can be adopted

Measure methodology adoption rate and outcome/benefits

As the methodology is deployed it is important to assess:

How many stakeholders within the PMO and project management teams have adopted it in their project management practice?

How many stakeholders from outside the PMO and project management teams—in functional units and vertically—have adopted the methodology?

Of those who have adopted the methodology, how many have adopted it out of compliance versus out of belief in its value? This can be gauged by the extent to which the methodology deliverables are satisfied and the level of quality of those deliverables. The goal is that all stakeholders have adopted the methodology out of belief in its value.

How many of the anticipated benefits have been realized, and to what extent?

Adjust plan to address discrepancies

As mentioned earlier, the program must evaluate the results and feed those results back to the earlier planning stage. Any and all corrective action necessary to bridge gaps identified during the pilot project implementation should be taken and the deployment plan modified accordingly for the full rollout and for all subsequent component implementations. Corrective action may be necessary on the level of the deployment (actions need to be taken to provide further training, coaching, or consulting services) or on the level of the methodology itself, which may prove to require adjustment, reformulation in certain aspects, or further tailoring to fit the requirements of the organization.

Step 5: Sustain the methodology

Once the methodology is transitioned into business as usual, there is a need to ensure the sustainability of the changed practice. If the deployment and transition have been executed well, there is a high probability that the methodology usage will be sustained by the organization. However, the OPM methodology deployment program will eventually close. The program manager should plan for the sustainment of the methodology long after program closure by putting into place supporting activities that monitor usage and the methodology's effectiveness as part of business as usual in the organization.

Ongoing communication, consultation, and representation of stakeholders

Communication, consultation and stakeholder engagement are ongoing activities from the onset of the methodology deployment program. However, it is important to continue the communication and engagement as the program closes to ensure a sustainable methodology. At this closing stage, it is also important to evaluate and adjust methodology components based on issues such as:

When to use what tools and techniques;

How to perform certain processes or use certain tools; and

What to do in cases of exceptions and outliers.

In the case where a methodology is deployed using a phased approach, this activity starts with the rollout of the first component of the methodology. For instance, if the program management team determines that it is in the best interest of the organization to first launch the business case formulation component of the methodology, then this task starts immediately once that component is rolled out, and in parallel with subsequent components.

Conduct sensemaking activities

As the methodology is deployed, the program management team needs to conduct a series of activities that prove the methodology “sensible”; or, in other words, that entice stakeholders to see the reasoning behind and for the methodology so as to ensure its continuous adoption. Although the effort associated with such activities is laborious, the sensemaking of a methodology needs to sustain communication of three simple aspects:

1. The benefits of the methodology;

2. How it achieves those benefits; and

3. How it positively impacts the organization and the individuals involved with its adoption.

Dictated efforts seldom result in buy-in. If one dictates the methodology, members of the organization may comply, but only until the reasons why they have done so are satisfied. However, if one sells the methodology, members of the organization will support it, and the end result will be sustainable change.

The success of a methodology requires that the methodology be perceived as an end in its own right. Stakeholders need to realize, value, and want the methodology to succeed, as this will solicit and sustain their buy-in and create sufficient support for the OPM methodology. Sensemaking activities help to ensure the sustainability of the methodology long after the deployment program ends.

There are multiple means of securing buy-in and the commitment of stakeholders5, as well as prerequisites to most of those means, such as trust and credibility. Initially, it is noteworthy that stakeholders with a vested interest in the methodology, its outcome, and the impact of that outcome on the organization, are easier to align and pose fewer challenges to the program management team in obtaining their buy-in. But when stakeholders are not part of the decision to develop or deploy the methodology—or cannot see the direct positive impact it would have on the organization or themselves—what they really need is to understand what's in it for them and the organization, as discussed earlier.

It should be the focus of the program manager and team to identify, highlight, and emphasize the benefits of the methodology to the stakeholders involved at a personal level, as well as to the organization at large, as part of a balanced, continuous effort from the inception of the program to the transition and sustainment efforts. They should also utilize the efforts of others to advocate for the methodology and to bring stakeholders on board. The appendix of this paper includes possible actions that various stakeholders can undertake to assist with sensemaking and ensure a sustainable outcome.

Measure benefits realization

If the organization isn't fully realizing the benefits of the methodology after it has been deployed, chances are the methodology will be discarded very soon and all investments lost. Just as it was important for the program manager to identify, clarify, and emphasize those benefits before the deployment of the methodology, it is also important for him or her to ensure that the benefits are being realized after the deployment. Failure of the program manager to deliver on his or her commitments will harm the credibility of the methodology and the team that set out to deploy it.

Check for the indicators of success and measure their degree of attainment. For example, perhaps issues on projects are now addressed within three business days as opposed to five business days. However, the target in the benefits register was two business days. Thus, there is a need to invoke actions and activities necessary to close the gap of such a discrepancy.


The deployment of an OPM methodology is best approached as an organizational change management program following The Standard for Program Management (PMI, 2013c) and guidance in Managing Change in Organizations (PMI, 2013a). Managing the deployment as a program allows for using a progressive approach, whereby elements of the methodology are developed and implemented as projects with the release into the organization in phases. The OPM deployment is a significant organizational change, so it is important to pay particular attention to preparing the organization for change and monitoring results along the way. Managing the deployment as a program further enhances the ability to monitor and adjust as the methodology is rolled out. This approach increases the probability that the methodology will be adopted in a sustainable manner.

By following the above structure, the program manager responsible for the deployment ensures that the program management team utilizes the right resources for the deployment, whether from inside or outside the organization. Consequently, the program management team is able to consider the magnitude of the deployment and the corporate culture and contextual attributes, as well as identify and engage stakeholders. The team is able to increase positive influence, eliminate negative influence, and maximize the benefit of the methodology for the organization. The deployment program needs to start with a focused effort to communicate the intent and value of an organizational project management methodology and demonstrate the value to all stakeholders, thereby increasing support and minimizing resistance.


Aziz, E. (2014). How to secure 360° stakeholder buy-in and sustain it. Retrieved from

Bridges, W. (2004). Transitions: Making sense of life's changes. Boston, MA: De Capo Press.

Combe, M. (2014a). Change agility: Readiness for strategy implementation. Retrieved from

Combe, M. (2014b). Building change agility: The strategic process for agility improvement. Retrieved from

Combe, M. (2014c). Change readiness: Focusing change management where it counts. Retrieved from

Miller, D., & Oliver, M. (2015). Engaging stakeholders for project success. Retrieved from

Project Management Institute (PMI). (2013a). Managing change in organizations: A practice guide. Newtown Square, PA: Author.

Project Management Institute (PMI). (2013b). Organizational project management maturity model (OPM3®) – Third edition. Newtown Square, PA: Author.

Project Management Institute (PMI). (2013c). The standard for program management – Third Edition. Newtown Square, PA: Author.

Project Management Institute (PMI). (2013d). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.

Project Management Institute (PMI). (2014a). Implementing organizational project management: A practice guide. Newtown Square, PA: Author.

Project Management Institute (PMI). (2014b). Pulse of the Profession® In-depth report: Executive sponsor engagement—top driver of project and program success. Retrieved from"

Richardson, B. (2014). Culture-induced complexity: What every project and program manager needs to know. Retrieved from

Whitaker, S. (2014). The benefits of tailoring: Making a project methodology fit. Retrieved from

1 See Whitaker (2014) for guidance on tailoring a methodology to ensure fit with organization culture and characteristics.

2 Richardson (2014) discusses the need for awareness of the cultural influencers—both geopolitical and organizational—and offers guidance on navigating the complexity, which results from cultural differences.

3 For additional information on assessing the culture, see the series of papers by Combe (2014a; 2014b; 2014c) on organizational agility and change readiness.

4 See Miller and Oliver (2015) for more information on building a useful stakeholder map to ensure that all stakeholders are identified and engaged.

5 For a more complete discussion of selling versus dictating the methodology, see Aziz (2014).


Managing Change in Organizations: A Practice Guide (PMI, 2013a) addresses a number of functions and activities that an organization may need to incorporate. The following tables describe the function of each entity in a change context based on that publication. The tables then explain how that function specifically maps to the methodology deployment initiative and suggests possible candidates to carry out the function.

It is important to note that the entities listed are functions and not necessarily roles. Many practitioners make the mistake of losing focus on what is being contributed by giving more weight and attention to assigning the role to an individual. One of the keys to a successful change program lies within the ability to deliver value based on functional contributions to the program regardless of who performs the function.

However, of those entities listed below, there is a clear and definite role of governance, sponsor, and the PMO. It could be argued that recipients are neither roles nor functions, but should be participants in the process from the outset for better adoption and sustainment—they are certainly participants when it is rolled out.

Governance Board

Function in Change Management Mapping of Function to OPM Deployment Typical Contributor in OPM Deployment Context
  • Provides overall oversight for the portfolio, program, or project change process, setting direction and providing leadership. Ensures that the change process remains aligned with the organization's strategic vision and direction.
  • Deals with the business issues associated with the change.
  • Ensures achievement of change outcome/benefits.
  • Sets direction and provides leadership for the overall methodology deployment.
  • Resolves conflicts and issues that arise at the business level related to the deployment of the methodology; could be interdepartmental or group focused. Issues may arise that can only be resolved at the executive level of the organization, including compliance with other regulations (e.g., conflicting policies).
  • Other means of “enforcement” may reside only at this level, for instance, the need to set key performance indicators (KPIs) for measuring adoption.
  • Ensures the methodology is deployed in a manner that best fits the requirements of the organization and delivers the anticipated benefits by assuring that the methodology is limiting bureaucracy and eliminating non-value adding activity at an organizational level (e.g., redundancy with other practices or processes).
  • Constantly ensures the methodology serves the purpose of the organization, and not that the organization needs to transform to fit the methodology's purpose (a common error when deploying new processes).
  • Governance board, either subset of overall enterprise governance board or formed on ad-hoc basis, comprised of senior executives.


Function in Change Management Mapping of Function to OPM Deployment Typical Contributor in OPM Deployment Context
  • Provides resources required for change.
  • Has the ultimate responsibility for the program.
  • Builds commitment for the change at the executive level across the organization.
  • Direct responsibility and accountability for the change needs to be clearly defined and accepted at an appropriately high level within an organization.
  • Advocates for the change.
  • Ensures that conflicts that could impede the change are resolved.
  • Assesses and mitigates resistance to the change.
  • Oversees the business and management issues that surface.
  • Supports the change by dealing with internal politics.
  • Ensures stakeholders are represented and continue to actively support the change.
  • Builds alliances across the organization to ensure successful outcomes.
  • Ensures senior management is aligned with, supportive of, and committed to the methodology. A methodology that is not deemed by senior management to add value and/or to be of necessity to the company is bound to fail. Many are not aware of the gravity of the situation when executive support is lacking.
  • Ensures senior management is astutely aware of the benefits of the methodology leading to their continuous support of the methodology, its adoption, integration, and sustainment.
  • Responsible for overarching adoption and integration of the methodology within other processes of the organization.
  • Ensures that the organization possesses, implements, and updates processes necessary to supporting the methodology.
  • Works actively to resolve conflicts that may arise through the deployment process, which are common and expected given the conflicting priorities of the different departments and positions within the organization.
  • Ensures that the program manager identifies and engages all stakeholders, managing their expectations and meeting their requirements.
  • Manages the political forces within the organization and their probable impact on the deployment.
  • Senior executive with influence and empowerment over as much of the organization as possible.


Function in Change Management Mapping of Function to OPM Deployment Typical Contributor in OPM Deployment Context
  • Not discussed in the practice guide.
  • There are multiple definitions and forms of PMO; what is referred to in this respect is the Tier 4 PMO (Aziz, 2014) that has the influence and power to define, plan, execute, monitor and control, and close out projects, while aligning them to overall business strategy.
  • The PMO would serve as the anchor for the deployment program. It may be the developer of the methodology, as well as provide the tools, techniques, and best practices for managing the program.
  • A mature PMO will have the skills and resources to apply program management best practices, thereby aligning the methodology and its deployment to organizational strategy, and ensuring delivery in the shortest time, with the most efficient resource utilization and minimal risk. Typically, it would authorize and terminate projects throughout the deployment process to ensure the methodology is deployed and modified (if necessary) to the best interest of the organization.
  • If the organization has a PMO that supports, manages, and controls projects, then that PMO will typically take on this role.
  • If the PMO does not have sufficient authority or empowerment, then an ad-hoc PMO may be formed or outsourced to manage the deployment of the OPM methodology. The program manager and the rest of the program management team should be part of such a PMO.
  • The PMO described above should be headed by an executive of commensurate position. That executive may also perform the role of the sponsor.


Function in Change Management Mapping of Function to OPM Deployment Typical Contributor in OPM Deployment Context
  • May be spread across multiple individuals.
  • Supports the overall change management process and implementation.
  • Includes coordination of the work streams within the scope of the project.
  • Ensures change management processes address the impact of requirements on business processes, workforce and infrastructure, and monitors implementation and risks.
  • Coordinates communications relating to the change to all relevant stakeholders.
  • Escalates change-related issues through the program manager for discussion and decision to the governance board or sponsor.
  • Advocates for the methodology—convinces and influences peers both formally and informally.
  • Helps deliver and facilitate any work related to the deployment of the methodology from within their immediate circle of influence, department, or function.
  • Provides critical feedback on the compliance of methodology with current processes or if lower-level detailed processes need to be changed or modified.
  • Ensures that all members of their department/function/circle of influence are aware of the methodology, able to use and/or support it, and aware of its benefits to them and to the organization.
  • Provides mission-critical feedback to the program manager on issues, decisions, successes, and failures of the methodology, as well as suggestions and recommendations for improvement.
  • Acts as the champion of the methodology within that department/function.
  • Should ideally come from different functions and departments within the organization. Optimally spread horizontally across the value chain and vertically through the organization structure.
  • Must have legitimacy and credibility. Must have knowledge of the methodology, impact, and value in their immediate span of influence.
  • A knowledgeable, popular team member with high communication skills and awareness of project management from each department involved.
  • May require training before they can actively contribute to the program.


Function in Change Management Mapping of Function to OPM Deployment Typical Contributor in OPM Deployment Context
  • Preparation and integration of the change into the business.
  • Major role in the implementation of the change.
  • Ensure that routine business activities are performed at an acceptable level during change.
  • May breakdown wide-ranging or complex change initiatives into groups of activities by business area.
  • Ensure that diverse work processes remain aligned to the overall objectives.
  • Integrators may be functional managers, executives, or other individuals, depending on the nature of the change.
  • Participate in the planning, conduct the execution, and provide feedback and implement recommendations of the methodology deployment project.
  • Responsible for performing all the work necessary to implement, integrate, and sustain the methodology in their respective departments or functions.
  • Provide the program management team with reliable estimates as to the scope, time, and cost of work that need to be done to deploy, integrate, and sustain the methodology.
  • Responsible for highlighting assumptions and constraints.
  • May lead other groups within their respective department or function to deliver work necessary to successfully complete the deployment.
  • Assist the program manager in planning and phasing the work necessary for the successful deployment of the methodology to best fit the work of the integrator's department and optimize results.
  • Best defined as the project team members. Not to be confused with the program or project management team members.
  • Assigned as ad-hoc members from the organization, coming from different departments, and reporting into the project and program manager through a balanced, if not strong, matrix organizational structure.
  • Diligent, rigorous individuals with strong knowledge of the operations of their departments and functions.


Function in Change Management Mapping of Function to OPM Deployment Typical Contributor in OPM Deployment Context
  • Active proponents and drivers of the change. May be early adopters who see the business benefits of the change and have embraced it.
  • Agents come from every area of the business and all levels of the organization.
  • Become a resource for integrating the change in their respective environments, thereby driving change into the organization.
  • Same as integrators, although might perform smaller, lower-level tasks.
  • Individual tasks may not span the entire initiative, but each task would contribute to the completion of a portion of the methodology deployment.
  • Perform all groundwork for the utilization and adoption of the methodology.
  • Their success is highly affected by the work of the leads.
  • Best defined as the project team members. Not to be confused with the program or project management team members.
  • Assigned as ad-hoc members from the organization, coming from different departments, and reporting into the project and program manager through a balanced, if not strong, matrix organizational structure.
  • Diligent, rigorous individuals with strong knowledge of the operations of their departments and functions.
  • In the case of methodology deployment, can be the same as the integrators.


Function in Change Management Mapping of Function to OPM Deployment Typical Contributor in OPM Deployment Context
  • People directly or indirectly impacted by the change. Recipients are collectively considered as one of the stakeholder groups, and their input to the change process is critical.
  • Sensemaking activities are directed toward them to help them make the transition. (Sensemaking is a combination of information received and prior knowledge and belief systems.)
  • Require attention and monitoring as the change progresses because they may foster or hinder integration.
  • In the scope of methodology deployment, recipients are a two-fold function. On one hand, their work is impacted by the methodology; on the other, their adoption of the methodology leads to its sustainment and long-term success.
  • Recipients in the case of methodology deployment can be further sub-categorized into: users, supporters, and governors.

    – Users are those who are expected to implement the processes, procedures, and tools and techniques, such as project managers and team members.

    – Supporters are those who have a smaller role, yet equally important, such as the accountants or procurement staff of the organization.

    – Governors are those who have a gate-keeping role. They are not directly involved with the implementation and use of the methodology (e.g., the CFO who has to approve funds or the internal auditor).

  • Each group must be identified separately, their requirements and expectations captured clearly, and managed closely.
  • It is important that the program manager devise and implement a series of communication campaigns about the methodology, each one targeted accordingly.
  • All users of the methodology, including those producing deliverables of the methodology (e.g., a new status report); those implementing a process of the methodology (e.g., process for planning a project); and those receiving or authorizing the work (e.g., those receiving the status report or approving the plan, or even allocating the funds to the plan after approval).

Beijing | Bengaluru | Brussels | Buenos Aires | Dubai | Lelystad | Mumbai | New Delhi
Philadelphia | Porto Alegre | Rio de Janeiro | Shenzhen | Singapore | Washington, DC

Project Management Institute
Global Operations Center
14 Campus Blvd
Newtown Square, PA 19073-3299 USA
Tel: +1 610 356 4600

©2015 Project Management Institute. All rights reserved. “PMI”, the PMI logo
and “Making project management indispensable for business results”
are marks of Project Management Institute, Inc. BRA-128-2015 (06/15)

img   Making project management indispensable for business results..®
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.

© 2015 Project Management Institute, Inc.



Related Content


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