Change is inevitable, so a clear change control process is essential to ensure the success of your product.

The approach to managing changes is closely related to the software methodology you are using on the project. Agile methodologies are quite flexible and embrace changes from the start while a more traditional Waterfall model has difficulty adapting to the changing requirements.

In this article, I’ll explain how the change process works on different kinds of projects and offer a simple step-by-step procedure you can use to handle changes even with the most inflexible methodologies.

Table of contents:

Why can requirements change during development?

There are many reasons your requirements can change before the project reaches completion.

The traditional Waterfall approach necessitates the collection of all requirements before the start of development. Sometimes, it’s easy to miss a minor requirement during the initial brainstorming.

Such issues are often discovered when only the client gets to use the system for the first time.

That’s why modern Agile approaches aim to split development into several iterations (often called sprints). The purpose of each sprint is to release a working piece of software and collect feedback from real users (either internal or external).

Shorter iterations can help you satisfy current business objectives and user needs (it’s also the reason why we have iterations on all our projects, even using the Waterfall model).

With public testing between iterations, it’s common to receive lots of suggestions and reports from users. It’s important to document and analyze such requests even when they contradict each other.

At the same time, stakeholders themselves often don’t understand what they actually need during the requirements gathering process. So when they take a first look at a working system, they may realize they need something entirely different.

This is why stakeholder involvement is crucial for the success of your product.

Another reason for changes during development can be internal politics.

All organizations have power structures and dynamics that can change while your product is being developed. Such changes inevitably shift your priorities, changing the project requirements.

We’ve seen some of our clients deciding at the last moment to add the current project to a portfolio that requires a Six Sigma quality control. This decision has affected the project timeline and budget.

Changes can also come from outside of your organization. Shifts in market trends, consumer needs, and even the release of competing products can all mean that you need to occasionally reevaluate your priorities in order to stay competitive.

Agile projects do this as a part of a framework while Waterfall needs an additional change control procedure (more on that later).

A change in standards and regulations is another important source for the changing requirements.

We’ve already seen some business domains adopting the standards that require all products to run penetration tests in order to evaluate system security (which requires additional funds and time).

Another recent case is the adoption of the GDPR which forced most of our clients to make significant changes to how they store and process user data.

What to do with changing requirements?

On Agile projects, requirements gathering is a constant process.
Whenever you have a new requirement, a person that represents stakeholders (i.e. Product Owner) will write it down as a user story (a piece of functionality from the user’s point of view – I as a user want feature x so that I could do y)

All stories are then added to a list called product backlog.

Items on the backlog are typically prioritized according to their business value and technical difficulty using methods like MoSCoW analysis.

It divides user stories into four categories:

• Must have

This category is mandatory to implement within the current sprint. If you have doubts whether a certain story is a must-have, ask yourself what would happen if you release the product without this requirement. If the release is useless without this story, it’s a must-have.

• Should have

They are still very important but not critical to the success of your product. Such stories can usually be postponed without affecting the current release.

• Could have

These stories are nice to have but aren’t the core proposition of your product. If removed from the current release, they have a lesser impact on the product.

• Won’t have right now

These stories aren’t going to be included in the current sprint to prevent scope creep which can easily derail ambitious projects. Depending on the feedback from users, the “won’t have” stories might be included in the next releases or abandoned in favor of other, more important initiatives.

Requirements at the top of the list are typically described in greater detail while items at the bottom of the backlog can be more vague.

At the start of each iteration, the team gathers for a sprint planning session. The main task here is to commit to a sprint goal. To achieve this, the team estimates the number of high-priority stories that can be completed within one iteration.

These stories form the sprint backlog.

Some agile approaches suggest that the requirements should be frozen for a current sprint with any changes being added to the backlog as new stories.

Another approach is to allow all changes as long as they don’t violate the sprint goal.

