Stepping into the Middle of a Configuration Management Project: Watch Where You Put Your Feet

So what is everyone doing in Configuration Management? I can only speak to what I’ve seen. Lots of clients think of the Configuration Management Data Base (CMDB) as the Holy Grail of IT Service Management. And no doubt, the vendors serving this space aren’t going to do anything to dissuade any potential customer from thinking that to be a true statement. But you just have to understand what the CMDB is conceptually, BEFORE you step off a cliff and into a life-long commitment to a vendor. If you are thrust into the middle of a project that’s already under way, take some time first to think about these issues:
• Understand the requirements. If you’re getting involved in a configuration project that’s already in progress, review the specification that went into the design of the CMDB. Along with the specifications, look into the source of the requirements. That's why I recommend using a traceability matrix which requires clear specifications documentation and stratification of each requirement, where they came from and how they will be addressed in the project plan. Things to look for include ownership, views considered, users and customers of and stakeholders in the process, integration challenges with existing tools, etc. I would also ask how they intend to keep the CMDB evergreen which begs the question: What is the source of truth for the data? You’ll need to know if this is going to be a data warehouse project or a functioning CMDB. What are the CTQs (Critical To Quality) that will tell you if the project is on track?
• On this last point consider a tools assessment to make certain that all required interfaces are considered. This is an ITIL-based assessment of the existing IT Service Management tool set(s). While this is done as a team exercise, vendors are not invited at this discussion - only internal tool experts/owners. Vendors, though, may be invited to a separate session following the initial tools assessment. The tools assessment will provide an objective review of existing tools and their ability or capacity to be integrated with the yet-to-be-developed CMDB.
• Particularly if you’re coming into the middle of a project, consider auditing the project immediately. This would provide immediate insight as to the health of the project and would quickly bring an outsider up to speed on how it's progressing and what its intended outcome is envisioned to be. An effective facilitator will also gain insight as to how the individual project team members really feel about the project.
• Find out what the longer-term vision for the CMDB is intended to be. What you want the team to focus on is a relationships-based service perspective. That entails defining a SERVICE which has the following characteristics:
1. All CIs versioned;
2. Components are reusable;
3. Service is built out of the reusable components;
4. The service components will change, thus the state changes;
5. You should be able to manage the service against the established configuration;
6. You need to be able to identify and record where problems occur in the service - i.e. which component of the service fails when the service is not available.
It's this service concept that has, to some degree, given traction to the SOA. I'm not recommending a fully architected SOA but the service concept is realized as a modularized set of components which is really a robust configuration management process supported by a CMDB.
• The configuration process is tricky but should be addressed as well. If you’re going to build a CMDB, it only makes sense that you’ll need a process to support it. But it's tricky because what is hidden in the ITIL materials is really two parallel but distinctly different processes. One is the configuration process itself which is "owned" by a process owner and regularly measured and audited. The other process is the actual implementation of configuration management.
• Configuration is critical for most organizations today, particularly, government, financial and medical companies because of security and SOX compliance issues. Find out if any of the compliance folks were involved in the configuration requirements. If you accept the premise that standardization is the domain of configuration and that standardization is the only way to ensure compliance, then configuration is essential for compliance. You'll want to make sure that the configuration process is capable and will withstand an audit.