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.