Chapter 4 Introducing Integrated Organizational Change Methodology (iOCM TM) – Managing Organizational Change


Introducing Integrated
Organizational Change
Methodology (iOCMTM)

iOCMTM stands for integrated organizational change methodology. It is not something that replaces traditional OCM, but rather it is a way of implementing OCM that results in significantly improved project outcomes.

Traditional Organizational Change Versus Integrated Organizational Change (iOCMTM)

The conventional method for adding an organizational change management component to an existing project management methodology is done by either adding specific tasks to an existing project plan, with the bulk of those tasks being relegated to the deployment phase, or by creating a separate but parallel OCM plan. However, when best practice organizational change principles are integrated into all facets of a change implementation project plan, the benefits that can be achieved are significantly increased.

OCM experts all agree that the primary principle of OCM is that successful change must take place at the individual level, and that a commitment to individual change builds over time. Isolating organizational change management activities from other project tasks, or deferring the majority of organizational change management tasks to the end of a ­project is counterintuitive to building stakeholder buy-in, and ultimately, end-user adoption. If an organization believes that organizational change management principles are meant to be exclusively associated only with those tasks owned by the OCM lead, and as a result, are managed completely apart from all other project tasks, then they are actually saying that it is not important to focus on the people side of change until all technical decisions have been made, the change solution has been defined, developed, and tested, and the only thing left is to tell people when they will be trained and when the change will be implemented.

This narrow approach completely misses the most valuable benefit of implementing OCM. Training someone on a new tool or process does not build trust in the decisions that were used to design that tool or process, or provide a clear understanding of how this new tool or process will benefit their business unit; it does not motivate individuals to do those things necessary to ensure the successful deployment; and it does not improve ongoing end-user compliance with new processes. To accomplish these things, individuals must believe that their needs and concerns were represented and considered throughout the design and development phases. They must be given the appropriate information (information that tells them how their job will be impacted and why), along with the opportunity to have their questions and concerns addressed. Training must not focus only on how to use a tool, but on how they will use the tool in the context of their daily duties.

To ensure both compliance with new processes and procedures and maximization of solution benefits, end users will need to know they will have access to support after implementation—not just from a help desk, but also from individuals they know and trust. If these things do not take place, end users will not be prepared to make a commitment to support the change. With that in mind, it becomes clear that this conventional approach to implementing organizational change management is significantly deficient.

It is important to integrate organizational change management principles into all project tasks throughout the project, not just as part of the specific organizational change management tasks. This is because the vast majority of interactions between the project team and the stakeholders (all of those individuals who will be impacted by the change) are not associated with formal organizational change management tasks. Think about this for a moment—deliverables from a number of nonorganizational change management tasks and activities are used to design, develop, and test the change solution that will be delivered. If the individuals gathering technical requirements, designing and building the solution, and finally, testing the solution to ensure it meets those requirements, perform these tasks without considering the various stakeholder perspectives, how realistic is it to expect a solution will be developed in a way that effectively meets end-user needs, builds stakeholder confidence, and ultimately achieves expected business outcomes? If your first thought was that any solution that meets every technical requirement could not fail, then I would like to share a story I told a very skeptical technical lead to explain this phenomenon when he told me that he and his team did not need to waste their time getting input from individuals with no technical understanding of the solution. He told me that they were the experts, and as such, would know how to make the most appropriate technical decisions. I knew he loved cars, so I decided to prove my point with a story about the perfect technical team designing the perfect car.

The Perfect Design that Failed

The president of a car company had a vision for creating the most innovative, streamline car in its class. He determined that to do so, the designers and engineers would need to “think outside the box.” And to ensure this, he hired the best technical experts available, but he made sure that these experts had no previous experience in the car industry (to ensure they would not be biased by traditional car design) to come up with new, groundbreaking ways to develop this “best in class” design. In fact, he did not even want to hire individuals that had actually driven a car, just to be sure they would not be influenced by their past, personal experiences.

The president wanted to get this innovative, new design to market as soon as possible, so rather than tasking the team with designing a completely new concept car, he chose instead to start them on their journey by redesigning one of his company’s existing, top-end models. He assembled his team, and he explained their task—to create the most stunningly beautify, reliable and comfortable car in its class. They were expected to do this while maintaining the power, speed, and safety features of the existing model; redesigning and reducing the overall size of the car by 10% to improve fuel efficiency, and increasing the interior’s open space by 5% (this was a luxury car, so it was critical that the driver not feel cramped). They were given twelve months to deliver a prototype.

