As a business analyst, you can make a huge difference in how change is managed and save your teams a lot of re-work while neutralizing the negative energy often associated with change.
In this short video, you’ll discover a simple 4-step process to manage change requests so they don’t derail the success of your project.
My number one tip when it comes to change requests is: Manage change or it will manage you. Outside of the four tips I share in the video, I highly suggest a Change Request Form that you can use across your organization.
My go-to Change Request Form is included in the Business Analyst Template Toolkit, which is one of our most popular digital products. When you invest in the Business Analyst Template Toolkit, you’ll receive:
- All 12 templates fully annotated in Word or Excel format and fully usable and editable by you. Customize them to meet your organization’s unique needs and share them within your organization.
- All 12 corresponding work samples so you can see what a fully completed template really looks like. These work samples are direct from the Bridging the Gap Redesign Project – they are completely new and you’ll get a peek behind the scenes of our business model.
- A 10-page guidebook walking you through the business analyst approach to a project, what templates are useful in each phase, and how to use the Toolkit to increase your effectiveness as a business analyst.
>>Click here to learn more about the BA Template Toolkit<<
Do you find that unexpected changes just pop up and take your projects off course? Or has someone just requested a change for your project and you’re wondering what you should do with it? As a business analyst, you can make a huge difference in how change is managed and really save your teams a lot of rework while also neutralizing the negative energy that’s often associated with change.
Stay with me and I’m going to show you a four step process that you can use to do this.
Hi, I’m Laura Brandenburg with Bridging the Gap, where we help you start, succeed, and excel in your business analyst career with weekly videos and business analyst tips and techniques. If you’re not subscribed yet, make sure to do so and hit that notification bell so you can stay in the loop with all of our new videos.
Today, we’re discussing a simple four step process to manage change requests so they don’t derail the success of your project because we know you’ve put a lot into the success of your project to get to the point where you’re at now.
Step 1 – Determine the Scope of the Change
The very first step is to determine the scope of the change. A change request could be related to the business requirements, the stakeholder requirements, the functional requirements, the data requirements. Any aspect of the project. Or it could impact all of those aspects. Obviously that’s a much bigger change. Here you use all of your business analysis skills and elicitation, and analysis, and validating the scope of the change with your stakeholders.
Along with identifying what that change is, you’ll want to identify the benefit of making a change or the business need driving that change. So you ask, “Why?” Just like we do for new requirements, we do that for changes as well. This is going to help your change approval team determine whether or not the proposed change is really worth the effort.
Step 2 – Determine the Scope of Incorporating the Change
Step two is determining the scope of incorporating the change. But before that happens, before you get to the change approval team, you want to make sure you understand the scope of incorporating that change into the project. This typically means identifying the impact of the change on the technical design, possibly on the project schedule, putting together a high level implementation plan and determining the level of effort to make the change.
With this information in hand, I often will document in a change request form, so you can see all of it together. You will be able to articulate whether the change impacts the project, the budget, the schedule, the scope. What aspect does it impact? And by the way, my go-to Change Request Form is included in our business analyst template toolkit. It’s one of Bridging The Gap’s most popular digital download products.
Sometimes there are multiple options for incorporating the change. For example, one approach could be trade off, like including the change and letting go of a lower priority requirement so that we’re not impacting the schedule or the scope.
Another approach could involve delays to the schedule in an increased budget, but keep the original scope intact, plus the change. Often during this step, there’s at least one, if not multiple, business stakeholders who are involved in evaluating the tradeoffs and the solution approaches. The goal in this step is to present the information to your change approval team and what they need to make an informed decision about whether or not to approve the change.
Step 3 – Gain Approval or Rejection of the Change
Step three is gaining approval or rejection of the change. You have the scope of the change, you know why it’s being requested, you have information about what it will take to implement it, perhaps a few options. Again, you can use the change request form to present all of that information to your team.
One thing to keep in mind is that most organizations have various levels of approval. So hypothetically, a change requiring just an hour of work might just be approved by the project team or the business sponsor, or the development lead, whoever’s in charge of that team. Maybe a change requiring a week or more of work might be approved by a mid-level management team who can authorize changes that have minor impacts to other projects on your company’s roadmap.
A change to a primary business requirement requiring maybe a month or more of work might be approved at the executive level because it could have impacts on other organizational initiatives and the whole strategy for the year. While those are realistic, they’re really hypothetical examples. More mature organizations are going to have specific criteria in place outlining what stakeholder group can approve what kinds of changes. More informal organizations, quite honestly, will just figure this out as they go along. It’s often up to the business sponsor to decide who needs to be involved in approving this change if they don’t have the authority to do.
Step 4 – Communicate and Implement an Approved Change Request
Provided the change is approved, it’s time to act on the implementation plan and communicate the change throughout the project team. That’s step four, which is to communicate and implement that change request.
Once the change request is approved, the project team needs to be notified. Probably there are project deliverables that need to be updated. So consider not just your requirements documents. That’s an important piece, but it’s not the only piece. At this point you might have technical design documentation. You might have test plans, project schedules, training documentation, any business process documentation for the future state that you’ve already completed as well.
Often these updates are facilitated by a formal change notification process where the project manager, or the business analyst, notifies the project team of the change, and each document owner then incorporates the adjustments into their deliverables.
Manage Change or It Will Manage You!
My final tip is to manage change, or it will manage you.
Often change is thought of as like a dirty word in the project circles. The reality is that change happens for legitimate business reasons.
In today’s fast moving and competitive marketplace, it’s really unrealistic to expect stakeholders to have perfect knowledge of what they want or need to achieve the business objectives.
Yes, we want to avoid drastic changes that are not tied to business objectives. We don’t want to change just for the sake of change. But we also don’t want to do so at the expense of ignoring real opportunities to deliver more value for the organization. The most important thing is that a very informed decision is made about if and how to incorporate the changes, and that there’s a really clear communication with everyone involved about why that decision was made.
As a business analyst, you really have an opportunity here to elevate yourself and your role within the organization by taking initiative. Ensure that steps one and two are completed before a change is brought before a decision maker. Again, that change request template we include in our Business Analyst Template Toolkit is going to give you a structure for pulling this information together.
One last thing I’d like to note here is that changes are often more frequent when you jump right into analyzing the software requirements and not starting by analyzing the business process and understanding the problem to be solved first. There is a lot more to analyzing a business process and it’s a critical business analyst skill that can really set you apart and establish your credibility.
We’ve got several other videos on business process modeling, and I invite you to watch the one below.
>>Save Time Creating Your Change Management Form<<
For a starting point for approaching common business analyst work scenarios, such as managing change requests, check out the Business Analyst Template Toolkit. All of the requirements templates in the toolkit are fully annotated and editable by you, giving you a great starting point for starting your next business analyst project or formalizing your work samples.