The Better Business Analysis Institute presence, the Better
Business Analysis Podcast with Kingsman Walsh.
Welcome back to the Better Business Analysis podcast with
Benjamin Walsh. And today we're continuing on
our BA Byte series and we're going to be talking about the
analysis squeeze. That's right.
This is when you're starting to do requirements.
There's pressure from the technical team or the delivery
team, pressure from your stakeholders to move into
creating something, doing something, seeing some tangible
results. And it's called the, I guess
it's the analysis squeeze. We just don't have much time as
BA's to do our job sometimes. And this is a common problem and
I've experienced this recently and I just want to outline what
the problem is and just some recommendations for you if you
find yourself in this situation. So you can be quite frustrated
that stakeholders just don't appreciate the time needed to do
thorough analysis right before requirements are written.
So people just expect, and I guess this is a bit of a, I
guess the transition from thinking that BA is just right
requirements or just documentation writers.
But actually, you know, we are business analysts and, and we
need to do analysis. Our job is to make sure things
are logical. It does matter how we write
requirements. It's not as simple as just
taking minutes at a workshop. And so there are some problems
here. You get a couple of problems and
one of them I guess we'll start with is the stakeholder
pressures. So there's a focused on speed.
Stakeholders often prioritize speed to market or project
completion, OK? They don't understand that you
need to spend a lot of time or a decent chunk of time upfront so
that you are getting the requirements complete and
accurate so they're not wasting money at the end of the project,
right. So there there's a long term
benefit in terms of project speak to do the analysis.
It happens many a time where development teams get frustrated
that the requirements change. And actually I would, I would
say that requirements do change and you can put a request for
change, request a process through, you can have change
control. You might be working in an agile
environment. But most of the time that I see
it, when we see developers saying, oh, requirements have
changed, I go back and I look and I examine whether or not the
BA has had enough time to do the work properly or whether or not
they've even asked their stakeholders, their product
owners for their requirements. And you'll be surprised that a
lot of times that isn't done. That isn't the case.
So when I say requirements haven't changed, well,
requirements weren't captured in the 1st place.
Now stakeholders don't see the value in the unseen work.
OK, like analysis, they focus on tangible deliverables like
written requirements or so there's very limited visibility
what we do as BAS. So for me, I use a couple of
techniques to make sure that the requirements are right.
You know, I go down, I go up I'm you know, I look different ways,
I do some logic checking, I try and play Chesser.
But this is analysis, right? You might want to feed data in,
you might want to check things with developers, you might want
to check with architects. This is all part of the analysis
process and stakeholders just don't understand it or
appreciate it. OK.
And they, I mean, they don't really understand sometimes what
BAS do, but this is a, this isn't a really important part of
it. They've also got this kind of
unreal expectation that coming from a non-technical background,
if you like, but they don't really grasp the complexity of
gathering and analyzing requirements.
And, and, and, and we, we stop really using the word gather
requirements because that suggests a bucket.
But actually it's elicitation. Elicitation.
Getting the technique of running a great workshop is one thing,
right? Running a great workshop, people
go, wow, that's the value of BAS.
Wow, BAS really good. You, you ran an awesome
workshop. I can't believe you managed
stakeholders and got some outcomes, right?
That's one part of it. And then they go, wow, I really
appreciate business analysis and your skills, but there's only
half of it. That's the business side of
working with the business, but you've also got to do the
analysis. There's also requirements phase
is also under pressure. When a project kicks off,
especially if the BA has been brought on late and the
development team's already, you know, in motion and you've
already got an architect there. This can be pressure from those
stakeholders to say, oh, well, we don't have much time to
deliver, so we need the requirements done now.
So there's tight deadlines. Projects have aggressive
timelines, putting pressure on the requirements phase to be
done quickly. But like I said, if you're not,
if you don't work out what you're going to build and you
you haven't worked out why you're doing it, then you can
just waste more time building. So it's really important to have
a, a decent chunk of BA time. When I say decent chunk, I would
suggest as a rule of thumb, 20% of the project should be on
analysis and design. So if if you're if you're
finding that you're only spending like 5% or 1% of the
total project time on analysis, then that suggests that
something's up. The other thing is that we work
can work in a incomplete information kind of hole.
Sometimes stakeholders don't necessarily have all the
information readily available and so you have to go back and
forth with them. So it's a process of check in,
sign off, and all of that is conflated in terms of your
estimation for the requirements phase, when actually the
duration might be pushed out because you've got to check with
people when you're going to get sign off and you get some people
to read documents. Whereas you're having so many
meetings and it's eating up your time.
And then a month passes and you've literally only spent a
couple of days doing analysis. This can be really frustrating.
There's also the post elicitation expectations, right?
So there's a misunderstanding of elicitation.
Like I said before, stakeholders see elicitation sessions,
workshops, interviews as a point where final requirements are
delivered, not at the starting point of analysis.
This is just when we're starting to elicitate reusing that word
to pull out the requirements, but it requires some time to go.
OK, did this stakeholder have, what was the overlap?
Which ones are common? This, this is where the really
important side of business analysis is.
So our job is to explain the importance of analysis for
building a solid foundation and avoiding rework later.
I think what you should do if you're stuck in the situation,
you need to explain to stakeholders that these projects
haven't gone well because you haven't really had enough input
into them. And when there's a disconnect
between the development team and maybe the business side,
historically you could say, well, that's because you haven't
done the analysis properly, development team started just
developing. This all gives you an indication
that the communication isn't quite right there.
Also, when you are outlining the requirements gathering process,
you need to highlight the analysis phase as a distinct set
of time period after elicitation.
So I think you should do elicitation, analysis and design
or whatever terms you use for their workshops.
Analysis design in the project plan or in your sprints.
You need to manage communication regularly with stakeholders,
keeping them informed of the progress and potential
roadblocks are due to incomplete information and you.
And just just be careful here that when I say this, if you are
under pressure to deliver something, you may be able to
lock down half your requirements, maybe the priority
ones early and still have time to work on the others.
And just explain that you might not deliver them as one set of
requirements and that's OK. The other thing that you could
do is get stakeholders involved in the analysis process when you
check in. So you could book in a whole lot
of workshops after the elicitation workshops to check
in and the project manager will see them as something that's
visible and tangible. So I'm going to give you just
one scenario before we finish here.
So you're a business analyst, let's say you're just working on
the implementation of a new check in kiosk at a hospital,
for example. And the challenge is that
stakeholders are eager to see the final requirements document
and kick off straight after the workshop to get their
requirements. And they really would just want
to get the chaos in as fast as possible.
So what I would do is before you even kick off the workshop is
maybe distribute a pre workshop document explaining the
requirements process that this is the workshop now.
But then afterwards you're going to have a series of refinement
sessions. You got to do some analysis and
then design is going to happen. Maybe mock ups are going to
happen after that. So they are aware straight up
going in what how this workshop contributes and they're not
expecting the requirements straight straight afterwards.
OK, clearly state that the workshop is followed by an
analysis phase to refine requirements.
Maybe even go to detail of how that's going to work.
You can, when you're having the workshop, you need to emphasize
what the workshop is about and that the analysis, the analysis
phase is now going, OK, well, how from a logical point of
view, maybe not a solution point of view, how that you're going
to get from the needs identification to some actual
tangible requirements. That's easier said than done.
You could also do a next steps session.
And one of the things that I do always, and I'll leave you with
this is do a PowerPoint presentation before the
requirements phase. So come back and say we, we
achieved this in the workshop. The next steps are following.
This is what you told us. And maybe give them a high level
idea and then show that you need to do some analysis on these
areas, these requirement areas, these epics, if you like, or
even user stories to really get to a point where they can be
handed over to the development team.
And again, you can show the development team that this is
the high level pack and that you'll be drip feeding, if it's
a kind of an agile approach, those requirements along the
way. And you can even ask them which
ones they need to, they need you to get clarity on before they
start the development phase. OK, so you know there is
pressure with the analysis phase.
And I hope you've learned something today about how you
can manage that. And you're not alone.
This happens to BAS every day out there.
Have a good week.