1
00:00:00,280 --> 00:00:04,360
The Better Business Analysis 
Institute presence, the Better 

2
00:00:04,360 --> 00:00:07,720
Business Analysis Podcast with 
Kingsman Walsh. 

3
00:00:12,680 --> 00:00:15,680
Welcome back to the Better 
Business Analysis podcast with 

4
00:00:15,680 --> 00:00:18,840
Benjamin Walsh. 
And today we're continuing on 

5
00:00:18,840 --> 00:00:21,480
our BA Byte series and we're 
going to be talking about the 

6
00:00:21,480 --> 00:00:24,200
analysis squeeze. 
That's right. 

7
00:00:24,400 --> 00:00:27,280
This is when you're starting to 
do requirements. 

8
00:00:27,520 --> 00:00:30,040
There's pressure from the 
technical team or the delivery 

9
00:00:30,040 --> 00:00:34,640
team, pressure from your 
stakeholders to move into 

10
00:00:35,120 --> 00:00:38,840
creating something, doing 
something, seeing some tangible 

11
00:00:38,840 --> 00:00:42,360
results. 
And it's called the, I guess 

12
00:00:42,360 --> 00:00:45,240
it's the analysis squeeze. 
We just don't have much time as 

13
00:00:45,240 --> 00:00:50,240
BA's to do our job sometimes. 
And this is a common problem and

14
00:00:50,240 --> 00:00:52,880
I've experienced this recently 
and I just want to outline what 

15
00:00:52,880 --> 00:00:57,040
the problem is and just some 
recommendations for you if you 

16
00:00:57,040 --> 00:01:02,560
find yourself in this situation.
So you can be quite frustrated 

17
00:01:02,560 --> 00:01:06,440
that stakeholders just don't 
appreciate the time needed to do

18
00:01:06,720 --> 00:01:10,400
thorough analysis right before 
requirements are written. 

19
00:01:10,800 --> 00:01:16,120
So people just expect, and I 
guess this is a bit of a, I 

20
00:01:16,120 --> 00:01:19,840
guess the transition from 
thinking that BA is just right 

21
00:01:19,840 --> 00:01:22,360
requirements or just 
documentation writers. 

22
00:01:22,760 --> 00:01:26,760
But actually, you know, we are 
business analysts and, and we 

23
00:01:26,760 --> 00:01:29,440
need to do analysis. 
Our job is to make sure things 

24
00:01:29,440 --> 00:01:32,200
are logical. 
It does matter how we write 

25
00:01:32,200 --> 00:01:35,160
requirements. 
It's not as simple as just 

26
00:01:36,160 --> 00:01:41,160
taking minutes at a workshop. 
And so there are some problems 

27
00:01:41,160 --> 00:01:43,040
here. 
You get a couple of problems and

28
00:01:43,040 --> 00:01:46,240
one of them I guess we'll start 
with is the stakeholder 

29
00:01:46,560 --> 00:01:50,440
pressures. 
So there's a focused on speed. 

30
00:01:50,440 --> 00:01:54,160
Stakeholders often prioritize 
speed to market or project 

31
00:01:54,160 --> 00:01:57,640
completion, OK? 
They don't understand that you 

32
00:01:57,640 --> 00:02:03,840
need to spend a lot of time or a
decent chunk of time upfront so 

33
00:02:03,840 --> 00:02:06,360
that you are getting the 
requirements complete and 

34
00:02:06,360 --> 00:02:11,039
accurate so they're not wasting 
money at the end of the project,

35
00:02:11,039 --> 00:02:13,320
right. 
So there there's a long term 

36
00:02:13,320 --> 00:02:16,920
benefit in terms of project 
speak to do the analysis. 

37
00:02:17,000 --> 00:02:21,160
It happens many a time where 
development teams get frustrated

38
00:02:21,160 --> 00:02:24,920
that the requirements change. 
And actually I would, I would 

39
00:02:24,920 --> 00:02:28,120
say that requirements do change 
and you can put a request for 

40
00:02:29,640 --> 00:02:32,840
change, request a process 
through, you can have change 

