Planning and Managing Change
The article provides a succinct step-by-step method to plan and roll out change in any organization. It includes an explanation of what to do and what not to do during the change management process.
Our species is the collective and summative product of all change that has come before us. The current iteration of humanity is the result of change which has either been foisted on us by our environments, our circumstance, or by others. Our environments and circumstances cause us to adapt to change. Alternatively, leaders (business, politics or other) who have seen the power of change and recognized the power in wielding it, have shaped humanity.
Over the past 15 years, with the implementation of IT, we have seen an evolution of the field that some call "change management". Do not make the mistake in believing that change management is a new phenomenon. Change and managing change have been around since the dawn of time. Change is likely the most disruptive and powerful force underlying and constantly operating in both the lives of individuals and organizations. Individuals who do not adapt or create change in their own lives, quite often end up stagnating, whereas organizations who do not embrace, adapt to, and harness change end up extinct. So, how do we use change processes to effect positive change?
The practice of change management has grown, more or less, out of the field of Organizational Behaviour and Organizational Development (OBOD). In OBOD, change is recognized as an adaptive and powerful tool and if used properly, can mobilize business interests in strategically successful ways. More and more, change management has been used as a tool to strategically introduce and manage business systems.
Change management in Information Technology (IT) is clearly a Petri Dish for studying change - how to plan it; implement it; manage it; and control it. Rolling out large scale system changes often occurs in environments with already established systems and processes. Changes to the "old ways" are almost always threatening for those who are or will experience the change. Even if the "old ways" are limited or defective, they are often seen as better than the change coming down the pike. This attitude can be pervasive and often stems from multiple abject failures that have occurred in the IT area, but is likely just a natural human response to any disruption (change = disruption for most).
The results of a poorly planned, executed or followed-up change process can be lasting intransigence; slow or non-adoption; high, cointinued, and/or inappropriate reliance on temporary project staff; political fallout (small p or large P, depending on the environment); and permanently negative attitudes within the change environment. Many of these items can be avoided or minimized if change is planned, executed and followed-up in a rigorous and strategic manner - prior to, during, and post project rollout.
There are a number of ways in which to minimize disruptive change and to make change work in your organization, these are:
1. Understand the culture and the sub-cultures of the organization, and most importantly, understand the differences. A "gung-ho-let's-get-it-done" management culture might set the right context for change, but if that culture is married with a highly-unionized, "gimme-my-paycheck-it's-clockin-out-time" culture then you have a recipe for disaster. Yes, sometimes change requires draconian measures including prescriptive direction, but always these should be the last resort. In any case, articulating a commitment to change is required by the organizational leaders. If change is not communicated frequently and effectively, the "change" will fail.
2. Engage the change audiences - use appropriate strategies for each layer of audience that will be required to adapt change or is responsible for the change.
3. Manage expectations - do not paint a picture that the change will solve all the problems of the organization. If you promise a "windows-based GUI and then deliver a "green screen", anything you say after that will be tossed out the window.
4. Whatever you do, train and facilitate; train and facilitate; train and facilitate... get my point? Half or more of success in any new environment is: knowing what to expect, being prepared for it, seeing it when you are there, and being confident to handle it when you experience it.
5. Identify "influencers", and build in appropriate methods of persuading them that change is for the best, and will make their jobs easier or more productive or simpler, or reduce errors, etc. Buy-in will need to occur with most of these folks if change is to work.
6. Identify additional benefits for high-power (informal or formal) end-users. For instance, if a system will better allow physicians to track patients or access lab results in hospital, but these benefits will occur in subsequent modules and rollouts, then they will need to hear this message early in planning and consistently hear it. If physicians are the end users and if they have not blessed the system or changes, then the change will be problematic and may even fail.
7. Expect and plan for the IT project team supporting the project for a period of time, after the rollout. A "cut and run" approach will only exacerbate an already tenuous and volatile environment. Phase the team's presence out gradually, i.e., as the number of calls on the log sheet diminish.
8. Do not set arbitrary, artificial deadlines that will create unnecessary and stressful results if not met. If the Project Manager has not been able to deliver due for legitimate reasons, then rushing to implementation without due regard to "change", may result in long-lasting employee intransigence, ill-will, and increase the probability of failure for future project implementation and change processes.
Whatever change is occurring, and the success of that change will echo through an organization and a culture of adversity to change will ensue. If this happens, no change management process or number of contracted change managers will be able to rectify the situation (though some will claim to).
I leave you with an age-old truism: "change is the only constant". Virtually every change process will be disruptive (even the positive ones as they typically shocks us out of our complacency). Virtually every change process will be met with "push-back" from at least a few employees. Virtually every change process can be handled better. It's up to those who envision change to make sure it is done properly - plan it out, execute, refine, and follow-up, and above all communicate the change as positively, directly, simply, realistically, and urgently (where applicable).
Over the past 15 years, with the implementation of IT, we have seen an evolution of the field that some call "change management". Do not make the mistake in believing that change management is a new phenomenon. Change and managing change have been around since the dawn of time. Change is likely the most disruptive and powerful force underlying and constantly operating in both the lives of individuals and organizations. Individuals who do not adapt or create change in their own lives, quite often end up stagnating, whereas organizations who do not embrace, adapt to, and harness change end up extinct. So, how do we use change processes to effect positive change?
The practice of change management has grown, more or less, out of the field of Organizational Behaviour and Organizational Development (OBOD). In OBOD, change is recognized as an adaptive and powerful tool and if used properly, can mobilize business interests in strategically successful ways. More and more, change management has been used as a tool to strategically introduce and manage business systems.
Change management in Information Technology (IT) is clearly a Petri Dish for studying change - how to plan it; implement it; manage it; and control it. Rolling out large scale system changes often occurs in environments with already established systems and processes. Changes to the "old ways" are almost always threatening for those who are or will experience the change. Even if the "old ways" are limited or defective, they are often seen as better than the change coming down the pike. This attitude can be pervasive and often stems from multiple abject failures that have occurred in the IT area, but is likely just a natural human response to any disruption (change = disruption for most).
The results of a poorly planned, executed or followed-up change process can be lasting intransigence; slow or non-adoption; high, cointinued, and/or inappropriate reliance on temporary project staff; political fallout (small p or large P, depending on the environment); and permanently negative attitudes within the change environment. Many of these items can be avoided or minimized if change is planned, executed and followed-up in a rigorous and strategic manner - prior to, during, and post project rollout.
There are a number of ways in which to minimize disruptive change and to make change work in your organization, these are:
1. Understand the culture and the sub-cultures of the organization, and most importantly, understand the differences. A "gung-ho-let's-get-it-done" management culture might set the right context for change, but if that culture is married with a highly-unionized, "gimme-my-paycheck-it's-clockin-out-time" culture then you have a recipe for disaster. Yes, sometimes change requires draconian measures including prescriptive direction, but always these should be the last resort. In any case, articulating a commitment to change is required by the organizational leaders. If change is not communicated frequently and effectively, the "change" will fail.
2. Engage the change audiences - use appropriate strategies for each layer of audience that will be required to adapt change or is responsible for the change.
3. Manage expectations - do not paint a picture that the change will solve all the problems of the organization. If you promise a "windows-based GUI and then deliver a "green screen", anything you say after that will be tossed out the window.
4. Whatever you do, train and facilitate; train and facilitate; train and facilitate... get my point? Half or more of success in any new environment is: knowing what to expect, being prepared for it, seeing it when you are there, and being confident to handle it when you experience it.
5. Identify "influencers", and build in appropriate methods of persuading them that change is for the best, and will make their jobs easier or more productive or simpler, or reduce errors, etc. Buy-in will need to occur with most of these folks if change is to work.
6. Identify additional benefits for high-power (informal or formal) end-users. For instance, if a system will better allow physicians to track patients or access lab results in hospital, but these benefits will occur in subsequent modules and rollouts, then they will need to hear this message early in planning and consistently hear it. If physicians are the end users and if they have not blessed the system or changes, then the change will be problematic and may even fail.
7. Expect and plan for the IT project team supporting the project for a period of time, after the rollout. A "cut and run" approach will only exacerbate an already tenuous and volatile environment. Phase the team's presence out gradually, i.e., as the number of calls on the log sheet diminish.
8. Do not set arbitrary, artificial deadlines that will create unnecessary and stressful results if not met. If the Project Manager has not been able to deliver due for legitimate reasons, then rushing to implementation without due regard to "change", may result in long-lasting employee intransigence, ill-will, and increase the probability of failure for future project implementation and change processes.
Whatever change is occurring, and the success of that change will echo through an organization and a culture of adversity to change will ensue. If this happens, no change management process or number of contracted change managers will be able to rectify the situation (though some will claim to).
I leave you with an age-old truism: "change is the only constant". Virtually every change process will be disruptive (even the positive ones as they typically shocks us out of our complacency). Virtually every change process will be met with "push-back" from at least a few employees. Virtually every change process can be handled better. It's up to those who envision change to make sure it is done properly - plan it out, execute, refine, and follow-up, and above all communicate the change as positively, directly, simply, realistically, and urgently (where applicable).

Use the feedback form below to submit your comments.

Use the form below to email this article to your friends.

- Finding A Great Change Management Consultant
- The Process of Organizational Change Management
- Change Management: Getting It Right
- Interim Executive Management: Challenge and Change
- Change Management Checklist – Give Your Change Program a Quick Health Check
- Change Management Strategies: 6 Ways To Take Your Organization To The Next Level With Change Management
- Change management
- Making the Transition from an Entrepreneurship to a Professionally Run Business
- Be the Change
- Buy a Human Resource Software for Resource Management and Planning
- Project Management calls for proper planning
- Payroll Management - Start Planning Now
- JAD Planning and Training
- Home Office Interior Design: Office Space Planning




