1
00:00:00,320 --> 00:00:04,360
The Better Business analysis 
institute presence, the Better 

2
00:00:04,360 --> 00:00:12,920
Business analysis podcast with 
kingsman Walsh Welcome back to 

3
00:00:12,920 --> 00:00:16,720
the Better Business analysis 
podcast with your host Benjamin 

4
00:00:16,720 --> 00:00:19,400
Walsh from the Better Business 
analysis institute. 

5
00:00:19,800 --> 00:00:25,480
If you haven't yet done your BA 
training, sign up at BBA dot 

6
00:00:25,480 --> 00:00:30,040
Institute and do your Certified 
Better Business Analysis Level 1

7
00:00:30,040 --> 00:00:33,880
course for 199 US. 
It's a great course. 

8
00:00:34,160 --> 00:00:36,720
You'll get certified and become 
ABA. 

9
00:00:36,960 --> 00:00:41,160
Let's dive into our BA Byte 
session this week and that is 

10
00:00:41,600 --> 00:00:47,400
top ten ways BAS accidentally 
sabotage projects and how to 

11
00:00:47,400 --> 00:00:51,760
avoid them. 
No one sets out to sabotage a 

12
00:00:51,760 --> 00:00:56,320
project, but even the best 
business analysts can make the 

13
00:00:56,320 --> 00:01:01,920
mistake that derails progress. 
In this episode, I'll uncover 

14
00:01:01,920 --> 00:01:06,160
the top ten ways BAS 
accidentally sabotage projects 

15
00:01:06,560 --> 00:01:08,960
and more importantly, how to 
avoid them. 

16
00:01:10,160 --> 00:01:14,840
So number one is assuming 
everyone understands the 

17
00:01:14,840 --> 00:01:18,400
requirements. 
BAS assume stakeholders and 

18
00:01:18,400 --> 00:01:22,800
developers are on the same page,
but what you find is that there 

19
00:01:22,800 --> 00:01:26,400
is a misaligned expectation that
leads to rework and frustration.

20
00:01:27,720 --> 00:01:32,520
Always restate the requirements 
in simple terms and confirm 

21
00:01:32,520 --> 00:01:35,880
understanding from both the 
stakeholders and the developers 

22
00:01:35,880 --> 00:01:41,520
before they start coding #2 is 
overloading stakeholders with 

23
00:01:41,520 --> 00:01:46,000
information. 
The desire to be thorough in 

24
00:01:46,120 --> 00:01:50,400
providing information can 
overwhelm in reports and long 

25
00:01:50,400 --> 00:01:53,760
emails and stakeholders will 
just disengage OK and they'll 

26
00:01:53,760 --> 00:01:58,240
miss the critical parts. 
So deliver bite sized updates 

27
00:01:58,240 --> 00:02:01,480
and use visuals like dashboards 
to convey key points. 

28
00:02:01,480 --> 00:02:04,400
Use the what I call the wiggles 
model which is the red, amber, 

29
00:02:04,400 --> 00:02:08,600
green. 
Don't over communicate or expect

30
00:02:08,600 --> 00:02:12,480
the stakeholder to have as much 
time as you might do when 

31
00:02:12,480 --> 00:02:17,440
analysing a problem #3 is 
focusing too much on the what 

32
00:02:17,560 --> 00:02:20,720
and not the why. 
B as get stuck in the details of

33
00:02:20,720 --> 00:02:23,560
delivering right and the 
deliverables and forget the 

34
00:02:23,560 --> 00:02:26,640
bigger picture projects. 
Lose sight of the business 

35
00:02:26,640 --> 00:02:30,120
goals. 
Continuously ask why are we 

36
00:02:30,120 --> 00:02:32,320
doing this? 
Why do we make this choice? 

37
00:02:32,680 --> 00:02:39,680
To ensure alignment with 
business value #4 is not saying 

38
00:02:39,680 --> 00:02:42,720
no to scope creep. 
You're allowed an opinion. 

39
00:02:42,880 --> 00:02:46,840
Fear of upsetting stakeholders 
or wanting to be seen as the 

40
00:02:46,840 --> 00:02:53,440
nice guy can just cause a 
project to grow out of control. 

41
00:02:54,280 --> 00:02:58,920
You could be the gate opener 
instead of the gatekeeper and it

42
00:02:58,920 --> 00:03:00,360
could affect timelines and 
budgets. 

43
00:03:00,560 --> 00:03:04,120
Be firm but diplomatic. 
Let's evaluate how this fits 

44
00:03:04,120 --> 00:03:06,240
into the goals. 
See if we can check it on the 

45
00:03:06,240 --> 00:03:11,960
backlog before we proceed. 
Or spend any time on this #5 

46
00:03:11,960 --> 00:03:16,400
Beers do this often is ignoring 
non verbal feedback in meetings.

47
00:03:17,480 --> 00:03:21,000
Focuses on the agenda not the 
room dynamics. 

48
00:03:22,040 --> 00:03:25,760
The consequence is you miss the 
opportunity to address concerns 

49
00:03:25,760 --> 00:03:29,560
or disengagement or the fact 
that people haven't spoken up in

50
00:03:29,560 --> 00:03:32,280
the meeting. 
Pay attention to body language, 

