The Community Blog for Business Analysts

Context: 

1. Intro
2. Change Request Definition
3. Reasons for CRs
4. Adaptive, predictive and mixed projects
5. Flow of processing change requests
6. Change Management Workflow
7. Tools and Techniques

1. Intro 

The World will never stop changing, as well as human needs and desires. The business environment evolves continually. An organization that fails to take over rising needs becomes obsolete and loses out in the long run. Take the mobile phone brand Blackberry, for instance. The one-time smartphone favorite, which had over 80 million users worldwide, recorded a 0.2% market share in 2016 due to its failure to adopt touchscreen technology. Change is a necessity for businesses to survive. That is why we often have to deal with change requests while working on project development. This article aims to demonstrate that there is nothing bad and negative about working with change requests if you know what to expect and are acquainted with tools to help you.

2. Change Request Definition 

To start with,we need to define what a change request is so that we are all on the same page. Change requests(further - CR) are appeals to make a change to a requirement or other suggestions for changes to product information that are raised by the business stakeholders or project team after a set of requirements is baselined. (The PMI Guide to Business Analysis)

Types of CRs

• System logic/behavior changes
• Scope changes
• Changes in naming/wording
• Changes in UI
• Technical changes (integrations, languages, etc.)

Removing items from the scope is also an example of changes to the scope of work. Items can be removed from an iteration’s scope for various reasons, including the following:

• Implementation issues are preventing an item from being completed within the current time frame.
• Issues discovered by product owners or during testing make the implementation of a particular user story unacceptable.
• Higher-priority items need to replace less important ones that have been planned for an iteration. 

It is like when you are planning to build a new house and after estimates have been given, the budget and project have been confirmed, the building process has started and you decide to change something. This might seem to be an example that is far away from software, but it will help us a lot throughout the article to illustrate the theory and make it more practical.

3. Reasons for CRs 

• Stakeholder changes their mind (1)
• Recommendations after seeing part or all of the solution (2)
• Risks (3)
• Regulatory change (4)
• Poorly defined/missed requirements (5)
• Internal or external constraints (6)
• Change in Sponsorship (7)
• Business Strategy Change (8)
• Updated Technology (9)
• Insufficient Resources (10)
• Natural Disaster (11) 

So, going back to our house. Instead of the monolith that was an initial solution in the project, we have used ready panels. The monolith is a good thing, but when the ground is good and the building is pretty small there is no necessity to use a monolith which is more expensive, harder, and longer to assemble. We defined this requirement poorly as we did not have enough competence at the outset(5).

Next, according to the house project, we were supposed to use special panels to make an incline of the roof, but these panels are not produced anymore, so we could not buy them, so we decided to make it from light concrete. Here we had to deal with external constraints(9). It can be compared to a software technology that changes when it is already in use in the project.

In addition, we ended up buying windows made from a German profile. The windows that we planned to buy initially were produced in Belarus. And this country, instead of sending its goods to Ukraine on export, is now sending Iskander ballistic missiles to Ukraine for no rhyme or reason.So, this is (4) - a regulatory change as Ukraine does not purchase products from Belarus anymore.

Moreover, the Knauf plant, a producer of building materials, construction systems, etc. had been destroyed by the russian army which keeps bombing civil infrastructure, so now we need to search for another plaster producer (11 + 6). This is an obvious example of how force majeur is combined with external risks.

4. Adaptive, predictive, and mixed projects 

While working with change requests we should consider the following criteria: 

• Project type
• Budget
• Communication
• Client’s policy
• Project phase
• Architecture 

How one handles change requests depends on many project characteristics, including the type of contract (fixed price or time and material), project management approach, etc. If you have a limited budget for house building, that is a fixed price. Under such circumstances, workers can offer you a certain house to be built in a certain period. That is when workers need to know all the requirements in advance to provide you with an estimate.

It might seem that it is almost impossible to introduce change when you work on a fixed-price project. Such kinds of projects are like sour lemons - no one wants to work with changes on them as if they occur, a lot of steps of the change management process should be made, to make the project go smoothly. However, we need to consider the “policy” of the service provider - whether the client is important to the company outside of the context where the company aims to earn money and what the budget of the project is. Fixed price projects by default means significant risks, assumptions, and constraints, hence a safety cushion is made to factor in all above mentioned. So, sometimes the team can agree to a CR implementation for the client “for free”. But it is very important to communicate the whole process, so stakeholders will understand the value and won't abuse the situation. And the lemon appears to be not that sour when you know you can eat it with sugar - so, you need to be armed with a corresponding instrument to rule. 

