Formal configuration management enables a resulting project with good change management. One where changes that are properly identified, structured, linked and owned. Configuration management provides the documentation explaining why the project changes occurred, who approved the changes, and who the assigned change owner is.
The PMBOK says that the Project Manager is responsible for the following change management responsibilities:
- Recognizing when a change has occurred.
2. Filtering out changes from inappropriate people.
3. Ensuring that change is beneficial.
4. Managing the changes as they occur.
Configuration management is the system for performing these responsibilities as well as providing product, system and software version control. The primary disadvantage to configuration management is that it takes time, costs money, and can bring with it a level of formality that some people view as unnecessary or are uncomfortable with. If all project managers were walking computers, we wouldn’t need formal documentation and configuration management (CM) tools. But, since PMs are generally juggling many complicated priorities, can’t remember all of the details, and more importantly can’t communicate everything perfectly, they may need to take the additional time to use more formal CM techniques.
Customers can be resistant to formal CM efforts. This level of documentation work takes time, and when in an urgent rush to get productive work done and minimize project costs, they may not see this work as directly adding value to their product. Some customers do not want to pay project management rates for what may be perceived as clerical work or work that could be handled less formally. It’s also possible that some customers don’t want change handled formally because the ramification is that they will be charged for changes which they would prefer to slip in unnoticed. This brings us back to the advantages of a configuration management system, because it informs the customers of how changes are going to be handled from the beginning.
The Institute of Configuration Management (ICM) at http://www.icmhq.com provides certification in CM. I’ve provided a few guidelines and best practices for general configuration management below, which is oversimplified compared to the level at which it is discussed at ICM. This discussion is geared towards a small-to-medium sized project environment, which is one at a much lower-technology and complexity level than those where configuration management software tools are usually employed.
The most important guideline for use is to start CM early in the project life cycle. The project manager should assess potential fluidity early on and create the appropriately scaled configuration management system during the project planning rather than half-way through the execution. According to a Best Practices in Change Management Report, when asked what they would do differently next time, most teams say they would begin their change management activities earlier in their next project, instead of viewing it as an add-on or afterthought.
Develop a Clear Baseline
It is important to develop a clear baseline plan (i.e.: the project description as defined at the beginning of the project), as well as document different versions throughout development, and the final project as released. This contrasts with lean development techniques, which tend not to define a clear baseline plan or use formal project configuration management.
Consider CM for Project and Product
You should consider configuration management for two areas: 1) the project management changes and 2) the product or content changes. For your project, this is evidenced in changes to processes such as approvals, budgets, schedules, or acceptance. For Products, this is particularly evidenced in content for business legal projects such as employee Intranets, where policies and benefits may change over time, and the company often needs to be able to document exactly what a specific policy was posted at for a specific date in time. I have had some experience with content CM while being the initial project manager for the American Standard Corporate Intranet. For this project, we limited our configuration management to the Intranet application functions and certain content areas that were legally sensitive, such as employee benefits and policies.
Another best practice is to document who is the owner for different parts of the project, including product features and functions as well as specific content. When these owners turn over, and the next person brings a new perspective to the project, there is normally a temporary increased rate of change. Stakeholder support for project changes and the configuration management process are critical to the success of the system. With the CM processes, the change acceptance decisions should be made at the level of an appointed change control board (CCB) and generally above the project manager level. However, the project manager often is critical in ongoing project balance – making adjustments to keep the project within approved cost, schedule and quality outcomes.
Plan Change Documentation
There are very complex and comprehensive CM software tools available to manage your CM effort. But, in certain projects simple configuration management tools are the best. For example, I have used a simple change tracking table in instances when I can create a clear project plan that is fairly stable and where my customer is the change control decision maker. In such cases, I add a table to the baseline plan document, like the excerpt shown below:
|Change ID||Date (latest on top)||Section Number||Description|
|2||9/8/18||TS6.2||The Macintosh operating system that is specified as a
testing platform was upgraded from OS 8 to OS 9.
|1||9/5/18||TS3.2.3||IIS Index Server Functionality was specified for the
Hosting provider for the keyword search. (The
programmer specified this during the project estimation.)
For this to work effectively, the plan document must be originated with careful attention to section numbers, which are manually entered so that they are not automatically changed when document changes are made. (The default outline feature in MS Word® is set to auto update numbers, which is not desirable for consistent CM.) When this is the CM method, the rule is that nothing in the plan document gets changed unless it is logged into this table, thereby tracking all project management and product changes. The minimal fields for this table include the four shown. Each change is given a unique ID, the date the change was added is recorded, a section number reference, and description. The documentation is given section numbers for every paragraph from the product description to the project management plan. This helps readers physically find the changed section of the document. And finally, the change to the project or product is described in as much detail as needed. If helpful, the Word track changes function may be used to help save the baseline plan wording compared to the changes.
1. CMII – Model for Configuration Management Rev B), White paper published in PDF form on the Web site for the Institute of Configuration Management. The Home of CMI, published in 2003.
2. Burrows, Clive. Configuration Management, Coming of Age in the Year 2000. http://www.stsc.hill.af.mil/crosstalk/1999/03/burrows.asp.
3. Change Management Resource Library, http://www.change-management.org/.
4. Best Practices in Change Management, http://www.changemanagement.com/best-practices-report.htm.
Contributed by Kay Wais, PMP
Successful Projects, LLC