The Better Business analysis institute presence, the Better
Business analysis podcast with kingsman Walsh Welcome back to
the Better Business analysis podcast with your host Benjamin
Walsh from the Better Business analysis institute.
If you haven't yet done your BA training, sign up at BBA dot
Institute and do your Certified Better Business Analysis Level 1
course for 199 US. It's a great course.
You'll get certified and become ABA.
Let's dive into our BA Byte session this week and that is
top ten ways BAS accidentally sabotage projects and how to
avoid them. No one sets out to sabotage a
project, but even the best business analysts can make the
mistake that derails progress. In this episode, I'll uncover
the top ten ways BAS accidentally sabotage projects
and more importantly, how to avoid them.
So number one is assuming everyone understands the
requirements. BAS assume stakeholders and
developers are on the same page, but what you find is that there
is a misaligned expectation that leads to rework and frustration.
Always restate the requirements in simple terms and confirm
understanding from both the stakeholders and the developers
before they start coding #2 is overloading stakeholders with
information. The desire to be thorough in
providing information can overwhelm in reports and long
emails and stakeholders will just disengage OK and they'll
miss the critical parts. So deliver bite sized updates
and use visuals like dashboards to convey key points.
Use the what I call the wiggles model which is the red, amber,
green. Don't over communicate or expect
the stakeholder to have as much time as you might do when
analysing a problem #3 is focusing too much on the what
and not the why. B as get stuck in the details of
delivering right and the deliverables and forget the
bigger picture projects. Lose sight of the business
goals. Continuously ask why are we
doing this? Why do we make this choice?
To ensure alignment with business value #4 is not saying
no to scope creep. You're allowed an opinion.
Fear of upsetting stakeholders or wanting to be seen as the
nice guy can just cause a project to grow out of control.
You could be the gate opener instead of the gatekeeper and it
could affect timelines and budgets.
Be firm but diplomatic. Let's evaluate how this fits
into the goals. See if we can check it on the
backlog before we proceed. Or spend any time on this #5
Beers do this often is ignoring non verbal feedback in meetings.
Focuses on the agenda not the room dynamics.
The consequence is you miss the opportunity to address concerns
or disengagement or the fact that people haven't spoken up in
the meeting. Pay attention to body language,
tone and facial expressions to spot unspoken issues.
And maybe have a bit of a debrief with your project
manager after the meeting and say hey look, Tob just didn't
seem happy. Karen wasn't disengaged.
He was on doing emails. How do we get them on board?
Number six is becoming a requirements dictator.
B as feel the pressure to own the requirements completely.
I do stakeholders feel excluded and it leads to resistance,
right? You just got to be careful here.
Facilitate collaboration by involving stakeholders early and
often and before you think that the requirements are final.
OK, And they need to be involved and just think of ways to keep
them consistently able to have their voice shared throughout
your requirements. Their requirements #7 neglecting
to update the requirements as things change.
B. As assume initial requirements
will stay static or the document doesn't need to be updated.
Deliverables become irrelevant or unstable.
Treat requirements as living documents.
Revisit them, revise them throughout the project.
If the previous actual requirements document like a
Word document is now superseded, then make it really clear that
the requirements live in Jira and DevOps #8 is you
underestimate the power of politics B as focus on technical
or process side and ignore organization dynamics that say
that often in 2025 you need to be different.
Then you find out that there was already misaligned priorities or
hidden resistance which is going to derail you along the way.
Stop, get those issues addressed, escalate, maybe even
map out those power dynamics in your organization and identify
the actual key influences, even if they are usually the people
that are a pain in the bum. Get them involved early and
you'll find that things don't turn to custard later on #9 is
skipping the retrospective project fatigue leads teams to
skip post project reviews? You just want it to be over.
It's the end of the year. Maybe teams missed the chance to
learn from mistakes and successes.
It's just too much pressure to have a retro fit them in.
Make retrospectors non negotiable and frame them as a
positive growth oriented activity, not just a bitching
session. And #10 it's forgetting to
advocate for the customer and end user.
Pressure from stakeholders shifts away from the end users
needs as projects get under pressure.
The consequences that your product, your change just may
not be adopted as well or you just might not meet the business
goals or value that you wanted to deliver.
Regularly check in within users and customers include their
feedback throughout the project. You as the BA are the one person
who can do that better than anyone else.
So there you have it. Ten ways BAS accidentally
sabotage projects. I will see you next week.