3 Tips for Minimizing Requirements Changes

We know that one of the ways we add value as a business analyst is through reducing rework and requirements churn. We get everyone on the same page about what DONE means, and minimize unnecessary requirements changes.

What do we do if stakeholders keep changing their requirements? How can we ever be done? And how can we ensure we are maximizing the return on investment for our projects?

That’s the topic of this video.

 

For those who like to read instead of watch, here’s the full text of the video:

I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

Today, I want to talk about requirements change because we know that one of the ways that we add value as business analysts is by reducing the rework and the requirements churn that happens in a project where somebody isn’t managing the requirements and communicating and collaborating about the requirements effectively.

As business analysts, we get everyone on the same page about what “done” means, and what a successful project looks like. We help facilitate the communication of how multiple people contribute to that solution and can fill their role to make sure that solution delivers the value in the end.

But what if requirements keep changing and stakeholders keep changing their mind about the requirements? What do we do? That’s what we’re going to talk about in today’s video.

The first thing, I’m going to share 3 tips, really simple tips, about how to manage and reduce unnecessary requirements change on your project. A super important way that we add value as business analysts.

#1 – Minimize Requirements Changes by Solving the Right Problem

The first way is that we understand the problem that we’re solving and we make sure we’re solving the right problem. You hear me say this again and again, but it’s so important, it’s so fundamental. And in our business analysis process that we teach at Bridging the Gap, it’s steps 2 and 3 of the process. Step 2 is defining the business objectives, and step 3 is defining the scope.

When we skip those steps, which we’re often tempted to do because it’s like just start coding or just start writing the requirements. Don’t worry about those business objectives. Just tell me what I need to build. Get me the requirements as quickly as possible. Big pressure that we feel.

When we skip steps 2 and 3, and we’re figuring out all these detailed requirements, that’s when they tend to change the most. All that time we saved not figuring out our business objectives and getting alignment from our stakeholder community around scope, is essentially time that gets re-purposed in churning through the details requirements again and again. Because we’re trying to hit what feels like a moving target.

One day we’re solving the sales problem, and the next day we’re solving customer retention, and the next day we’re solving a sales problem again. And our requirements keep changing because the problem that we’re solving in this project isn’t understood clearly by our business community, isn’t understood clearly by us, and so we have a challenge of shaping the requirements to solve that problem. Number one; way easy. If you do nothing else, do that, and it will help reduce requirements change.

#2 – Minimize Requirements Changes by Reviewing and Validating Your Requirements

The second tip is to think about your review and your validation processes. Do you have all the right people in the room in that process? Are you walking through the requirements in such a way that your stakeholders can truly understand what they mean and how they’re going to impact them and their business?

Often, we might, historically, have a long list of functional requirements or, in current day, have a long list of user stories. So, you’re like reviewing these individual pieces one at a time. Okay, do you want this? Is this good? Do you want this? Is this good? It’s hard to keep track of the big picture, and it’s hard to see once I have all these individual requirements, is this what I want as a business user?

Thinking about how to include more analytical models and more visual models is why we do business process models, use cases, wireframes, process diagrams, and entity relationship diagrams, context diagrams showing how the system is going to work, and helping people see their role in that system is a more useful way of doing that validation. When you’re getting the requirements approved, people know what they’re approving and how that’s going to impact them.

#3 – Minimize Requirements Changes by Communicating Implications of Change

The third tip that I want to share with you is to be clear about the implications of change and what it means to actually approve requirements. We could say, “Oh, you’re signing on the dotted line.” So, what? I can change my mind. We’ve got a change request form. How do we change? There’s always going to be room for some change in projects, but clearly identifying what the cost of that change is.

One example, my very first agile project, they were like, “Laura, we need the requirements by Monday. We’re going to have our sprint planning meeting. Please just do your best and get them to us in the best possible form. If we have to change them later, it’s no big deal.” This is what the developers told me. I was like, okay, it’s agile. Change isn’t a big deal anymore. I drank the Kool-Aid. And then it comes two days, and I had one stakeholder that I couldn’t get time on their calendar to confirm the requirements.

And, so, I knew that the requirements were not validated the way that I would have liked. So two days into that first sprint was a two-week sprint, I got time on that person’s calendar. We walked through and we made some changes, and I had the adjustments to those requirements, those user stories that they were building from. I was like, okay, now I’ve got them final. They were like, “No, no, no, we’re going to wait until the next sprint to make those changes.”

Then, when I went into the next sprint planning meeting with the updated requirements that they just had two weeks implementing, they weren’t super happy with me as their business analyst because they were like, “Well, we just spent two weeks implementing something and it was the wrong thing.” I was like, yeah, that was the cost of me not being able to confirm those requirements ahead of time and the pressure that we had.

Being clear with your business community about the implications of the change, as well as your development community, if they’re pressuring you to have the requirements “done” before you’ve done the validation that you know you need to do, those are both ways that we need to step up as leaders, as business analysts, and we need to say, “This is when we know the requirements are done. This is what it means, like to our business users, this is what it means to be done.”

Somebody is going to go build this. If you want them to build it again, it’s going to be another sprint, which will either delay other requirements that you have, or it’s going to add costs to the project. Making sure that kind of message is getting in front of the people that actually are in charge of the costs, or are in charge of the scope and so they understand the implications of what change means from that forward.

You’ll find, when you start to have that conversation with people they’ll be like, “Oh,” and they’ll start dialing in and paying more attention to the walk-throughs because they understand there’s a downstream impact if they make a change after that point.

That doesn’t mean that there’s no change. It just means that you’ve done the best work you can as a business analyst to eliminate and minimize unnecessary change, which is change that just comes up because people aren’t paying attention, they’re not reviewing the documents, and they’re not understanding the documentation. They’re not communicating clearly about what they want.

So, you’re still going to have some change in projects. Project environments will change, business goals will change, things outside your project will impact your project. You’ll see what’s been created and you’ll discover new needs and wants, and those will get reflected as changes into your project. There’s always going to be some change. You want to reduce the unnecessary change that just comes from, quite honestly, lazy business analysis.

That’s my tip for you today. Please leave a comment below. What adjustment are you going to make to your requirements process to reduce unnecessary changes to the requirements?

Again, I’m Laura Brandenburg from Bridging the Gap. We help you start your business analyst career.

>>Looking for More Support?

Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.

Click here to learn more about the Effective Conversations Template Collection