This newly formed team of technical experts was provided with all of the data and technical requirements they would need to succeed. They knew the dimensions and makeup of every part used in the existing model, as well as those in competing cars in that class. They understood the required technical interfaces needed to support both existing and potential secondary devices functions. To address the limited amount of time they had to deliver their end product, they set up multiple sub-teams, and assigned them to produce plans for specific groups of deliverables, but always with the requirement that their designs would integrate seamlessly with each of the other designs.

In the end, a new car was designed that reduced the total size of the previous model by 11%, improved fuel consumption by 13%, and increased the over-all interior open space by 6%. And they were able to do this all the while maintaining current power, speed, and safety levels. And on top of that, the prototype was delivered with two weeks to spare on the allotted timeline. The technical team was incredibly proud of what they had accomplished. They did not just meet their customer’s expectations—they exceeded them. Which made it all the more shocking when the president entered the prototype, and without even starting the engine, determined that the design was a failure—he was livid and the team was stunned. How was it possible that this perfect design (based on meeting or exceeding every requirement) could have failed, and how could the president make this determination when he did had not even take the car for a test drive?

The answer is very simple; this perfect design failed because there was one fundamental flaw throughout the design process. While the designers were hyper-focused on the technical requirements, there was virtually no focus on how the end design would impact the ability of a driver to actually operate the car. While there were multiple examples of this failure throughout the design, none was so glaringly obvious as the design of the emergency brake.

The technical qualifications of the team tasked with designing the emergency braking system were outstanding. All held degrees in either mechanical engineering or applied mechanical physics, so there was no aspect of this design task that they did not grasp. It was clear to them that the traditional emergency braking system could easily be redesigned to better maintain stability when stressed (for example, when a car was parked facing downhill without the wheels being turned to the curb, or if hit by another car while stopped). They were also able to maximize the efficiency of the braking apparatus used by the driver to engage or disengage the system by making significant changes to the emergency braking engagement device. They focused on creating a sleeker, more elegant design that would take less effort to engage than the existing device. To do this, they eliminated the traditional lever that required the driver to pull up, while at the same time pushing in a button on the end of the lever. Their design replaced this lever with a push button emergency braking engagement device that required 50% less effort to engage, and then they moved it from the current location in the center of the console to the rear of the console, resulting in a less cramped, more visually pleasing design. What this team did not consider was that relocating the device to this location would require the driver to turn toward the console, then reach back awkwardly to engage the brake. Nor did they appreciate that by moving the device to the rear of the console and eliminating the need for upward thrust while pushing in a button on the end of the lever, the emergency brake could now be easily activated accidently while the car was in motion by someone seated in the back seat. How is it possible that the design team failed to see these fatal flaws? This incredible oversight was possible because, even though they were all experts in their field, none of them had actually been in a car, much less driven one. Because none of them were actually “end users” they did not have the ability to see their design within the context of actual use.

Again, this was only one of the many flaws of this “perfect” design. If each of the technical teams had taken the time to discuss their design plans with the president or his representative (subject matter experts), as well as with potential car owners (stakeholders), they would have had access to the critical input needed to identify potential flaws in their design, and they could have made adjustments that would have resulted in a well-designed, highly functional prototype that people would actually be able to drive.

Yes, this would probably have increased the time needed to ­complete their design work, but the results would have been far better. You see, designing the perfect technical solution is not the same thing as designing a technical solution that perfectly meets the needs of end user.

Then, I asked the technical lead this one, critical question, “Have you, or anyone on your team, ever held the role for which this solution is being designed?” The answer, as I expected, was no. I am pleased to say he agreed to engage with business subject matter experts to review his team’s design plans prior to finalizing them, and also to involve them in unit testing, to make sure that the solution did not just work as the design team intended, but that it worked in a way that was appropriate for the end users. When the project was complete, he thanked me for helping him to understand that there really was value in taking the time necessary to engage with the nontechnical business and functional subject matter experts. He and his team now understood that they needed additional knowledge of existing business processes, and a better understanding of how end users would actually be using the solution in the course of their daily duties to enable them to create a design that was both a strong technical solution and an appropriate business tool. They all came to understand that the extra time invested in working directly with business resources would reap significant rewards.

