How important is it to manage business & organizational risks in large business transformation initiatives?

Ever seen a project where the solution that is left behind is worse than the one it replaced? Some typical excuses (pardon the sarcasm):
- The stakeholders are “ the source” of the problem [when they were not properly engaged as the project team made decisions that were shortsighted, poor decisions with foreseeable negative impacts that ended up causing far more harm to the business than generate benefits]

- Stakeholders are “resisting” change [instead of blindly embracing the (sometimes shortsighted) solution that’s being implemented]
- It would cost too much money and time to customize the new solution so that it offers the same highly customized features and convenience than the one it replaced [therefore the project team implemented an off-the-shelf solution that is clearly worse than the one it replaced but it did it on time and on budget –sometimes even that doesn’t happen]
- … (there are many others )

Sometimes an “us” (project team) vs. “them” (business/organization) mentality can develop during the long implementation of large, complex business transformation initiatives. There are various reasons why things can evolve to that point and usually both parties contribute to the exacerbation of the situation but I typically blame the project team. The reason is simple: they should know better. The project team should not assume that because they proliferate their project propaganda (aka “project communications”) that the impacted stakeholders will bite and automatically believe the rosy image that is painted of an idealistic future state. Most large organizations have seen the havoc that can come with poorly managed business transformation initiatives and people don’t just swallow the Kool-Aid anymore. Project teams need to go beyond the 1-way communication/propaganda and invest time in properly engaging the impacted stakeholders. 

I recently came across an interesting comment that was left after a re-post of the presentation I used in my last PMI LEAD CoP webinar (“A Risk Management-Driven Deployment Framework for Project Ownership/ Accountability”). As I was replying to the comment, I thought the issues that were raised would be good topics for my next blog.

The comment touched on 3 areas that relate to the relevance of managing business & organizational risks in large initiatives:
[A] It is fine to have the stakeholders involved in managing risk but if the stakeholders themselves are the source of the risk then the management may not occur. The stakeholders may choose to not acknowledge the full source of the risk.
[B] The second potential issue may be stakeholder fatigue. If the stakeholders are required to address every business risk they may become inundated with detail. The flip side is that the designated stakeholders my [may?] not have sufficient authority to implement change which can lead to unnecessary inflation of the decision-making process.
[C] It is important to note that almost every project management methodology and change management methodology believes in engaging the stakeholders. The deviations occur in how the risk vs. output is managed. While managing risk is important it is important that risk management is not a primary goal. This if the major goal is to manage risk then that will become the goal of the project. This could in turn instill an almost legalistic perspective to project management.

I feel that the thoughts expressed in the comment are mainstream. I decided to expand on my original reply and write a blog out of it. Just a little context… The approach I presented back in September was designed for overly long and complex projects where some of the impacts/side effects of an initiative are not clear and organizational risks are fuzzy. I’ve used this approach many times in the past decade and it bodes pretty well with these types of business transformation initiatives. I’d say it wouldn’t be worth it to roll out that much effort for a short and straightforward project.

I explained some of the main concepts behind the framework my last blog: Leveraging stakeholder input to continually identify, assess, mitigate, and manage deployment risks can foster buy-in, shared ownership and joint accountability. The advantage of using such an approach allows for the early identification and mitigation of potential risks and issues that come up during the deployment. This DOES NOT mean that the project team always does what a group of stakeholders wants; but it requires a lot of listening and a lot of dialogue. The most challenging part is that the project team must partner with the business and for this symbiotic relationship to work well, the project team must relinquish some control. I have worked with project managers who are simply unable to do that, they feel they must control everything, and they end up excluding the business from major decision points that have significant impacts on operations. Once these project managers made a decision, then their definition of “change management” is to shove their decision down the business’ throat. If concerns are raised by the impacted stakeholders, they identify the concerned individuals as “resistors”, heretics who are resisting the path to change.

