Assess Requirement Change

The only thing that is constant in today’s world is CHANGE. Companies around the world do realize that their success depends on the ability to adapt to changes.

The Business Analyst normally has to drive the change requirement if they arise. A change request can come anytime during the project life cycle or even after the project has been implemented. A Business Analyst should be prepared for a change request anytime.

A change request might look very critical to the stakeholder but that can be just tip of the iceberg. A BA has to properly assess the change request that is brought forward from the view of project goal, time, resource and cost.

Every change request whether it is small or big BA has to understand the reason behind it, on a high-level what it could result in, why and how the need arise. Ensure there are necessary agreements before one proceeds.

All said whether the change request should be accepted or rejected there is a vital time lost on the timelines. This depends on the methodology used for the project.

If the project is running on a waterfall model the client/stakeholder will always have the opportunity to give change request until the project closes while if it’s running in Agile model the change requirement can be dynamic as the entire project is running in sprints where the lifecycle of the iteration is equal to no. of sprints.

What can be done to avoid Change Request?

• SOW of the project can hold max CRs that the project will take into account
• Exception where CR threshold can be exceeded

How can we handle CRs best

• Does the new requirement support the product vision statement?
• Does the new requirement support the current release goal?
• Does the new requirement support the current sprint goal? – For Agile model
• Have the development team estimate the effort for the new requirement.
• Prioritize the requirement against other requirements and order the priority.