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:
- 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)
- Monitor the evolution of the transformation, and proactively identify/address organizational risks & issues (a robust change network makes this possible)
- Align, enable, and drive the change (stakeholder engagement is key)
- 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.