Small Change Request, Big Impact?

Picture above. The Erasmusbridge in Rotterdam. Two months after the opening the bridge deck moved a lot at wind force 6 Beaufort. A big change had to be made. Eventually the pylons of the bridge were enforced.?

The level in which a Change Request is introduced largely defines the impact on the project

It is good practice is to structure requirements hierarchically. This helps to manage the requirements during the project execution. During the entire lifecycle of a project Change Requests are submitted that affect requirements. While working on the change process in my current project (called Warehouse) I realized that the level in which a Change Request is submitted, largely defines the impact on the project. In this article I explain how you can determine the impact of a Change Request depending on the level it is submitted.

In the project Warehouse ?we started by defining the mission in the form of high-level requirements. These high-level requirements were gathered and defined by the business in a broad sense: sales, service, maintenance, production. We call these requirements level 1 requirements. We have used these level 1 requirements in Warehouse to create the architecture of the entire system. After this we created requirements for each architectural component. These requirements are on project level, i.e., level 2 requirements. In Warehouse the design and building is done by external suppliers (acting on level 3). Level 2 requirements are used per component to create the contracts for suppliers. The suppliers uses level 2 requirements for their specification, design, and build activities. These activities are executed on level 3 (see figure 1).

Figure 1. Hierarchy of requirements

During a project Change Requests will arise, as there will be design issues, changes in business insights, interface issues or any number of issues. The impact needs to be determined for each Change Request; does this request affect scope, functionality, cost/benefits, or planning? Tracking and tracing requirements helps us to structurally and completely determine the impact of a Change Request. Because the requirements are linked in a hierarchical way, it is easy to see which requirements are dependent of each other.

Interestingly, a Change Request is submitted on a certain level. Initially, the thought is that ‘the lower in the hierarchy the requirement is, the less impact the change will have on the project’. So, if a Change Request is submitted on level 1, there is a considerable chance that the impact will be quite large. On the other hand, when a Change Request is submitted by a supplier, the impact on higher hierarchical requirements and the entire project is expected to be smaller.

This principle looks sound, but it is not a law of the Medes and Persians. There will be cases where a Change Request of a supplier on level 3 may have an enormous impact on the project or a Change Request of the business on level 1 will have minimal impact.

Changes at level 1

Let’s investigate the process to gather the involved requirements of a Change Request depending on the submission level.

Figure 2. Impact of a Change Request submitted by the business on requirements

Suppose a Change Request has been submitted by the business (see figure 2). To determine the impact, begin by determining which of the level 1 requirements are involved in the change. With each level 1 requirement you must determine which level 2 requirements are impacted. The same must be done for each level 2 requirement to see which level 3 requirements are affected. Having gathered all the involved requirements, you can use them for an impact analysis on scope, functionality and, ultimately, budget and planning. In figure 2 the submission level of the Change Request is indicated by the orange color. The arrows in the figure indicate the tracing direction resulting in the affected requirements that are colored yellow.

An example: Some years ago a new train trajectory was being built: Betuweroute. Originally meant to be a cargo line, the project was already underway when the parliament decided the line should also be able to transport passengers. This was a huge change and resulted in a large increase in project costs.

Changes at level 2

Figure 3. Impact of a Change Request submitted by the project on requirements

When the Change Request is submitted on project level, the process differs a bit. In this case, the Change Request will be focused on level 2 requirements (see figure 3). As in the previous case, the involved requirements need to be gathered. Meaning all dependent requirements must be investigated, i.e. level 3 requirements, but also the linked higher level 1 requirement. It should be investigated via this level 1 requirement whether any dependent level 2 requirement is affected by the Change Request. As you see you need to go up to the higher hierarchical requirement to see if any neighbor requirements are involved and you need to check the dependent level 3 requirements. Often, changes on this level are on process level.

An example of a Change Request on level 2 is the following: In my project Warehouse the printed barcodes were of insufficient quality to be scanned automatically. The project chose to change the manual process itself. In this case each product is scanned manually. The process change had quite an impact on productivity. Still, the impact of the change was localized in a part of the project and not the entire project.

Changes at level 3

Figure 4. Impact of a Change Request submitted by the supplier on requirements

Suppliers can also submit Change Requests (figure 4). These requests normally originate in limitations during design or development. Often changes on this level are on an interface or system level. The project needs to determine the impact of the Change Request on the other parts of the projects as the supplier does not have sufficient knowledge of the requirements on project level. In this case you will start with the requirement on level 3. You go up to the level 2 requirement that the requirement depends on and check the underlying level 3 requirements.

A small remark about the involved persons with the impact analysis. The supplier will certainly have expert knowledge on their specific part of the project, but the supplier cannot execute the impact analysis by itself, as it lacks knowledge of the other parts of the project. Also a person from the project is not an expert on all the ins-and-outs of the level 1 requirements. So in the case level 1 requirements are affected, certainly a business analyst should take part of te impact analysis. So, to summarize, the impact analysis needs to be executed by persons with knowledge of the specific affected parts/components on the various affected levels.

Example: In Warehouse a supplier needed to add a keep-alive message to an interface to see if the communication was still alive. This message was not yet described in the interface description. Therefore, the supplier created a Change Request to change the interface. The impact of this Change was limited in the system of the requesting supplier and the interfacing system. The documentation also needed to be adjusted.

It looks as if this article is only applicable in a Waterfall or V-model project, but I think that this also applies to Agile projects. Also in Agile projects we have level 1 requirements, called epics or goals, level 2 requirements as features and level 3 requirements in the form of user stories.

In this article I have described the impact of Change Requests depending on the level they are submitted. We can conclude that structuring the requirements hierarchically helps enormously with an impact analysis of a Change Request. Also “the lower in the hierarchy the requirement is, the less impact the change will have on the project" will most often apply. Do you recognize this? Please share your examples in your own projects.

This article is an article in the series about the versatile profession of requirements engineering. Every week a colleague of?Improve Quality Services?will share with the reader an aspect of requirements engineers from daily experience. Every article begins with a picture of a bridge. The bridge visualizes connecting two sides. In requirements engineering connecting different stakeholders assisting the stakeholders in collaboration and communication about requirements.

Interesting articles published in this series:

4.???Van Twin Peaks naar Twin Pines?(Patrick Duisters, 22 december 2020)

52. Really proud! It was ‘only an experiment’ (52) (Benjamin Timmermans, December 2021)