The risk of changes to requirements can be minimized by having a robust requirements gathering process.
For various reasons requirements could still change and it is important to have a process in place to manage these changes when they happen. Changes need to be prioritised, documented, communicated and implemented if approved.
The main steps and questions to answer when planning the process are set out in the diagram below:
Below sets out an example for proposing a change request process. This will need to be adapted depending upon circumstance. This may fit into a set of slides or approach paper to present and gain agreement on.
Raising a change request
Process for raising a change request
- Changes can be proposed by lead SME, sponsor or project manager
- The requestor summarises in writing change to be proposed
- Contact Business Analyst for discussion
- Changes can now be proposed
- Change requests will be added to a change request log and communicated at regular project meeting
Outputs
- Change request form (standard template required)
- Change request log (standard template required)
Assessing change request
Process for assessing change request
- The business analyst will co-ordinate and document:
- Cost and time estimates
- Benefits
- Risks
- Priority
- Options for meeting change request
- Prioritisation compared with other requirements
- Impact analysis – to understand the full impact of the proposed change and the impact of not doing it
- The stakeholders required to assess change request to be discussed and agreed at regular project meeting
Outputs
- Updated Change request form
- Updated Change request log
Making a decision
Process for making a decision
- The project manager and sponsor will be responsible for approving the change request.
- The decision (under review, approved, declined or deferred) will then be updated in the change request log and communicated via regular project meeting.
Outputs
- Updated Change request form
- Updated Change request log
Implementing an approved change
Process for implementing an approved change
- The approved change will be incorporated into plans.
- Establish when the work can start on the change and when it can be implemented
Outputs
- Updated Business requirements document if applicable
- Updated Solutions requirements document if applicable
- Updated test scripts if applicable
- Implementation
The documentation such as business requirements document and solution requirements document should be updated to ensure traceability.
In an agile environment change will be more fluent but will still need to be managed. There is only a finite time and capacity for the work to be progressed. There will still need to be some level of impact assessment to re-prioritise and re-plan to ensure the most valued requirements are delivered first.
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