41
00:02:32,840 --> 00:02:35,160
control. 
You might be working in an agile

42
00:02:35,440 --> 00:02:38,080
environment. 
But most of the time that I see 

43
00:02:38,080 --> 00:02:40,880
it, when we see developers 
saying, oh, requirements have 

44
00:02:40,880 --> 00:02:45,520
changed, I go back and I look 
and I examine whether or not the

45
00:02:45,520 --> 00:02:49,080
BA has had enough time to do the
work properly or whether or not 

46
00:02:49,560 --> 00:02:52,240
they've even asked their 
stakeholders, their product 

47
00:02:52,240 --> 00:02:56,600
owners for their requirements. 
And you'll be surprised that a 

48
00:02:56,920 --> 00:03:00,080
lot of times that isn't done. 
That isn't the case. 

49
00:03:00,360 --> 00:03:02,160
So when I say requirements 
haven't changed, well, 

50
00:03:02,160 --> 00:03:04,520
requirements weren't captured in
the 1st place. 

51
00:03:05,280 --> 00:03:11,440
Now stakeholders don't see the 
value in the unseen work. 

52
00:03:11,600 --> 00:03:16,160
OK, like analysis, they focus on
tangible deliverables like 

53
00:03:16,160 --> 00:03:20,360
written requirements or so 
there's very limited visibility 

54
00:03:20,360 --> 00:03:23,720
what we do as BAS. 
So for me, I use a couple of 

55
00:03:23,720 --> 00:03:27,160
techniques to make sure that the
requirements are right. 

56
00:03:27,160 --> 00:03:31,600
You know, I go down, I go up I'm
you know, I look different ways,

57
00:03:31,600 --> 00:03:34,760
I do some logic checking, I try 
and play Chesser. 

58
00:03:34,760 --> 00:03:38,400
But this is analysis, right? 
You might want to feed data in, 

59
00:03:38,400 --> 00:03:41,160
you might want to check things 
with developers, you might want 

60
00:03:41,160 --> 00:03:44,800
to check with architects. 
This is all part of the analysis

61
00:03:44,800 --> 00:03:49,240
process and stakeholders just 
don't understand it or 

62
00:03:49,240 --> 00:03:50,200
appreciate it. 
OK. 

63
00:03:50,200 --> 00:03:52,360
And they, I mean, they don't 
really understand sometimes what

64
00:03:52,360 --> 00:03:55,160
BAS do, but this is a, this 
isn't a really important part of

65
00:03:55,160 --> 00:03:58,160
it. 
They've also got this kind of 

66
00:03:58,200 --> 00:04:03,280
unreal expectation that coming 
from a non-technical background,

67
00:04:03,280 --> 00:04:06,800
if you like, but they don't 
really grasp the complexity of 

68
00:04:06,800 --> 00:04:08,600
gathering and analyzing 
requirements. 

69
00:04:08,960 --> 00:04:12,000
And, and, and, and we, we stop 
really using the word gather 

70
00:04:12,000 --> 00:04:14,400
requirements because that 
suggests a bucket. 

71
00:04:14,720 --> 00:04:17,040
But actually it's elicitation. 
Elicitation. 

72
00:04:17,040 --> 00:04:21,240
Getting the technique of running
a great workshop is one thing, 

73
00:04:21,279 --> 00:04:23,560
right? 
Running a great workshop, people

74
00:04:23,560 --> 00:04:25,040
go, wow, that's the value of 
BAS. 

75
00:04:25,280 --> 00:04:27,960
Wow, BAS really good. 
You, you ran an awesome 

76
00:04:27,960 --> 00:04:29,880
workshop. 
I can't believe you managed 

77
00:04:29,880 --> 00:04:33,160
stakeholders and got some 
outcomes, right? 

78
00:04:33,160 --> 00:04:35,560
That's one part of it. 
And then they go, wow, I really 

79
00:04:35,560 --> 00:04:38,920
appreciate business analysis and
your skills, but there's only 

