The Butterfly Effect & Change Management

This is the first of two posts on this topic. The second one is here.

In theory I am all for change management; in IT change is inevitable. In fact, to keep things the same you often have to change them constantly. In a field with so much flux built in, managing the change is essential.

In practice I see two problems with how change management is implemented. In accordance with common practice I will keep my rants to one issue per post.

This post is about the difficulty of assessing the potential impact of any given change, and how that leads to poor change management decisions.

In an idea world rolling out changes is an exercise in risk analysis: for a small change there need only be a small amount of overhead while a large change merits a large amount of overhead.

(In this context, "overhead" means testing, validating, documenting and deploying.)

Note that we are often a bit sloppy with our terminology here: is a small change small in scope (amount of stuff being changed, eg lines of code) or small in impact (only effects the color of some menu items) or small in risk (has little interaction with other parts of the system)? And therein lies the problem: some small changes (in scope) are very big (in terms of interactions) and some big changes (in scope) are very small (in terms of risk).

One way of thinking about this apparent paradox is the Butterfly Effect from chaos theory: if the conditions are just right, then a butterfly flaps its wings in China and it rains in Canada. Sometimes a small change makes a huge and unexpected difference in an unexpected place with possibly very unwanted consequences.

Ok, so it is hard to have confidence in our ability to assess how big an impact a change might have; so what? So you might end up with the wrong amount of overhead. What is the problem with inappropriate overhead? The problem is that too much overhead makes it too hard to make truly small changes that customers really want while too little overhead makes it likely that, soon or later, a change will cause real and avoidable problems.

The former problem (too hard to make small changes) is such a problem that the Agile movement was invented to solve it. The latter is such a problem that Change Management was invented to solve it.

Many IT departments I have worked with have been bitten by too little overhead, so they now require maximum overhead all the time. Changes have to be gathered into releases which have to scheduled and tested and suddenly fixing an embarrassing typo takes weeks or months instead of hours.

Many development teams that I have worked with overreacted to this bureaucracy by embracing the "move fast and break stuff" ethos.

 So let Ted Hayes educate you on Change Management in his posts, but remember that a methodology rarely absolves you of your responsibility to exercise your judgement. Let the punishment fit the crime and let the overhead fit the change.