Don't change too much at once!

I have recently been working on a large Architectural diagram that a significant number of people have been looking at on a regular basis and have followed through its evolution. I have been doing some large changes to this diagram, but rather than making them all at once I have staggered the changes across a number of versions of the diagram. There are a number of reasons I have done this, including:
  1. People often get overwhelmed if there is too much that has changed.
  2. The validity of the diagram as being a trusted reference is undermined if it is significantly changed with each release.
  3. People are often much happier if they are taken on the journey.
  4. Less noise. Fewer changes reduces the areas for debate and allows them to be rapidly addressed without the confusion of other changes.

Change can be good, but too much at once is often not a good thing. I have been treating the aforementioned diagram like a brand, whereby whilst it is possible to completely overhaul it, if you make small changes to it over time, you can take people with you rather than getting them to recognise something completely new today than what they were used to yesterday.

Whilst this may seem fairly obvious, it is a common mistake that people fall into. Changes on websites are another great example of where it is often best to do it in chunks and take people on the journey. Technology Operations teams are also often strong advocates of not doing too many changes at once, since identifying the root cause is much more troublesome if there is a lot that has occurred, and rolling back can be a major headache.

Change can occur in many different ways across all facets of People, Process & Technology, but a common theme across all of these is that change is best achieved through understanding where you are (current state), where you want to be (future state) and then planning how to get there (transition plan).

Balancing up how much change to do at any one time is an art and a lot of variables will come into play. A key variable will be the number of affected people, as will the cost of having multiple steps. Going straight from current state to future state may be feasible in some scenarios, but all I am suggesting is that in many scenarios this may cause more harm than good (and it may in fact cost significantly more due to brand damage).


Popular posts from this blog

Using Raspberry Pi as a Time Capsule to backup a Mac

Solution: Getting macOS Messages to work with Google Chat / Talk / Hangouts in High Sierra

IT & Enterprise Architecture Conference 2015 - Day 2