80
00:04:38,920 --> 00:04:40,800
half of it. 
That's the business side of 

81
00:04:40,800 --> 00:04:42,920
working with the business, but 
you've also got to do the 

82
00:04:42,920 --> 00:04:46,680
analysis. 
There's also requirements phase 

83
00:04:46,680 --> 00:04:49,680
is also under pressure. 
When a project kicks off, 

84
00:04:49,680 --> 00:04:52,760
especially if the BA has been 
brought on late and the 

85
00:04:52,760 --> 00:04:55,480
development team's already, you 
know, in motion and you've 

86
00:04:55,480 --> 00:04:58,360
already got an architect there. 
This can be pressure from those 

87
00:04:58,360 --> 00:05:00,240
stakeholders to say, oh, well, 
we don't have much time to 

88
00:05:00,240 --> 00:05:02,000
deliver, so we need the 
requirements done now. 

89
00:05:02,000 --> 00:05:04,560
So there's tight deadlines. 
Projects have aggressive 

90
00:05:04,560 --> 00:05:07,240
timelines, putting pressure on 
the requirements phase to be 

91
00:05:07,240 --> 00:05:09,840
done quickly. 
But like I said, if you're not, 

92
00:05:10,600 --> 00:05:13,160
if you don't work out what 
you're going to build and you 

93
00:05:13,240 --> 00:05:16,160
you haven't worked out why 
you're doing it, then you can 

94
00:05:16,160 --> 00:05:19,440
just waste more time building. 
So it's really important to have

95
00:05:20,000 --> 00:05:24,480
a, a decent chunk of BA time. 
When I say decent chunk, I would

96
00:05:24,480 --> 00:05:28,680
suggest as a rule of thumb, 20% 
of the project should be on 

97
00:05:28,680 --> 00:05:31,680
analysis and design. 
So if if you're if you're 

98
00:05:31,680 --> 00:05:35,440
finding that you're only 
spending like 5% or 1% of the 

99
00:05:35,440 --> 00:05:38,680
total project time on analysis, 
then that suggests that 

100
00:05:38,680 --> 00:05:42,560
something's up. 
The other thing is that we work 

101
00:05:42,560 --> 00:05:47,000
can work in a incomplete 
information kind of hole. 

102
00:05:47,000 --> 00:05:50,640
Sometimes stakeholders don't 
necessarily have all the 

103
00:05:50,640 --> 00:05:53,400
information readily available 
and so you have to go back and 

104
00:05:53,400 --> 00:05:57,840
forth with them. 
So it's a process of check in, 

105
00:05:57,840 --> 00:06:02,160
sign off, and all of that is 
conflated in terms of your 

106
00:06:02,160 --> 00:06:04,640
estimation for the requirements 
phase, when actually the 

107
00:06:04,640 --> 00:06:06,960
duration might be pushed out 
because you've got to check with

108
00:06:06,960 --> 00:06:09,200
people when you're going to get 
sign off and you get some people

109
00:06:09,200 --> 00:06:13,000
to read documents. 
Whereas you're having so many 

110
00:06:13,000 --> 00:06:14,920
meetings and it's eating up your
time. 

111
00:06:14,920 --> 00:06:18,240
And then a month passes and 
you've literally only spent a 

112
00:06:18,240 --> 00:06:21,600
couple of days doing analysis. 
This can be really frustrating. 

113
00:06:22,280 --> 00:06:25,560
There's also the post 
elicitation expectations, right?

114
00:06:25,880 --> 00:06:27,960
So there's a misunderstanding of
elicitation. 

115
00:06:27,960 --> 00:06:31,000
Like I said before, stakeholders
see elicitation sessions, 

116
00:06:31,000 --> 00:06:34,920
workshops, interviews as a point
where final requirements are 

117
00:06:34,920 --> 00:06:38,120
delivered, not at the starting 
point of analysis. 

118
00:06:38,360 --> 00:06:42,840
This is just when we're starting
to elicitate reusing that word 

119
00:06:43,080 --> 00:06:46,000
to pull out the requirements, 
but it requires some time to go.

