According to BABOK, Requirements Life Cycle Management refers to "the tasks and activities that Business Analysts perform as part of their role to manage & maintain requirements & design information through [the] entire journey of any initiative, from the start to the very end”.
A change in requirements can have an enormous impact on many aspects of the software development process. It affects the overall project delivery and business goals/expectations. This can increase the effort, timelines, and associated costs. It is crucial to understand how to manage continuously changing requirements and deliver products based on the customer’s business needs. In this article we will discuss the reasons behind, and solutions to, dynamic requirements.
Why does requirement change inevitable?
The following are some of the reasons changes might be introduced during the system development process:
- Changing requirements mostly come from customers and stakeholders. Such situations include:
- Clients sometimes do not know what exactly they want at the very beginning and may come up with a better idea later.
- Stakeholders might know what they want but not how the final output will look. During development, discussions, and demo sessions, these changes are realized and introduced.
- Stakeholders might realize that features are missing or need changed.
- Some stakeholders may not be involved at the beginning of the project. Over time, some stakeholders may leave to be replaced with new stakeholders. Stakeholders represent requirements. Missing stakeholders results in missing requirements.
- There may be mismatches between stakeholders’ expectations and what they see in prototypes or trials.
- A poorly defined or neglected requirement development process can lead to defective, inaccurate, and missing requirements.
- Unforeseen problems occur, such as budgets cuts, shifting delivery dates or changes to the systems with which you interact.
- There may be uncontrollable external factors such as changes in the marketplace, technology, or the law.
How do changing requirements impact the development process and business overall?
Generally, the impact of change is good & healthy as the team and business want to deliver solutions that build value.
From a business perspective, the product is going to be more fruitful since the delivery is going to meet expected business goals according to current market demand.
From a development process perspective, these changes introduce improvements in architecture, designs, and technology as business needs dictate.
When these changes are not controlled, it can be disruptive to the development process. The momentum and flow of the team is impacted. The team must exit the current flow and participate in extensive grooming/solutioning sessions. In turn, this can impact the delivery timeline, the quality of deliveries and erode team morale.
The Requirements Change Management Process
Based on our experience and after conducting interviews with our business analyst colleagues, we have identified some of the most widely utilized change management procedures:
- Raising a change request
While a request may be more likely to come from a stakeholder or project lead, a proposed change can be made by anyone.
Usually, each partner organization will have their own request form template. If not, as a Business Analyst you should create a change request form so that changes can be raised in a standardized way. It’s important to have consistent information in your change requests so that when reviewing and approving changes, you have all the facts you need to make the right decision for your customers.
Once the request form has been filled out, you should update the change log with a name, brief description, and any other details you may need, such as the date and name of the requester.
2. Assess the change request
When a stakeholder or team member makes a change request, you will want to inspect it to ensure the change is necessary and assess its impacts.
Here are a few simple questions to help you and your team determine how to handle this process:
- What is the change?
- Why is the change being introduced?
- Does the change contribute to our project goals?
- What challenges does the change present?
- What is the priority of this change?
Once you have discussed these questions with your team and stakeholders, you can focus on how the change will impact your timeline and budget. It is a good idea to get your team together to talk about the level of effort required by the impending change.
Different organizations will have different ways of going about the approval process. A change control board is the governing body that is typically responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project.
The final decision should then be updated in the change request log.
3. Communicate the change request
Of course, anytime you make changes to your plan, you will need to let your team and stakeholders know. This will help everyone involved understand the specifics of the change, why it is necessary, and what the project future state will look like.
4. Implementing the change
If the change request is approved, the process will move on to the implementation phase and the project deliverables will need to be updated. This can include plans and schedules, business process documents, and requirements documents. It is best to disseminate the request information and the change log in a shared workspace so that everyone can easily access the information during implementation.
Finally, you can delegate tasks to appropriate team members to implement the updated workflow.
In Summary
Changing requirements are and will always be a challenge for the team. That said, managing change is a fundamental and beneficial part of project work. The tips that have been discussed in our article can help you manage changes in a more effective way and deliver products that address clients’ business needs.
References:
IT Service Management Foundations: Change Management
Project Management: Preventing Scope Creep
Template: Configuration and Change Management Plan (An official EPAM template)
Acknowledgements
We thank Phuong Vu for being co-author for this article. Thank Rahul Ahluwalia, Linh Trinh, Hanh Nguyen, Catherine Kierans, for sharing their experiences and providing opinions for this article. We also thank Robert Abbott for assistance in the final editing.
Comments