CM Change Control

So, as one speaks admittedly of controlling the changes in the (CM) Change Management, one ought to call it actually Change Control rather than Change Management. Justifications for such control are typically the following: the critical outages, enormous costs and grief that (any) uncontrolled and non-authorized change inevitably brings in.

It may turn out quite sensational to realize that such justifications are based on an implicit assumption that any modification or change that is made to the system gets instantly buried in the system and becomes indistinguishable from it. The world built on such assumptions can be called the "/main/LATEST" world (comes from the ClearCase terminology), or (as has been referred many times already) the "CM" one.

And in the Change Control the major stress is on "managing" (read: controlling) the people side of change. Therefore: not any code changes allowed prior to the approved change request (disarming the developers), customer change request specification is required beforehand (to be a potential proof of innocence for the change providing party), impact analysis and feasibility study from developers’ side are required (to be second in importance party to blame if the need arises), and so on.

Whereas even the control of the change itself is amazingly simplified - basically it's the question: "to be or NOT to be"? And funnily enough, it's quite often the latter that is preferred as the easier and relieving choice. (Perhaps, it's still always easier to state the impossibility of doing a certain change due to e.g. lack of resources, time or money, rather then taking up that huge risk and being obliged to deal with the infamous black boxes (i.e. the changes themselves) all the way long).

It seems that in the Change Control process the idea of having multiple alternative versions of the same change is totally out of scope (there is no way to distinguish between the two black boxes - the "change sets" don't really help much - and it's anyway too much risk and hassle even with the single one).

These methods of dealing with the changes look tremendously over-authoritarian and quite outdated, as if e.g. one would try to deal with the time using the Babylonian tools and methods.

It's amazing to see though how all the need for such excessive authority disappears with the entrance of one key idea: any system configuration (and thus change) has to be identifiable. Having this in mind one can empower himself to step ambitiously forward from the poorly working change control methods to the actual change management.

-- TatyanaShpichko^? - 21 Jan 2007