We’ve all probably heard, and even used, the phrase “fail to plan, plan to fail” but never has this been more pertinent than when planning for a corporate IT configuration management capability – from strategizing, through selling the investment in it, to using it to make a difference to IT and business operations.
Ideally, configuration management is one of those ITIL and IT service management (ITSM) processes that should sell itself, but the reality is that it’s much harder to get buy-in for configuration management than say change management. Then, once an initiative has been started, configuration management is an ITSM capability that can quickly spiral out of control, consequently failing to deliver on the promised positive business outcomes, and thus it needs very careful planning in order to be effective.
Don’t worry though, this blog contains the first four, of a total eight, top tips for creating an effective configuration management plan, one that you’ll have no trouble “selling.”
Start by explaining that ITIL’s service asset and configuration management (SACM) is the process (or capability) responsible for ensuring that the assets required to deliver IT services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.
It's also a case of setting the scope and boundaries for configuration management – what it is and isn’t, and what it will and won’t do. Thus, the plan’s introduction (or a referenced appendix) should include an overview of how configuration management will work in your organization, along with objectives and key outcomes.
This will likely include:
One of the primary reasons configuration management initiatives fail is because people try to do too much too soon. So setting the right scope is a key part of your plan. When planning for configuration management, there are two key approaches:
The latter approach is usually the one taken, as it provides maximum value early on.
Then there are three basic layers to consider:
The inventory (management) layer takes care of consumables: keyboards, mice, CD drives (if still used), power cables, USB sticks, security peripherals, etc. It’s all about equipment that needs to be tracked for monetary value and to make sure that it’s in stock…but that’s about it.
The next layer is assets or asset management. Example assets include: PCs, laptops, and printers. This is still the stuff that we need to keep track of for monetary reasons and to make sure they’re in stock when needed, but we also need to know locational information and how they are supported.
The final layer is (configuration) items under the control of configuration management, which are often the important items that make up your critical IT and business services. Servers, network devices, and business applications are all CIs that should be under the control of configuration management to ensure that they are managed, supported, and subject to the appropriate change control.
The plan should explain any proposed, or agreed, naming conventions or nomenclature. Confused? Every CI or item that’s under the control of configuration management should have a unique name or identifier. When I’m tasked with implementing a configuration management capability from scratch, I try to use a naming model that will make it easy for the CI to be identified. So I tend to use something like the following:
Type of Service – Location – Level of Complexity
So a WinTel server based in New York requiring third-line support would be WinTel1234-NY-L3 and a business application located in Dublin requiring first-line support would be BusApp1234-DUB-L1, and so on. In terms of naming conventions, it doesn’t matter what logic you use, as long as everything has a unique identifier.
A key part of your plan is the baselining process, taking a snapshot of the critical services and their key dependencies so that we know exactly what makes up the IT or business service. The purpose of a baseline is to take a measurable part of the service so that it can be added to a CMDB (configuration management database) or CMS (configuration management system).
Since it’s a snapshot of the state of a service at any given point in time, it can be used as part of change management activities. Because, if the service has changed, there will need to be a valid, authorized change request against it, as well as being a stable reference for future planned change works.
However, don’t fall into the trap of trying to capture too much data at first – you can always build things up later. If you try to go into too much detail when starting out, you might run out of time and money before achieving any communicable success. Also bear in mind that the more detail you capture, the more work it will be to maintain it.
Here are some useful CI attributes to capture as a starting point:
So that’s my first four configuration management planning tips. Want more tips? Please come back soon for the second part of this blog.