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.