51
00:03:32,280 --> 00:03:36,760
tone and facial expressions to 
spot unspoken issues. 

52
00:03:36,760 --> 00:03:39,160
And maybe have a bit of a 
debrief with your project 

53
00:03:39,160 --> 00:03:43,080
manager after the meeting and 
say hey look, Tob just didn't 

54
00:03:43,080 --> 00:03:45,480
seem happy. 
Karen wasn't disengaged. 

55
00:03:45,480 --> 00:03:48,200
He was on doing emails. 
How do we get them on board? 

56
00:03:49,760 --> 00:03:52,880
Number six is becoming a 
requirements dictator. 

57
00:03:53,040 --> 00:03:56,440
B as feel the pressure to own 
the requirements completely. 

58
00:03:56,440 --> 00:04:02,120
I do stakeholders feel excluded 
and it leads to resistance, 

59
00:04:02,120 --> 00:04:04,040
right? 
You just got to be careful here.

60
00:04:05,000 --> 00:04:08,320
Facilitate collaboration by 
involving stakeholders early and

61
00:04:08,320 --> 00:04:13,360
often and before you think that 
the requirements are final. 

62
00:04:13,560 --> 00:04:18,279
OK, And they need to be involved
and just think of ways to keep 

63
00:04:18,279 --> 00:04:21,920
them consistently able to have 
their voice shared throughout 

64
00:04:21,920 --> 00:04:27,240
your requirements. 
Their requirements #7 neglecting

65
00:04:27,240 --> 00:04:29,520
to update the requirements as 
things change. 

66
00:04:29,840 --> 00:04:32,480
B. 
As assume initial requirements 

67
00:04:32,480 --> 00:04:35,520
will stay static or the document
doesn't need to be updated. 

68
00:04:35,880 --> 00:04:38,640
Deliverables become irrelevant 
or unstable. 

69
00:04:38,920 --> 00:04:40,840
Treat requirements as living 
documents. 

70
00:04:40,840 --> 00:04:44,400
Revisit them, revise them 
throughout the project. 

71
00:04:44,400 --> 00:04:47,520
If the previous actual 
requirements document like a 

72
00:04:47,960 --> 00:04:51,400
Word document is now superseded,
then make it really clear that 

73
00:04:51,400 --> 00:04:56,320
the requirements live in Jira 
and DevOps #8 is you 

74
00:04:56,400 --> 00:05:01,280
underestimate the power of 
politics B as focus on technical

75
00:05:01,280 --> 00:05:04,480
or process side and ignore 
organization dynamics that say 

76
00:05:04,480 --> 00:05:07,160
that often in 2025 you need to 
be different. 

77
00:05:08,000 --> 00:05:11,800
Then you find out that there was
already misaligned priorities or

78
00:05:12,280 --> 00:05:16,000
hidden resistance which is going
to derail you along the way. 

79
00:05:16,720 --> 00:05:22,480
Stop, get those issues 
addressed, escalate, maybe even 

80
00:05:22,480 --> 00:05:26,800
map out those power dynamics in 
your organization and identify 

81
00:05:26,800 --> 00:05:30,720
the actual key influences, even 
if they are usually the people 

82
00:05:30,720 --> 00:05:34,880
that are a pain in the bum. 
Get them involved early and 

83
00:05:34,880 --> 00:05:40,080
you'll find that things don't 
turn to custard later on #9 is 

84
00:05:40,080 --> 00:05:46,320
skipping the retrospective 
project fatigue leads teams to 

85
00:05:46,320 --> 00:05:50,120
skip post project reviews? 
You just want it to be over. 

86
00:05:50,120 --> 00:05:53,160
It's the end of the year. 
Maybe teams missed the chance to

87
00:05:53,160 --> 00:05:55,640
learn from mistakes and 
successes. 

88
00:05:56,240 --> 00:05:59,760
It's just too much pressure to 
have a retro fit them in. 

89
00:06:00,080 --> 00:06:04,440
Make retrospectors non 
negotiable and frame them as a 

90
00:06:04,440 --> 00:06:08,080
positive growth oriented 
activity, not just a bitching 

91
00:06:08,200 --> 00:06:10,960
session. 
And #10 it's forgetting to 

92
00:06:10,960 --> 00:06:13,280
advocate for the customer and 
end user. 

93
00:06:13,920 --> 00:06:16,800
Pressure from stakeholders 
shifts away from the end users 

94
00:06:16,800 --> 00:06:19,120
needs as projects get under 
pressure. 

95
00:06:19,920 --> 00:06:22,920
The consequences that your 
product, your change just may 

96
00:06:22,920 --> 00:06:26,560
not be adopted as well or you 
just might not meet the business

97
00:06:26,560 --> 00:06:29,960
goals or value that you wanted 
to deliver. 

98
00:06:31,520 --> 00:06:35,520
Regularly check in within users 
and customers include their 

99
00:06:35,520 --> 00:06:39,080
feedback throughout the project.
You as the BA are the one person

100
00:06:39,400 --> 00:06:41,320
who can do that better than 
anyone else. 

101
00:06:41,720 --> 00:06:45,040
So there you have it. 
Ten ways BAS accidentally 

102
00:06:45,040 --> 00:06:49,320
sabotage projects. 
I will see you next week.