120
00:06:46,000 --> 00:06:49,440
OK, did this stakeholder have, 
what was the overlap? 

121
00:06:49,440 --> 00:06:53,600
Which ones are common? 
This, this is where the really 

122
00:06:53,800 --> 00:06:56,520
important side of business 
analysis is. 

123
00:06:57,200 --> 00:07:01,320
So our job is to explain the 
importance of analysis for 

124
00:07:01,320 --> 00:07:05,120
building a solid foundation and 
avoiding rework later. 

125
00:07:05,120 --> 00:07:08,640
I think what you should do if 
you're stuck in the situation, 

126
00:07:08,640 --> 00:07:11,320
you need to explain to 
stakeholders that these projects

127
00:07:11,320 --> 00:07:14,160
haven't gone well because you 
haven't really had enough input 

128
00:07:14,160 --> 00:07:16,600
into them. 
And when there's a disconnect 

129
00:07:16,600 --> 00:07:19,960
between the development team and
maybe the business side, 

130
00:07:20,680 --> 00:07:23,040
historically you could say, 
well, that's because you haven't

131
00:07:23,040 --> 00:07:25,880
done the analysis properly, 
development team started just 

132
00:07:25,880 --> 00:07:28,360
developing. 
This all gives you an indication

133
00:07:28,360 --> 00:07:30,800
that the communication isn't 
quite right there. 

134
00:07:31,920 --> 00:07:35,800
Also, when you are outlining the
requirements gathering process, 

135
00:07:36,040 --> 00:07:40,400
you need to highlight the 
analysis phase as a distinct set

136
00:07:41,040 --> 00:07:44,400
of time period after 
elicitation. 

137
00:07:44,800 --> 00:07:48,360
So I think you should do 
elicitation, analysis and design

138
00:07:48,360 --> 00:07:52,160
or whatever terms you use for 
their workshops. 

139
00:07:52,160 --> 00:07:55,920
Analysis design in the project 
plan or in your sprints. 

140
00:07:56,600 --> 00:07:59,240
You need to manage communication
regularly with stakeholders, 

141
00:07:59,240 --> 00:08:02,280
keeping them informed of the 
progress and potential 

142
00:08:02,280 --> 00:08:06,200
roadblocks are due to incomplete
information and you. 

143
00:08:06,360 --> 00:08:11,040
And just just be careful here 
that when I say this, if you are

144
00:08:11,040 --> 00:08:13,520
under pressure to deliver 
something, you may be able to 

145
00:08:13,520 --> 00:08:15,800
lock down half your 
requirements, maybe the priority

146
00:08:15,800 --> 00:08:18,920
ones early and still have time 
to work on the others. 

147
00:08:18,920 --> 00:08:21,800
And just explain that you might 
not deliver them as one set of 

148
00:08:21,800 --> 00:08:26,680
requirements and that's OK. 
The other thing that you could 

149
00:08:26,680 --> 00:08:31,360
do is get stakeholders involved 
in the analysis process when you

150
00:08:31,360 --> 00:08:32,880
check in. 
So you could book in a whole lot

151
00:08:32,880 --> 00:08:36,320
of workshops after the 
elicitation workshops to check 

152
00:08:36,320 --> 00:08:38,600
in and the project manager will 
see them as something that's 

153
00:08:38,600 --> 00:08:42,280
visible and tangible. 
So I'm going to give you just 

154
00:08:42,280 --> 00:08:44,280
one scenario before we finish 
here. 

155
00:08:44,720 --> 00:08:48,920
So you're a business analyst, 
let's say you're just working on

156
00:08:48,920 --> 00:08:53,480
the implementation of a new 
check in kiosk at a hospital, 

157
00:08:53,480 --> 00:08:56,680
for example. 
And the challenge is that 

158
00:08:56,680 --> 00:08:59,520
stakeholders are eager to see 
the final requirements document 

159
00:08:59,520 --> 00:09:02,400
and kick off straight after the 
workshop to get their 

160
00:09:02,400 --> 00:09:04,240
requirements. 
And they really would just want 