When working with an organization to help them develop a customized organizational change management approach that will work with their existing project management methodology, it is important that they understand how critical it is to actually apply organizational change management principles to all project tasks, and not just traditional organizational change management tasks. And, once this customized approached has been designed, they will also need to institute a governance process that uses an outcome-oriented success metric, rather than a task-­completion success metric.

I found that giving this concept the formal title integrated organizational change methodology (iOCMTM) made it much easier to show that the major emphasis needed to be on integrating OCM principles into all project tasks, rather than merely adding OCM tasks to their existing project plan templates. Getting agreement that this would be the methodology that would be followed was only the first step; the second step was to provide guidelines on how this could be accomplished.

Successful integration of organizational change management principles throughout all project tasks is only possible if the outcomes (both technical and organizational) associated with each task have been explicitly defined. For example, when following a traditional methodology that focuses on task completion, providing proof that a project manager held a required executive project status update meeting would be enough to consider that task successfully completed. On the other hand, when following an outcome-oriented methodology (the governance processes used for iOCMTM projects), there would be additional criteria required to show that the meeting actually met predetermined outcome expectations. Using the same task as an example, if this was the initial meeting with the executive group, the intended outcomes may be to provide a high-level overview of the project vision, introduce the strategic plan for achieving that vision, and gain formal agreement from all executive committee members that they support the intended change, and that they will introduce the change initiative and express their personal support for the initiative in their next staff meeting. If one of the executives was not in attendance, but was represented by a direct report, the task would not be considered complete until the executive not in attendance was provided the same information and personally agreed to express support of the project in his or her next staff meeting.

Another example of how task completion metrics and outcome-­oriented metrics differ can be demonstrated using the example of user acceptance testing (UAT). On a traditional project, if UAT had taken place, the task would be considered complete. In the context of an ­iOCMTM project plan, the UAT event is only considered complete if it met previously defined success outcomes. These success outcomes would include both technical and business objectives. For example, having trained end-user subject matter experts (SMEs) as UAT facilitators; having actual end users from each functional group impacted participate in the testing; creating test scripts based on end-to-end, role-based use cases (which had previously been reviewed and approved by business SMEs); providing a mechanism for gathering UAT participant input (questions, concerns, issues, omissions, and so on), and including a process for providing post-UAT status updates on how the project team will address this input.

There is no question that using the outcome-oriented metric is a much more involved process because it requires a deeper level of thought when project tasks are being defined. However, this is the only way to ensure that project tasks are actually accomplishing both the technical and organizational goals that are necessary to move both the change solution and the organization closer to success.

Implementing iOCMTM principles on a change project requires the technical team to work closely with business resources throughout the project. This concept of requiring someone outside of the technical group to sign-off on technical requirements or provide input on design is (understandably) unpopular with many technical teams. Typical pushback includes statements such as “all of our designs are based on the technical requirements that have been formally agreed” or “this will add significantly to the project timeline” or, the pushback arguments that I hear the most “business SMEs will have the opportunity to sign off on everything during UAT, so adding this step to each testing cycle is redundant and a waste of time.”

But, it is not just the technical teams that resist this partnership arrangement. Business managers often remind me that their resources have full-time jobs and the burden of covering the loss of their time and efforts on existing responsibilities would fall to other business resources, and the business leader would be accountable for any loss of productivity, not the change initiative’s project manager. And all of this is true—assigning individuals to actively support project activities requires a substantial invest time, and business managers are rightfully concerned that these individuals will not be able to maintain their workload, resulting in reduced productivity for the business unit.

The fact is I completely understand why there is pushback from both fronts on requiring this level of business resource involvement to support obviously technical tasks. These pushbacks are based on genuine concern. This is why it is so important for the project and business teams (not just the project manager and the OCM lead) to understand the substantial, tangible value associated with adding these engagement requirements to a change initiative’s project plan. In short, the technical team will have less rework when concepts are reviewed with business SMEs before designs are completed, and business teams will be provided with a solution that improves, rather that complicates, the ability of end users to do their jobs effectively.

iOCMTM: Providing Measurable Return on Investment

