Configuration Management

The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

In this article I am going to explain about Configuration Management(CM) and share my experiences in setting up CM processes for projects.

One of the secrets of projects that are having minimal rework effort is that the projects have a proper configuration management process. Whenever a new project is started the first process area I start with is Configuration Management. This is one process area which covers all the assets in the project starting from the hardware to the software delivered to the end customer.

Most of the projects that I worked early on included only source code of the project and the version control system under CM. This is where the problem starts. In some of the projects I worked on the development task took only one day to complete but to deploy it to build, test and stage environments took more than 1 day for each environment. The deployment was simple XCopy of files to a specified folder but the environments were not consistent and the application didn’t work after deployment. I am sure many project managers can vouch for this problem in their projects.

In one of the projects I worked on all the applications suddenly stopped working. The developers investigated two days to find out that the database team which is a shared service across organization changed a database users role. The same issue happened again few months later but this time the root cause was very tricky to find out. The problem happened because the network team which is a shared service across organization changed the IP address of few of the servers.

In my first project I was assigned the role of creating setup files for the product. I worked for the development team and there was another team called support team who do installations of the product on client servers. Since the project didn’t have CM process and documentation one of the freshers in the team picked up an older version of the setup on the client’s server. This almost led to the firing of that team member.

The starting point to define CM process is to identify the list of assets that needs to be tracked and defining their life cycle. Here are few of the assets I track in projects.

  • Hardware configurations
  • Server Operating Systems configurations
  • Desktop Operating System configurations
  • User Accounts
  • Network Shares
  • Software Deployed
  • Backup and Recovery Storage
  • Documents

The next step in CM process is to define the life cycle of these assets. Most of the projects I worked on have only half of life cycle defined for these assets. The CM plan will be missing the archival stage of the life cycle for most assets in the project.

The third step in CM process is to define the audit process and audit points for the assets. The key item in the audit process is to define to how track the status of an asset and how changes to the asset has to be performed.

Most of the projects now use one or more shared services like database team service, network administration service. It is better to work with them and explain the CM process followed in your project so that you can track the assets that are owned by the shared services team but used by your team.

Another point to consider when defining CM process is to work with other development teams to defined a combined CM policy and procedure for shared assets so that the software installed by one of the teams does not break the applications of other teams.

The last step in defining CM process is to identify the team members and assign them ownership of the assets and identify the CM audit personnel.

The next step is to put what is in paper to practice. Do the CM Audits as frequently as every month initially so that team members adhere to the CM processes and maintain assets in proper state of its life cycle. Once the team follows the process rigorously then reduce the frequency of the audit to every 6 weeks.

You can also keep CM audit as a post process for your sprint cycle and include that in your project learnings.

In the next post I will explain in detail how to implement it specifically for a development project and how to track and automate part of the CM processes for efficiency.

Credits and References