The Better Business Analysis Institute presence, the Better
Business Analysis Podcast with Benjamin Walsh.
Hi everybody and welcome back to the Better Business Analysis
Podcast with Benjamin Walsh. Now today on the podcast we are
going to be talking about frustrations and I just really
want to be straight up on this podcast and let you know that as
a BA part of your role can be quite frustrating.
There are challenges and there are strategies and tips for
working around these frustrations or these roadblocks
that you will experience as a BA.
And so I wanted to talk about navigating the trenches, the 10
frustrations. OK.
So we're going to go through the 10 frustrations that I've kind
of thought of. I'm sure there are others that
you may have experienced. I'd love to hear from you.
We're going to go through these 10 frustrations.
I'll give you an example, and then I'll talk about some tips
or strategies that you can use to kind of navigate your way
through these frustrations or the trenches of frustration.
OK, cool. So let's dive deep into the top
10 frustrations that ABA can experience.
And #1, it's one of my favorite. It's one that you've experienced
even if you're not ABA, but you've worked in the IT project
space and it's scope creep, OK? It's the ever expanding project.
So the problem that you're experiencing is that when you've
got scope creep is when the business and and this may be
this is not talking about you as a business analyst, but you as
the project or the team that's working on this.
Sometimes it's a, it's a formal project, sometimes it's
informal. And the problem you're
experiencing is basically in our language, the business
requirements are fluid and they're changing mid project.
OK. Now if you're an Agilist, you
might go, well that's what Agile's about, not your high
level objectives, not the high level job to be done.
That shouldn't be changing midway through.
If you are totally changing your business model or the the higher
epics and the user stories and the objectives of your project
midway through, then you know you've got big problems.
That is not what agile is about. Agile is about the user stories
and about elaborating them as you go through and any details
and and changing the sequence and working on the ones that
have the highest value. It is not around throwing away
the baby with the bathwater and the fact you've decided to build
a baby, for example. Then you know you need all those
components. You need the arms and legs and
the head and the torso. OK.
So if you're doing that, then you're actually pivoting or
you're changing completely what you're doing.
And that means the project that you have formed, if it's
informal, if it's formal or informal, either way, the cost
and the benefit analysis needs to be redone.
OK. So scope creep is really
problematic because it's not something necessarily that's
huge, it's something that can happen overnight.
It's slowly where, you know, you get a whole bunch of user
stories added to the backlog, and then you're working on
what's important and the sprints and an agile team, for example.
But suddenly the backlog's getting bigger and you're like,
whoa, and you're getting pressure from the product owner
or the business that's now saying no.
You have to work on these items and the sequences are the most
important, but no one is really looking after the fact that all
those pieces of the puzzle or the baby I talked about before
need to be in place. So that's a problem an an
example would be you're defining a new e-commerce platform,
right? And then weeks later marking
directed demands additional features that weren't discussed
upfront. So you agreed that you're doing
an MVP for a new e-commerce platform.
Maybe you're just implementing one like I don't know, Shopify
or WooCommerce for example. And you know you've got those
processes down properly about what the process is going to be,
which is adding to CART, standard e-commerce platform
kind of processes. You've got those epics and then
suddenly he talks about integration with another system
and that that's critical and that has to be done, whereas
your team hasn't. You can add that to the backlog
and it gets pushed out. But he's saying that that is
critical in order for this whole user journey or this job to be
done to be, you know, to be met. But you haven't talked about
that. You haven't planned that in and
the amount of work to break that down would require more sprints
than what you actually have time to do.
So you can go, well we can do that, but we can't do the base
functions. He's like I need both, OK, I
need these two components and you could say they're two
different projects. So that happens all the time.
The impact is that you as ABA, if you're on that, you you can't
meet expectations. It's really hard to say.
Well the money that the whole process, the whole high level
requirements, you gave us the epics, we've broken those down
into stories. You know you've been involved in
that and that's where your chunk of change is going.
Now for us to now pivot and to then basically park what we've
done in Sprint one and two to then introduce this new
component for the rest of the sprints of which maybe you've
got 12 in terms of fun, in terms in terms of time and in terms of
the people, resources and in terms of money.
You could, you know maybe if you're looking at at that then
we're going to spend all our time doing this integration.
You're not going to get the base features that you've you asked
for which apparent were your must haves to start off with.
So that can be a real hard place to be and that really means that
your project will continue on. So budget and timelines get
pushed out. And even if you're working say
like I said in an agile environment where you're adding
to a product, generally those but the budget and the time line
in some sense the word has to be managed through product
management or through the organization.
No one has unlimited money to work on one product.
OK, That just isn't the way the word works.
Unless you're extremely focused, you're extremely focused,
extremely well funded organization that's all about
adding features to a product that people might not want.
So that can happen. I mean the the real, the tips I
can give you to kind of sort this out and this is a major
problem everyone experiences as part of their career is to set
expectations up front. You need to have kickoff
meetings with all stakers. You need to define the scope of
the project and potential limitations and we define that
scope which is which is pre getting into the agile delivery
framework. Use epics as a good way of
chunking up the highest level processes and defining the
project scope. Also acceptance criteria you
know as part of those epics. So there isn't any ambiguity in
terms of the fact that this e-commerce platform was supposed
to integrate with their ordering system which is a a typical
integration and now suddenly you go well this person saying well
it has to integrate with the order system or otherwise the
whole e-commerce project is a waste of time.
You need to even though you are into you know scope, Creepers is
around growth and agile is about growth.
You need to embrace in a true agile mindset.
You need to be prepared to adapt to changes but clearly impact.
You know, communicate the impact on timelines and resources.
We can do this, but the project will 00.
I don't have that money or yes, I can seek that.
It's not a problem. So don't.
You've got to be really clear that your job isn't to say no.
Your job is to define the impacts to that to a point that
might become not very viable to do it in the 1st place.
The next part is around just the maintenance really of the
documentation. And when I say documentation, I
don't mean 50,000 page specifications.
What I mean is document every requirement, the decisions and
the changes. So the best way to do that
without adding a whole lot of bureaucracy is to use a
requirements traceability matrix all along that that front
scoping side. And then once they've gone into
the delivery cycle then use a tool like Jira or Azure DevOps
or something like that to manage those requirements and record in
the notes section or the description.
There's usually like a little bit of a thread the changes and
decisions that were made throughout the project.
And if you don't, if your tool doesn't allow you to do that
very well, then you know, link out to Word document or that
that can or a website which or internal website that can
document that, like Confluence. That's number one.
Scope creep, #2 is stakeholder management.
It's like herding cats. You generally will find the
bigger the project you're dealing with or the bigger the
the MO, bigger the amount of processes you're dealing with is
that you have to deal with diverse stakeholders, OK?
And they will have, because they might be across divisions or
different teams, or even different one's internal, one's
external. They will have competing
priorities, they will have different communication styles,
they will may have different technical understanding.
And this is interesting. This I usually find sometimes
when you work on projects which involved a complex solution that
digital or the IT team start to have an unfair amount of input
into the project. They should be talking about
solutions. But sometimes they get involved
also in terms of being the loudest voice in terms of the
requirements, and you know that that can be problematic in
itself. So how do you manage that?
How do you tell digital just to hold off for a second and not
get involved too early? How do you actually get the
stakeholders you want to listen to, to communicate So they've
got the the most valuable requirements for example, or
they are the people you need to speak to to ascertain what how
this logic might work. And when I say logic might work,
your job as ABA is to make sure things are logical and that the
pieces, like I said before, that the sum of the parts you know
add up to something. OK, to add up to the ultimate
goal here with stakeholder management, you know you should
know who your stakeholders are. It is worth putting it into a
spreadsheet or into like some kind of documentation so you
know who they are. Not doing things like races, you
know, knowing who, Definitely knowing who your your product
owner is or the business owner if you change.
Understanding who the players are within the project and
understanding who the SME's are. And I think you need to
understand that at a minimum, but it is worth knowing who
your, who your customers are and the true sense of different
divisions and what impact what ownership do they have.
And again you can use processes or process owners to associate
ownership. So you say this process is owned
by this division, that division is run by, you know Karen for
example, the other one's run by Stew.
So they've got, they do have interest, they are a stakeholder
in this project because they're process owners.
You can talk to them and maybe they can get delegates and you
can say hello, we're impacting you.
You're going to be impacted by this change.
We want to, we want to talk to you about your piece in the
puzzle. But in that example where you're
talking to both Karen about her process and Stu about his
process, and they might be two pieces of the puzzle.
As I said before, you know, Karen might have opinions about
Stew's process and vice versa. But at the end of the day,
you're trying to get that person who owns and the people from
those team that own that process to talk about their piece of the
puzzle. And that's who you should be
listening to the most. An example here would be you're
juggling the demands of say like a tech savvy CEO who wants
cutting edge edge features, right?
And then on the other side, you're actually stuck in
between, say the compliance officer or the compliance team
who's really focused on security.
So that can happen quite a lot. There's things like you've got
certification, there's something that's like or the privacy team,
it's quite hot at the moment, privacy officers and security
acts. I actually went to a Microsoft
presentation today talking about this topic, and there's the
example where you know from a security point of view, you
could be really careful about feeding personal information
into AI tools. For example, right?
If you ask an AI tool and you connect it Copilot.
Microsoft Copilot as an example, it integrates with Office.
If you ask IT information, it will give you all the
information you want from your, you know, from all the
information on the network potentially, if you've tuned it
that way and allowed those features.
Now that's hugely powerful and the benefits might outweigh the
risk. But what you don't want to do is
be using the public version of that copilot to share public
information, for example, which happens at ChatGPT by default.
Now the IT manager or the CIO might go well.
I want my people using AI now because, you know, I've seen
that our procurement documents aren't as written as
consistently as they could be. We want to use AI tools.
It's pretty easy. I've done it at home.
Let's do it. That's great.
But then you might have to weigh up the fact that you want a
private kind of check GBT, which stops your information from
going outside the network. And so you need to manage the
risk profile of that and talk about that between those two
stakeholders. Another kind of way of dealing
with or what an impact of dealing with different
stakeholders can do is it can be quite difficult, like I said
before, gathering accurate requirements, right?
Who, Who? Which requirements are the most
important? OK, how do you address concerns
effectively? Is everyone aligned with the
goals? And so by using some of the
techniques that we cover at the bit of Business Analysis
Institute about, you know, process driven, the full PS
using epics, allocating owners to those epics which may be
across business units. That helps with making sure you
know which requirements more a priority than others.
And ultimately you can, you know, there's talk around just
asking the the product owner, they're ultimately making the
decision, but they need to make an informed decision and your
job as ABA is to give them techniques for doing that.
Some tips and strategies for dealing with hooting cats or
stakeholder management is play close attention to stakeholder
concerns. I think their concerns and their
pain points and their problems are way more important then
their solutions. So you need to get them to sort
about their problems and their pain points not their solutions
and tailor your communication accordingly to their level.
Make sure that when you're doing the list of stakeholders you're
doing some kind of mapping, stakeholder mapping we call it
where you know who the key decisions makers are, who their
influencers are and what impact they might have on the project.
I've I've been involved in projects before where we've
actually done a bit of a internal scale, like a really
quite a secret scale of like who might be a detractor from this,
who's got some political interest in not seeing this
project succeed. Like there are literally those
conversations you might have. Be very careful about how you do
that. That could be career limiting.
But you can have offline conversations across coffee and
you do need to think about how you manage those stakeholders.
That's where great change and PR people can help.
When you facilitating workshops can help here too.
You need to manage those, well, workshops and not just getting
everyone into the room. Group discussions can foster
communication and open communication.
And so I think by grouping by using like voting group
mentality on voting, getting people to work at individual
level and then putting cards together and then getting them
to vote and then group ideas together can be a really good
way of using kind of democracy to manage difficult
stakeholders. So that's you know, I can do a
whole podcast topic on that, but I think it's there are some
great techniques for managing stakeholders, especially through
the democratic process. So for example, if you've got
two people who are like NASA as they're going to take you on a
journey, maybe take another three people to the meeting and
get them to have just as much time or equal time to talk about
The positives about maybe what you're trying to achieve #3 are
unclear requirements working in the fog.
Now you're not going to completely deal with this
problem. This is just a general ongoing
problem that ABA has. So I would say it's a
frustration, but it's equally just part of the job.
Now the problem example I'll give you here is when you
receive incomplete or really ambiguous requirements from
stakeholders. OK, so an example might be ABA
has tasked with building a new data analytics dashboard.
This is pretty common at the moment.
You know, build me a Power BI dashboard or a tabular
dashboard, your stakeholder doesn't give you the data
points. So for example, it's there's a
hot topic in New Zealand at the moment for politicians, which is
route attendance, school attendance.
And I happen to be helping one of the government departments
with that problem. Now they want daily attendance
to be reported. Now let's say if the minister in
charge of that particular request said, look, I just want
to see graphs on daily attendance, but they didn't say
what they meant by that. They didn't say, you know, they
wanted to see it by school or region, but they didn't want to
show individual data or they didn't want to show ethnicity on
the on the graph. Sometimes what they don't want
to show is just as important as what they do want to show.
And so by actually not having a true specification or even a
mock up of that, it's really difficult to know what to
include in the report. And of course when someone tells
you this is this is the old kind of red T-shirt example where
someone goes into a shop and goes, oh, I really like to have
a red top. And then the, you know, there's
maybe a shop full of 300 different types of red tops and
you just go through them one by one until you find them a top
that they might want or they don't like it.
It's not quite right. All the rest of it, it's the
Goldilocks situation. Too hot, too cold, just right.
It is not an efficient way of doing business analysis.
So if you you can't just go. If you don't give us really
clear, unambiguous requirements about what you want, then of
course we can come up with 50,000 solutions and they may
not ever meet your expectations about what you want.
So that's an example. And and the the the impact of
having these incomplete or unclear requirements is there's
extra effort required to clarify those.
Through extensive back and forth.
Like I said, you know, there's this T-shirt, this T-shirt, this
and T-shirt potentially leading to rework and delays.
And you sometimes that becomes worse when we start talking
about solutions instead of going, well, what are you trying
to achieve? And the answer is, well, you
know, I really want a a red T-shirt.
It's like, why do you want a red T-shirt?
Well, I'm actually going to a fancy dress party and I need the
red T-shirt to go with the white pants.
So I look like a certain character and it's like, oh OK,
I I get ya. So I've got more clarity on you.
So I'm going to go over to the kind of fancy dress, red T-shirt
area or whatever the case may be.
So that is the importance. You can't deal with unclear
requirements. So if they are unclear, they
should never ever ever ever get down to the delivery level.
That's just a waste of their time.
Don't be. Don't cop out by just making it
someone else's problem and then getting the development team,
which is the well oiled machine to waste any resources making
and manufacturing something that isn't clear.
Now the tips for dealing with unclear requirements are around
using user stories. Of course, using use case
diagrams, interviewing techniques, and elicitating
clear requirements. This is easier said than done,
but you can do better elicitation of requirements by
probing questions, asking specific details from
stakeholders. What do you mean by that?
Focusing on problems like I said, not solutions, and using
feeble of visual use process diagrams.
Use mural boards. Use lo fi prototypes to
represent the solution or context and then provide
feedback on it so I can work on it.
Gives them to draw a picture of the solution.
That's a really good technique. OK, so there are ways of
unpacking and making requirements clearer now.
Sometimes just don't get confused between unclear
requirements and big requirements.
OK, so something is big and needs to be broken down into its
components. So epic to user story, and even
user stories can break into, can evolve into other user stories.
And we didn't call them child user stories, but they do
effectively evolve into a series of user stories from 1:00.
So and don't be don't make sure you know the difference between
unclear requirements and just a requirement that needs to be
broken down. And sometimes breaking down
those requirements into smaller pieces makes it easier for you
to then define them. OK #4 Lack of recognition, the
invisible hand. So B as sometimes feel that
their Critical role role in a project goes unnoticed or
unappreciated. And I, if you're not a BAI,
really need to make this clear. I think I've kind of touched on
it before. No one becomes ABA to get a
medal. At the end of the day, OK, we
are not in the our job is difficult and you usually get
paid well for that. But what you don't get is
generally other recognition. So if you one, if you're one of
those people that really thrives on being singled out and getting
a medal at the end of the day and I'm I'm I'm actually trying
to There are lots of people that are successful because they get
rewarded in a way which you know either it's promoted self
promotion or in front of a group and people go man Daniel did a
great job today. That kind of environment and
that kind of reward which is really really important to some
people like and and partially important to others.
I think all of us want some recognition that you know
situation you might get from like a sales team where you know
they make a sale and they ring a bell and they go out for dinner
and celebrate success or maybe something that maybe a project
manager might get. Or maybe it's a situation where
if it's not sales like you're really you're giving directly
back to an end customer by like donating money to them.
Whatever the case may be B as don't generally get that just
want to be really straight up. OK, so you might spend months
meticulously gathering requirements, crafting user
stories, working with customers, and at the end of the day, they
might. The CEO will most likely say,
man, the development team really smashed out this great
e-commerce platform. No mention of you.
OK? And you might say, well, I'm
part of the development team. That's fine.
So that can lead to feelings of demotivation or undervalued.
It can make some people even move on.
Now I think that the way to deal with that is one, except that
that's the type of role you're in, and two, be really your
project manager, your program manager.
Your team as a collective should be proactively sharing product
project updates with stake items.
You should be highlighting the work that you've done on the on
the project outcome. You should track the kind of you
should think about the time you saved, think about the positive
feedback you got, which around the demo of the product, You're
all part of that. So get your joy from some of
those other data points and make sure that one of the things we
need to do as ABA is we do need to promote and advocate for BA.
The reason I do this podcast and the reason I'm involved in the
institute and the reason I've, you know, been team leader, so
lots of BA teams that I continue to coach people.
It's not for the money, trust me, OK, it's not.
Obviously I've got money as ABA manager, but all my other stuff
generally covers this cost. The reason I do it is because I
really believe that business analysis as a profession makes a
difference when done well, when it's better, OK?
And you, we need to advocate for BAS as a profession.
So Fbas aren't getting recognition.
And if the development team's getting all the recognition or
the architect's getting recognition, then you also need
to kind of make it really clear, maybe not for yourself, but
maybe do it for a colleague and go, well, actually look,
Samantha did a fantastic job getting those requirements
through a whole lot of processes, whole lot of
different stakeholders. It's really difficult work to
wrangle those cats, you know to manage those stakeholders to
keep the scope on track in order to you know get this project off
the ground that there have been 5 attempts of doing this project
previously and man, Samantha really smashed it out.
The way that she was able to take all of that information and
synthesize it into a summary which we finally got to get
bring over to our development team who also did a fantastic
job was amazing and and we should recognize her for that.
You know and and you know even buying a cup of coffee or a pat
on the back you know can sometimes be enough.
So make sure you as ABA also promoting BA as a profession and
but also like I said at the start of this kind of point, it
isn't a full of recognition. You're not a sports
unfortunately you are a sports player on the team, but it's
you're not going to get the same recognition as like your
favorite sports team. Winning you know a World Cup #5
is something I've experienced a lot actually in New Zealand more
than anywhere else. And this comes down to the last
point around the fact that sometimes B As just aren't
acknowledged and and part of that reason is the fact is there
are some really bad B as out there who just aren't doing a
great job or aren't keeping up with their learning.
Same as PM, same as any IT professional and you know and so
some of those people and and the circles that I work with you
know can do just as much harm that that then they can do good.
So ideally you're working on the good side of actually making a
difference here. And So what that can lead to,
and this can also happen because people really want output, is
you can end up with a situation where if you're working with an
solution architect that they can kind of disregard the
requirements process and dictate technical solutions without your
involvement. I've seen this happen many a
time, even with great architects I I respect and I love and it
happens a lot. All they said is a means to an
end. So it's minimized, the time to
do the requirements capture is minimized and there's a lot of
more time doing the solution side.
And actually it's built on a false premise because we haven't
actually worked out what our customers want.
So you know, there should be at least equal time there to do
things. An example would be an architect
starts building a new system based on assumptions and then
you have to do retrospective requirements.
And what actually happens is once you do that, you find
there's a big gap between the business need, the actual
problems you're trying to solve and what they've already put
into place where they've got a predefined idea.
It happens all the time. Architects on average are paid
more and they sometimes have better seats at the table.
And This is why I have a cave for enterprise.
Basi talk about Basi don't talk about business architects as
much. It's because BA is a profession
and it needs to step up or it's not going to.
It's going to be at the kiddie table and it's not going to be
at the adult table with the architects and with the CTO.
We need to do a better job as BAS to make sure this doesn't
happen and call it out when it does.
When you're bypassed by design, OK, and this can the impact.
It means rework, it means delays, it means that a solution
is in, but it doesn't meet user expectations and everyone might
clap and and celebrate that. And then of course, three or two
years down the track, no one's using the solution.
The key to dealing with this is around collaboration.
Foster, open, communicate communication with architects
from the outset. Share your requirements as you
go. They may want to start working
in parallel and that is fine. It's not a waterfall situation.
Be involved in discussions. Listen to their ideas.
They do no solutions. They are involved in the non
functionals. They they're experts in the non
functionals. I would say architects in some
ways are non functional requirements so you know you'll
have a good idea about what they are.
It's a circular conversation. If they know that some of these
requirements and say you've defined them to a level in which
they can be understood are going to be really impossible, then
maybe get them to do an early response to those requirements
so you can talk to your product owner.
Just online items which might be really expensive, so they can
help provide more clarity to the requirement which is your job.
And you can communicate that to the product owner and you can
have a conversation about the fact that this requirement might
be too big or too expensive and we may need to break those down.
You need to escalate to your project managers and senior
stakeholders if your concerns are not addressed.
OK, you need to raise this. It's really hard to do, but
ultimately you need your PM should be managing you the two
sides of the coin and it's a bit like a a fighting mum and dad.
Architects and BAS do have conflict most of the time.
That conflict should be healthy. It should be healthy between you
managing both requirements, advocates for the requirement
true and proper, and that advocates for what's possible
and what the solution is and ultimately how much it's going
to cost. Because ultimately most of the
cost comes from the solution itself.
Now those you should have battles.
Here I I had a conversation actually yesterday with an
architect. I was a little bit nervous
beforehand and we were talking about a couple of options.
Now I sometimes you dip into solution mode right as ABA and I
hate stepping on having my toes stepped on by an architect and
I'm sure the same happens the other way, but I had looked
through at a couple of solutions which was keep using a paid
solution. So basically a do nothing
solution. The example of ours using quite
a simple solution, which wasn't the best practice architecture,
but it wasn't particularly bad architecture.
It just was a more simplified way of sealing solving a problem
we had. And the third option was
probably the most, you know, the best architected solution which
will be scalable and would you know, be strategic and all those
good things that we should be thinking about and advocating
for. And I was worried that the
architect would disregard the second option which is more
tactical and look at the just the more complex answer.
And that generally sometimes happens when you know you get
people that are you get this with BAS as well as architects.
Whereas an architect sometimes you see it on Grand Designs or
one of these building shows where the architect you know it
has to be at a 35° angle so that you know and the window has to
be perfectly here or otherwise you won't optimize the sunlight.
But then when the building gets in, you know, they, they, they
make changes. And so in the same situation,
BAS can be the same. They can say the requirement
says us and there aren't going to be no changes and we're not
going to negotiate. You know what I mean?
We're not going to negotiate with you architect terrorists
for example. But no, it's the opposite.
We should be negotiating and we should be talking on solutions
here. We should be walking back and
forth and collaborating. And in that example I talked
about that, you know my experience working with lots of
architects got me to that position.
But this particular architect was like, well it totally makes
sense why we should go with the second solution which is less
complicated because actually we end up in a similar place
ultimately And we had a value conversation which was a really
nice conversation to have. You do need to with with the
architect to take over is make sure that you are have working
and communicating at the same level.
And for me, architects are very good at looking at them bigger
picture. So you as ABA need to look at
the bigger picture too. You need to think about how your
requirements and how it benefits the kind of whole, OK architects
are really good looking the whole house, and you might be
looking at 1:00 room. So you need to be talking about
and advocating with architects and talking about it at the
level they're discussing, which might be the whole solution or
the whole house. They're just some tips.
It's not an easy one to deal with and I'm going to move on to
#6. Frustration #6 is around limited
customer interaction, so you've got a disconnect from end users.
This can happen quite a lot. So this is where B AS are
restricted from directly into like interacting really with
customers. Now sometimes it's internal and
you can't talk to the end user. That seems ridiculous.
I think if if you're in a company where you're BA where
you can't talk to end users in the company, you're not allowed
to talk to them. You'd need to ask why.
Now there might be a product owner and it might be around
roles and responsibilities. And if that's the case, I still
think ABA, if you're doing true proper BA, you should be talking
to these end customers. Sometimes though, if you are
talking about actual customers of your business, there can be
some difficulties there with talking to customers because of
maybe cost, maybe just getting them involved, maybe timing.
None of them are really good reasons for this.
I think you should be talking to the actual person who gets value
out of this, like the end customer.
But what you might find is you have customer advocacy teams who
have got stats on it, so you might have to use it as a
conduit. What the problem is when you
can't talk to your end customer, not talk about the end customer,
not end user. If you can't talk to end user, I
think you should really consider if you're in the right
organization because you can't really do BA properly.
But I do see cases, and I've been in situations where I
haven't been able to spend a large amount of time with the
actual, you know, end recipient of maybe a public service.
OK, they just haven't got the money, time and resources to
talk to those people. That sucks.
But they might have marketing companies or customer
interaction companies and they've they've interviewed them
and we will have to work on those kind of as a different way
of elicitating requirements from them.
So I mean obviously there's a difficulty there.
The impact means that there's difficulty in gathering genuine
customer insights and specific needs around specific questions.
It means you could miss the mark and fail to address like really
core pain points in the job to be done or the user journey.
What I would suggest is you know can you can you conduct surveys
or user interviews? Are you able to use kind of
usability testing maybe to if you had an existing product?
Are you able to give the research company that's talking
to these customers a set of questions or at least review
them? Ask if you can partner with user
experience professionals. So like UX designers and
researchers who specialize in user behavior and experience.
So even if you're not been able to attack and attack in a good
way the you know full range of your personas that are in scope
then or representations of real people that represent those
personas, then maybe you can get some advice from UX designers
who have dealt with different segments that are similar.
Make sure that you can like maybe look at support tickets,
chat history, social media feedback, looking for areas of
improvement, especially if you're working on a product.
So it's not an easy one. I like I said if you're not
talking to end users that that is a political problem and
that's something that I I would have struggled to work with.
But you may need to use cus customer research if you can't
directly talk to your customers all the time.
And of course talking to friends and families is is always
biased. So you really need to talk to
end customers if you've got to do this properly.
And then you know no, there's a margin of error by looking at
this information or it's not going to be specific enough, #7
is just requirements not taken seriously, OK?
So this can happen where you've worked really hard to gather
requirements, work across stakeholders, and then they're
downplayed or disregarded by stakeholders.
OK, So that can give you a sense of discouragement, you don't
feel valued, decrease, you know, in motivation or just feeling
like there's some games being played.
So sometimes you need the requirements won't just come
from your stakeholders, they might come from the data and
metrics. So you need to be really clear
about where the requirements came from and maybe advocate for
them. So like I said, BAS work in
logic and stakeholder might not realize that there needs to be a
requirement in order for this whole flow to work and so
provide data for it. Actively involve those
stakeholders in the process and maybe talk about those.
Ultimately, you're not generally generating requirements, but
your job is to make sure that the end to end process or or
problem is solved. And sometimes requirements just
naturally pop out and all you're doing is facilitating that and
doc and talking about that to the product owner for example,
because it needs to happen. So you need to make them aware
of it and you need to highlight the bigger picture.
So requirements like not being taken seriously or disregarded
down. The fact does happen, and it's a
bit like the architect example I gave above or the development
team, just, you know, not reading the requirements and
going ahead on doing doing your own thing.
You need to call that early. And in a situation you know
effectively, if your requirements are not taken
seriously or as a collective as a whole and you've just been
asked to do this work, you need to say this was a waste of my
time and my energy. If you're just going to
disregard them, why am I? Why am I working on this and
escalate it to management? #8 is just limited visibility.
OK, so a lot of the work that BAS do often remains unseen by
upper management or key decision makers.
OK, there's organizations I've worked at as ABA working on
really critical stuff. Never talk to the CIO, never met
the CEO. Now that's usually a problem of
company culture. So it's not just you who's
experiencing that problem, but if you're working on something
that's really important, then you can feel that your work
isn't being recognized. But also if you're working on
something you might think from a career point of view, you know
senior leaders don't don't know what you're doing and and maybe
it's being credit's being taken in other areas or it's it could
hinder your career advancement. If upper management or key
decision makers, you can never speak to them or or present to
them, especially if they're ultimately the ones that are
getting value in what you do. So again, you know, it's around
proactive communication, it's about showcasing your work and
it's about building our relationships.
So don't make sure that you have limited, if you have limited
visibility, you need a way to put your story out, start
blogging may maybe internally talk about the fact that BA's
work should be advocated for. And also you know, like I said,
it's around making sure that the value the collective project
team is acknowledged somehow and include names in that.
So you know if you're up for contract renewal or you're
you've worked on a particularly successful project, you know,
list out the team members names maybe on the Internet or ask the
project manager to put that through.
These people worked on the project that worked really well,
not just that the project was a success, but this collective
team could work well together. That's happened quite a few
times I guess by default on projects I've worked on.
We've worked in really successful teams that have
delivered some stuff and upper management, if they've seen that
through our great communication from product managers or change
managers, not even from myself, your name gets recognized again
and again and then they go, well that guy, he's pretty good.
So when it comes up to contract renewal for example, they might
say well we really want to go and above and beyond what we
usually would to keep these people around.
OK, I've got two more for you. So hopefully not falling asleep
here, but there are two more that I'm just going to throw in
here. One is work life balance.
OK, so this is the kind of juggle that BAS need to worry
about. The demanding nature of BA work
can lead to long hours and difficulty maintaining a work
life balance in BAS experience, burnout, stress, decreased job
satisfaction, and all of those factors that you can experience
can have a real impact on your work too, because you need to be
empathetic. And the first thing that goes
when you're stressed or you're burnt out, you know if you don't
want to is the empathy level goes down.
So your average empathy goes down and your tolerance for for
dealing with some of these difficult stakeholders or
politicians in the organization you know gets less and less.
And sometimes, you know, you can be in a position where you're
just not doing your best or you're just not handling it.
Well-being there, you know, being there, done that, the old
saying goes, you need to be. Really, the tip here is to be
really clear about your time, what you're going to spend your
time on prioritizing tasks, delegating where possible,
sitting boundaries. You know if you work from 9:00
till five, then block your calendar out after 5:00.
If you need to work longer hours, sometimes ask for time
and loads a time to take off later, you have to.
If you're working on project work, there are going to be
times where you may need to work late or weekends or you know and
you know not for for a couple of weeks.
Now I think it's OK if it's a couple of weeks and it's not all
the all the time, but if it starts becoming all the time,
you need to call that out because it's unsafe and no one
wants that. You shouldn't be.
I know a lot of my podcast listeners work in the States,
and I think there's a culture in the States of just being at work
as well. I've noticed when I've worked on
that's not me making a generalization.
I've experienced it myself when I had worked at Sony Ericsson
and I had different teams from across the world doing the same
job, just in different time zones.
And what I found in the States was that the team would work
longer hours. It wasn't the fact that they
were mucking around or anything. It's just there was more of a
culture of being at work longer in the States, which is a, which
is just in this particular organization, it was like being
on the floor mattered. So you've got to appreciate that
no one wants you to burn out, OK?
No one wants you to be in a bad place.
So be really clear on your workloads with your project
managers and your team leads. Seek adjustments.
Do some self-care, like relax, go for a walk.
Best thing to do ever. If you're in the middle of a
hard project, get away from the computer.
If you're at the computer and go for a walk, go for a walk
outside. Don't think about work.
Don't get off the laptop. Don't doom scroll, Don't read
the news. Don't read what Trump's up to
this week or what's happening in the, you know, in the Ukraine.
Get away from that because it's just going to add to your stress
area, things you can't control. And go and take a walk, OK, grab
a coffee, go for a walk. You know, integrate maybe a gym
routine into your BA career. One thing I always do is I work
workshops. If I do a workshop, I want to do
them really well. I'm exhausted after a workshop,
so I might do the workshop, which means, you know, no lunch
break, getting to work a little bit earlier, working the night
before, and then I'll just go home in the afternoon.
I'm like, it's a waste of time, me being there for the
afternoon. I'll write the notes up later,
or use some AI tools to help me with that.
Or a junior BA. OK.
And last one, frustration #10, is that some BA, especially if
they're internal BA, can feel a lack of career growth and they
can feel like they're stagnant in their careers.
Now if you feel like your career growth has stagnated, so maybe
you're ABA and there aren't any senior opportunities or a senior
BA and that's it for you. And you might feel like there's
limited opportunities for upskilling or advancement in
your role. And then that can give you a
lack of motivation too. And you can go same mode, same
old, same mode. And again, this is probably the
reason I do the podcast and I'm involved in the institute is
that you can can. There's so much stuff to learn.
We're really lucky in our domain.
We work across industries, we work with tech, we work with
people. I actually think that our job
points you in so many different areas that you can.
There's always something to learn, is what I'm trying to
say. Professional development and
learning. You know, online course, getting
a certification, learning about the new thing.
There is constant learning opportunities there.
OK You can look at specialization in different
areas. If you really want to get become
a specialist in one area. You can just generalize and
learn about the world. You can network with other
BASBAS, love to network with other BAS and talk about stuff
and moan about bits and pieces. So if you feel like there isn't
a, if you've got in a good job, you're getting paid well or the
market's bad, so you're not looking, you know, to move to
another company or change and your management's not for you
and you're just your BA or a senior BA, say, just that's
terrible, that might be it. And that's fine, that's great.
You know, that's if you're getting paid well and you're
comfortable with it and you're enjoying your job and the work's
got a great culture then, but you just feel stagnant as you're
not growing, then you can look externally for that.
OK, You can talk to your manager.
If they've got a great culture, just say I'm going to do some
learning around Power BI. I'm going to work out how AI
might affect the organization. So there's always opportunities
for you from a continuous learning and improvement point
of view. OK, so they were 10 frustrations
that you can experience as ABA now.
I hope you got value about navigating those trenches and
next time you are frustrated, you might try some of these
techniques so you can get out of that frustration and continue to
be the best BA that you can be. I'll see you next time.