In the section What Do the Experts Say in Chapter 1, the importance of organizational change management in achieving measurable return on investment was introduced. There is no standard return on investment percentage that can be expected, because both the urgency of the need for change and the cost of implementing complex change within an organization varies widely, depending on existing business factors, ultimate change goals, the type of change being implemented, the existing organizational culture, and the number of individuals that will ultimately be impacted.

The average cost for implementing significant organization change can be in millions of dollars (this can grow to tens of millions if the change is global in nature and impacts both employees and customers). From an executive leadership point of view, any investment this substantial would be expected to provide benefits that reach far beyond those tied directly to improved functionality or more streamline processes. Any organization would agree that this level of investment would be expected to result in measurable improvement to things like faster time to market, improved product quality, decreased manufacturing costs, reduction in material waste, greater regulatory compliance, improved customer satisfaction, and more innovative product design, because these are the areas that increase an organization’s competitive edge, ultimately resulting in increased bottom-line profits. While it may seem counterintuitive, achieving these high-level organizational benefits will require the project implementation team to focus on change at the individual level. Let us take a moment and understand how focusing on change at the individual level will result in better outcomes at the organizational level.

Maximum change acceptance will only be achieved if the individuals impacted both agree with the benefit of the change and comply with the changes as related to their own role and responsibilities within the organization. Unfortunately, the standard project implementation approach is to rely on end-user training immediately prior to deployment to provide the end users all the information needed to ensure their compliance. Again and again, this approach has proven to be ineffective for the vast majority of change initiatives. The reason this does not work is because it does nothing to build understanding of, or support for, the upcoming changes at the individual level. And, establishing the requisite change at the individual level has a direct impact on the six primary factors a project must address to maximize return on investment.

Most experienced project managers are very familiar with three of the impacts to return on investment—time, money, and resources—because combined, they total the cost of investment that is used in the standard return on investment calculation (ROI = (gains – cost)/cost).

However, analysis of data from thousands of change implementations shows that there are actually six primary factors that impact change projects return on investment.* The additional three factors are: end-user ability (proficiency), time between change deployment and change adoption (speed to change), and lasting change adherence (ongoing utilization). It is significant to note that the first three impacts to project return on investment are all measureable at, or immediately after deployment, while the final three impacts to project return on investment are often only measurable months, and sometime years, after deployment.

The Eight Key Elements of iOCMTM

You have just been introduced to two of the eight requirements of ­iOCMTM: integrating organizational change management principles into all project tasks and implementing a governance model that is based on an outcome-oriented success metric. I always start with these because once an organization commits to making these two changes to their ­project management methodology, they have laid the groundwork necessary to incorporate all eight iOCMTM requirements. Following is a description of these eight requirements, provided in the order they are introduced on a project.

Formal Sponsorship

While the concept of project sponsorship is not new, historically, the title executive sponsor has been used to signify the executive that approved budget expenditures for a change project. While actual details vary depending on the structure and culture of an organization, this position has been primarily passive in nature, with the responsibility for action falling on the project management team to keep the executive sponsor and his or her down-line informed on project status, milestones met, risks or issues (and associated mitigation plans), and so on.

However, best practice organizational change uses a significantly different definition, one that defines executive sponsor as a formal OCM role, with its own set of tasks and deliverables. This is a critical distinction because having strong executive sponsorship is one of the most common denominators in change success. The Project Management Institute (PMI), a U.S.-based nonprofit organization for project management professionals, teaches that actively engaged executive sponsors are the leading factor in project success. Not only does having a strong executive sponsor help to mitigate employee resistance and build stakeholder acceptance, it also ensures the project is in line with the overall corporate goals and objectives.

The role of executive sponsor is essential, but it is not the only important sponsorship role on a change project. Stakeholders look to the executive sponsor for messages (both formal and informal) to verify that the change is supported at the highest level of the organization. They look to the business managers, project team leaders, and functional and business process SMEs for evidence that the change is achievable. And finally, they look to their own supervisors and trusted peers for assurance that they will have the support needed as they implement the change. As a result, there are individuals at every level of the organization who will be required to fulfill a sponsorship role. Whether acting as a formal project sponsor, or as an informal sponsor (often called a change agent), the support of these individuals has significant impact on project outcomes. It is the responsibility of the project leaders to prepare both the formal and informal sponsors to fulfill their respective roles. This is done by inspiring a shared vision and mission of the project, a clear understanding of the impact of the changes on individual groups, and building a personal commitment to their individual sponsorship responsibilities on the project. Without this, these sponsors will not be prepared to provide the information and support that individuals need to understand, embrace, and ultimately, implement the upcoming changes effectively.

