Configuration Management can be confusing for some, especially in concert with all the other knowledge areas and processes associated with project management. Therefore, I would like to clarify what configuration management is and how it is supposed to work in this article.
First of all, Configuration Management is linked with Change Management. However, the former is mostly associated with product requirements and features and tracking and monitoring any changes to these requirements and features. Change Management, on the other hand, is there to monitor and track changes of any kind, including those associated with product scope change, but also non-product related changes, such as cost overruns and/or schedule delays, among others.
The following examples will help you understand the difference between Change and Configuration Management:
- Example 1: the client notifies you, mid-way through a project, that she wants to change the battery charge storage from 4 hours to 8 hours. In other words, she wants to double the amount of charge the laptop has before the user has to charge the laptop battery again. This request will obviously generate a change request, which will impact the following:
- Scope: since this is a new requirement, the scope of services must be updated and the corresponding scope baseline revised.
- Cost: more budget is required to perform the additional work
- Schedule: more time will be required to redesign the battery and other systems.
Other parts of the project might also be impacted, such as Quality, Procurement, Stakeholder Engagement, and Communications. However, such a considerable change to product requirements will result in an impact to:
- Configuration Management: this will occur because the battery charge being increased will most likely result in designing a larger and, therefore, a heavier battery that needs to be integrated into the overall design. Also, a larger battery might mean that the laptop may not be as thin in width as originally planned. As you can see, configuration management ensures that the non-administrative parts of a project, which are scope, budget, and schedule, are also taken into account. These refer, as noted above, to the product scope and requirements. In this case, the design of the laptop.
- Example 2: if in the fictitious example used in Example 1 above, the client had only asked to move the deliverable deadline up one week, and the product (laptop) requirements remain the same, then change management would be used to determine the impacts to scope, budget and schedule as described above, but Configuration Management would not be required, since the product features are not changing.
As you will note, a change to product requirements will activate the Change and Configuration Management processes to address the change properly. However, if a change is not associated with the product features, only Change Management is required. In other words, Configuration Management requires Change Management to function, but Change Management can function without activating Configuration Management procedures.
Mr. Doherty has a long history of business development, financial strategies, and planning. He has launched and managed several ventures personally, so he understands the challenges of managing day-to-day operations in an uncertain environment. He strongly believes in adopting Agile methodologies to deliver customer value early and often consistently. His combined startup background, along with Agile expertise, allows him to help his clients deliver products in an efficient, cost-effective manner to meet the ever-changing needs of their users continually.
