I was speaking to friend recently, who had just taken on a new role leading a large-scale organisational transformation (only part of which involved IT change). Along the way, she mentioned a conversation with the organisation’s Head of Communications, who had expressed the need to keep presenting a positive message to the staff about what they were intending to achieve. My friend, however, had a different view. She wanted to make it clear that the staff would be going through periods of uncertainty, and that they would need support for that.

She also referenced the Kübler-Ross change curve, and in particular the “valley of depair” that is inevitable during any change process when difficulties start to materialise. (As an aside, it’s probably no coincidence that the Gartner hype cycle looks very similar—they are both about complex promises meeting reality.)
This recognition of, and support for, people facing uncertainty is about honest communication. A Transformation Lead might think they need to be the cheerleader-in-chief—and it’s definitely important to remind people of the goals we’re trying to achieve with a transformation—but sooner or later people will see reality for what it is. If we don’t acknowledge this before it happens our teams will lose trust in us.
It’s important, therefore, to acknowledge the uncertainty that will occur, and that people will feel it. And we can find ways to help them. Just acknowledging that uncertainty is inevitable is a start, because it legitimises the conversation. There may usefully be forums for people to talk about it—in formal groups, in passing, or in line manager one-to-ones. And we can be open to adjust our plans in response to that uncertainty; this will always help to achieve a better outcome.
So reminding people about the goals of a transformation is important. But it’s also important to acknowledge the inherent uncertainty that people will feel. We can use that feedback to ensure greater success.
The moment we would introduce a ‘transformation’, we cause uncertainty, just like with any other introduction of some change. How about just doing it with them, without calling it anything. Just suggesting different ways of doing things, letting them finding out the benefits themselves (if there are any benefits). Later, we may give it a name, if we should at all. This way, we can circumvent the whole Kübler-Ross, and whatever other cycle. Saves a lot of energy, and success is easier to achieve.
Don’t improve a bad solution :-)
I think it depends on the scale of the transformation-like-thing. On a smaller scale, it’s silly to call something a transformation – for example, updating a wiki page is not best described as “content transformation”. But the further you go up the scale (for example, up to an organisation-wide change of process, management structures and reporting) the more it becomes a useful option. Calling something a transformation immediately brings a whole lot of associated ideas. Some of those are definitely not so good (the uncertainty, for example) but some are good (for example, the ability to identify useful tools and processes, not least from just being able to use the word “transformation” in a Google search). And while I definitely support make such change with the people most impacted by the change, there is a lot of value in having a single vision (which might take some time for people to understand and accept) and a centrally coordinated plan.
The larger the ‘transformation’, the more waterfally it probably is. Not?
The funny thing about that observation is that I know so many transformations that are labelled an “agile transformation”.
Then it cannot be a large transformation.
Think MVP. To get feedback that we probably are doing something that is not adequate. Better assume that our assumptions are wrong.
However, for the transformators that’s probably not a good idea. I suppose they want to transform big ($$$). Sending a lot of people to courses, etc.
However, I suppose that’s not what the transformators like. I assume they rather do a big transformation for big $$$. First sending people to courses.
You should set yourself up as a transformation consultant. If you can charge medium-sized $$$ when others are charging big $$$ you might be onto a winner.
I merely coach people/teams/organizations to deliver better results in less time. Agility and transformation will be an effect, not a goal. If not calling myself agile or transformer gets me less $$$, so be it. Or should I call me so, in order to deliver better results in less time?