Formal Sponsorship Roles:

Individuals fulfilling a formal sponsorship role are assigned project tasks and deliverables that are included in the formal change project plan.

Executive Sponsor

  • Communicate the corporate vision and long-term business values of the project
  • Ensure senior managers understand and fulfill their role as change agents (communicating change project information, actively supporting change activities, and so on.)
  • Provide project status updates to executive leadership, and act as liaison between the project leaders and the executive leaders

Functional and Business Process SMES

  • Leverage experience and expertise to assist in stakeholder engagement, testing, and training activities
  • Share knowledge of functional and process requirements with the project team, and understanding of the change and related impacts with individuals within their respective business groups
  • Liaison between business and project team throughout the project
  • Provide at-elbow go-live support to their local work groups

Project Manager and Core Team

  • Integrate OCM best practice activities into all project plan phases or tasks
  • Identify organizational risks (and develop appropriate risk management plan)
  • Perform Change Readiness and Change Impact Analysis assessments
  • Develop outcome-oriented Sponsorship Roadmap, ­Communication plan, User Acceptance Testing, and Employee Engagement plans
  • Support project sponsors by remaining engaged, providing timely project status updates, and maintaining honest, open, two-way communication that allows for feedback to be ­considered in project planning decisions

Informal sponsorship or change agent roles:

Informal sponsors fulfill their sponsorship responsibilities as part of their regular job duties

Senior Managers

  • Actively and visibly support change initiative activities throughout the change project
  • Ensure down-line reports are committed to supporting change activities and providing adequate and appropriate resources in a timely manner to support change project activities

Middle Managers and Supervisors

  • Communicate their personal support for the change initiative while sharing messages and updates in team meetings
  • Support efforts required by their team members to fulfill change tasks (time investment)
  • Support employees through their transitions
  • Engage with, and provide feedback to, the project team and SMEs throughout the change initiative

Formalizing sponsorship roles means that actual tasks, with deliverables, are assigned to each formal sponsor, including the executive sponsor. Obviously, it can be somewhat problematic for a project manager to assign tasks to an executive or a senior manager. To be successful, this must be presented in the context of following OCM best practice to ensure the goals and expectations specifically set by that executive sponsor or senior manager will be met. In a sales environment, this would be called focusing on the individual’s WIIFM (what’s in it for me). It will also be necessary to assure these sponsors that the project team will provide all collaterals needed for every sponsorship task (i.e., messages and presentations will be drafted by the OCM lead, status updates will be provided by the project manager, and so on). Successfully moving the formal sponsors from a passive to an active role on the project is the first organizational change management task that will need to be addressed.

Clear Definition of Expected Return on Investment

Many companies show return on investment (ROI) by using this very simplistic formula: expected value = implementation of a new tool and/or process—meaning that all expected ROI will be assumed to have been met if all project plan task were complete and the change was ­implemented. Obviously, this calculation does not measure actual ROI, but it does ­provide a simple (yet virtually useless) way to show executive leaders that a project was successful.

An established and well-regarded calculation used in finance and often applied to project management is: ROI = (Gains – Cost) / Cost × 100. But, as discussed earlier, the decision to invest in change is made with the expectation of benefit to the organization as a whole. Determining expected ROI on an iOCMTM project requires that expected organizational gains be identified, including those gains that are not intrinsically tied to the business unit in which the tool or process was deployed. And, in some cases, the return that is being expected is not financial, or the financial benefit will take years to determine (i.e., higher caliber of job applicants, measurable increase in job satisfaction, establishing an effective customer outreach program, and so on). When defining expected ROI, it is critical to look at intended value from multiple perspectives: what problems or issues are expected to be solved, which functional group or business unit is expected to benefit and how, which product or service will be improved, which market segment will increase, what value will be recognized by company shareholders, which working relationships across business units will be improved, what corporate vision is being supported, and so on. By taking this broader view of value, it will be much easier to define appropriate outcome expectations for project tasks and activities, as well as to identify risks and issues that would have been otherwise missed.

Integrated Project Plan

