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.