Generally, we only accept a change if it’s approved by the client and is relatively small (a larger change might disrupt the development flow).
The team might also accept larger changes but only as an exception to the rule. In such a case, the change will be added to the sprint backlog as a new story with another story of similar size moved to the next release.

In the end, accepting a change during an iteration is usually born from a discussion between the Product Owner and the team that owns the sprint backlog.

Waterfall change control process

In some situations, Agile is a poor choice for the project methodology.
In such cases, the choice typically falls on the more traditional Waterfall model.

Such projects are typically divided into several clearly defined phases, from requirements collection, to design and implementation.

As the scope, budget, and schedule are typically fixed at the start of the project, managing change can become problematic. Many projects fail due to uncontrolled changes bloating the budget and timeline.

Although teams should resist unnecessary changes, it is important to stay open to new opportunities that could bring more value to the project and the organization.

As Waterfall projects don’t have a Product Owner, the duty to control changes falls on the project manager. One of the most important tasks here is to make sure that any change to the project baseline (i.e. scope, budget, schedule, quality, and risks) is formalized as a software change request (CR).

MindK change request form

The first task a project manager should do after documenting a CR is to assess whether it’s a must-have or nice to have using the MoSCoW analysis or some other technique.

This is extremely important as it’s common to receive a whole host of CRs from different stakeholders which might contradict each other and incur significant changes to the project’s budget and timeline.

What’s more, change requests are often a symptom of a deeper issue.

At this point, we like to use the 5 Whys technique to get to the bottom of the issue.

We often ask clients “What is your goal here, what do you want to achieve with this change?”

As it turns out, users often don’t realize whether the change is necessary or not. By asking follow-up questions, you can dig down into their motivations and discover underlying needs and frustrations.

A project manager should be extremely careful when providing a CR assessment.

Recently, we were developing a project for one of the biggest recruiting agencies in Western Europe. Our client requested a pretty large change – a query language-like search. The feature was rather complex from the technical point of view and seemed unnecessary as we already had a simpler search.

As implementing the feature would’ve delayed the release, we recommended the client to postpone its implementation.

Imagine our surprise when the client kept on insisting the change is an absolute must-have. So we started digging deeper and it turns out a single employee (let’s call him Bob) refused to use the system unless it had this feature.

Seems ridiculous, right?

Why on Earth should an organization of more than 150 people wait a whole month for just one employee?

Well, it turns out Bob earned our client more than 50% of revenue. And if that one feature made him more productive, it would be more than worth the wait.

The lesson here is that a client might not know what’s in their own best interests, but the project manager doesn’t always know better. So it’s important to communicate and use common sense when analyzing change requests.

To avoid such issues, we came up with a 7-step process for change request management on Waterfall projects:

1. Check whether the proposed changes affect the project scope, budget, schedule, quality, or risks. If the baseline isn’t affected, there’s no need to document the change request.
2. Calculate the impact on scope, cost, and schedule if the change affects your baseline.
3. Gather the technical team to evaluate the change request. Assess whether the proposed change should be implemented ASAP or added to a product backlog using your prioritization method of choice.
4. Send the team’s recommendations and detailed impact calculations to the Change Control Board (CCB). A CCB typically includes key decision-makers from the client side along with the project manager and sponsors. Its role is to decide whether to approve or reject a change request.
5. Capture the decision after the project change request is approved; update the budget, schedule, and risks.
6. Alter team assignment to implement the approved changes.
7. Archive all the changes in a Change Request Register. Even rejected requests should be documented to avoid problems with forgetful stakeholders.

Conclusions

Change is unavoidable, so it’s important to learn how to handle requirement changes in the middle of an iteration, whether you’re a project manager, Product Owner, or an important stakeholder.

The exact process will depend on the type of your project.

While Agile encourages changes throughout the development process, the

Waterfall model often resists change due to high implementation cost, especially later in the project.

You can use our change control process even on the most structured projects.

And if you need some help in managing a high-pace Agile project or a team of professionals to build your dream product, you can always rely on MindK.

Just drop us a line.