Who is responsible for ITIL configuration management?

(This reply was also posted on "IT Service Management Forum" LinkedIn group in response to Trevor Usken's discussion posting )

The comments before me all bring up some good points. I’d strongly suggest that you do not give the ownership/accountability of Configuration Management to anyone/group who may be the cause of a failed/unauthorized modification to the production environment because then they may be more interested in covering it up than resolving and documenting the issue/incident.

If your organization is large enough to warrant a separate and distinct CCB, then I’d suggest doing that. If you have a smaller organization, then I’d still seek to implement the intentions of a CCB by leveraging existing resources to make sure you have a strong check-n-balance model in place.

Ultimately, there needs to be one who is accountable, the old “one throat to choke” statement comes to mind. But, you need to make sure this person has enough authority to make things happen such as when discrepancies are detected across the federated data sources. What will likely be most successful is a layered/hierarchical accountability model. Establish metrics that you can measure regularly and report on them so that all layers of accountability are kept in line with the primary objective.

If you have any more questions, please feel free to contact me directly,
Carlos

Carlos Casanova
Email: info @ k2sg.com
http://www.k2sg.com
http://www.cmdbimperative.com

There is no definitive answer to this as it will very much depend on the 'configuration' of your organisation.

The key element is not who will take responsibility for the work itself but who will 'own the process'. It is essential that someone provides governance ensuring that the process is documented, published to all stakeholders, regularly reviewed and updated and most critically, enforced.

Most ITIL / Service Management initiatives fail due to a lack of management buy-in or a lack of empowerment for the process owners. It is therefore critical that the Config process is supported from the top and that those responsible for carrying out the work have the credibility / authority to do so.

In terms of those carrying out the work key roles are

Change Manager - will authorise (through CAB) changes to CI's
Release Manager - will ensure properly formed releases and update CMS as appropriate
Config Manager / Librarian - if appointed will manage the Config information and its maintenance

All ICT staff should be responsible for the CMS data and ensuring that it is accurate and up to date, escalating issues when discovered and ensuring that all relevant policies are adhered to.

Sticking to your core question, and adding up to Carlos' points, I believe there are 3 main guidelines:

1. Even if you are a small shop, set up a separate team, even if minimal. As Carlos said, operational teams let on the loose will naturally tend to cover up their own failures. But not only that. Additionally, not all existing teams will have the required expertise (Change/Incident/Release for example). Finally, operational teams usually have already a hard time running the business. Additional burden will be postponed to death.
2. In the bottom line, CM is a process. Supported by tools, but nevertheless a process. Thus, any process-oriented mind with a good IT background could be in charge. Give him/her a good ITIL implementation training. In a bare minimum, add up a skilled tech person and a process analyst. Here you go, a CM team!
3. Again Carlos' advice is fundamental. The team leader needs to be accountable, but also needs the necessary authority to demand compliance. Yes, CM needs compliance from operational teams too. For example, give the CM owner authority to reject a RFC if not compliant to CM rules.

Last thing. Configuration, Asset, Change and Release Management are part of a chain. Owners must agree on procedures and strategies.

Hello All,

I have some experience at a large company were the Configuration Database was populated and contained over 100,000 components from various federated source. Our model was to follow the ITIL standards and have Configuration Managers own components and architecture, while the Configuration Team oversaw the entire process.

The Configuration Managers were responsible for loading the initial components and defining the hierarchical relationship architecture. The Configuration Team was responsible for overseeing the component loads and creating reconciliation reports to monitor and report to the Configuration Managers.

The Change Managers were also responsible for monitoring for the correct component on Change records, and also reviewing information in the Configuration Database based on what was put in the Change records. This allowed another level of validation and reporting back to the Configuration Managers.

One of our issues became the load of Asset information, which should also be the start of you component records. This process was not fully mapped out and caused many duplicate components to be loaded in the Configuration Database, because we were not classifying the components consistently. You really need to have the complete Asset to Component to Decommission life cycle process mapped out before you take this on.