Change requirements, or Change Requests (CRs), are an integral part of requirement management. CRs are not limited to just changes in requirements but can also include changes to project scope or development plans. However, in this post, I'll focus solely on changes to requirements.
1. Where do CRs come from?
CRs can originate from various sources, with the most common being:
Clients: Changes in client thinking, business processes, or internal constraints and funding can lead to CRs.
BAs: New functions/logic might emerge during the analysis phase that the BA didn't initially identify or missed.
The Project: Technological constraints or resource limitations might necessitate changes to requirements to align with the technical solution.
2. What to do when encountering a CR?
When faced with a CR, BAs should have a clear management process. This ensures that CRs are evaluated, reviewed, and implemented systematically. This way, you can avoid constant minor updates and the urge to jump into modifying documents every time a CR pops up.
You can refer to the following steps for the CR management process:
Record: When receiving a CR, ensure that the change information is fully documented. At this stage, URDs (User Requirement Documents) and MoMs (Minutes of Meeting) are helpful tools for recording information.
Evaluate & Analyze Impact: Don't immediately implement a CR after receiving it. Analyze its impact first. Use impact analysis techniques to assess the scope and extent of the impact when applying the change. This will help you identify the affected functions/features, along with estimated time and resources required for the CR.
Confirm: After evaluating the impact and estimating the time and resources, the CR needs to be confirmed with stakeholders. In some cases, due to significant time and resource requirements, the CR might be canceled or transformed into a different CR. If the CR is modified, start again from step 1 until it's approved.
Implement: This is straightforward. Once you understand the change and have analyzed its impact, proceed with implementation and documentation.
Track: Typically, after implementing a CR, most people consider it done. However, as I mentioned in the post about requirement management, updated CRs also need to have their change history recorded. You can use a requirement traceability matrix for tracking.
3. Points to note during CR management:
Ensure the CR is thoroughly evaluated in terms of both business and technical aspects, just like when you receive new requirements.
Perform impact analysis to mitigate risks to the product.
All CRs should be transparently shared and confirmed by stakeholders.
When there are too many CRs or the project is in a critical phase, prioritize their implementation. For example, CRs with low impact, easy implementation, and high value can be done first, while those that are difficult to implement and have low value can be addressed later.
4. Practical Experiences:
Here are some practical observations I've made about CR management and implementation:
Too many CRs: This issue arises when clients make excessive changes to one or a few issues. If you encounter this, speak up and let them know:
Such changes will impact the project and the investor's budget.
Not all CRs can be addressed immediately; other requirements also need to be developed.
Too many changes can demotivate the development team and affect product quality.
Propose some acceptance criteria for CRs (e.g., no more than 5% of the total project effort, or no more than 3 changes per function/feature).
The recording and confirmation phases can be done simultaneously: This can be done at the same time you receive the request from the client if you're confident in your product knowledge and analytical skills. However, don't be complacent and try to be as careful as possible.
The CR approval process might be nonexistent or very time-consuming: If you encounter this, instead of waiting for client confirmation, discuss with the project manager to make a temporary decision about implementing/postponing the CR. Don't leave the task hanging without any action.
Unreasonable CRs: Sometimes, client CRs are quite unreasonable or infeasible with the project's current technology. Instead of dismissing them, try to find alternative solutions that still meet the client's needs and persuade them with those solutions.
I hope this post helps you with requirement management.
Comments