There is this aura around the words “change control” that gets a negative reaction from stakeholders and BA’s alike. It usually means there is added work to the project. Which, in turn, means the requirements will have to go through the approval process again. If you have read my previous article, then you already know my love/hate relationship with the stakeholder approval process.
Even so, I like to think of change controls as the misunderstood animal of a project’s lifecycle. Take rats for instance. They are often represented in the film industry as disgusting creatures that eat garbage from dumpsters and live in the sewers. They are also blamed for spreading the bubonic plague even though they were simply a host for the disease-carrying fleas. No one ever thinks about the “goodness” in rats. I prefer to think of rats in the light of Master Splinter from Teenage Mutant Ninja Turtles. They are quite affectionate and rarely bite people. They are extremely intelligent and can perform tricks if trained properly; similar to a dog. If you take care of them well enough they will love you always.
One look at my daughter’s pet rat jumping from a chair into her arms 5 feet away after being coached to do it changed the way I view rats forever. One word. Adorable.
Now. I don’t think that I will ever call a change control “adorable”, but like rats, they are often misunderstood. Yes, they create more work for all parties involved. Yes, we have to go through the approval process one more time. However, they provide a better end solution or product. They are often necessary to express clarifications or add a missing piece to the solution. Just because a change control is needed doesn’t mean someone made a mistake or didn’t do their job. On the contrary, we need a change control because someone is doing their job. Someone noticed something missing or incorrect and requested to have it fixed.
In order to reduce or even eliminate all together the stigma surrounding change requests we, as BA’s, need to educate ourselves and our stakeholders. What is a change control? What does it mean for me? Is it good or bad?
What is a change control?
According to the BABOK, a change control is “controlling changes to requirements and designs so that the impact of requested changes is understood and agreed-to before the changes are made.” (BABOK, 2015)
In essence, it doesn’t mean that someone missed a requirement. Although, this may happen. No one is perfect; therefore, no project team is perfect. Requirements may get missed or a better solution may be presented that affects the requirements. The change control documents these changes within the requirements.
What does it mean for me?
As a BA, we are change agents. In my opinion, the term change agent should be in every job description for any BA role. So, if we are change agents why are we so afraid of change controls? I think, often times, we look at the negative associated with change. At least, initially. I know from my past experience I would view the need for a change control on requirements as something that I missed or something I got wrong, which means I failed. I’ve learned that we need to accept change. There are things that are out of our control and we need to be flexible to make changes that benefit the project. Remember, you are not alone. You are part of a project team. The requirements were created together with everyone’s input considered. We are all accountable, so to not accept the change needed may negatively impact the project as a whole.
Does this mean we just accept any change control?
Each request will need to be evaluated for benefit and impact on the project. If the benefit is high and the impact is low, then it may be a no brainer to create the change control. If the request is somewhere in the middle more analysis is needed to identify the cost, benefit, duration, and resourcing before creating the change control.
Are change controls good or bad?
Change controls are not characteristically good or bad. They are a necessary cog in the project lifecycle. Without change controls, we risk introducing a solution that is not complete or not what the stakeholders requested. If there is a better solution or a clarification needed to the requirements it is the BA’s job to document, it. We need to stop looking at change controls as “bad” and look at them as sometimes “needed” in order to fulfill our duties as a BA.
In the end, you will be thankful that change controls are made because it will avoid rework later in the project lifecycle, internal audits against projects, poor customer experiences, and provide better customer solutions.
After all, if you had a pet rat, wouldn’t you want it to show you affection and know all the tricks?
BABOK®: v3: A Guide to the Business Analysis Body of Knowledge (2015). pg. 443. Toronto: International Institute of Business Analysis.