The changes your IT department implements can be hard at a personal level and at an organizational level. The speed of the change plays an important role in how the change is accepted. But it isn’t the specific speed of the change that matters, it is the speed of the change compared to what people expect.

As I talked about in my post, Square Root Of Change, there is a dip in productivity (however you measure it) when a change happens. It takes time for productivity to get back to the level it was, or hopefully higher.

Here I want to talk about the time leading up to the change. The time between people first hearing of the change and when the change affects their day-to-day activities.

There is a simple heuristic that I believe drives most of our opinions of the speed of change: If we want the change, it is too slow. If we don’t want the change, it is too fast. Business management is littered with failed changes, many because they happened too fast. Social commentary is filled with complaints about change being either too fast or too slow.

There is also the scope/scale factor. The bigger the thing being changed, the longer it will take. Changing a personal habit can be faster than changing a company culture. Changing how a five person team handles a specific process is faster than a town gets used to a new roundabout intersection.

And the icing on the cake is looking at all the change that has happened in the last one hundred years. Virtually no aspect of human existence has been change-free. Even at the same time that the changes we want are happening too slow for us.

Going back to the IT department that we all know and love, we need to spend time up front explaining the change to make sure that as many people as possible believe it is a good thing. The more that want it, the faster the organization will want the change. Having most of your users think you are implementing a change too slowly is much better than them thinking you are rushing a change too fast.