161
00:09:04,240 --> 00:09:06,160
to get the chaos in as fast as 
possible. 

162
00:09:06,840 --> 00:09:12,160
So what I would do is before you
even kick off the workshop is 

163
00:09:12,160 --> 00:09:15,280
maybe distribute a pre workshop 
document explaining the 

164
00:09:15,280 --> 00:09:18,240
requirements process that this 
is the workshop now. 

165
00:09:18,240 --> 00:09:20,760
But then afterwards you're going
to have a series of refinement 

166
00:09:20,760 --> 00:09:23,120
sessions. 
You got to do some analysis and 

167
00:09:23,120 --> 00:09:25,320
then design is going to happen. 
Maybe mock ups are going to 

168
00:09:25,320 --> 00:09:28,440
happen after that. 
So they are aware straight up 

169
00:09:28,760 --> 00:09:32,680
going in what how this workshop 
contributes and they're not 

170
00:09:32,680 --> 00:09:35,120
expecting the requirements 
straight straight afterwards. 

171
00:09:35,720 --> 00:09:39,320
OK, clearly state that the 
workshop is followed by an 

172
00:09:39,320 --> 00:09:41,720
analysis phase to refine 
requirements. 

173
00:09:41,720 --> 00:09:44,160
Maybe even go to detail of how 
that's going to work. 

174
00:09:45,760 --> 00:09:49,840
You can, when you're having the 
workshop, you need to emphasize 

175
00:09:49,840 --> 00:09:54,000
what the workshop is about and 
that the analysis, the analysis 

176
00:09:54,000 --> 00:09:57,160
phase is now going, OK, well, 
how from a logical point of 

177
00:09:57,160 --> 00:10:01,400
view, maybe not a solution point
of view, how that you're going 

178
00:10:01,400 --> 00:10:05,520
to get from the needs 
identification to some actual 

179
00:10:05,520 --> 00:10:08,280
tangible requirements. 
That's easier said than done. 

180
00:10:09,360 --> 00:10:12,240
You could also do a next steps 
session. 

181
00:10:12,240 --> 00:10:15,240
And one of the things that I do 
always, and I'll leave you with 

182
00:10:15,240 --> 00:10:19,400
this is do a PowerPoint 
presentation before the 

183
00:10:19,400 --> 00:10:21,800
requirements phase. 
So come back and say we, we 

184
00:10:21,800 --> 00:10:25,400
achieved this in the workshop. 
The next steps are following. 

185
00:10:25,600 --> 00:10:28,160
This is what you told us. 
And maybe give them a high level

186
00:10:28,160 --> 00:10:32,120
idea and then show that you need
to do some analysis on these 

187
00:10:32,120 --> 00:10:35,280
areas, these requirement areas, 
these epics, if you like, or 

188
00:10:35,280 --> 00:10:39,280
even user stories to really get 
to a point where they can be 

189
00:10:39,280 --> 00:10:40,760
handed over to the development 
team. 

190
00:10:41,160 --> 00:10:43,320
And again, you can show the 
development team that this is 

191
00:10:43,320 --> 00:10:46,240
the high level pack and that 
you'll be drip feeding, if it's 

192
00:10:46,240 --> 00:10:49,080
a kind of an agile approach, 
those requirements along the 

193
00:10:49,080 --> 00:10:50,600
way. 
And you can even ask them which 

194
00:10:50,600 --> 00:10:55,480
ones they need to, they need you
to get clarity on before they 

195
00:10:55,480 --> 00:10:59,320
start the development phase. 
OK, so you know there is 

196
00:10:59,520 --> 00:11:01,000
pressure with the analysis 
phase. 

197
00:11:01,000 --> 00:11:03,440
And I hope you've learned 
something today about how you 

198
00:11:03,440 --> 00:11:05,200
can manage that. 
And you're not alone. 

199
00:11:05,200 --> 00:11:08,600
This happens to BAS every day 
out there. 

200
00:11:08,800 --> 00:11:09,480
Have a good week.