Editor’s note: This article was reviewed and updated on 16 September 2024.
The change control process is a method used by teams to capture, manage, and communicate any deviations from the agreed-to plan or initiative. Part of this process includes using a change control document or change request form to request and document changes.
As the famous quote by Benjamin Franklin goes, “In this world, nothing is certain except death and taxes.” In life — both personal and professional — change is inevitable.
Change can occur at a micro scale, such as the particular team you are working on, or at a macro scale, such as a change in the company’s goals or strategy moving forward. Regardless, the inevitability of change means that there should be some foresight by product managers.
PMs need to put methods, frameworks, and systems in place that minimize the adverse impact of changes and maximize the positive potential, both for themselves and their teams. This could include establishing a formal change control process, templating a change control document, and more.
As a product manager, it is your responsibility to look a few steps ahead into the future, identify the risks of something that either might potentially change or is bound to, and put together a process to mitigate the negative effects of that change — all whilst simultaneously informing stakeholders about the reason, impact, and mitigation tactics.
Change can happen at any point during the software development lifecycle (SDLC), which can either make or break the ultimate delivery of your plan. Establishing a formal change control procedure allows you to efficiently identify, validate, evaluate, and execute the change, documenting along the way.
Although a product manager can be involved in all types of changes within the company (including the larger macro strategy of the company moving forward), the type of change we’ll cover here are those to the delivery of your expected epic, feature, or initiative. The “delivery” (or “deployment”) phase of the SDLC is rife with uncertainties, ranging from delays, unexpected problems, and changing requirements, which can all impact your initiative moving forward.
Throughout this process, the product manager is expected to consider how these impediments or changes in direction can impact the delivery of their initiative, as well as communicate the decision that they make around whether they accept, reject, or modify the change to suit the successful delivery of their feature.
Contrary to popular opinion, the differences between change control and change management are not as wide as they seem.
Change control is a part of change management, as it is a way of communicating the changes being made, the impact of those changes, and what is being done to mitigate them. There’s usually a formal change control document that lives within a wider change management strategy for the company.
Conversely, change management is a wider umbrella, encompassing different types of change control procedures. This can include budget and resource allocations, communication channels between different types and levels of stakeholders, and directly responsible individuals (DRIs) at every level of the chain when making changes within the wider organization.
As such, both are complementary to each other. The change control process lives inside the wider Venn diagram that is change management.
The following are the advantages of following a well-structured and fully communicated change control procedure:
Creating and sticking to a formal change control process can help improve not only how your team can work together to deliver the intended product or feature, but also the effectiveness and efficiency of your team. This can result in a better quality product overall.
The change control process facilitates these benefits by enhancing communication and visibility. Using a change control document ensures that the changes you’re planning to make are clearly described, along with the reasons behind why the change is occurring in the first place.
Your team and interested stakeholders will have all of the information to piece together what needs to be done and can work creatively together to ensure that this works long-term.
Providing increased visibility over the kind and reason for a change gives the product manager and interested stakeholders sufficient time and capacity to try to mitigate the change. Increased visibility also helps inform their experience with the change that may occur again in the future.
This experience will help them put safeguards in future initiatives — whether that gets discussed in a retrospective or otherwise — to ensure that said change, if it has negative effects, will not happen to the team again.
Finally, it helps to have a living, breathing change control document in place for your change control procedure. You can direct interested stakeholders to this document, giving them one place where they can understand the kind of challenges, changes, and problems that your team needed to mitigate.
This change control document can also help them understand why those challenges exist in the first place, the decisions made to address the changes, as well as their impact on the delivery of the initiative.
For larger organizations in particular, the product manager will not have time to meet interested stakeholders one by one to facilitate a conversation around the changes made to the SDLC. Having a single place to direct all interested stakeholders reduces the amount of time a product manager needs to take out of their day to explain the changes. PMs can rely on the assumption that “If they are interested, they will read.”
The following are the steps in the change control process:
A change can be requested at any moment in the SDLC process. The requested change can either positively or negatively impact the initiative. Change can come from anywhere for several different reasons, such as:
When a change is being proposed, it’s best to have a communication channel or funnel where these changes can be introduced and discussed. Several examples of how this channel can look include:
Once a change request has been communicated or discussed with the team, it’s the product manager’s responsibility to assess the information associated with the change request. They also have to make a preliminary decision as to whether the change request has legs to stand on — whether or not it is being made for a valid reason to accomplish a valid purpose.
There is no science about this initial triage. It all depends on the nature of the change request presented to the product manager and how the current circumstances of the company dictate its acceptance or rejection. Several things that the product manager can consider at this stage are:
Once the change request has passed the initial assessment or triage by the product manager, it is time to determine whether the change should be approved or declined.
The product manager then arranges a chat with all interested stakeholders, including team members and other individuals outside of the team with a vested interest in the change, to do the following:
Sometimes, it might not require a large discussion with multiple different individuals to come to this decision. If there is one decision-maker that stands head and shoulders above everyone else when it comes to suggesting and committing to changes, then they should be the first port of call for discussing and deciding whether to approve or decline the change.
Once the decision is made, it would be good to document the change. This documentation can come in multiple forms, depending on the type of change that was discussed and decided upon.
For example, if it is a change that was decided as part of an initiative or an epic, there can be a small table that exists in your epic that looks something like this:
The table is pretty self-explanatory — it’s a way for the product manager to capture the conclusion of the change request and ensure that whoever picks up the initiative or feature fully understands the different decisions, twists, and turns that have been made along the way.
Please use this link to download a free change control process template on Google Sheets! It includes an example entry to showcase how you can use the change control procedure to effect change in your team and company:
You can adapt this sample change control process template to your needs, depending on the specific process your team uses or the information you prioritize.
Follow the steps above and you’ll be on your way to implementing a change control process in your team and company in no time. Until next time!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
Learn more →
