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.