BA Bites - Top 10 Signs Your Requirements Are Doomed (and How to Save Them)

BA Bites - Top 10 Signs Your Requirements Are Doomed (and How to Save Them)

Requirements are the backbone of every project—but what happens when they start to fail? In this episode, I break down the most common warning signs that your requirements are doomed and how to rescue them.

🎧 Tune in to discover:

• The 10 red flags every BA should watch for.
• Real-world examples of failed requirements (and how they were saved).
• Practical techniques to fix issues before they derail your project.

Episode Transcript

(00:00):
The Better Business Analysis Institute presence, the Better
Business Analysis podcast with Kenzerman Walsh.
Welcome back to the Better Business Analysis podcast with
your host, Benjamin Walsh, And let's dive in to this BA Bytes
episode 10, Signs Your Requirements Are Doomed and How

(00:25):
to Save Them. This episode taps into the
common pain point of failing requirements.
It's an Evergreen topic for business analysts.
OK, and we're going to talk about the subtle warning signs
and practical fixes to solve theproblem with your requirements.

(00:46):
Every BA has been there. You're halfway through a project
when you realize the requirements just don't work.
The good news? There are always early warning
signs that your requirements arein trouble.
In this episode, I'll share the top 10 signs your requirements
are doomed and more importantly,how to save them before it's too

(01:06):
late. Number one is when stakeholders
can't agree on priorities. This happens because there are
competing interests or unclear goals.
OK. And so you get conflicting
requirements from various stakeholders and it leads to
scope, which wasn't the intention of the project in the

(01:28):
1st place. So you need to really have that
one product owner and raise that.
It's really, really important. You can facilitate a
prioritization workshop to help align everyone on what the
critical requirements are versusthe nice to have.
So bring everyone into the room and get them to choose,
prioritize, get them to do it #2is when the requirements are

(01:54):
just too vague. OK, this happens often.
So you just, you think you've got it, you think you
understand. But when you get into maybe
elaborating on those requirements, you realize
they're too vague, there's lack of details, or you've relied on
too many assumptions from previous work.
And so the developers in the testers end up guessing, and

(02:14):
that causes overwork or rework. So ask clarifying questions like
what does success look like? Or can you provide an example
and write that into the user #3 is there is just no input from
end users. So the management stakeholders
assume they know what users need, but there are misaligned

(02:37):
requirements that lead to low adoption because they're the end
user who's going to be using it.So you need to involve users in
surveys, interviews, and usability.
You need to use people who want to use your product, who are the
end person that you're measuringsuccess on.
They need to be involved in the process #4 happens all the time

(03:00):
is when scope creep is out of control, so new ideas are just
added without proper evaluation.They're added last minute or
there's changes made because you've like releasing artifacts
that get changes, but you haven't done the most important
stuff. But stakeholders just care about
the user facing stuff. But the back end doesn't work,

(03:22):
so you end up with delays and bloated budgets and unclear
objectives. So you need to introduce a
change control process at the right point to evaluate new
requests against the original goal.
And you need to make sure that some of the underlying user
stories that the users don't care about, stakeholders don't
care about, are put in the rightposition and the user story map

(03:46):
and are delivered. Maybe first before you start
doing kind of areas which will gain a lot of feedback #5 is
that when the requirements all about features and not outcome.
So there is a focus on deliverables instead of solving
the core problems. Happens often in an agile

(04:08):
environment which is feature focused or product.
You just build something that doesn't achieve the business
goals. So you need to shift the
conversation to outcomes. What problem are you solving?
How you measure this? You need to take ABA mindset,
not a product feature mindset. The other one is when number

(04:29):
six, which is when the requirements document is
gathering dust or virtual dust. It's created and then it's
ignored. Teams work on outdated or
incomplete requirements because you've moved into an agile tool. 00:04:44,360 You need to make the
requirements a living document. You need to review it and update
them regularly during stand ups and retros.

(04:49):
If you are now saying that the document per SE is now closed,
then you'll use the stories now to need to #7 which happens.
It's going to sound stupid, but it happens often and it's no one
knows who owns what. Sounds stupid, aye, but roles

(05:10):
and responsibilities are not clearly defined.
This happens on so many projects.
I'm involved. Bottlenecks occur,
accountability is lost. Start getting new stakeholders
halfway through. So you need that racing matrix
to clarify who's responsible, who's accountable, who's
consultant, who's informed, who's your number one
stakeholder. Make sure you do that.

(05:30):
It's really, really important. And even more important when
projects are critical or under pressure #8 is when the timeline
is just unrealistic. Stakeholders underestimate the
effort required and you haven't given them a good estimate or
they don't care about your estimate.
So Russ work, rushing to get thework done leads to poor quality,

(05:52):
missed timelines. You need to work with the team
to create a realistic timeline. Tell us what your outcome is.
We'll tell you how long it's going to take.
And then they'll challenge back and you'll say, OK, well, where
do you want us to give in the scope?
And you need to present it alongside with the risk of rushing
something. OK, you need to say if we rush
this, but this is the quality outcome, the level of quality

(06:15):
you're going to get from that outcome.
And is that OK? And they might go, yeah, that's
fine. So don't overcook it as well #9
is when requirements are writtenin text speak.
I see this all the time and they're not or they're too
business focus. There's a middle grounder, a bit
of a kind of Goldilocks state that you want the requirements

(06:39):
to be in. So you can either have
misalignment with the business if it's too technical, or
misalignment with the technical teams of it's too business.
And miscommunication often causes delays or incorrect
implementation. So your job is to bridge the
gap, OK. And by using visual aids like
process diagrams, user stories that allow both users to see it

(07:01):
from their side of the mirror, then that will help people
understanding it on the same page.
And #10 is when there's no validation or testing plan,
everyone just assumes it's goingto work.
This is not just technical testing.
Issues are discovered too late in the development process
because testing's always squeezed.
You need to develop acceptance criteria and involve QA early to

(07:24):
validate requirements with end users and stakeholders.
User acceptance testing. Before the coding begins, you
need to get that QA on the requirements upfront.
V model. Look up the V model if you don't
know it and clarify that and test those requirements before
you test this. OK, I hope you've learned

(07:46):
something there. There were ten ways in which you
might realize that your requirements are doomed and how
to save them along the way. I'll see you next week.