Also, it is very important to consider the stage of the project when the change appears. If you already have built the walls of your house, it is better not to change the plan of the house. If you decide to move an already-built wall, you will need to ruin what has already been done. So, the later the stage, the more expensive the change.

In adaptive approaches, there is no formal change request process. When a stakeholder requests a change, it is written in the form of a user story and added to the backlog. These are typically not referred to as change requests. A prioritization process is used to evaluate product backlog items against existing backlog items to determine which items will be included in the next iteration. The prioritization process works to ensure that the team focuses development efforts on the stories deemed of the highest importance and value. 

In the real software world, we usually work on mixed projects… We stick to the Times and Materials contract type but usually have some limitations.

Usually, software companies prefer to deliver work in sprints, so there is some advice that you have to consider while working with CRs in sprints:

• Don’t take CR into an ongoing sprint
• Don’t perform unscheduled groomings
• Do inform the client that the team’s velocity will drop
• Do take out tasks from the ongoing sprint to fit in the change request
• Do stop the ongoing sprint and start a new one
• Do switch from Scrum to Kanban if changes occur often 

5. Flow of processing change requests 

So, now that we know what CRs are and when they can occur, we need to figure out how to manage them. The change management process is a series of tasks outlined for a seamless transition from a current state of affairs to a new one without obstructing the workflow or suffering any damage. To build such a process the team has to define how each step of the process will be conducted.

● Determine the process for requesting changes (specify which requirements and designs the change control process covers and determine whether it applies to all changes or only to changes of a specific size, cost, or level of effort. This process details the steps for proposing a change, when changes can be proposed, and who can propose them).

