LogRocket’s Galileo AI watches every session, surfacing impactful user struggle and key behavior patterns.
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.
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.
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.
The following are the advantages of following a well-structured and fully communicated change control process:
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.
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.
Learn more →
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.”
The following are the steps in the change control process:
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:
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:
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:
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 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.
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!
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.
Christina Trampota shares how looking at data in aggregate can help you understand if you are building the right product for your audience.
Sep 6, 2024 ⋅ 8 min read
Combat marketing myopia by observing market trends and by allocating sufficient resources to research, development, and marketing.
Sep 5, 2024 ⋅ 6 min read
David LoPresti, Director, U-Haul Apps at U-Haul, talks about how certain product features have evolved from wants to needs.
Sep 5, 2024 ⋅ 9 min read
With so many conflicting sources of information, it can be difficult to grasp how to actually implement a sound product strategy.
