CM as Communication and Coordination Enabler

It has long been recognised that these terms are not necessarily very clear to developers, project managers and others within your organisation. 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 - and I encourage this work.

Some of the classic signs of poor CM practices and processes are things like:

• being unclear as to what is the status of particular artefact (such as 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 you want to change something then 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 of the things that is important for CM is being clear about documentation of what you are responsible for. ITIL refers to this as the Service Catalog.

It may seem like a simple and obvious concept, and yet it can be surprisingly difficult in practice, and many organisations are not in very good shape.

Classic problems:

• inconsistent naming conventions

• duplicate names for the same thing (particularly in different parts of the organisation)

• unclear boundaries and definitions of what is part of what
• whole areas being excluded (overlooked)

We had experience at one client where a major outsourcing contract 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. And yet 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 or what?! Which one is correct?! Is there actually more than one system?

You also have to be clear about your definitions of terms within the organisation - and these are typically going to be specific to each organisation.

For example, larger organisations have projects which change existing systems and/or deliver new systems. Projects may be grouped together as programmes - multiple concurrent related projects - delivering together. You need to be clear about project names (ensuring they can be uniquely identified where appropriate). Also, when is something a project or a programme - is it financial (e.g. > $1,000,000 means a programme?).

Dependencies

To paraphrase John Dunne: "No application is an island, entire of itself". Organisations of any size may have hundreds of individual applications and systems. These will be linked together and depend on each other, so a payments gateway to a third party may interface to multiple applications within your organisation.

Because of these dependencies, you need to manage change appropriately - you often need to change multiple applications at the same time to implement some new piece of functionality.

This question of co-ordination becomes more complex when you factor in multiple projects proceeding in parallel, more than one of which may require to change the same applications, but in different ways. These changes must be coordinated and implemented together.

In addition, if you think about making releases to multiple applications at the same time, you need make sure that changes are tested appropriately, and synchronised according to the requirements as to when they will be released.

It is