Why do companies implementing shared services and outsourcing first think about the term “change management” in the weeks before they go live with the new solution? Is it hubris (“they will do it and they will like it)? Limited awareness of the implications of what is changing? Discomfort with the so-called “soft stuff?” Haste to move to a new model? Lack of internal resources? Trust that all will go well? I’ve been operating under a hunch that the sourcing organization or function gets so swept up in the act of sourcing that they forget to sit down and think about the implications of sourcing—what will change, what won’t, and what is unknown at the moment. This suggests there is no fundamental definition of “change”—whether it’s moving work from down the hall to Delhi, whether it’s implementing new workflow, whether “no” or “not now” will be added into the corporate vocabulary, or if the new model is going to cost stakeholders more or less.
Would the outcome be any different if the sourcing organization developed a change case as part of the development of a business case? Think about what that might entail—mapping what will change to each affected stakeholder group, then figuring out if the totality of the change was workable/palatable?” Sort of a heat map? This process might open up some eyes—tinkering with the pace or starting point of deployment, scaling the solution up or down, changing out technology, or pushing for faster innovation—all in the pursuit of making change stick.
Has anyone out there actually developed a change case in the sourcing process? If so, what did it look like? How did it “change” the course of change?