It has long been recognized that these terms are not necessarily very clear to developers, project managers and others within your organization. There have been some recent discussions in the CM Crossroads forums about terminology and the CMBok (Body of Knowledge) has resurfaced with Mark Bools trying to prod things along.  I encourage this work.

Some of the classic signs of poor CM practices and processes can include:

• Being unclear as to what the status of particular artifact is, including a software module or an application.
• Which is the master version?
• Which version was released and when?
• Why was a particular change made?
• What was the precise change made?
• If something needs changed, what process needs to be followed?

This brings Rudyard Kipling's short poem to mind: 

I keep six honest serving men
(They taught me all I knew);

Their names are What and Why and When
And How and Where and Who.

An Application/Service Catalog

One important aspect of CM is being clear about the documentation of what you are responsible for. ITIL refers to this as the service catalog.It may seem like a simple and obvious concept, but can be surprisingly difficult in practice, and many organizations are not in very good shape.

Classic problems include:

• Inconsistent naming conventions
• Duplicate names for the same thing, particularly in different parts of the organization
• Unclear boundaries and definitions of what is part of what
• Whole areas being excluded or overlooked

We had an experience with one client involving a major outsourcing contract that referred to a list of 100+ services. It quickly became clear on investigation that there was no definitive master list of these services. There were a variety of spreadsheets floating around, but they were all slightly different. Still, a multi-million pound contract had been signed with this unclear definition of what was being provided.

An example in Geoff's work was:

• Forex
• XXXX
• FourX

Do these refer to a foreign exchange trading system, an Australian beer? Which one is correct? Is there actually more than one system?  Clarification was lacking.

Organizations must also be clear about your definitions of terms, as typically these will be specific to each organization. For example, larger organizations have projects that change existing systems and/or deliver new systems. These may be grouped as programs, such as multiple concurrent related projects, that are delivered together. Project names must be clear to ensure that they can be uniquely identified where appropriate. Also, when is something considered a project or a program?  Is it financial (e.g., > $1,000,000.00 equates to a program?) or do other factors decide this?  

Dependencies

To paraphrase John Dunne: "No application is an island, entire of itself.”

Organizations of any size may have hundreds of individual applications and systems. These will be linked together and depend on one another, so a payment gateway to a third party may interface to multiple applications within your organization. Because of these dependencies, change must be managed appropriately.  Multiple applications often need updated at the same time in order to implement some new piece of functionality. The question of co-ordination becomes more complex when factoring in multiple projects proceeding in parallel, as more than one may require change to the same applications, but in different ways. These changes must be coordinated and implemented together. In addition, when considering making releases to multiple applications at the same time, be sure that they are tested appropriately and synchronized according to the requirements in relation to when they will be released. It is surprisingly common to find the same applications have been changed by different projects looking to release together, but without the projects aware of each other until late in the process. This can cause unexpected delays.

Coordinating Change Across the Organization - Who is Responsible?

It is vital that for each service/application there is a definitive, responsible owner who makes decisions about that service/application. If there is not a single owner, generally speaking, there is no owner.  Involving service/application owners in changes is a simple coordination mechanism.

A simple table or spreadsheet such as the following is remarkably effective in communicating and coordinating change across the organization:

Geoff started pulling together this information and publishing it on their intranet. Though he took responsibility for pulling it together initially, he intended to make others (application owners) take appropriate responsibility for making decisions and coordinating changes across the organization.

One mistake organizations make is to confuse responsibility with documentation. Because CM people understand the principles, they often take it upon themselves to pull out the information and then communicate it (intranet/information radiators). Just because the CM team has pulled the information together, though, doesn’t mean that they’re actually responsible for changes or deciding what to do. 

Change in Status

While a simple table conveys a good amount of useful information, it becomes even more useful if changes and updates are easily made:

It must also be very clear where the definitive version of this document is and what the process of changing it is.  For example, who has access rights and how will concurrent updates be detected? Wiki pages with version control can be very effective, but be aware of the trap of using spreadsheets, as they are often hard to compare and, with email updates, it quickly becomes difficult to track status. Once information is obtained, it is vitally important to ensure that the information is maintained and kept up to date. If people start mistrusting it because of errors, or because the information is out of date, then it quickly loses value. Don't go overboard with the information that is shown.  If it is too difficult to update, then it will also become out of date and get ignored. A variant of a simple dashboard has become common with many tools in recent years.  Still, you don't need to go overboard with the technology behind it to get great value and usefulness from it.

Geoff successfully used this within the bank, and some quotes from management included:

• “I didn't know I owned all of those apps.”
• “That's not one of mine!”
• “I'll get the developer to check.”
• “Great, just what I wanted for the next release.”
• “How do I trigger a change to the list?”

Custom Fields/Columns

Consider the requirements for your organization in deciding what information is of value. It can be very useful to have an indication of criticality, for example, and this will depend on the requirements for each organization. Some applications/systems are internal only and not many people will be affected if there are problems. However, if a component of a public facing web site is down, this can have very serious implications for the organization, including financial implications and, potentially, damage to reputation.

Audit, but Not the Type You Were Expecting

The increased need for control, particularly SoX in financial organizations, brings the need for a catalog into sharper focus. It further increases the pressure on CM to become the central point of knowledge. Geoff has continued his “spreadsheet” concept with other organizations, providing summary output for external auditors. IT Service Managers are delighted when they can prove to auditors that they are truly in control of their systems. Have we moved on from “configuration audits” to “service audits”?

How Do You Get Started?

The easiest place is to start at the top! Senior management very quickly understands the power and usefulness of such concepts, and will provide the necessary resources and backup to make it happen. In order to persuade senior management, a prototype with a few fields is incredibly effective. This takes some initiative on your own part.  The idea is then to pass control to a “real owner”. Very often management won’t buy-in without providing an example of what they are missing. There is a role as an "information collector/disseminator," but it’s important to note that this is not the same as being responsible for deciding which changes should be implemented and when.

Conclusion

The principles described here are fairly simple, yet are often not practiced within organizations. It may not be in the job description of CM, but it is an area that can definitely add value and, indeed, help to educate the organization    about the value of CM and its principles. Though it may not seem particularly agile or lean related, we believe it conforms to both those principles. CM is not just a dry and dusty academic discipline, its principles are foundation stones for successful organizational management. We've all seen the problems caused by lack of clear identification, change control and status recording; let's get out into our organizations and improve communication and coordination. As the Japanese would say: Gambatte!

References

See Geoff Thorpe's Presentation at the BCS CMSG website.