It should now be clear that adding organizational change management tasks into an existing project plan is not the same thing as developing an integrated project plan. Organizational change management principles must be integrated into each task within the plan (not just those tasks traditionally considered to be people-focused). This requires expected outcomes for each task to be defined, and those outcomes must ­consider both the technical and the people goals associated with each task, or task deliverable. Successful implementation of iOCMTM also requires that the ­project team understand the basic principles and associated values of effective organizational change and commit to supporting those principles.

Stakeholder Engagement Roadmap

A stakeholder engagement roadmap will overlay the existing project plan roadmap and will show, at a high level, what engagement activities will take place, when these engagement activities will take place, the facilitator of these activities, and the targeted stakeholder group for each identified activity, and the intended outcomes for each activity.

Each iOCMTM project will have similar stakeholder groups and engagement activities, but some will have an additional, unique set of stakeholder and activities, dictated by the nature, scope, and complexity of the change being implemented.

Audience-Focused Communication Plan

Traditional project communication plans focus on communicating a high-level overview of the upcoming change initiative, and providing status updates on the progress that is being made throughout the project. However, because change implementations require individuals within the organization to make personal changes, this generalized approach is not adequate. Additional messages that use a variety of communication vehicles (e-mail, meeting announcements, workshops, posters, hand-outs, intra-website, and so on) will need to be added to ensure each communication is focused on providing individuals within various stakeholder groups the information they need to move closer to change acceptance. Following are some tips to ensure all project communications achieve their intended outcomes:

  • Before writing any communication, first identify the resulting outcome that you want to achieve (formal sign-off, commitment for resources, SME input, agreement of understanding, and so on), and ensure the communication provides the information and motivation the audience will need to take any action required to reach the intended outcome.
  • Plan ahead—communicate the information necessary to prepare people for what will be happening next and be specific about what will be expected of them at that time.
  • Choose the right messenger for each message to improve intended outcomes. Research shows that high-level organizational impact messages are best received when delivered by an executive, while employees overwhelmingly prefer personal impact messages come from their direct supervisors or a trusted advisor.
  • Communicate information to each group in a way that addresses that group’s collective WIIFM (What’s In It For Me). Remember, an executive is not interested in or ­motivated by the same things as an end user.
  • Provide opportunities for audiences to give feedback and develop a formal response procedure to ensure follow-through (a closed-loop process).
  • Expand your communication plan to include secondary stakeholders (i.e., human resources, facilities, training, purchasing, customers, and so on) that will be impacted by the change.

Formal announcements and project updates are only a fraction of the communication that must be planned. Every document, presentation, meeting, workshop, demonstration, or phone call that relates to, or even mentions, the change initiative will send a message. Work closely with formal and informal sponsors to provide communication collateral and to ensure messages are audience-appropriate and are sent using the best communication venue (some examples are as follows).




Cafeteria ­postings

Comms cascade



Plasma screens


Fact sheets


Focus groups

Group meetings

Hallway ­conversation

Information fairs



Lunch and learns






Project fairs

Recognition events

Road shows


Site visits

Status reports


Success stories


Team meetings



Text messages

Town hall meetings

Training courses


Voicemail messages

Webcasts and


Word of mouth


Outcome-Oriented, Gated Governance Model

An iOCMTM governance process is based on a gated review model, meaning that, at the end of each project phase, the project management team must provide proof to the governance board that all tasks have achieved their intended outcomes and that all milestones expected in the project phase have been met. This gated review model relies on a go or no-go decision by the governance board, and a project cannot proceed to the next phase without a go decision. While I have never seen a project completely stopped (although I have heard of this happening), at a minimum, there must be an agreed plan for completion of all outstanding tasks for the project to pass a review gate.

Formal Resistance Management Plan

There is a common misconception that, regardless of how individuals feel about any given change, if the organization has decided to move forward, people will have no choice but to support (or at the least, accept) the change when the time comes. Extensive research shows that this is not the case, and my personal experience confirms this. I have found that, the more complex and far reaching the change, the more end users will be motivated to find a way to work around it. In fact, I have never met a developer, designer, engineer, or manufacturing lead that could not find multiple ways to circumvent mandatory process changes that they found personally restrictive or unnecessary. And, if they can convince their managers that their way is better (faster, easier, provides improved results, and so on), these workarounds (noncompliance) will become the informally approved processes that will be used by that manager’s team.

