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. Whether it occurs 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, 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.
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.
- What is a change control process in the context of product management?
- What is the difference between change control and change management?
- Advantages of following a change control process
- Typical steps of the change control process
- Change control process template
What is a change control process in the context of product management?
The change control process is a method used by teams to capture, manage, and communicate any deviations from the agreed-to plan or initiative. Change can happen at any point during the software development lifecycle (SDLC), which can either make or break the ultimate delivery of your plan.
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.
What is the difference between change control and change management?
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. This is usually a formal 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 processes. 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.
Advantages of following a change control process
The following are the advantages of following a well-structured and fully communicated change control process:
Improves collaboration and productivity of the team
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 way that the change control process facilitates this is because of enhanced communication and visibility, enabled by the fact that the process makes the changes that are contemplated clear, as well as 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.
Allows the PM and directly responsible stakeholders to take action earlier
By having increased visibility over the kind and reason for a change, the product manager and interested stakeholders have the 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.
Increases effectiveness of communication between the organization
Finally, it helps to have a change control process in place as a living, breathing document, as it directs interested stakeholders to one place where they can understand the kind of challenges, changes, and problems that your team needed to mitigate. It also helps 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.”
Typical steps of the change control process
The following are the steps in the change control process:
1. A change is requested
As can happen at any moment in the SDLC process, a change is being requested that can either positively or negatively impact the initiative. Change can come from anywhere for several different reasons, such as:
- The initiative is taking longer than initially planned and a change is required to either reduce the scope of the initiative or increase the amount of time to deliver it
- The initiative is running into technical roadblocks and a change is required to identify the risks and issues (e.g., as part of a spike) to figure out the issues
- The initiative no longer aligns with the strategic direction and foundations of the company, and a change is required to realign the overall direction and focus
When a change is being proposed, it is 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:
- A simple face-to-face meeting between both the requested stakeholders and the product manager
- A Slack channel for your initiative, where interested stakeholders can join in to track the progress of the initiative and suggest changes
- A request for comment (RFC) process, where the change requester can write up a formal document requesting a certain change, describing it, and explaining how it would benefit the initiative or organization
- A structured change request form that provides key information, such as details about the change request itself and the intended impact of the proposed change
2. Discuss and evaluate the impact of the change
Once a change request has been communicated or discussed with the team, it is 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:
- What is this change trying to accomplish?
- Is this change to the benefit or detriment of your customers?
- Does this change hinder or assist with the completion of your initiative?
- Does this change unearth information and facts that you were previously unaware of?
- Does this change align with the overall company strategy and vision for the quarter or the year?
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.
3. Approve or decline the change
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:
- Summarize the change and its intended effects
- Make a recommendation about whether to accept or reject the change
- Cultivate discussion and discourse within the team as to whether that is the right decision
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.
4. Document the implementation of the change
Once the decision is made, it would be good to document the change. This 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 is 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.
Change control process template
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 process to effect change in your team and company:
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!
Subscribe to our product management newsletter
Get articles like this to your inbox
Featured image source: IconScout
LogRocket generates product insights that lead to meaningful action
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 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.