So you think you know all about configuration management

Configuration management: the dos and don'ts

We often see that governance initiatives yield the full benefits only in mature organisations in which senior management fully supports configuration management (CM).

CM handles relationships between configuration items – and if senior management allows a favourite project to ignore it, failures in related projects are likely.

The repercussions may even rebound on the favoured system, as it is unlikely to operate independently. In these cases CM may be seen as an overhead without benefits.

Light and shade

As I explore later in this article, there is a dysfunctional “dark side” to most things that work – even senior management support – if you do those things wrong.

Let's start with the light side. Having well-trained people with access to good information and good technology-enabled processes works well for CM, as does having the right skills-transfer partners or consultants as mentors.

CM is about helping people manage technology, not about replacing people with tools.

A well-planned and properly resourced CM implementation, with buy-in from the business process owners, tends to succeed. And it should have realistic scope and objectives, agreed by everyone involved.

Start small, demonstrate success and then grow

Start small, demonstrate success with a limited scope and then grow. At all times, communicate clear benefits to stakeholders – and don't stop after implementation.

That is the “light side”, as identified by participants in the interactive sessions at the British Computer Society Configuration Management Specialist Group conference in July 2008. However, a dark side was identified too.

Lack of senior management commitment is certainly on the dark side, but less obviously so is too much commitment or the wrong sort. CM imposed by decree, without consulting the people who have to use it, can be fatal if managers are telling those at the sharp end how to do their jobs.

That is when you start seeing viral adoption of open-source tools. There is nothing wrong with this per se – but it can be risky and wasteful if you are paying for expensive commercial tools at the same time, and if your open-source tools lack a support contract.

An unfeasibly large CM implementation with ill-defined objectives is often associated with poor management support. This is bad news, especially if combined with poor planning and unrealistic expectations of short-term return on investment.

You might think these issues are obvious – but CM implementations do fail and often for these very reasons.

A less obvious cause of failure is a siloed approach – islands of CM. This is perhaps the dark side of the “start small and grow” story.

Blame the tools

It should be a case of think big, build small: your initial, limited-scope CM implementation should be the basis of a larger conceptual framework.

Looking at only the technology while ignoring people, process and data is a recipe for failure too, as is overlooking dependencies on other projects (such as implementation of Agile and systems engineering).

It is also worth remembering that CM is likely to fail if your overall development processes are poorly designed or implemented.

And poor tool selection processes are often a route to failure (as in: “We have XYZ in-house already, it will give us a tool cheap, Gartner says it's OK, we will use that. Now, what does it do…?"). Good tools are an important enabler; bad or inappropriate ones can be a disaster.

To conclude, CM is A Good Thing – but making it work requires commitment, investment and skilled people. ®