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.