Scope changes - towards the end of the project.
Requests for changes to requirement should be accepted as a reality in software projects. Managing these changes does not begin when the requests start flowing in. The best way to handle change requests is to have an agreed Change Request Management process in place before the actual execution of the project. Given below are some general tips while handling requests to change in requirement.
· Any change, whether big or small, should be taken through this Change Request Management process.
· It is absolutely essential to track all changes to requirements – whether big or small. This should be done regardless of who absorbs the cost of implementing the requested change in requirements – it could be absorbed by Vendor or paid for the by the customer.
· Discuss the change ASAP with the client to get a complete understanding of the changed / new requirement and expectations. Understand the criticality of the change to the client’s business – this will help prioritize the requests to be taken up for execution.
· For each change:
o Analyze the impact on timeline and the dependant modules due to the changed requirement
o Estimate the effort needed to implement the change. While estimating the effort, include the effort required to integrate with other modules, any activity required to put that change in place, testing of individual and integrated system.
o Estimate the cost for implementing the change.
· Compute the cumulative impact of all changes on effort, cost and schedule.
· Include status of change requests in the project in the regular status reports. If the project involves interacting with multiple units at the customer end, each of these units should be updated about the status of changes requested.
· Usually, a lot of change requests come during UAT. Change requests should be treated separately from normal defects reported during UAT. Sometimes, a change in requirement can slip in as a defect – watch out for this tendency. While the cost of fixing defects found during UAT is usually absorbed by the vendor , the same cannot be said of cost of implementing a change in requirement.
· Lastly, even removing a requirement, especially after it has been implemented, should be treated as a change request.
|
Viewing changes to requirement as a risk |
Showing prototype to the client before final delivery |
Contingency Bucket approach |
|
Requirement changes should be identified as a risk before the project starts. Adjust the probability based on the confidence level of the team and customer on the requirements. Adjust the impact based on the stage of the project. The impact will start rising once design phase starts, and will rise sharply in later phases. A well defined Change Request Management process is the risk mitigation plan for handling the risk of changing requirements. Identify the risk in the status report from the start of the project, long before it materializes. Once the risk materializes, increase the risk probability to 100% and change the color to Red, to ensure it gets all the visibility. |
Right from the early stages of the project, plan for a prototype demo to the client. This should include a demo of the functionality to the client when the project is still in execution stage. Thus, the client gets to see the application first hand much ahead of UAT and when implementing changes is far easier. This also helps the project team to develop a better understanding of the client’s expectations and help validate assumptions.
|
Create a contingency bucket by allocating some percentage of total project effort. Any new requirement coming in after a certain stage in the project would be taken up as a change request. Track individual requests effort being taken from the bucket keeping client appraised of the same.
|