● Determine the elements of the change request (identify the information to be included in a proposal to support decision-making and implementation if it is approved. Possible components to consider on a change request are:

• Cost and time estimates: for each area affected by the proposed change, the expected cost of change is estimated.
• Benefits: an explanation of how the change aligns with the initiative and business objectives to show how the change adds value. The benefits considered include both financial benefits and tactical benefits such as implications to scope, time, cost, quality, and resources.
• Risks: an analysis of risks to the initiative, the solution, or business objectives.
• Priority: the level of importance of the change relative to other factors such as organizational objectives, regulatory compliance requirements, and stakeholder needs.
• Course(s) of action: the course of action for the change includes an assessment of the components of the change request (cost, time, benefits, risks, and priority). It is common to identify several alternative courses, including those recommended by the requester and by other stakeholders so decision-makers can make a choice that will best serve the needs of the initiative. 

● Determine how changes will be prioritized (the priority of the proposed change is established relative to other competing interests within the current initiative).

● Determine how changes will be documented (configuration management and traceability standards establish product baselines and version control practices that identify which baseline is affected by the change).

● Determine how changes will be communicated (how proposed changes, changes under review, and approved, declined, or deferred changes will be communicated to stakeholders). 

● Determine who will perform the impact analysis (specify who is responsible for performing an analysis of the impacts the proposed change will have across the initiative. 

● Determine who will authorize changes (include a designation of who can approve changes)

6. Change Management Workflow: 

All the above-mentioned information helped us to create our custom Change Management Process adapted to our needs. 

6.1 Identify CR

When a request is received we need to identify that it is something new the client is asking for, not something that does not work properly.

A bug is something that is broken in a requirement that has already been implemented. 

A change request needs to go through a cycle in which the impact and effort have to be estimated for that change, and then it has to be approved for implementation before work on it can begin.

I'd say that if the color of the home page was originally designed to be red, and for some reason it is blue, that's easily a quick fix and doesn't need to involve many people or man-hours to do the change. However, if the color of the home page was designed to be red, and is red, but someone thinks it needs to be blue, that is, to me anyway, a different type of change. For instance, has someone thought about the impact this might have on other parts of the page, like images and logos overlaying the blue background? The link underlining is blue, will that stand out?

Bug VS CR: 

1. Clients won't be paying any extra money for bugs under fixed-price contracts. The client places a request, the provider estimates it and puts a number to it, a contract is signed and a price is agreed upon. That price is as much as the client is going to pay. Any defects will come under the contract, which means the client won't be paying any extra money for it, while change requests will be part of a new contract, which means the client will pay extra for it. Here is a good argument for debate.

2. Service providers may be penalized if more than a certain number of bugs appear under the Service Level Agreement (SLA). SLA may state that the provider may be penalized if more than a certain amount of bugs appear, which is another reason to fight for the change-request category.

3. Regardless of whether the customer pays for it or not, a defect always raises doubt about satisfaction; if the client gets the impression the work isn't done properly they may end up choosing a different provider hence leading to you losing a revenue channel.

4. Unhappy developers

5. Poor statistics in bug reports

6.2. High Level Elicitation

When we have identified a change request we need to define the scope of the requirement necessary for high-level estimation.

The following steps from 6.3. to 6.8 describe Impact Analysis that has to be conducted while working with CR. Below is what you need to take into consideration doing Impact Analysis:

1. Requirements Baseline
2. Conflict: whether the proposed change Conflicts with other requirements
3. Benefit: what will be gained by accepting the change
4. Cost: the total cost to implement the change including the cost to make the change, the cost of associated rework, and the opportunity costs (number of other features that may need to be sacrificed or deferred if the change is approved)
5. Impact: the number of customers or business processes affected if the change is accepted.
6. Schedule: the impact on the existing delivery commitments if the change is approved.
7. Urgency: the level of importance including the factors which drive necessity such as regulator or safety issues. 

6.3. Analyze the Impact

Here we need to identify related requirements (user stories, epics, modules) that help to clarify the scope of work.

6.4. Schedule Estimation Session

When a Business Analyst is ready with his part of the work, then the Project Manager can schedule an estimation session to understand the cost of the change.

6.5. Estimate

The estimation session itself is conducted in line with the rules that exist on the project. Usually, it is a rough estimation as we have gathered enough details to understand the size of the CR.

6.6. Present Estimation Results

When an estimate is received, the Project Manager has to communicate it to the client. We know that money is usually a key aspect of requirements approval and prioritization.

6.7. Approve

It is necessary to receive approval from the client: 

1. Rejected CRs are to be Obsolete or moved to any other status identified within the project (eg.: Rejected, ect.).
2. Approved, but postponed CRs have to be prioritized into an appropriate release or put into the backlog.
3. Approved for the current release are to be processed.

6.8. Update Timelines/Present to client 

The Project Manager is then responsible for updating the project artifacts showing timelines. Adding changes usually requires additional time, so the timeline of the project changes moving forward. If a change request removes features from the scope, then timelines might change so that the release date will occur earlier. This also has to be communicated to stakeholders as it might happen that an earlier delivery date is not possible due to some agreement with the previous service provider.

6.9. Confirm Timelines/Offer Tradeoffs

If the client is not satisfied with the new timelines, then the team can offer tradeoffs. We can either think of a different way to implement the change to trim the estimate, or we can remove some items from the planned release to fit the CR and stick to the timelines.

6.10. Document Requirements Changes

Here we should find a method to show the changes in the requirements: logic, behavior, and approach to implementation. Sometimes the client request might change the behavior of the system that is already implemented, but due to a number of reasons it is postponed till the next release, so it does not impact the scope of the current iteration. So, it is an enhancement to the existing requirement, but not a CR.

6.11. Document Scope/Effort Changes

Here we need a way to document that the CR was approved and now should be taken in an already planned release/iteration. This is how we show that the baseline has changed and how we can define later why the timelines were changing. 

6.12. Update Change Log

If it is agreed on the project that Change Log has to be managed then it is part of the Change Management Flow. My Business Analyst team and I insist it is the responsibility of the Project Manager

6.13. Process Requirements

No matter whether a requirement is determined as CR or not, it has to go through the same process to be shared with the development team and delivered to the client.

7. Tools and Techniques 

And here comes the most interesting part: how we document all of the received information. I offer the following approaches to documenting:

Requirements Changes:

1. Versions of requirement/ additional issue type (CR)/ [CR] in requirement title
   1. Versions of requirement
   2. Additional issue type (CR)
   3. [CR] in requirement title
2. "Archived" status/"Actual Version" label
   1. "Archived" status
   2. "Actual Version" label
3. Related issues

1.i. Versions of requirement

1.ii. Additional issue type (CR)

2.i. “Archived” status

2.ii. "Actual Version" label


3.i. Related Issues

Scope/ Effort Changes:

1. Additional issue type (CR)/ [CR] in requirement title
2. Label [CR]

1. Additional issue type (CR)/ [CR] in requirement title

2. Label [CR]

Select different techniques for different purposes! To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.