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.