Configuration Management Plan

In ASL, Configuration Management is one of the five processes in the Maintenance process cluster. Like all processes, we want everything we do about it to be clear, structured, managed and audit-able.

The ASL-Bisl foundation, which you can find here, inherited all the stuff from the ASL foundation. It has a "Configuration management plan maintenance" and an example.

Unfortunately the plan does not state the goal of the document. Why is the CMP written?

In my humble opinion, a configuration management plan fits into the Waste - definition of Lean. Still, it is a useful item to prevent other kinds of waste.

A good Configuration Management Plan fits into both Maintenance and Development.
The configuration Management Plan defines  the items that are governed by the CMP, and the processes governing these items.

The CMP thus makes everybody involved clear:
A - what items are important to us?
B - where are these items stocked?
C - what is their status?
D - how do we make sure the items and their status is up to date?
All the rest is bogus.

Now why is this Waste as defined by Lean? Simply because it is not a primary process to produce what the customer demands of an IT organization. Is it useful? Yes, nevertheless it can be very useful, because it prevents other wastes.

These other wastes include:
(i) - Having lost track of items which are important nevertheless. On of my customers, an organisation with a large IT-department, had programs running. These programs ran for years, and never got changed. When after some 10 years they had to be changed, the sources could, albeit with considerable effort, still be hunt down, but the development environment was lost, simply because no one knew it was important. So it is very important to make a list of ITEMS which are important to a project or organisation.

(ii) - In the previous example, I used the expression 'hunted down' on purpose. Looking for programs can be extremely effort costly, even with networks and search facilities available. This search effort is clearly a waste of time. Thus: For every item you deem important, write down WHERE

(iii) - Did it ever happen to you that the developer made three copies of the programs - just to be sure? Fine. Now which is the current version? Time to sort this out is waste is Lean terminology. That is why it is important to keep track of the STATUS.
Status will generally vary over time. With version 2.2 in production, version 2.3 may be in acceptance test, release 2.4 in development and release 3.0 on the drawing board. Unless you know which status each items has, you may have a problem by moving a wrong component into production.
Another pitfall is the release that was successfully developed, but which did not move to production because of other business concerns by the customer. After three years, no one remembers this stalled project and items from the most recent version may be used for an emergency production patch - with all disastrous consequences, because software suddenly fails as the item moved depends on other items changed in that release.

(iv) It is one thing to write a CMP once. It is quite another to stick to it. Therefore the processes to change items and to maintain the CMP must be described too, and be part of the CMP. The processes described in the CMP govern Items, the Storage, the Status and even the CMP itself.