Yesterday was the start of a synonyms for change exercise.
More synonyms for change:
Would this be fixing something that is broken or breaking something to change?
The first could be the tactical change that happens within the project stream. At the project phase of the change process the “management” has a lot to do with fixing things that are broken- IT initiatives for software, cultural for competencies, data management for sales, etc.
The second might be deliberate efforts to get something to break to show that change is necessary or to test to see if something will break under stress and pressure.
Or this type could just be making sure there is some rest in this whole change process.
If you squish something its form changes.
Layoffs, firings, GE type culling, squishes, big time.
Stakeholders see and feel the squish. They either see how much pressure they can handle by staying or they scramble to avoid the crushing.
From experience I can say that is a very distinct kind of change management (not for the faint of heart).
Like the above, but slower.
Sometimes slow enough to be unnoticeable for awhile. Think a GE culling approach with no mention that it is happening. Keep stripping away 10% and sooner or later you will not be able to fill the gap OR you will start to have problems with the top 10%. It is hard to survive with the middle 60% (especially if the competition got your top 10%).
If there absolutely has to be a reduction in force Contraction Management could make it smoother.
This would be a good term for an IT technology initiative.
Switching from one software technology to another can be a pretty traumatic change process. To the stakeholders it often means losing the old, having to re-learn for the new and finding themselves in about the same situation in terms of keystrokes that they were when the whole change thing started.
That happens because a lot of sold software is not a whole lot better on the front end than the older version. Those solutions MAY be better as a result of the backend data (depending on how the data gets used), but the stakeholders will not see that and do not know about it unless the change process has clear end state descriptions.
If there is a well managed change process that includes the development of end state descriptions (filled with numbers about how the use of the software will better both the company and the employees), the software REALLY is better and works out of the box and Leaders are owners of the solution and the process then Conversion Management is an excellent term.
This sounds like it would be change around fixing things.
One of the things I see in organizations that makes true successful change tough is the inability to admit things need to be adjusted or fixed- especially in the middle of change. By fixed I mean fault with the change process itself. Sometimes things come up that require extra time to address. Sometimes that is because planning was weak or someone made a mistake.
Using the term more specifically to call out necessary corrections to original end state descriptions, or parts of plans, or lists of tasks or changes to structure might just be helpful.