But, resistance is not confined to end-users issues. There are significant triggers that can take place at the leadership level. These can be related to budget redistribution or a reduced focus on other projects that, as a result, negatively impact a leader’s priorities, unanticipated change in business circumstances or goals that are now not in alignment with the change initiative’s stated goals, or even concerns by an executive that successful implementation of the change will reflect badly on them or their group, or that successful change will give a peer a better chance at promotion. There will always be resistance (some end-user issues and some leadership issues) that falls outside the authority or ability of the project management team, but even these issues must be addressed in the iOCMTM resistance management plan.

There is one other trigger to organizational change resistance that is extremely difficult to overcome, and the resulting resistance crosses all stakeholder groups. When an organization has a history of one or more failed change initiatives, it will be much more difficult to garner the necessary support for any following change initiatives. Past experience has taught individuals at every level within the organization a very painful lesson—time, money, and effort spent to support change will be wasted. Often, this is not expressed openly. In fact, it is not uncommon for these stakeholders to appear to be supportive. But, when the time comes for leaders to tell their down-line reports, they expect them to support the change activities by providing the necessary business resources when needed, they will often add caveats like “but not at the expense of productivity;” or “it should not negatively impact our group, but if you think it will, let’s discuss what we can do about this;” or “just come to me if you have any conflicts and I’ll see that they get worked out.” In these cases, leaders have created an environment in which managers will feel empowered to choose not to assign SMEs to support project activities, and the general belief that their down-line can disregard any updates or messages regarding the change initiative that require them to take action.

Leading a change initiative that follows one or more failed change projects requires an increased effort to identify and mitigate stakeholder resistance. Visibility of project sponsors; one-on-one meetings with impacted business leaders and managers; active, two-way communication throughout the project; and a robust effort to recruit change agents throughout the organization are all common elements of an iOCMTM resistance plan, but in this situation, the quantity and level of engagement of these activities will be much higher.

An effective resistance management plans will include the following:

Resistance Prevention

Using the shared circumstances, incentives, and values information that was gathered during the stakeholder identification process, some resistance points will be obvious. For example, if a group is incentivized financially, based on the number of widgets that they ship daily, and the shipping process will have added steps to improve quality and reduce returns (but reduce initial output by 5 percent), you have a point of resistance. In this case, resistance prevention would be to update the incentive program to support the time taken to follow the new processes (i.e., tying incentives to reduced returns).

Proactive Resistance Management

Proactive resistance management addresses issues at the time they arise, ideally before the final design or implementation decisions have been made. Because resistance can happen at any level within the organization, and at any time during the project, a forum for providing both positive and negative input must be put in place. These forums can be formal meetings or workshops, informal discussions, or anonymous surveys. And, they must take place regularly throughout the project. Business and personal circumstance change, and without open communication, the project team will be unaware of these changes—and, as a result, unable to be proactive in addressing them.

Issue Resolution

Even with a concerted effort to engage all stakeholders throughout the project and provide forums for them to express their questions, concerns, and suggestions, resistance will still take place. When resistance is not immediately identified, it moves from an anticipated risk to an actual issue. If an issue is not identified until the change solution has been deployed, the issue resolution process is much more difficult. Regardless of the project team’s feelings about the validity of an identified issue, it is important that all it be acknowledged and addressed. If the issue is associated with an actual flaw in the design or testing or training associated with the change, and is identified prior to change deployment, then the project team will need to make every effort to correct the issue before the change is implemented, and that risk resolution plan must be shared with the impacted stakeholders. If it is not possible to correct an issue before the change solution has been deployed, a temporary workaround will need to be developed and the short-term workaround and long-term solution communicated.

Post-Deployment Support

The roots of a robust post-deployment support strategy are planted very early in project activities. By engaging with functional and business SMEs from the beginning of the project, leveraging their expertise, involving them in various aspects of requirements gathering, solution design and development, and finally, testing and training, they will be fully prepared to provide at-elbow support to their local end-user groups during and immediately after change solution deployment.

* Prosci blog - three-factors-of-change-which-define-or-constrain-project-roi

Project Management Institute and Boston Consulting Group. October 2014. Executive Sponsor Engagement: Top Driver of Project and Program Success, 2. ­Newtown Square, Pennsylvania: PMI/BCG.