8 Tips on How to Plan for Configuration Management – Part 2

In the first part of this blog series I provided my first four tips for creating a configuration management plan. These related to getting a common understanding of the basics, setting the right scope, agreeing a naming convention, and knowing more about your IT estate. This blog offers four more tips, taking it to eight in all.

Please read on to learn more about how best to get started with configuration management through effective planning.

Tip 5: Watch the Edges

One of the most closely aligned IT service management (ITSM) process to configuration management is the change management process. Therefore, your configuration management plan needs to cover how change will interface with configuration and at what point in the change lifecycle the configuration management process will need to be called upon.

Referencing your change management process in your configuration plan means that there’s appropriate support in place to ensure that when a configuration item (CI) is updated, the configuration management database (CMDB) or configuration management system (CMS) is also updated, such that what you have in your CMDB or CMS matches exactly what you have in your production environment.

Nothing will make your configuration management capability fail quicker than your CMDB or CMS having incorrect or out-of-date information. Thus, control is a critical aspect of configuration management.

Also, work closely with change management personnel to ensure your processes are in sync. For example, you could put a process step in place where a change can only be closed off as successful when the CMDB or CMS is updated. Something else to consider is putting change restrictions or freezes in place during key configuration management process points such as baselining or audit exercises so that you have stability during these critical periods.

Tip 6: Remember Your Lifecycle

Having a section on status accounting in your configuration management plan ensures that the lifecycle stage of each CI is captured accurately. (You can read more about that in this great blog: ITSM Basics: How to Do Configuration Management.)

Some example configuration management statuses include:

• Purchased
• In test
• In pre-production
• In production
• Out for repair
• In disaster recovery (DR) environment
• Spare
• Disposed of

Status accounting ensures that all CIs that make up the service baseline, or snapshot, have been captured and that all changes have been captured by change management and are correctly reflected in the CMDB or CMS.

Tip 7: Verify and Audit

For your configuration management plan to be truly effective, you need to have a section on how you will verify the accuracy of your data as well as how to respond in an audit situation. Verification includes routine checks that are part of other processes – for example, verifying the serial number of a desktop PC when an end user logs an incident, or checking that the version of software updated in a planned change has been added to the CMDB or CMS. Also, make sure that you detail who will be doing the checks, and how often, in your plan.

When defining an audit schedule, in the plan, look to the rest of the business for guidance. Do you have any regulatory requirements such as SOX or BASEL 3, or any standards such as ISO/IEC 20000 that need to be adhered to? If so, these will probably come with a defined audit cycle.

Also, add in a schedule for internal audits. Because, when preparing for external audits, the best thing you can do is to run an internal audit first so that you can correct any potential issues, or at least come up with a plan to improve in the case of any major findings, beforehand.

Tip 8: Don’t Forget Your Reference Section

The configuration management plan should include a reference section too – that details where information has been sourced from.

When you’re creating a CMDB or CMS you’ll be talking to third-parties such as support teams, service architects, and project managers – tag these teams or roles as references relative to the information they provide. Plus, you’ll need to capture the non-human sources of information such as a service catalog, support documentation, vendor contracts, or service level agreement (SLAs) so that it can be verified as necessary before it’s placed into your CMDB or CMS.

So, that’s my eight tips for what to include in a configuration management plan complete. What else do you have in your configuration plan? What would you add to my tips?