Article Overview
Change Management is a structured process with tools to capture the best information of the change requested and the impact, positive or negative, to the project or product in terms of cost and schedule. Keep reading this article to find out more about the different approaches to manage the changes.
Table of Contents
- Overview of Change Management
- Why Change Management
- What is Change Management
- Different Approaches
- Conventional Approaches
- Agile Approaches
- Connection to Configuration Management
- Conclusion
Projects and Product Development can have a measure of fluidity. That is, we may not know everything. Things change in projects as well as products as we do the work and learn. As we are doing the work, we should have an eye toward getting a better understanding of how we are going to meet the project objective and the defined scope. There are times we may have a pretty solid idea of the product at the beginning of the project, perhaps this is a new version of an earlier project.
There are times when what is known at the beginning of the project is only a fraction of what we need to know, and maybe we know that, or maybe we do not. Even in instances where we have very good information, things can change, and the ability for the project – or product, to adapt to whatever we learn along the way.
From our experience, a significant cause for project failures and product rework, which has a depending consequence of late deliveries and budget-busting, due to the uncontrolled change to the product and impact upon the project.
A new iteration of a vehicle is under development that has changed in a few components. For one of the components, a marketing person approaches the developers, with a request to change that component. The developers make the changes to the component and deliver an instantiation of the product for testing and integration into the vehicle. Of course, the vehicle integration effort produces a failure, and the reason for that failure, is one component of the system changed, but the other interfacing components or parts were not updated to accept this change. This required an expenditure of effort to find out why the system did not perform as documented in the requirements and then to perform the rework. This was effort and rework not accounted for in the project effort, waste of time and at a cost to the project. 
In another instance, we saw changes to physical parts of the vehicle left uncommunicated to other parts of the company. Eventually, the disparate parts come together to produce the vehicle and a bulkhead shows up where the wire harness was supposed to go. Meaning, the wire harness could not go to that part of the vehicle. The redesign comes unexpectedly and at a time when the team is working to build a prototype version of the vehicle from which learning can happen. We have seen many projects go over budget and deliver late due to rework required to solve issues like this one. When this obvious lack of change management was taken to the ISO responsible person in the company with the lament that we have no change management process, he promptly whipped out the company’s work instruction book and turned to the page, and declared, we have change management.
Yes, on paper you have change management yet this project alone is over budget by millions and late by months at least in part due to uncontrolled changes.
Change Management is a structured process with tools to capture the best information of the change requested and the impact, positive or negative, to the project or product in terms of cost and schedule. Costs considered are the resources, human and material, required to deliver the proposed change. This should include a rework of any previously executed work or material purchases. Schedule impact should include the time required to make the proposed change, any additional time to rework and/or acquire new materials, and any quality or testing time. The change management system helps coordinate the response to the prospective change, who needs to change what to produce the final expected or desired result.
An adequate change management system can ensure an understanding of the impact of any proposed change on the project, product, and/or system before we undertake the effort. Understanding the cost and schedule impact is necessary to make a rational business decision.
There are a variety of ways in which to manage a project, and therefore, there are numerous ways to manage the changes. There are attributes of how to undertake the change.
- A mechanism for recording the proposed change – delineating one from another (alphanumeric or naming designator)
- A mechanism for understanding the impact of the proposed change on the project and product
- An acceptance or refutation of the proposed change
- A mechanism for identifying the version that includes the change should it be accepted
- Verification of the introduction of the change.
- One less known or used approach is to charge to produce the proposed change documentation. Usually, the same people executing the project have to be pulled off their work to research the change’s impact. This time is not a line item in the original budget.
Conventional project management identifies the objective and the scope of the project early in the project. That is not to suggest that things cannot change, though some may believe that to be true, defining conventional approaches as a waterfall. Waterfall is often presented as all of this first part of the work (for example specification work) then all of the next (developing the product) with no update to one of refinement. We have never worked on a project to produce a product that used this approach, and we have worked many conventional automotive and industrial projects.
There are iterations of the work, different than agile approaches – for example, the time for iterations are spaced further apart in time. Specifically, rather than 2 weeks to 4 weeks, the iteration may require a few months to produce. At the end of that iteration, there will be a review, testing, customer reviews and more to learn about the product requirements and customer needs, and in what way we need to move the product in the next iteration, that will move us toward the end result needed by the customer and the organization. For example, in automotive product development, specifications will be written, delivery of an iteration of the product with the prioritized portion of the requirements will be delivered for testing and evaluation. This will generate updates to specifications, a release of those specifications and the development of another iteration of the product. This loop continues until the product is as the customer desires. Each iteration will have a new part number, and fit into a defined prototype level.
Agile approaches the project operate in a different way. Rather than write specifications upfront, we identify the features of the product in the product backlog. The product backlog is the desired end result of product content at a specific future time. This does not mean that all of those features will be delivered in one increment, but some prioritized portion of that will be moved into the sprint where the work is performed. The change management comes in the form of changes in the product backlog and this can happen from the customer or from learning about the product as we work to develop via the sprints.
Eventually, these components of the product backlog will either end up in terminated or in the sprint backlog. Once a sprint is underway, there will be no changes to the product (ideally anyway). This is not a problem as the iterations are typically short focused durations as noted above between 2 weeks and 4 weeks and in fact the shorter the better. In this way, the changes happen in the product backlog and only vetted and approved product backlog items are allowed to make it to the sprint backlog for work.
The changes accepted (and even rejected) are traceable via configuration management. Configuration management connects the product documentation to the product incarnation, through systems incarnation to manufacturing, and allows for traceability forward and backward in time. With configuration management, we can directly trace the differences between product incarnations. Those of you familiar with product release notes have seen but one of the elements of configuration management. While, this is not configuration management how-to article, but it is important for the project manager to understand that change management and configuration management are connected and will apply in any method of project and product management approaches. Configuration management is larger than product change management and is connected with testing, manufacturing, and future product iterations.
Experience indicates that poor change management controls will ensure a project is over budget and late, and definitely not a team morale builder either. The more distributed the system, or the more components the component under development must interface, the more important it is to have an effective change management system. This is especially true for distributed product development, where there are multiple suppliers for a complex system. Lack of change management control will result in a dysfunctional, costly rework, and delayed product. This is not the road to success, and we have many ways to solve this issue.