Earlier, we mentioned that planning business analysis governance is predominantly carried out to ensure the effective management of changes to business analysis information during the project.

There are seven main things you must include when designing your change request processes. They are as follows:

1. Determine what steps must be followed by stakeholders to request a change.
2. What are the elements of the change request you want to analyze; for example, the change cost and time estimates, the benefits of implementing the change, the risks of not implementing the change, its priority, and what should be the next steps in relation to the specific change?
3. Determine how the changes you receive will be prioritized.
4. How will you document each change request?
5. Determine the communication method for updating stakeholders on new changes received and changes currently being considered, finalized, and included or excluded.
6. Determine who in the team will be performing the impact analysis for each change request. 
7. Finally, the business analyst should define who can authorize any decisions made relating to the change requests received.

An example of a real-world change request process could be that as a business analyst, you will provide or help a stakeholder who wants to change the attributes used to capture a customer record to define what exactly the change is that they need. This could be done using a change request template. Once you understand what their change request is and you have it fully documented, you will involve other stakeholders to assist with impact analysis, cost and time estimates for the implementation of the change, risk analysis in terms of what it means if those attributes are not included, and so on. All of these change considerations will be included in a change control board meeting held on a weekly or fortnightly basis to discuss changes like this one. The change control board will typically then agree to prioritize the change request based on factors such as the benefits, risks, and effort to implement. The change request will then be approved and scheduled or it will be declined. As a business analyst, you will provide the necessary updates to the stakeholders who have raised the request in terms of the decisions that were made. You will typically communicate information including but not limited to the impact analysis, identified risks, cost and time to make the change, and any other specific determinations you may have learned about during the change request analysis.

The example change request process described here may not necessarily be complete and appropriate for all project types. However, something similar should always be in place for a project.

You will now also see that without having a change control process, it will become very difficult to manage the project’s scope, requirements, and ultimately, you will not have much control over which requirements have been implemented, changed, or discarded.