[Notion #1] Claim that stakeholders don’t want to be accountable - Involving the stakeholders in the risk management process is very useful, especially when they are pegged by the project team as “being the source of the risk”. I believe not doing so can be the source of many problems on large, complex initiatives. Some PMs don’t properly manage the organizational and operational impacts of their initiatives. Typically, things that get scrutinized and focused on are the factors that can directly be measured and whose impacts can be felt in the immediate: schedule and budget. Most organizations don’t really have a robust benefits realization framework in place, therefore, organizational and operational impacts can sometimes perceived by some project managers as collateral damage that will not come to light until well after the project’s closure. Why attempt to proactively identify, and mitigate issues that may not appear until a project’s closure? Why bring to light potential business and organizational impacts when the sponsor seems to only be interested in wrapping up the project on time and on budget? The easy thing to do is to say that the stakeholders are the source of the problem and leave them to deal with it after the project team has left. In all honesty the project team can’t be fully blamed for the scenario described above if the main metric that is being used to assess its success is adherence to the schedule and the budget. Poor sponsorship and poor governance structures can contribute greatly to this mindset and in some cases, the sponsor(s) and the executives who are part of the governance structure simply don’t know any better.

One of the main tenets of the approach I presented is to get to the point where the stakeholders are an integral part of the risk management process, and are able to help identify, understand the risks and acknowledge their role (as impacted stakeholders) in the mitigation of these risks and issues. I believe that’s where some of the real skills of a change manager lie. I feel that having a project team simply say that the stakeholders are “choosing not to acknowledge” their role or responsibility is a cop-out on the part of the project team and it’s a problem that plagues a good number of initiatives. It’s the responsibility of the project team to change the mindset, it is not the responsibility of the impacted stakeholders to blindly accept everything they are fed. Getting the stakeholders to understand their role in managing the change, equipping and supporting them (stakeholders) so that they can actively participate in the mitigation of potential risks/issues that may have negative impacts on them (stakeholders) is what stakeholder management (and change management overall) should be about.

[Notion #2] Claim that if stakeholders are engaged, stakeholder fatigue will set in - Stakeholder fatigue is a potential risk that should be monitored and managed as such but if stakeholder engagement is done properly, and taken to a level where the project team and the stakeholders are partners, it really becomes less of an issue. Again, that’s one of things that differentiate an excellent change strategy from a mediocre one. In a lot a cases, the stakeholders are not really given a seat at the table and have no real say in decisions that will impact them for years to come. The latter creates an adversarial relationship between the impacted stakeholders and a project team that is attempting to IMPOSE change on the organization. The framework I presented identifies (stakeholder) “Enablement” as the second most critical component of the approach. I always stress the importance of this construct whenever I present or write on the topic.

I would like to refute the idea that “if the stakeholders are required to address every business risk they may become inundated with detail”. That’s what good stakeholder stratification is all about. It’s not the same stakeholders who help address and mitigate all business risks: issues and risks are divided and channeled to the appropriate party(ies). With the right framework in place, no one gets more than they can chew, the approach that is put in place should be able to monitor the environment and ensure that stakeholder groups are not overburdened. If there is potential for that situation to arise, then it’s a risk and it should be mitigated. There are various ways of dealing with such a situation.

[Notion #3] The (relative) importance of managing risk in a large transformation effort – If one looks at papers and books that have been published in the past decade, risk management is typically highlighted as a critical component of project management. Project managers are constantly managing elements that may impact their schedule, the budget, and the scope of their initiatives; I consider that risk management. That form of risk management couldn’t be more explicit: the PM is managing risks associated with time and money, two very precious commodities on a project. What I am suggesting is that the risk management approach that is used in large business transformations should be robust enough that it can help detect and mitigate “fuzzy”, less defined, less predictable, more ambiguous types of business & organizational risks that can throw a monkey wrench in the execution of large initiatives. Whereas risks that will directly impact the schedule and budget can sometimes be easier to identify and quantify, risks that will solely impact the organization (and are the results of project-related decisions) are more difficult to properly anticipate by the project team. Proper stakeholder engagement is a key enabler in that area. Continuously managing divergent needs, addressing the stakeholders’ perceived risks and issues, helping them anticipate potential problems that may not surface for months after the project’s closure, … is HARD but that’s what competence in the change management area is all about (or better yet, I feel it should be). As I mentioned in past blogs, I’ve always been a proponent of looking at impacts 2-degrees remote. By that I mean leveraging the stakeholders to identify impacts to their daily grind but also educating them so that they can identify residual impacts on their own stakeholders: this means that the impacts of the project are identified 2 degrees remote (direct impacts to the stakeholders and indirect impact to the stakeholders’ stakeholders).

Whether project managers like it or not, at the end of the day, project success is in the eye of the impacted stakeholders (these stakeholders can be part of the organization, they can be customers, regulators,…). Their perception determines whether the project was successful but then again, if a project team’s philosophy is “I’ll be gone by then”… then it doesn’t matter, does it.

Looking at studies that have been conducted over the past decade, 2 out of 3 initiatives that aim at changing the way a business operates fail to fully achieve their goals. We need to move away from certain aspects of mainstream thinking and move more towards approaches that leverage stakeholder engagement and stakeholder input to continually identify, assess, mitigate, and manage business & organizational risks which in turn can foster buy-in, shared ownership and joint accountability.

A Risk Management-Driven Deployment Framework for Project Ownership/Accountability

Over the past few months, I have written a couple of blog entries on the importance of incorporating change management as a key component of projects that aim to transform the way an organization or a group of people operate. In my last webinar with the PMI LEAD CoP I highlighted the importance of (1) developing a highly customized and systemic approach to proactively identify and mitigate change-related risks and issues and (2) establishing an environment that is conducive to sustaining the change-related elements. The presentation from the previous webinar is available on the LEAD CoP website (and is also available on my LinkedIn page). The main components of the framework are highlighted in the following figure.

A well designed Change Management (CM) strategy will complement a project plan like a glove. Organizations are made of human beings, some reactions are driven by decisions that are not always logical and not always predictable. When it comes to stakeholder management, projects that enable change must be able to address unexpected challenges. At the end of the day, a good CM strategy should help identify risks and mitigate issues stemming from the (sometimes) unexpected quirks of human nature. The adaptive nature of a good CM strategy will help identify and address unexpected challenges that come up during a deployment. Unlike a project plan which is more rigid and structured, and may have difficulty adapting to issues that were not foreseeable when the plan was drafted, the change management plan should be designed so that it is easily adaptable and the elements of the plan can effortlessly be re-prioritized to address a burgeoning risk before it becomes a full-fledged issue. The latter is done by leveraging the CM infrastructure that was put in place prior to the deployment.

If anything is to be remembered from my last webinar, it would be that:

• Communications management or the dissemination of project propaganda is NOT change management. Communications should always be viewed as an important tool in the CM arsenal and a critical component of stakeholder management; but it is a means and not an end.
• Training delivery is NOT change management. Again, when appropriate, it can be a critical component of the CM strategy but it should always be viewed as an aspect of a broader learning/knowledge strategy.
• Resistance and skepticism on the part of the impacted stakeholders is not always a bad thing. Constructive criticism can be one of the most potent tools that can be leveraged to enhance the success of a business transformation initiative. Destructive criticism that can potentially lead to obstructionism and sabotage must be identified and addressed early on, but sometimes it’s a very fine line between constructive and destructive criticism. Over the past decade, I have come to realize that some project managers have difficulty distinguishing between the two.
• The best people equipped to drive the change may not necessarily be in a formal position of power. Change does not always need to be driven from the top but needs to be supported by the top.
• One size never fits all. Stakeholder stratification and segmentation is at the heart of good stakeholder management. Each team, department, functional area, business unit, regional area may not absorb or cope with the changes the same way. The project team should account for these differences and it may require that a different approach be used to address the needs of each homogeneous group of impacted stakeholders. In one of my past initiatives, my largest homogeneous group was as large as 2,000+ people and the smallest one as small as 11 people. In the particular example I just mentioned, the level of effort it took to engage the 2,000+ individuals was roughly the same as what it took to keep the group of 11 “special needs” stakeholders involved, engaged, committed, and supportive of the initiative. Stakeholder stratification/segmentation is a science that is covered very well in the marketing literature. Many of the concerns that apply to segmenting a customer base can be leveraged when dealing with impacted stakeholder groups.

If I had to define change management, I would simply state that it is the art and science of managing stakeholders with divergent interests while attempting to forecast the unknown and address complex organizational and operational issues that arise in complex organizational systems. It’s all about leveraging people to identify, mitigate, and manage risks and improving the odds of successfully implementing an initiative that seeks to change the way an organization operates. All of the above can only be done by IMPLEMENTING change WITH the impacted stakeholders and NOT by IMPOSING the change ON THEM. There isn’t a “fits all” magic methodology, no silver bullet. Managing the change associated with a transformative initiative involves a lot of time talking with impacted stakeholders, walking in their shoes, understanding their concern, putting in place the necessary support structure and reassuring them that they will be equipped to deal with the changes that are coming (lots of dialogue, lots of collaboration, lots of brainstorming, and a whole lot of “pro-active problem solving” --one of my favorite oxymorons).

 

The deployment of new processes, new policies, and/or new technologies can be the Achilles heel of even the most mature Program Management Office. No matter how well a Project Manager is prepared, there is always the possibility that unexpected issues will arise during a deployment. I have seen projects where the deployment phase was littered with constant fire drills, where the project team was continually attempting to react to the issue of the day. These fire drills can plague various aspects of the execution phase and impact both the schedule and budget. In many cases, the project team would get side tracked by issues that seem to come out of the blue but throughout the various project post-mortems I have conducted over the past decade, one common theme was that these “unexpected” issues were typically foreseen by someone from the business. These “oracles” were not necessarily at the top of the food chain, they weren’t VPs, directors, managers, or even supervisors; nor did they purposely withhold information so that the project would fail. In most cases, the project team did not seek their insights, in others, these folks kept silent thinking that voicing their concerns would be perceived as resisting the change that was being sponsored by their leadership

Leveraging stakeholder input to continually identify, assess, mitigate, and manage deployment risks can foster buy-in, shared ownership and joint accountability. The advantage of using such an approach allows for the early identification and mitigation of potential risks and issues that come up during the deployment. This does not mean that the project team always does what a group of stakeholders wants; but it requires a lot of listening and a lot of dialogue. The most challenging part is that the project team must partner with the business and for this symbiotic relationship to work well, the project team must relinquish some control. I have worked with project managers who are simply unable to do that, they feel they must control everything, and they end up excluding the business from major decision points that have significant impacts on operations. Once these project managers made a decision, then their definition of “change management” is to shove their decision down the business’ throat. If concerns are raised by the impacted stakeholders, they identify the concerned individuals as “resistors”, heretics who are resisting the path to change.

When a project team operates with the intent to control every aspect of a deployment and fails, the failure is theirs and theirs only. On the flip side, if the business is engaged and a sense of co-ownership and joint accountability is developed, the business will do all it can to make the deployment successful. 

In my upcoming PMI LEAD CoP webinar (on Wed, Sep 7th), I will go over a case study of a successful stakeholder & risk-driven deployment framework I have used many times in the past. By engaging the impacted stakeholders and establishing shared ownership and joint accountability for its success, a project team can enable the following:

• Co-ownership of outcome/Shared responsibility. The approach relies on the stakeholders to identify and help mitigate business and user-related risks through shared ownership and joint accountability.
• Highly customized to local needs. If the deployment is modular and co-owned by the business and the project team, change management activities are highly customized to the needs and culture of a specific group of users, which leads to increased acceptance.
• Early detection of potential issues. Deployment impacts are proactively identified and the rollout of the solution is customized to fit the cultures/sub-cultures of the groups being impacted and to minimize disruptions to business operations and processes.
• Better resource forecasting. The proactive identification and management of risks reduces the possibility project crises (some projects can be in a constant crisis mode which requires require resource mobilization which in turn may impact the budget and/or the schedule)

Like everything else I have previously shared with you, the approach is not intended to be viewed as a magic elixir, a step by step recipe you can follow that will magically ensure that your deployments will always be successful. Unlike most consultants, I am not all seeing and all knowing. The framework should be viewed as a philosophy to guide in the creation of a customized deployment strategy that works for YOUR impacted stakeholder groups, in such a way that they feel they have some “skin in the game” and are willing to go above and beyond to ensure your deployment is successful.

A practical framework to enable organizational/operational change and align “enterprise environmental factors”

I would like to thank everyone who attended my last PMI LEAD CoP webinar on “Leveraging Change Management to Enable Project Success” (the recorded webinar is available on the Project Management Institute (PMI) LEAD CoP website and the presentation is available on my LinkedIn profile). I took the opportunity to talk about a broad framework (“high-level framework” in consultanese) I have been using (and refining) for the past decade to enable change and drive the successful implementation of projects that seek to transform the way a business operates.

There are a lot of frameworks out there that offer step by step recipes to address the challenges of business transformation efforts. These frameworks usually promote all or some of the following activities: (1) a communication workstream that usually involves the intricate planning and dissemination of large amounts of project propaganda, (2) lots of training to attempt to indoctrinate the new way of doing things into the minds of the “targets”, (3) lots of time invested in driving change “from the top”, (4) and attempts to use new technologies and processes to quickly and magically “transform” a culture that (in many cases) has evolved over decades and endured all sorts of disruptive events.

I believe it is close to impossible to develop a cookie cutter approach to managing change, a detailed step by step method that can be applied out of the box without a considerable amount of customization, expertise, and thoughtfulness; with the ever ending need for adjustments and modifications, no matter how well designed. When it comes to managing the change process, scope creep is the norm and unlike managing other components of a project, the real challenge with the change management plan is to periodically be able to properly reassess and reprioritize scope elements (it is not uncommon for priorities to change drastically because of unforeseen issues that could not possibly have been anticipated early on). That is why I have tended to use a rolling wave approach with a planning window that is based on the specifics of the project and organizational factors.  A dynamic planning framework works well for the change management components of projects and programs.

Here are some of the key precepts/principles of the framework I presented:

• Change management is an oxymoron. The term “change management” in the context of organizational/operational change is an oxymoron. In many cases, it is not possible to really manage the effects of the change itself, or to truly control reactions to it, at best the project team can manage the process that is used to push the change agenda and adapt it when necessary. People, teams, departments, business units, regional areas, … will tend to deal with change in their own distinct way. Therefore, being able to formulate a change strategy that caters to those different needs is critical and most often that is what separates a novice from an expert. Change management is an attempt to devise a journey through unchartered territory, you can’t fully plan out a course because you don’t have a complete map but with the appropriate set of “sensors”/tools you can proactively identify potential obstacles before you hit them. Once these obstacles have been identified, you must then use a set of basic rules to figure out how to overcome them, and throughout the process, continually adjust your direction and speed, and learn about the terrain so that the overall process improves continuously.
• Change should be implemented  WITH the impacted stakeholders as opposed to having it be   IMPOSED  ON  them. Change management should be about enabling people and fostering the stakeholders’ responsibility to contribute to the process and become accountable for their own success . This is predicated by the fact that at the end of the day, the impacted stakeholders will have to live in the new environment.
• One size never fits all, even when you are dealing with impacted stakeholders in the same organization, in the same department, and sometimes even in the same team. The proper stratification and breakdown of stakeholder groups can make or break a successful change management strategy. A change manager or project manager shouldn’t simply lump a functional area or operational area together. Finding the right level of granularity can be tricky (e.g., in the past, on some of my projects, I've had groups that were as large as 1,000 and while others were as small as 2). As a rule of thumb, the more granular and customized, the better (conversely, the more granular, the higher the overall level of effort needed to manage the process). When looking at the impacted stakeholders, it is usually worthwhile to do it 2 degrees remote: assess not only the impacts to the directly impacted stakeholders but build a framework that allows you to also assess the impacts to the stakeholders’ stakeholders, a lot of surprises can be avoided by doing so.
• Managing change is not about eradicating resistance. Obstructionism and sabotage should not be confused with resistance. In many cases, a bit of resistance is a good thing and does not result in obstructionism or sabotage. A complete lack of skepticism usually means that people don’t care and that can be even more problematic. I posit that resistance and skepticism can be very healthy reactions, provided that they are handled properly. The ability to leverage resistance and turn it into a critical thinking exercise can help improve the transformation effort by questioning some of the underlying assumptions which allows for the refinement of the change strategy. Leaders and decision makers are not always right; sometimes decisions are made based on incomplete information or wrong assumptions. The change management strategy should provide a medium to periodically “ground” the assumptions and vet them through the impacted stakeholders. In many large organizations, middle management can serve as a fairly potent filter that prevents the top decision makers from truly understanding what is occurring in the organization (e.g., what’s truly the cause of issues with suppliers, customers, etc.) The change management strategy should incorporate a dynamic feedback loop that can bypass natural organizational “filters” that may exist in an organization.
• Communication management is not change management. We are social beings, good two-way communication is the basis for almost everything we do: it is essential to a good partnership, critical to a good relationship with our supervisors and coworkers, essential to healthy business interactions with our suppliers, our customers, … but we must keep in mind that good communication alone will not necessarily result in a successful partnership; if an employee is incompetent or simply a bad "fit", good communication will not result in success at work; if a company keeps producing inferior products, having great communication channels linking it with its customers won’t matter unless the problem is fixed. When it comes to managing organizational/operational/business change, the end goal should not be to "manage" communications, it should be to effectively engage the stakeholders, to properly identify and address their concerns (which by no means results in all stakeholders always getting what they want –needed to clarify that). Communications should definitely be organized and aligned but should always be pervasive, ubiquitous, and should always be perceived as an enabling activity that’s a beginning, never an end goal. It is an enabling activity, a tool, much like a hammer or a screwdriver would be tools of the trade to a master carpenter (these days, power tools would probably be a better analogy). Planning for and periodically distributing one-way project propaganda is fairly easy to do and easy to quantify: the project team sent out 5 e-mails a month, a project newsletter every quarter, and put out a video of the executive sponsor telling everyone that the change is important. Never mind that most the recipients are drowning in e-mails and never opened the messages, or bothered reading the newsletter, or viewed the video. If the goal is to push out propaganda, once it has been pushed, the team can affirm that it has reached its goal; and if that is the standard that must be met, then it is very difficult to fail.
• Training delivery is not change management. Delivering training is not managing change; it is an activity that should be viewed as a component of a broader learning/knowledge diffusion/Knowledge management strategy that enables the impacted stakeholders so that they are equipped to move towards the desired future state. When done properly, this can even lead to innovations that could not have been anticipated during the initiation of the project.
• Ensuring systemic alignment is critical. The overall alignment of goals and expectations must be both vertical (e.g., hierarchical) and horizontal (e.g., functional) and should apply to all impacted stakeholder groups (if applicable, that might even include pertinent customers, suppliers, business partners ,…). A successful business transformation effort will require the systemic alignment of not only people but also strategies, processes, technologies, policies, organizational structure, culture & any sub-cultures,…  (PMI’s PMBoK 4rth edition refers to many of these as “enterprise environmental factors”). Alignment must be across the board and even though this might seem like a herculean effort, with the proper strategy in place and an adequate framework a lot of the responsibilities can be delegated and the challenge becomes the efficient management of the change management network once it is put in place. Since I mentioned culture earlier, I should specify that in the context of organizational/operational change management activities, culture should be considered somewhat immutable unless there is a specific initiative aimed at fostering culture change. If the goal is to “nudge” certain elements of an organization’s culture in a certain direction, then yes, that may be possible through change management activities but if the aim is to fundamentally change core aspects of the culture, then that should be a separate, long term, well defined initiative that is staffed with Organization Development (OD) experts whose expertise is culture change. In such a case, the change management activities can be aligned with and enable/reinforce the OD intervention in various ways.
• Change does not always need to be driven from the top. I’d even go as far as saying that in some cases leadership should provide the broad direction, the necessary resources/support, and get out of the way. In many large enterprises, the most critical group to bring on board is middle management (the titles to be included in this group will vary based on the organization but I’d say in most cases, that includes Directors, Managers, and Supervisors). Not having middle management on board is usually a recipe for disaster, even when the senior executives are the biggest cheerleaders and proponent of the change.

This blog is getting longer than I expected. Please take a look at the presentation for additional information on the framework. I'll start going over the components of the framework in the next blog entry.

MY  GOALS:

—  Engage Project Managers (PM) who are interested in enhancing their skill set around managing organizational and operational change

—  Promote Change Management/Change Enablement (systemic approach) as a key component of projects having direct/indirect impacts on people in an organization

—  Start a conversation and engage PMs who are interested in sharing best practices: what works and what doesn’t work

—  Push the envelope and engage you in discussions around various topics related to Change Management (CM) and Project Management (PM)

NEXT STEPS:

I am looking for Project Managers who manage, support, or enable business transformation initiatives and are interested in collaborating to:

1.  Redefine/refine/adjust the framework I described in the webinar (presentation available here)

2. Align the framework with the PMBoK. Even though I believe that organizational/operational change management holds its own as a distinct knowledge area, a good change management framework can thoroughly strengthen some of the existing (PMBoK) knowledge areas such as integration management, communications management, and risk management (Human Resource management was left out on purpose).
The relationship with the first 2 knowledge areas listed is fairly clear but in case you are wondering why I listed risk management, I figured I’d expound on that. If stakeholders are properly engaged and have bought into the initiative, they can help mitigate many of the organizational risks and remove organizational and operational hurtles that are impeding the project. A well designed sensing network can help identify potential risks well before they would typically appear on the project team’s radar. Also, organizational/operational risks can be “fuzzy risks” which are not clearly defined and may not have a clear answer (things that may have to do with internal politics, culture, or items that cross a variety of boundaries and domain areas in such a way that there is no clear owner or set of expertise that can easily help resolve the issue…). If stakeholders are properly engaged and have bought into the initiative, they can help mitigate many of the organizational risks and remove organizational and operational hurtles that are impeding the project.

3.  Share tools and approaches that enhance the skill set and change management competencies of project managers. I would like to start conducting webinars on tools and approaches I have used in the past that worked and also do a couple on “lessons learned”. It would be a pleasure to collaborate with PMs who would be interested in sharing their experiences and contribute so that we can increase the group’s competencies around managing change.

Identifying the major work streams of a change management strategy

Here is a brief review of my blog entries thus far:

• I’ve talked about some of the issues that typically plague project implementations that are aimed at changing the way a business operates and I have highlighted that 2 out of 3 of these types of rollouts tend of fail. In order to increase the success rate of these type of initiatives, project managers should start leveraging Change Management as one of the key enablers of successful project/program implementations.
• We’ve also talked a bit about the outcome of a successful change management framework and how a well designed Change Management strategy can increase project success.
• In my most recent blog entry, I gave a quick snapshot of Change Management as seen through the eyes of large consulting firms, focusing on some of the themes I saw as I reviewed white papers and other marketing paraphernalia I came across while browsing the websites of 50 prominent consulting firms. I took the opportunity to share my thoughts on some of the emerging themes I identified and also talk about what I perceived to be shortcomings.

As I move forward, I would like to begin focusing on the traits that define a well-rounded, well-designed strategy to manage change. A lot has been written on the topic. What I am aiming for is not an academic paper, not an opportunity to write about a brilliant idea that came to me on how to magically  solve all problems associated with the transformation of an organization (while making heaps of money selling it as a "flavor of the month"). I simply want to start a discussion on issues I have experienced over the past decade, how I’ve dealt with them; my successes, and of course my failures (and what I learned from those). I am hoping that you’ll be willing to share your points of view as well. The ultimate outcome of this is to identify frameworks, approaches, strategies, tactics, etc. that can help address the challenges we face as we implement initiatives that will disrupt the way an organization functions.

I’ll start by saying that a robust strategy to successfully manage organizational change should have at least 4 major work streams covering activities that:

1. Plan, coordinate, and manage change-related processes/tasks/activities (project management tools and frameworks should be leveraged. I’m a big proponent of using a dynamic planning framework, a rolling wave approach with a planning window that is based on the specifics of the project and organizational factors)
2. Monitor the evolution of the transformation, and proactively identify/address organizational risks & issues (a robust change  network makes this possible)
3. Align, enable, and drive the change (stakeholder engagement is key)
4. Anchor, transition, and sustain the change (stakeholder buy-in, and ownership is needed for success.
   
   

If you are interested in an example that uses the 4 work streams listed above, you can take a look at a framework I've used in large business transformation efforts. 

Although the terms “ownership”, “responsibility”, and “accountability” are sometimes used interchangeably, they are fundamentally different concepts, and we can talk about the nuances in more detail at a later time* (see note at end of blog). The mix of ownership/responsibility/accountability will vary across the clusters of activities in the 4 groups. The successful achievement of activities in group A will tend to depend primarily on the project teams whereas successfully accomplishing activities in group D will rely primarily on the organization, specifically certain critical stakeholder groups. Successfully accomplishing group B activities will require (1) stakeholder engagement across the board, and (2) the project teams’ ability to foster and nurture that engagement. Group C activities will necessitate (1) the creation and management of a good “sensing” network that is crucial for the early detection of issues and (2) a robust change agent network that makes it possible to assess these issues and design/implement mitigation strategies to address obstacles.

To wrap up, we could theoretically expand the above list to include dozens of potential work streams but my goal is to identify the least number of common denominators and I think all change activities fit into one of the 4 broad areas listed above. I’d like to remind you that we are looking at this from the perspective of change that is associated with the rollout of an initiative aimed at transforming the way a business operates, whether it be due to new processes, new technology, new policies, … within a context that is restricted by a finite time frame, a finite scope, and finite resources. We are not looking at this from the perspective of a continuous/on-going change effort that stems from an organization development initiative aimed at changing an organization’s culture. I welcome your thoughts and comments on the 4 groups of activities I identified.

* Note: If you’d like to understand the nuances between “responsibility” and “accountability”, you can Google the terms “RACI” or the variants “RASCI” and “RACI-VS” (where: R=Responsible, A=Accountable, S=Supportive, C=Consulted, I=Informed). The RACI/RASCI classification scheme aims at categorizing the role of stakeholders in the change process. You’ll find many other variants where, for example,” accountability” is sometimes replaced by “ownership”, but in the end, they’re very similar. I do like this classification scheme but with all the variants I’ve seen in the past decade, I haven’t come across one that had all 3 categories (“responsibility”, “accountability”, and “ownership”) and differentiated between “accountability”, and “ownership”.  I see that as a shortcoming because in this era of out-sourcing and in-sourcing, accountability is not always synonymous to ownership. RACI has been around for decades and back then, in most cases, accountability and ownership were tightly linked. Nowadays, there is a difference between being responsible for something, being accountable for that “thing”, and owning that “thing”. You might think that it’s all semantics but I disagree. As an example, I’d say that if you’ve ever worked in an environment where a process or an operation has been out-sourced or in-sourced, you’d probably be able to relate to the distinction I am attempting to describe. When something has been out-sourced or in-sourced, the original owners no longer really "own" it, nor are they responsible for managing it day-to-day, yet in some circumstances, they may still be accountable for it. In this particular situation, any change strategy that is being implemented must take into consideration that distinction. In such a situation, one of the best levers of influence to drive change might be a “Service Level Agreement” (SLA). The latter can bring some leverage to a group that is accountable but does not own something. There are multiple situations where distinguishing between ownership and accountability can make a difference between a successful change strategy and a less successful one. I’ve already deviated too much from the original intent of this blog so I’m not going to spend more time on this topic, perhaps I can focus a later blog on this subject.

A quick snapshot of Change Management as seen through the eyes of large consulting firms

In order to better frame future discussions, I have been focusing my first couple of blogs on defining the status quo. The next step will be to further identify the need and wants of the PMs who read this blog, and then we can move on to discussions around tools, frameworks, etc … As I mentioned earlier, this blog focuses on change management associated with business transformation efforts (e.g., process, IT, or operations-related), a domain that is still primarily controlled by large consulting firms. I felt it would perhaps be valuable to visit the websites of some of the largest consulting firms out there and take a  quick snapshot of change management-related web marketing paraphernalia and white papers they have made available though their portals. One of the interesting observations is that the approaches being used by these consulting firms haven’t changed much over the past decade, even though there have been many developments from the academic side.

In the process of writing this blog, the websites of 50 of some the most prominent management consulting firms were reviewed in search of white papers and other documentation describing their change management approach. This non-scientific endeavor was aimed at (1) getting a quick assessment of the frameworks that were being used and (2) getting a sense of recurring themes around change management, as described by these practitioners in the frontlines. Given the non-empirical/non-scientific nature of the review, the full list of websites is not being provided. The goal was not to criticize specific consulting firms but to provide a cursory review of the lay of the land.  The review of the websites resulted in the following observations:

--- I should first of all say that I am not affiliated with any of the firms I mention in the following bullets. I was always told that if I didn’t have something nice to say, I should keep it to myself. In that same spirit, I will only identify and highlight companies/firms I have positive things to say about ---

• Change management can improve the odds of successfully implementing a business transformation initiative. Almost all of the consulting firms highlighted the value of change management as a means of increasing the likelihood of a successful business transformation effort, whether it be IT, process improvement, strategy, or specific to the operations of a particular functional area (such as finance, HR, customer service, and others).
• John Kotter’s 8-step approach is still one of the most popular frameworks. Many of the firms tended to use a lot of buzz words and cited Kotter’s seminal 1996 work on managing change. Among the firms that offered white papers describing their change management philosophy, many described variations of Kotter’s 8 step process, selling it as their own innovative, pioneering, ground breaking methodology.
  
  Note: If you are interested in learning more about Kotter’s work you can browse excerpts of the e-book version of “Leading Change”.
• There seems to be little thought leadership/original ideas out there coming from the large consulting firms. Overall, the quick review of these websites highlighted that with the exception of a few outliers, there is very little thought leadership across the large consulting firms. Many claim to collaborate with academic or research institutions but it seems that in most cases, the surveys were primarily designed to better highlight a need for their offerings, these surveys seem to be marketing tools rather than original contributions to advance the field. I must mention that two consulting firms seem to clearly be an exception to this trend.  The Katzenbach Center which is now part of Booz  & Company and McKinsey & Company’s McKinsey Quarterly have been prolific in publishing thought pieces and attempting to leverage academic research to improve practical change management models. You can check out their websites for articles and other insightful documentation on managing change.
• There seems to be a confusion between Change Management and Communications Management. Many of the consulting firms seem to blur the line between change management and communications management. In some cases the documents on the websites seems to suggest that change management is somehow a subset of their “communications” offering.
  
  My thoughts:
  I know it depends on how one defines “communications” but I personally have an issue with this for a variety of reasons:
  1) A well designed communications strategy is a tool, not an end. At the end of the day, the goal is to enable the desired changes in behavior not just to communicate what the project team plans to do. In many large programs, the change management strategy seems to rely primarily on pushing out project “propaganda” which in most cases is not very effective.
  2) You need to keep in mind that people don’t necessarily resist change because they don’t understand. If resistance is simply due to lack of understanding, I believe it is easier to address. In many cases the most potent and effective resistors are the ones who do understand the change and its implications. Simply pushing out project propaganda does not help address this type of resistance.
  3) Many of the sites seem to claim that the best approach is to push out communications from as many channels as possible as much as possible. I’d say that can actually be dangerous. If you over-communicate, your stakeholders will eventually tune you out. The best approach is to properly assess your stakeholders and communicate appropriately. The approach should be custom tailored to the various stakeholder groups and that’s where a good stakeholder segmentation strategy comes in. Furthermore, I’ve found that a good indicator of an effective change strategy is when information is being “pulled” by the stakeholders (as opposed to having the information “pushed” on them by the project team) or information is being shared within and across stakeholder groups. Depending on the organization and its culture, Web2.0 technologies, collaboration and information sharing technology (such as MS SharePoint) can do a pretty good job at facilitating these types of interactions.
• There seems to be a belief that change must be driven from the top. Most of the firms promoted a top down approach to managing change, highlighting their experience working with executives. Not to be cynical but one could assume that having the consulting firms continually working with senior leaders in an organization and having exposure to the top decision makers does make sense from a marketing and sale standpoint. Very few of these consulting firms broke that mold, notably Aon Consulting which highlights its approach that “focuses on the middle” and stresses the importance of middle management in driving change.
  
  My thoughts:
   I disagree with the notion that change must necessarily be pushed from the top, I’d say that it depends on the situation. Don’t get me wrong, I believe the change must be supported by the top managers: they must provide the resources for the transformation. In the end, the most effective way to enable change is through effective change agents and these people are not always at the top of the organization. In a bureaucratic/hierarchical environment with a strong command and control culture, pushing change from the top makes sense. Such an approach would work well in the military and other organizations where command and control is critical and where abiding by the rules and regulations is mission critical (the nuclear industry comes to mind). Modern organizations tend to be matrixed, more decentralized, and the post potent and effective change agents are not necessarily at the top of the organization. One of my favorite books on change leaders is Real Change Leaders (1997) by Jon R. Katzenbach. Identifying these change agents is a science and quantitative/mathematical models have been used for that purpose, if you’d like to find out more, you can Google “Organizational Network Analysis” (also known as ONA). Rob Cross (at the university of Virginia) is one of the foremost experts in this area and provides various resources on the topic on his website. Sadly, very few consultants use tools such as ONA. I plan to devote one of my future blogs to explaining the concepts behind ONA and talk a bit about how PMs can leverage the results of a well designed Organizational Network Analysis to improve the success of a business transformation effort.
• Some consultants seem to think that culture is an easy thing to change. There is a myriad of references to culture change as the miracle elixir that can cure most transformation related problems. Reading the documentation on many of these websites, one would think that changing an organization’s culture is one of the most common and perhaps easy task to undertake. One large consulting firm even claims that a culture change at a large corporation can take “months or even years” but thanks to their suite of web2.0 tools, breakthroughs can now be achieved in “as little as 72 hrs”. That said, it must also be noted that a few firms such as Oliver Wyman highlight the phenomenal effort that is required to change an organization’s culture and also provide detailed on the their comprehensive approach to address the challenge, but Oliver Wynman is one of the exceptions.
  
  My thoughts:
  When it comes to culture, unless cultural change is in-scope and a distinct component of your initiative, the project team should refrain from assuming that changing a few processes and putting in place new technology will automatically change the culture. New systems and technology could “nudge” the current culture into a particular direction and can even trigger an evolution but that doesn’t always happen. Culture can be defined as an organization’s “personality” and is difficult to change in most situations. That said, I’d like to stress that it is critical that the project team understand the culture and attempt to forecast the potential impacts of and organization’s culture and sub-cultures on their implementation plans and adapt them accordingly. If you don’t take into consideration an organization’s culture, it’s more likely that people will find workarounds to the new processes you put in place instead of blindly embracing the changes. At the end of the day, unless you are implementing change in a manufacturing environment, the most critical element in driving change is the human element, performance improvement specialists who come from a manufacturing background or use tools that were originally designed to be used in a manufacturing environment (e.g., some of the six sigma tools) usually struggle with this, they tend to forget that humans are not machines or processes: they REACT to change. If the reaction is in the right direction, great but often enough, it’s not. The “build it, they will come” approach is usually not very effective.
• Most of the consulting firms seem to identify resistance as a bad element that must be eradicated. The common listed root causes for resistance ranged from lack of communications, people’s natural apprehension to change, fear of the unknown, etc.
  
  My thoughts:
  Resistance and skepticism are not always bad things. People don’t always resist for the sake of resisting. Sometimes the solution that is being pushed by the project team is a bad one, sometimes the project team makes a decision that is not well thought out, sometimes, there are variables that were not taken into account by the decision makers, in these cases, the challenge is not to simply  eradicate the dissenting voices but to properly identify the ones that are genuine concerns from the ones that are simply crying wolf.

This quick, cursory review of the web materials put forth by the 50 consulting firms seems to indicate that the range of change management capability of consulting firms vary. In some firms, it seems clear that they want to be positioned as thought leaders in the change management, change enablement, organization transformation arenas. At others, change management seems to be a secondary source of income, their core competence being either IT implementations or business process reengineering, with change management being another way of extracting revenues from established clients.

As I reminded you in an earlier blog, 2 out of 3 projects that aim at changing the way a business operates FAIL. I’ll flatly say it: these initiatives fail not solely because of the absence of change management but also because of poorly designed CM strategies. I’ll conclude with a reminder that a communication strategy by itself, is not a change management strategy and culture change is HARD. As a project or program manager who is running an initiative, you must be aware of the culture in order to successfully operate within it. You should not assume that having leadership support will automatically mean that you will be able to eliminate pockets of resistance. If properly managed, resistance can be a potent tool in helping identify issues the project team didn’t even see coming, and it can strengthen the project’s risk management framework by expanding it to include organizational issues that are often overlooked by project teams.