Change Requests for Software Business Analysts

The term ‘Change Request’ in the software industry probably cuts across industries (or geographies). So much so that this term has become integral to the world of IT Services and even in software product companies. It is worth examining the importance of this term in detail.

What is a change request?

A change request (CR) is basically any change in the initial set of signed-off requirements. So, typically in a waterfall model implementation, the requirements phase ensures that all the requirements (features/functionalities/functional and non-functional) are agreed upon and documented before development starts. After that, any new scope brought or requested by clients becomes a change request. There is an additional cost associated with implementing a change request.

Even in the agile model of working, although there is flexibility in the implementation of the project, vendors ensure that a high-level set of requirements are discussed and agreed upon. The iterative way of working ensures that clients have their eyes on the product as it is developing and can suggest corrections or alignments. However, no vendor can work with entirely flexible requirements. It's not feasible from a budgeting standpoint.

So, what happens in these scenarios is a ‘change request’.

The process of a change request

As you would have assumed, change requests are debatable in every sense of the way.

1. Clients and vendors have to agree that the requirement that is mentioned is indeed a change request and not an implicit already agreed requirement.
2. There has to be an agreement over the estimate and the priority of the change request. Nobody would want less priority change requests to derail the project. The development team would want to assess the technical changes required to implement it if identified at a late stage. The cost of implementing change requests has to be determined in terms of man-days or any other unit. This has to be converted to an actual monetary amount, which surely must have been agreed upon while compiling the statement of work.
3. Once agreed, change requests should be documented within the original specification with proper references to the change request number. It has to be explained, discussed, and handed over to the dev and QA team for implementation and verification.

How does a CR discussion originate?

Let us first understand how a CR discussion originates.

During UAT/Demo: When the feature or a product is being tested by the actual users, or when a demo is given to clients after iterative development, clients often notice a missing functionality. It is at this time that the missing piece of the puzzle is pointed out. This piece of the puzzle becomes a CR if it cannot be traced back to the requirements doc.

During defect discussion: Consider a scenario where the vendor business analyst and the end users/client business analyst/client testers are engaged in a verbal battle to establish that the defect is indeed valid/invalid. Again, the defect becomes a CR in case the behavior in the defect cannot be traced back to the signed-off requirements document.

Role of a software business analyst in the CR lifecycle?

To start off, since the business analyst has drafted the specification document, he has to sit with the clients and understand/debate about the so-called new requirement.

If the change is not mentioned in the document or cannot be inferred in an implicit manner, they have to convince the clients that it is indeed a CR. This is the most complex kind of meeting since both sides would argue on their side.

If the CR is indeed agreed, the BA has to go back and update the specification and get it signed by the clients. Before this, they have to carefully check the feasibility of the CR and the timelines impacted by them. Typically developers are never happy (or sometimes they love to give a hard time to the BA) about new changes brought to the built software. So, a proper walkthrough has to happen to the developer and testing team.

Pointers to keep in mind for business analysts during CR discussions

1. Keep the specification handy. Know and revise the changes being debated and prepare your points.
2. Discuss the approach of handling CRs with your manager/senior management. Some vendors want to be more flexible if it is a very important client. Some don't want to take in CRs due to a lack of bandwidth.
3. At times, have a give-and-take approach. If the change is really small and cosmetic, business analysts tend to accept them in order to maintain a good rapport with the clients. However, always check the feasibility of even small requirements. What might seem small to you may be technically very challenging to the development team.

A change request is not always a bad thing

A lot of times, vendors do not have a full understanding of the requirements or the complexities of the client business process. They go ahead with the signed-off requirements with the tactical understanding with the client that more features might come as a form of change requests. In such cases, clients are looking for quick and simple implementation and then look at CRs for enhancing the product.

Sometimes CRs help a vendor in having repeat business and longer engagements with the clients. It's a kind of win-win for vendors and clients.

Managing CR discussions and implementation is a good skill to have for a software business analyst. This is for the simple reason that, unlike most industries, software requirements have a huge propensity for change. For this, we should be ready and flexible to consider them.

But. Make sure that CRs are not originating due to your mistakes in drafting vague specifications. That's a hit to your credibility and means extra work for the team at a later stage.

Some pointers to avoid CRs being identified due to improper specifications :

1. Be as detailed and verbose with the specifications as you need.
2. Cover all corner and edge cases in the document.
3. Walkthrough the specifications with clients as much as possible.
4. Save all email communication with clients where they discuss the requirements. Be as explicit as possible in the emails.

Change Requests could be your friend or your foe depending on how you learned to handle them.

Author: Pushkar Anand, Business Analyst

Pushkar Anand has been working in the role of business analysis for over 12 years and is specialized in air cargo operations, hospitality, and digital marketing. Has experience working with some of the biggest airlines in the world and some of the biggest players in the hospitality industry. He is passionate about discovering the newer aspects of business analysis and domains and sharing that with the business analysis community.