6 Ways Business Analysts Minimize Project Rework

Minimizing project rework is one of the values I hold close to my heart as a business analyst. My insides nearly turn out when I discover the development team is changing their implementation of a requirement that I gained approval for.

Even so, notice I didn’t say that I expect myself to eliminate rework. Yes, rework will happen. Even with the best of business analysis practices, there will be times when you miss or misunderstand minor requirements or where the business learns something new between requirements and development that leads to changing important requirements.

(As an aside, this is why shrinking the time lag between requirements and development is becoming such an important element of business analysis effectiveness. Business contexts are shifting too quickly to finalize a set of requirements one year and implement them the next.)

But I digress! Even as an effective business analyst, the kind who might reasonably be expected to miss a requirement here and there, you will be minimizing rework in the best possible way.

And here’s how.

#1 – Discover Business Context

First, you investigate the business context before defining specific software features. It might be by understanding the business need, exploring the business process, or creating a system context diagram, but you don’t look at software features in isolation. You look at how they matter and why they matter. This raises all kinds of interesting elicitation questions and makes you less likely to overlook anything important.

#2 – Ensure Stakeholders Understand

Second, you ensure stakeholders understand what they are getting before they get it. Oftentimes requirements change because the stakeholder did not really understand the requirements in the first place. Effective business analysts use visual models, particularly workflow diagrams and wireframes, to help confirm the requirements. They also use a wide range of validation techniques.

#3 – Include All Stakeholders

Third, you ensure all possible stakeholders are included in the process. If you see a link to accounting, you get a representative from accounting involved before conducting your final requirements review. If your gut tells you a stakeholder is going to disagree and raise a stink, you deal with that stink before confirming the requirements rather than after the code is tested.

#4 – Resolve Disagreements

Fourth, and this follows from above, you take care to resolve disagreements before code is implemented. This takes a bit of a thick skin, because it means that you need to step into the conflict and help stakeholders negotiate to an acceptable solution. It is also one of those effective business analysis practices that can actually feel like it’s taking more time instead of less, but it pays dividends in terms of costs later on.

#5 – Analyze the Requirements

Fifth, and this goes to the heart of what we do as business analysts, you analyze requirements. This means you discover connections, such as data fields that show up on reports but are never collected, and go beyond the requirements stakeholders tell you they want to also identify the requirements they will need. You might rely on your intelligence and logical thinking skills to find missing requirements, or you might use a collection of analysis models, such as use cases, business process models, and data models.

#6 – Establish Reasonable Schedule Expectations

Finally, you push back on development or project management when they are asking you to deliver requirements now (or yesterday) but they are simply not ready yet. I once made the mistake of passing on requirements a week too early. It was my first agile project and development convinced me that changes would be embraced.

While I was able to make assumptions that led to getting the requirements about 80% right (which is not bad considering I was an outside consultant and lacked much knowledge of the business domain), the 20% I got wrong due to lack of time for validation caused nearly 50% of rework for the developers. The development team was not happy and I learned my lesson. Stay strong and establish reasonable expectations as to the business analysis schedule.

When you are applying effective business analysis practices – such as engaging stakeholders, analyzing connections, validating requirements, and keeping the big picture in mind – you are minimizing rework by the entirety of your project team. And that fact is extremely important when it comes to establishing your value as a business analyst.

Minimizing vs. Eliminating Rework

Before we close off today’s article, I want to speak to this difference of minimizing rework and eliminating it entirely, because the last thing I’d want you to do as a result of reading this is to refuse to pass off anything to development because you are not 100% sure it’s correct.

Effective business analysts can expect a small amount of rework because you are maximizing your time applying the set of techniques you believe will help you discover the most relevant information, rather than throwing every technique in the book at a problem. Effective business analysts pick and choose and sometimes they choose wrong.

Realize that if you over-invest in the requirements process by using every possible technique, you might feel like you are theoretically discovering more and better requirements, but you aren’t actually reducing costs. And, besides, by the time you get the requirements done, the business context may have shifted, and you’ll end up facing rework anyway.

There is a healthy balance here between completeness and progress that an effective business analysis is always aware of and driving to. And that’s why the best business analysts might actually be expected to miss a requirement here and there, even if it turns their insides out a little.

By the way, this is one of those articles you might want to pass on to your manager, the other business analysts on your team, or quietly post on your company’s intranet. It explains why you do what you do as a business analyst. And if you share it, you will be even more likely to actually follow through on effective business analysis practices when it feels difficult to do so.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.