In all projects that I have been involved with that have had input from an outside consultant the question has been asked about what sort of Configuration Management we were using. In none of these cases has the consultant been able to define Configuration Management. So what is it?
What Software Configuration Management (SCM) is boils down to answering the following:
- What source files where used to make our end product?
- What has changed from the last time we made our end product?
- Why did we change it?
This in turn can grow to a quite large and ugly "process". The process issues are why most developers eyes glaze over at the mention of SCM, as this means tracking source files, defects and requirements; then tying it all together so you can audit changes (This is an Ideal world from a management point of view as it gives a good manager tools to better see what resources he needs where.)
This is different from ITIL Configuration Management which is actually software asset tracking, what software is running where (which server/ workstation) and what is the setup for that software.
In other words your consultant more then likely wants to know is how YOUR company/development group answers the three questions at the top of my answer.
Configuration Management encompasses "everything else" that's not directly related to writing code. So it's how you manage releases, how you manage and triage bug reports and feature suggestions, how you perform your builds and so on. It often also includes how your source code is managed (e.g. what version control you use, branching strategies, how you [possibly] manage multiple concurrent "releases" etc).
Configuration Management has meant a lot of things over time. I consider it more important to administrators or operations than directly to developers. When your an operations person trying to keep servers up and running you worry about setting up machines, managing their configuration, and keep it running. If you just log into a computer and start installing software, and changing config files on a machine you're not managing that configuration. What happens if that machine dies? What happens if someone goes on that machine and changing a config file and everything starts to freak out? What if you need to start up another machine configured exactly like the one that's running? Can you do it?
Without a configuration management strategy you can't. And that's why it's important. It's all about repeatability. Developers approach repeatability differently than operations people do so we care about repeating different things.
There are some great open source tools that help you do this: Chef, Capistrano, Cook, and even SVN. Why should SVN just be used by developers? Check in your config files, scripts you use to configure machines, and track their versions. Those parts of your organization are vital to keep it running. You don't want to loose those.