#Podcast 6 with Pragati Sinha out now.
Pragati is a seasoned #BusinessAnalyst who has worked on various enterprise systems including #Salesforce and it was really fun to talk to her.
We muse about requirements gathering, working with end users, prioritising user stories, and loads of things in between.
I learned how to categorise user stories using animal classification and why! Guess where the Sloths sit! 🦥
I invite you to listen in on our conversation here. Enjoy!
#OnThePeiroll
Transcript
Pei Mun Lim 00:03
Morning Pragati Hi! Welcome to my podcast. It’s called OnThePeiroll. How are you today?
Pragati 00:10
I’m doing great. How are you doing?
Pei Mun Lim 00:12
Fantastic. I’m really looking forward to this conversation because because you are a business analyst. And it’s something that it’s one of the roles that I used to have. And I’m really, really passionate about it. So I can’t wait to dig into the topics that we’re going to talk about today. So
Pragati 00:32
I know I’m saying here, I’m really excited. And, obviously, because analysis and just the project space is a topic really close to my heart. And I just love chatting about it. So it’s an awesome time. Thank you.
Pei Mun Lim 00:46
Okay, right, looking at your profile, you’ve got very deep business analysis experience. And in one of your roles, you work with Salesforce, can you just walk us through your journey from from the university until present? Oh,
Pragati 01:05
sure. So I actually kind of stumbled into business analysis. So my first role was actually with a company, it was like a contract role, just to help out during tax season. So I actually have a big my education is in biological sciences, Life Sciences. So it’s nowhere near technology or anything that around it. But I was kind of like, you know, I wanted to make a career in technology, but I wasn’t exactly sure where I was headed. So I got this role just kind of help out with the tax season more like an admin role. But within a few weeks of starting disposition, I was offered a role with another department, the finance department, that was actually doing a special project. So that’s sort of like the starting point of me being part of projects. And it was interesting, because somebody in my team told me, you know, what, the special projects are really, really boring, like, you’re going to be bored to death. And I was like, really, like I do, I want this. But anyway, I ended up taking it, I loved it. It wasn’t more like a data analyst role, but still had quite a bit of business analysis, which I didn’t know at the time. But I learned over the years. And then I realized that kind of like the field that I wanted to go into. So I actually went ahead and did like a Master’s certificate in business analysis just to learn all the skills and techniques and what it means to be a business analyst. And from there onwards, I’ve worked for different companies, as a business analyst. In compliance space, I have worked in retail. I’ve also worked in a quick service restaurant industry. So a lot of it has been really core business analysis. And so just like work in different business domains, sometimes as a full time employee, sometimes as a consultant contractor, depending on where my interests were, at the time, and most recently, I was working as a senior analyst for a cybersecurity company. And so there, that was my first kind of introduction to the Salesforce ecosystem. So I was really scared when it started. But when I actually started working, I realized how much potential the system had and how much I loved actually learning about it. So right now, I’m actually focusing on really kind of honing my knowledge in Salesforce. While also, you know, kind of, you know, focusing on my core skill set, which is data for business analyst.
Pei Mun Lim 03:49
Excellent, we’ll get drawn right down into the question that I really, that I’m always wondering about, do you need domain knowledge to be a very good BA?
Pragati 04:04
Domain knowledge definitely helps. Because that helps you understand the terminologies. You know, a lot of times when you get into a new field, people are talking with things that, you know, you kind of need to ground yourself in. But is it all this required? I don’t think so. Many because that’s, that’s one of the good skills that we have as ba is like, we can jump into things and kind of figure out a way out, like if you throw a really wig project or a wig in a requirement as like, we’re good at, you know, working through it and trying to make sense of it. That’s actually one of the things that I’m often asked in like my interviews or, you know, if when I talk to people, I just because I’ve worked in a lot of different domains. And what I like to usually say is, and I really firmly believe this, is that because a job on tablet, I have limited knowledge of this new field that I’m going into, I’m going to be able to ask better questions when I’m doing business analysis. And that is a really, really important skill set for a business analyst to ask questions. We all know that, but if you feel like you know, everything in a domain, or like, you know, feel like yeah, I kind of got this, you’re gonna have a lot of blind spots. You know, eventually, you’ll just be like, Well, you know what, I know this, I don’t need to check on this. I, you make a lot of assumptions. And that’s like the worst territory you can go into as a BA. So I think it helps, yes. Maybe from like, if you’re trying to transition to a new field or become a new business analyst, maybe somebody would really be interested in your business knowledge. But once you are a business analyst or lucky No, I don’t think from the perspective of doing the actual analysis work. You absolutely require it, you can learn it.
Pei Mun Lim 06:00
I think it’s actually a double edged sword, whether or not you have domain knowledge, my thinking is, so I’ve been in projects before where we’ve had VA, who were brand new to the production of Huawei. And now, especially in the small to medium sized consulting partners for Salesforce, Microsoft, there is an expectation that the functional consultant, pick up the business analysis part of the project, right, where I see a BA who doesn’t have any domain knowledge, just like what you’re saying, You are really good questions. They’re very expensive. I wrote, I wrote a post I think, a couple of days ago about whether somebody needs somebody who has a horse, that doesn’t take him from A to B very well, what does he need to solve the problem? Is it a faster horse? Or is it a car or something else? And I had somebody who commented on my post, well, maybe if you’re the one with Uber, you might also quit questions. So that he says, Well, actually, I need an Uber, which is a leading question, though, instead of asking the right question, to find out the pain point, you are asking different questions to lead the users to the direction you want him to take.
Pragati 07:26
That’s interesting. Yeah.
Pei Mun Lim 07:27
So I can see that happening with if you have domain knowledge. As I always say, if your hammer everything for nail to everything needs to be coded when you bring a very important point about the value of asking great questions, and I can see why you’ve got to where you’ve got to. So in your, in your experience, how have you How have you bridged the gap between yourself? So as a business analyst, as you go in? There’s a requirement there between what you see as the current situation, business problem, and translating that into a language or documentation or a way that the development team needs to understand in order to execute the plan, so to speak, how do you bridge that gap?
Pragati 08:33
So sorry, so this is just about how we, the challenges with documenting the requirements, it can be documented communication is what I’m trying to get to. So you’ve got the circuit, you’ve got the user with a particular issue,
Pei Mun Lim 08:49
you’re a business analyst, you may or may not know the product that is being used to work on right, the issue. Okay, this team who’s going to work on it, right? How do you how do you make the translation because that’s what you are? Yeah, translate business requirements into technical ones, you know, right.
Pragati 09:12
Yes. So, when you as BAs, even if, you know, as you go through, if you go through training, or even if you don’t, when you’re working, you develop those skills. One thing that’s really important is for us to be solution agnostic to a very, very large extent. So how that business requirement is going to be coded. It’s something that you have to keep the business stakeholders away from and also to a large extent yourself, because then you kind of you will start thinking about in terms of solutions from like the get go, and that is, that is a no no, like you have to make the point of being the business analyst or being that person in general. do is to really prod and talk to the business to understand what they need, and not what they want, as we always say. So digging into that is your core skill sets and your, I would say the, the bulk of your communication and negotiation skills actually lie with working with business stakeholders to really prod them in the right direction, and get get what you know, they want to get them to tell you what they want. Basically, from there onwards to moving towards the developers, obviously, there’s an awful lot of analysis that goes in trying to understand and make sense of the requirements. And then for that, to a very large extent, what I do is like, if you look at the way I write requirements, or user stories or acceptance criteria, they are really about what’s needed, like. So it’s about this is, this is why the customer needs it. And this is what they need, in terms of the actual solution and design, how you’re going to do it, that I live to the developers are like that, that’s their main skill set, right. So I’ll explain why they needed. And I’ll explain what we need from a business side, and how you’re going to implement that into the system. That is completely up to the technical things. And if there, if it has a UI element, then obviously, or some kind of design considerations that you know, the customer really wants it a certain way, I would recommend it and say this is how the customer’s envisioning it. But the details obviously lie with the execution team or the delivery team. Having said that, obviously, since you work in Agile, there’s a lot of feedback loop. So you can take what the team is developing, show it to the stakeholder and say, Well, this is where we’re going. Is this the right path? Are you happy with it? And then we can, you know, adjust and reiterate based on that. And that’s kind of like the whole point of doing the cycle. And so just being the person to make sure, did I get the right requirements did I get? Are we building the right thing. And if we are, are we doing it in a way that will satisfy the customer, and then we just kind of go into that loop? Pretty much. So I think that’s sort of like the path that I normally take with just, you know, just really focusing on making sure that I’ve got the right business requirements. And just kind of going back to like that horse analogy. And for some reason, I love horse and camel analogies. But it’s really important that, you know, it’s actually something that one of my instructors had said in one of the courses I was taking on business analysis. And he just said that the role of the BA, is to make sure that if the business is asking for a horse, to get a horse, and not a camel, so that’s sort of like your place in the whole system, where you’re just making sure that you know, we are building the right thing at the right time. So that’s kind of like where I see the role of a bat, in terms of communicating those requirements back and forth.
Pei Mun Lim 13:16
Thank you for that was really quite helpful. Can you give an idea of the size and scope of the projects that you are in so so where I’m coming from is currently, because it’s consulting engineers, I will say we need all of this done. By this time, this is the more in scope. And I hope, with the help of my architect will say, right, this looks like a team of 15 for sewing days, maybe half onshore and offshore. So that gives me a an idea of complexity and size. Which then in my head, I can then apply the whether it’s upfront heavy business analysis, local, real complex stuff, these kind of things that we will do more is smaller in size, then the BA portion becomes much, much more limited. And it’s something that a consultant can pick up. Okay. So, can you just give a rough idea of the kind of size or complexity of projects that you run on a daily basis.
Pragati 14:35
So, from my end, like I worked in consulting, as well as you know, like in house business analyst, so the kinds of projects that I do now, obviously, are different from what I did earlier in my career. So earlier, it was more like, you know, limited projects, limited scope for your change in the future. And maybe you have Like one developer working with the one developer and tester, and then you’re just kind of added, you have like, a constant stream of business requirements coming or client requirements coming in, you’re just kind of hitting the system here and there. But as obviously, I’ve progressed, it’s become, my work has become more holistic. So like, I’m looking at areas of changes, I’m looking at, you know, major initiatives that the company is working on, and just kind of taking a more leadership role in terms of the projects that we are doing. So working really closely with like business, like with the business stakeholders, like the executives, and just kind of being the face of the project. So in those we’re talking about, like a full team of, you know, maybe five developers, three testers, things like that, and we’re all focused on this one project for like, you know, three to six months. And depending on obviously, the complexity, a lot of those, my recent projects have affected like, you know, 1000s of users, like those are big, like data migration projects, or we are enabling, or we’re making changes for, to respond to tax laws for like, you know, multiple countries at the same time. So those are sort of like the projects that I’m working on in like, more recent times. Before that, when I was working more like in boutique consulting role, it was because they had our own software that we were selling. So it was obviously making customizations for these customers who were actually, you know, just to kind of align with their business processes. So those vary, depending on you know, how much of a change the customer is requesting. Some of it was really custom work. So I’ve done like, client onboarding, which lasted like two years. And some of them were more like, you know, those were smaller companies, or, you know, they were happy with, like, the software that they got, and they really needed like small customizations. So those last maybe about a month or two months or something.
Pei Mun Lim 17:18
Let me tell you why I’m asking. And I think I went down one road, and your answers actually pulled me back. And let me tell you what I’m thinking. In the Salesforce consulting, ecosystem, that part, the ecosystem. Generally, in the product teams, we it’s not usual to have a pure Ba, there have been companies that work with the larger gsis did have. So the projects are huge, whereby business change is a large component of the whole project. And I can see the value in that you have POV. But also the other thing for Salesforce, as you know, there, it’s not all development. As we want to implement something, you’ve got a you can customize the system so well with point and click. Anybody without development background can pick up learn to do process builders, and workflows and inflows, that sort of thing without all you need is more logical thinking and problem solving skills. And you can do that you don’t need developer so that I’m, I’m just clarifying the definitions of when I say developer, yeah. So in the Salesforce consulting space, you have the developers who do the actual Apex coding, if God the consultant, who generally does the EAP work, and the configuration during the reporting dashboards. And for the larger projects, we have the BA is with the change management team that does a wide a piece of work around transformation, for example. Okay, that’s one example for the BA in the cell phone system. The other one is on the other end, they’re quite small, but they still had a BA, who also function as a scrum master and pm, the front facing. So in the way that you described it, it sounds like what you do anyway. So the stakeholder management conflict management. So the pm skills in and what she did was, that’s what she did, and then she would write the requirements and that gets handed over to the developer. So in that scenario, there weren’t very many pure functional configurators. So in my head, so I’ve been asked, and I’ve had this conversation with various partners before as to the role of a pure BA in a mine. That’s that’s that’s the reason why I’m so invested in is trying to understand that I Have a feeling that it’s not the size that determines it or not, in my thinking from what you’re saying, because I know your background is love bespoke custom system with software as a service in that, and I think in those environments, you actually don’t have the functional configurators.
Pragati 20:22
You for bespoke software, you no. That sort of like, you know, we we don’t normally because it’s not like the Salesforce system where you know, as you mentioned that it’s like, a large part of it is configurable. And you know, there’s a lot that comes out of box. Versus with those systems, if you’re not happy as a customer with what we’re offering you. There’s a lot that goes into the customization. So then, then there is really like a solid need for a BA to really understand what what the customer wants, and why they want it before you can make that change.
Pei Mun Lim 21:00
Thank you that really crystallized the classification in my head, and I understand a lot better. now. Go, sorry.
Pragati 21:10
Yeah, I just wanted to comment on the Salesforce ecosystem of a BA, I think maybe I’ll go back and let you know, when we talk more, I’m might bring up this point again. But I really think it’s important like for a BA to kind of remove ourselves from like the system that is going to be implementing the change. So whether you’re working on smaller customizations, if you’re the configurator, that’s different, obviously, because you’re taking the requirements, and you’re kind of implementing it right away, then you need the knowledge of the system. Definitely very important. Very helpful, no doubt about it. But if you’re working from a pure BA perspective, what’s really key for me, like what I’ve learned over the years, is that really focusing on making sure that we’re building the right thing all the time. So whether you are doing it as just like an like, you know, incoming flow of changes, and even then it’s important, just because you know that the system can do it, should it be done. And, you know, this is like one quick change for you, you know, just pull up this object and you know, make that change, and you’re done with it, who’s using it? How are you using it, who else is impacted, like all of that other analysis that needs to be done. So I think that’s important, like that skill set, like, you shouldn’t forget, that doesn’t matter if you’re working on a digital transformation project, or if you’re working on like, you know, just incoming flow of information, that incoming flow of tickets,
Pei Mun Lim 22:42
I like that point I like, let me just, let’s just stay on that prevention. So again, with my background is we are consultant we go in and we help the customer. So if we look at that as as a whole. So when you’re talking, you’re talking about the understanding of what the customer wants, right, so if we if we’re talking about a partnership between a client in a consulting partner, then that absolutely needs to be done in the most ideal current projects that have been on the Those were the implementation has been absolutely spot on. And really sweet is where the client have their own ba is. Because I think in I always advocate this, that all businesses should actually do their own process improvement all the time, they should always be looking for ways to get better. Yeah, cut out inefficiencies to save money and just to be slick in their operation. So that that should be separate whether or not you’ve got a transmission coming on, or whether you want to put CRM in or Salesforce, whatever that might be. So in my projects, where there is this internal department, and there are many names for it, in some project, well, you have internal VA RPM, that the partnership works so so well, because the VA is can tell us and they know that just so on top of things, we do this because of this reason, yes. And we take that from a consulting point of view to say, okay, that is really when you know, the thing is, you have bought Salesforce and these are our limitations will take you 70% of what you want. And the 30% will be quite expensive to implement that so the composition becomes so much deeper,
Pragati 24:50
right, right now I get I can totally see that. Because I’ve actually worked as that ba that you’re mentioning like that in Yeah, right. So it’s actually, in my particular role, it was all in house pretty much we had our own development team. So we didn’t, we weren’t contracting without, with an outside company. But having said that, that dynamic is still there. Because I mean, even if you work as a BA in any role, it’s like, well, this is what the customer wants, this is why they want it. This is why they’re doing it. But then the system kind of, you know, limits certain things, right? That system could be Salesforce could be another CRM could be even your, you know, bespoke, customized system, where Yes, you can do a lot, but do you want to, it’s going to cost money, right? So having that conversation is really important. So I think that that is the role of the BA, like the way you defined it, it’s like to know, what’s going on to kind of keep on top of that, and then to kind of, you know, negotiate with the team that’s implementing it, that could be a whole team of consultants and, you know, delivery teams, or that could just be an in house development team. But that, you know, shaping. So you have you have shaped your requirements, now you’re shaping the solution. So you kind of have to be on both sides of the equation, and just make sure you’re like, on top of things on both sides.
Pei Mun Lim 26:24
Absolutely. So I see, I see, the role and activity is very key, making sure that the solution is the right one. Exactly. In projects, I’ve seen where that role is not there. And where, again, from a consulting partner point of view, we have a consultant going to pick up that piece of work. I know that the solution hasn’t been the optimum for the client, right, specifically, because we don’t understand the business in the way in a deep way that needs to be understood. So we go in, we have certain number of days to ask questions that we can. And in those days, the key stakeholders need to be on hand switched on, ready and willing and able to provide all the information that we asked for, and maybe those that we don’t ask for as well. So bringing back to your point about being system agnostic. When this situation arises, our consultants will ask great narrowband of question, because they are, we’ve got the sales happen. Yeah, I know, I can do this using this way. So my Christians will have that flavor. Right. And therefore, I’m not saying that the project is delivered, doesn’t solve the business problem. But it could have been a lot lot better. Yeah, in a way. So I can see the such it’s so valuable, I think, for all businesses to have a BA role somewhere within the organization, it sales operations, or service, or customer onboarding. xand ever that might be,
Pragati 28:14
I think, nowadays, like, you know, you’ve hit on a really key point, like, right now, like, what I find is like, you know, bees are really associated with writing user stories, acceptance criteria, just you doing your requirement work, which is important, which is our deliverable. But it’s important to know how we got there, right. And as a BA, when you are focused on, you know, learning the business learning, what kind of makes them run, understanding the business processes, you know, improving certain processes, and, you know, really kind of questioning why we do things a certain way, and could we do it better? That role is really important, that role needs to exist, as you said, making you’re on the client side, because somebody needs to kind of gather that information and be that point of contact for you, even from a consulting perspective. And sometimes, even as a consultant, when you go into a new company, like you know, you have a new project, like it takes more than half the time to you and figure out are you talking to the right people or not? Right? The ba because they are obviously in that role, and they are part of that company, they have a better sense of that person to go to even if they don’t have the answer. They can direct you to the right person. They can tell you well, these are really important, you know, and there might also be a group that you may not think about talking to just because, you know, nobody told you from an executive level, but like from the perspective you’re like, No, no, no, it’s really important that you talk to these people because they are the ones doing this day in and day out. Those are the people we most often miss, like you know, the people with the least amount of power but the most impact big You know, especially as a consultant, you have limited time, so you’re going to make the most effect, right. And so that’s really important for that person to be there. And to kind of direct you almost to say that, you know, this is where you’re heading, don’t go there might be. So you need that person to work with. And it’s their role. It’s their, it’s their expertise. And it’s also like, you know, just be like, at the end of the day, we always say, like, you know, it’s about providing value, like, are you going to be providing value as part of this change? If yes, then you need to be lucky enough to kind of work into the equation.
Pei Mun Lim 30:41
Absolutely, totally agree. Now, thank you for that. So we talked about. So let me just, we talked about the point between getting requirements and user stories. Yeah. In, in a Salesforce consulting point of view, that is all squished into one, during a discovery. And I have found that to be hugely, like I said, if we don’t have a VA on the client side, that is all on our shoulders, we do the best we can with the time that we have. And it’s not always the most optimum method of doing things, though, in your role, when you were asked to do us a story from a requirements, can you walk us through your process? And what happens between the two points?
Pragati 31:36
So I think from like an initial requirement gathering meeting, I don’t even like to call the first requirement gathering because you know, everybody kind of puts their requirements hat on be like I’m giving you requirements. That’s not what it’s about, at the first meeting is always about a conversation is understanding, you know, where we are, what are we doing? It’s very high level. So I tried to stay away from calling my first meeting requirement gathering or requirement workshop or anything in requirement, like, so it’s more about, can we do this? What are we doing? What are you thinking, it’s just kind of push and prod a little bit. Usually, from the second or second meeting, obviously, depending on the scope of the project, as I’m zooming like, it’s a major transformation project, that’d be heading into, you know, something that will take you a couple of months. So the next meeting is where we actually kind of corral and to, you know, go back to certain things that was said in the meeting in the last meeting, and just kind of bring those up, and try to get a sense of, you know, the really high level requirements, to say, Okay, this is what we want, this is something that, you know, we need, and this is sort of like something that we can live without, for now and later. So, kind of like the negotiation start at that point, you’re not exactly prioritizing thing at this point. But as a BA, you kind of know where to, you know, where you need to kind of start focusing your analysis on. So I usually try to have make at least once a week, again, depending on the scope and size of the project, like once a week, I still want to like talk to the business stakeholders understand what they are doing in the first couple of meetings are really just literally take it in to say, like a sponge, give me what you got, what were you thinking, not really thinking, really? What are you thinking and how you want to go and things like that. So it’s more about just gathering the information. At this point, I don’t click and I try my best not to be like, Oh, well, I know internet gambling, that’s gonna be a lot of work or like, you know, that’s going to cost you a lot. But I try to refrain from seeing that in like, initial meetings, just because it, it kind of shuts the conversation down. And then it becomes more about nobody really want this, I don’t care how much time it takes. And then the parties are not willing to meet in the middle and just say, well, like, it’s almost like if you say no to somebody that we can do it like they wanted even more. So that’s that’s the part that that’s why I don’t want to bring up like, you know, resistance, right then and there to say, we’re not gonna do this. I know internally, that’s not happening. But still, I tried to stay away from that. And it actually helps like, you know, later on, when you when I’ve had a chance to pick, you know, I don’t want to be like upfront without even like really analyzing the requirement, come back and say, No, I’m not going to do it. I don’t want to do that. I want to understand what you want. I want to go and analyze the system, the business processes, what’s going to be impacted, who’s going to be impacted. All of that work needs to be done before I call a requirement, a requirement. And that will start to take the shape and form of a user story. And that’s the part that I feel like we’re focusing on less and less orders. Less recognition of the work that a BA does in that space, just because it’s about the user stories now. So I gave you the requirements. We just talked about it one meeting, you know, in an hour recovered, like 20 things. I want all those 20 things. I’m in JIRA, yes, we could have it, but those are going to be placeholders, right? any value out of it. But the part that the BA plays is actually where you’re looking at the requirement, breaking it down, understanding what’s the impact, and then kind of building up to the solution. So that analysis bit, exactly, it’s analysis. Like, you know, you are a business analyst, like I’ve actually said that to people, again, when they think are like, you know, are we done with the users tourism? Like, no, I’m doing analysis, Nick, what do you have to do? I just gave me the requirements. I’m like, you could have just written those in JIRA, he didn’t need me for that. Right. So I’m doing what I’m here for, right, which is the analysis.
Pragati 35:59
And also kind of, you know, help the business prioritize requirements that are because I have some sense of what the solution is gonna look like. So, you know, kind of helps shape that conversation, because that’s really important. And that’s something that even we miss as big as, where we just take what the business is giving us as, like, for this, this is it, you have an opportunity to negotiate. And, like, we definitely should take that opportunity. Actually, before we even get to the negotiation, really understanding what they can, what the priorities are. And the reason I say that is the way I see it as like, you know how we have the MOSCOW system of prioritisation. So you have your Musts and Should and Coulds and Woulds. The way I kind of envision it in my head is the Musts are the gorillas, the Shoulds are the elephants. The Coulds are the Red Herrings, and the Woulds are Sloths. So the reason for that is like, you know, Gorillas – 800 pound Gorilla, it can sit anywhere, right? So if it’s a need, it’s a Must you have to work on it, there’s no question. So that is a Gorilla in my head got to work on this. Right?
Pei Mun Lim 37:24
Okay.
Pragati 37:25
The Should is, are the Elephants, which is the one that usually scares me the most, because it’s the Elephant in the room. This is where those requirements lie. That is that the business really, really, really wants, but they want to appear flexible. So they kind of slide it down the scale and make it seem like it’s not as needed at the corners. But sort of in the back of their mind, they kind of know this is a Must. And you know it to that it’s a Must to just kind of pretending until they get to a point where this is a big deal. And you’re just going to shift things around. So this is the one I guess category of requirements. And I’d be beset because when that Elephant becomes a Gorilla, and usually does like the first time possible in your project, so you have to babysit that you have to really make sure that what you have in the Elephant category is really Elephants, right. And then the next one that is so your Coulds are like Red Herring, which you know, usually are the smaller pieces that the delivery team will agree to this to say, Hey, we are flexible to begin to let this go. And just to make like this happy. So those are Red Herrings, throw them off the scent. And then the last one, you know, you always have those fourth priority would really love it, but I don’t really care. And we’re not going to talk about it next year. So those are just the Sloths, which are not going to go anywhere. So there’s just
Pei Mun Lim 38:58
So this animalcategorization system thing that you came up with,
Pragati 39:03
um, I kind of built up to it, because I felt like the more more and more, you know, I worked on these things like this is kind of by how I envision it. So when people talk about like prioritisation , like I started telling myself, I this is an elephant in the room. And like, you know, that’s how kind of like those Association. Now, I was working on this project, which was a non project because the goal was to make sure this didn’t become a project from for, to some extent. And I was asked to play the role to really like I was making the business case not to do something, because there was something else coming down the pipeline, which would solve this problem in a much better way. And so basically, it was to show that, you know, it’s worth the wheat. So just weed it out for a little bit. We can do this. So much better, so much easier, but we need time. I’m sorry, that. So when I was building up to that case, like, you know, I also had to highlight the requirements that were being that are being asked to deliver. So when I was literally like putting up the slides, and I was like, You know what, I could just put them up here and an elephant here and the rendering there. So to really communicate that I didn’t, but you know, it was an executive presentation. So like, that was something that I really wanted to. Yeah, okay. All right. That’s how I just kind of started missioning things in my head,
Pei Mun Lim 40:32
it’s a good way of doing it, because it’s very visual, I’m not going to be able to forget it now. Gorilla. Thank you. Thank you. You know what, I just realized that time’s going on, and I’m having just so much fun. So I’m just going to pivot slightly. And one of the things that I like to do is towards the end of podcasts and a little bit more about you. And there’s this thing called the EU user manual, I’m not sure if you’ve heard of it, but basically, wouldn’t be great if everyone came with a little document that says, this is how you operate with me. You both have children and young one would be great. Is it your mom, this is what makes me really annoyed, I do not like that properly, you’ve been feeding me, please, cuddles, and that sort of thing. So here’s some questions just to get to know you a little bit more. What are the kind of things about you that not very many people know, so some unfiltered truth and moral truths about yourself that not many people know that you’d like them to know, maybe so that they can work better with you.
Pragati 41:50
So from a work like a professional perspective, I think it’s, um, I think a lot of times, like my, I’m really passionate about, like, you know, just kind of work that I do. And I, as I mentioned earlier, I kind of stumbled into it. So, but over the years, as I’ve learned, I’ve grown really passionate about, you know, what I do, and how we do things, and not just about, you know, being a good business analyst myself, but, you know, just kind of working on making, you know, my work as a business owner, etc, and also kind of working with other people, like, you know, Junior analysts or people who work with me, you know, just kind of helping guide them or mentor them. And I really enjoy that, like, I really like apart from just my work work as a BA, just working with these younger people, and you know, just kind of helping them shape their career in business analysis, or, you know, how they, you know, how they would proceed in the world. So, that makes me really happy. And I, I was doing that on and off, like, not like, obviously, in a formal way. But I’ve just like really realized now that, you know, that’s a really big part of why I enjoy working in business analysis because I also get to interact with like, you know, DCM grandness and kind of help shape, they are thinking, and I want them to be excited about this field of four, because I’m really excited about it. And to some extent, it like kind of rolls back into me to where, if I see that, well, they get it, and they are happy with what they’re doing, then it makes me happier, it makes me love my profession
43:35
even more.
Pragati 43:37
So that’s the part that I personally really, really enjoy. Just kind of, you know, making sure that everybody’s enjoying business analysis, whoever’s entering it, like if I if I can shift that conversation, then that’s, that’s a big part of what makes me really happy in my life.
Pei Mun Lim 43:54
So at heart, your your mentor and a coach. Um, I don’t want to leave myself Oh, no, but you know, watching young analysts, making sure that they’re excited about things. If that’s
Pragati 44:11
Yeah, what I want to do it except like, I guess the only thing is, if I call myself a mentor, I just feel like if they, if what we do, and if they think I’m a mentor or a coach, then that Exactly,
Pei Mun Lim 44:23
exactly. So this is this is a label that other can give you a no media
Pragati 44:27
nightmare. Yes, exactly. Exactly. That’s right. Over that label, but yes, that’s one. That’s one of my passions with the work that I do.
Pei Mun Lim 44:36
Okay. Just one more thing. Before we wrap up. I’d like to understand what are the kind of values that you hold most important in yourself and in others?
Pragati 44:48
I that’s the most important one for me is respect for yourself, for the other person you’re speaking to, and just for your work It goes, it applies to a lot of things. But I think for me respect kind of is like, it’s like a requirement, it’s a baseline need for us to talk. I find like, you know, especially as DBAs, we sometimes find ourselves in really hostile environments. Because, you know, change is hard, nobody likes change, we talk about it all the time. And sometimes when you’re in that conversation, you’ve kind of either face the brunt of the anger, or depression, or whatever feelings are going around that particular change you’re implementing. So, it’s important for you to be as, as you know, as a DA, you have to be embedded in you have to show empathy, and you have to understand what, you know, what do you see color coming from, but there is a level that you can have to maintain that I need other people to maintain with you to have to say, I’m here to understand I’m you can vent, all you want to me, and we can talk about, you know, what you want, where, you know, any issues, every, I’m open to everything. But I need that level of, you know, just kind of respect to forest to me from you, you from me, like, you know, just, I know, it seems odd bringing that up in like a professional environment, because you expect like a level of sales, because we are like professionals, and you wouldn’t expect that. And for the most part, it’s been good. But I’ve run into certain situations where people were like, in another, you know, mindset that, you know, doesn’t quite sit well with a professional environment. So you kind of have to make, take yourself out of it and say, we can have this conversation, we can take this forward. But
Pei Mun Lim 46:46
you also need respect first. Yeah,
Pragati 46:48
yes, absolutely. For the work that we are doing for, for us individually. And as you know, the work that we’re doing together. So it’s not just like, Well, you know, you’re not an assistant, I’m not understand I’m not a scribe, you know, I’m there to help you even as a junior analysts, they definitely tell even like, my junior analysts, if they start treating you like an assistant, or your scribe, just like, this is what it gives you and just take it away. No, you have to push back. And you have to say, Well, you know, I appreciate that, you know, you gave me the requirements, are we talking about this, but, you know, we need to work on this in a different way. So I think that’s really important.
Pei Mun Lim 47:29
Thank you very much. This has been such a fun conversation. I really enjoyed it. You have shared with us how you work in the various different organizations, including Salesforce, and the other companies. We talked about user requirements. So very much we talked sorry. We talked about requirements in user stories. And there’s a difference. And you made a distinction quite clear, and process that goes between turning user. That’s right, I get between turning requirements into user stories. There’s a lot of non-systemic to be done on. There is a very, very good argument for having a BA in all organizations, if they want to improve if they want to be better than they were yesterday. So I really appreciate your input today. It’s been such a fun conversation.
Pragati 48:25
And so much it was awesome. I loved it.
Pei Mun Lim 48:30
Thank you. All right. Take care.
Pragati 48:33
Thank you.
Pragati 48:34
Bye bye.