As a senior business analyst, you should be having a fluid conversation with your interviewer like this example.
Transcript
Emal – All right. So this is a mock interview with Rishi Pani. Rishi has close to 10 years of experience working in the capital markets domain as a programmer analyst and as a business analyst. And the purpose of our conversation today is to get to know Rishi a little bit better and to understand some of the experiences that he’s had as a business analyst.
So with that said welcome Rishi to the mock interview. Thank you. Thank you, mark. All right. So Richie, what I’d like to do is kind of, I’ve had a chance to go through your resume and I see that you do have quite a bit of experience in the domain that is being interviewed for what I’d like for us to do is to really just kind of get to know each other a little bit.
And then we’ll just dive into the contents of your recipe a little bit more. So I’m wondering if we can start that off with you just telling me a little bit about yourself. Sure. So as you pointed out, I have over nine years of experience as a business analyst, most of it has been in the capital market space.
Rishi – In my most recent project, I was working with one of the leading investment banks in Europe. And I was part of that IBO implementation. I was the lead business analyst for software that was responsible for the submission of interest rate benchmarks. On a daily basis. So the bank that I was working for is on the panel that’s that makes regular submissions to benchmark administrators.
And that’s why the software is not only critical from a functional or an operational perspective. It has reputational risks associated with it as well. Absolutely. So that seems very it seems like one of those, those types of projects where there’s a lot of pressure to make sure there aren’t any major mistakes, especially with the reputational risk involved here.
Emal – So that’s great. And we’ll get into your experiences, as a lead business analyst a little bit later on. So that’s great, I. That’s a great first answer to that question. Can you kind of just gimme a little bit of an overview of the throughout all of the projects that you’ve been through you know, there are certain types of projects where you can be on where.
Things tend to go very smoothly. And undoubtedly, if you’re involved in any kind of it project you’re always going to be involved in a project where things don’t go as smoothly. Yeah. From your own experiences have you had any situations where things haven’t gone as smoothly? And can you talk a little bit about some of the things that you did in that project?
Rishi – Yes. The way I look at it I am only able to make a living because things don’t go smoothly because if they did, most people like me wouldn’t be required. I, I don’t mean to be a firefighter, but what I’m trying to say is the kind of work that business analysts do is fraught with ambiguity, right?
So and the risk is even more when the when. Projects deal with really important things like IBO submission or the implementation of a major regulatory platform like METU and so on, on a regular basis, I’m faced with the typical issues that business analysts face for example difficult or Altran stake mm-hmm people I would say stakeholders who are not clear exactly on what they want.
They know why they’re doing something in some, some cases, not even that, but mostly I’ve been lucky enough to work with stakeholders who’ve got their business drivers sorted out. But they, it, it becomes very difficult for them to prioritize their needs. So that’s a frequent challenge and, those priorities even once decided, keep moving up and down.
Right. Right. So that’s something I have. To deal with secondly being at the crux of the development process, the software development process I have to deal with development teams with QA professionals, deployment professionals DevOps guys, right. And all of these guys have their.
Timelines their own agendas and in a lot of cases, their own motivations. So to balance all of these, right. Mm-hmm , that is something that is common that that’s, that’s something I’ve experienced in all my projects. Right. So I would say that these two. Are, I would say, yeah, these two are the, the biggest challenges that in general are faced in my career.
Emal – Yeah, that’s actually great because that answer kind of really, it, your experience really shows through in that answer, because what I’m hearing there is that you’ve had the experiences where you’re dealing with a lot of stakeholders who are not totally clear about their own needs. First of all.
You’ll have oftentimes stakeholders in organizations where you’ll have the stakeholders that you have on your own project are gonna have competing needs. You’ll experience those types of situations on a lot of projects. and what I’ve also noticed in what you’re saying here is that you actually have full life cycle implementation experience because if you’re working with the DevOps teams, for example, that typically means that you are working to move things from one environment to another.
And so you’re not just doing the upfront business analysis work. You’re actually working full life cycle across the entire development life cycle and delivery process, which is, which is very good. Just cycling back to the. The idea of working with stakeholders who have let’s say very unclear needs.
Can you talk to us a little bit about your approaches to dealing, let’s say with a stakeholder who especially when you’re dealing with much more senior stakeholders who are at the strategic level, a lot of times have a good sense of the direction that they want the organization to go in and they.
Understand their own business needs at a high level. Can you talk to us a little bit about what you do with stakeholders like that, to help them understand what their more detailed requirements might be and to help them kind of clarify their own understanding of what it is that they need operationally?
Rishi – Sure. So typically what happens with fairly senior people is that as you said, they know very vaguely what they want. But they’re not quite sure how to go about it. And in some cases, they might have a set of priorities, which they want to pursue, but they’re not quite sure of the order in which they are to be pursued.
So Techniques or tools that I’ve used successfully in the past are there’s a set of prioritization techniques. So there is something called the hundred dollars technique. So I hypothetically speak to them the first list out say the top five or six things that you want to do.
I will not counter question anything that you say, let’s just write down whatever you, whatever comes out of your mouth. Right. And then. If I gave you a hundred dollars right now and ask you to spend it on just a top four out of these five or. What would be the amount that you would allocate each of those four?
And which ones would you leave out? That sort of gives me an idea of what, what they are subconsciously prioritizing, but not able to probably get through immediately. Yeah. That’s one. Second is we use something called quality function deployment. It’s something that is, is, is very time consuming.
Mm-hmm and that’s why it’s used only when your traditional approaches don’t have traction. So things like let’s do a cost-benefit analysis. So if you do something. What is the benefit that you were going to get versus what is the risk or the loss that you face if you don’t do it? Right. So a combination of these two things often helps us to prioritize if to take it further.
What we, what I often do is get it, get some technical personnel involved mm-hmm and add to this mix, the level of technical risk involved. So FEAS. With respect to the resources that are available. Right. That’s also important. Yeah. Which helps us sort of get a very good handle on what needs to be tackled.
Emal – Yep. And I think that’s a very it’s a very effective prioritization technique that you use to basically give somebody a certain amount of credit and say, you know, what things do you really want? Because when you force a person to really have to. Allocate those fictional you know, credits, then you really get forced them to, to kind of think that think through their own priorities in a, in a very, in a very clear way, which is, which is very good.
Now let’s imagine a scenario where we have. Let’s say two director-level stakeholders on your project, and you’re really spearheading the scoping of the project and you’re doing the business requirements. And now these two directors have very different priorities regarding what they want from you.
And let’s say we have an example where. There’s one director who is really looking for a certain feature in the product that you’re looking to deliver. But another one of our directors who’s on the same project has very strong objections to expending the resources needed to deliver that product to deliver that feature in the product.
And they’re really trying to get their own items onto the list ahead of the priority. If you’re faced with a situation. What are some of the things that you can do to help resolve, that situation? Yeah, so I faced a similar situ not, not exactly the same because frankly, I’ve never had the fortune slash misfortune of dealing with two directors at the same time.
Rishi – So there was just on my last project where on the LIBOR implementation there are two groups that are constantly at loggerheads because of the nature of the work that they’re supposed to do. One is the group that is responsible for getting the submissions out on time.
Mm-hmm the second is our internal surveillance group. Okay. Who will do anything to slow things? so as to minimize the risk of erroneous submissions, now you can probably imagine why these two guys are all these two groups are always at, at cross purposes, right? So there was a feature where the submission team had wanted a copy from yesterday’s feature mm-hmm
So the figures that were submitted yesterday could be submitted today. And he was. He was really adamant that we should have it. Right. Mm-hmm but the, so when this, when these features were taken to the surveillance group for their validation they were up and arms. They didn’t want this. They said that if the team is getting paid every day, they should be using their brains every day to come up with numbers.
The software is helping them to do that copy from yesterday is not a good feature for several reasons. Yeah. Yeah. So. Obviously, arbitration is the first approach I tried to get, you know, get them on the same table and speak about it. But when it became clear that that was not going to work and I don’t clean the credit for this.
One of my reportees suggested this. We, we super we, we sort of refined the idea and we put it to both parties. The idea was that the Submission team would be able to copy from yesterday, but they would be able to do that only a certain number of times a week. Uhhuh. and the number of times that they would be able to do that during a week would be controlled by the surveillance team, depending on the okay.
Depending on the periods of stress for the bank. And so in that experience, did you find that both of the parties were I don’t wanna say happy, but were they both willing to go along. With that suggestion. Yes. Yeah. Yes. They were willing to go along and they actually drafted a note of appreciation, which of course I duly passed on to my subordinate and I was really happy.
Both parties got something out of it. Not exactly what they wanted. Mm-hmm but yeah, that was one recent example of how we dealt with competing requirements. That’s excellent. And it’s good to hear that you have. Stakeholder group negotiating in the way that you did in that case, because oftentimes you’ll find that when there are those types of competing priorities, a lot of times the two sides can’t come together and they can’t really agree on a solution that’s as innovative as, as the one that your team delivered.
Emal – So that’s, it’s great. Now let’s just imagine that same scenario, but let’s say we didn’t have that innovative solution on the table and we just really couldn’t get the two teams to agree. Would there be another approach in your mind to handling that situation? If that hadn’t worked I had only one thing in mind.
Rishi – I was going to escalate this to my manager and ask him to arbitrate because he was more likely. Be listened to mm-hmm and this might seem like a vanilla solution, but to be honest, that was the only thing, that I could have done. The only other thing that I could have thought of was in our project, right.
It’s all revenue driven. So sometimes it’s a simple question of who’s paying for the feature mm-hmm okay. So if someone’s paying for the feature and they’re ready to have it delivered and. It’s the burden of not executing the feature due to sort of an audit step falling on the surveillance team.
Then I would tell them, look, take it up with the audit team, your superiors, if that’s right if you produce this feature and they bin it later, then at least it’s not in our bucket. Yeah. Yeah, that’s good. And I think that the last option to escalate is always the option that we have to fall back on. A lot of times as business analysts, when we’ve tried everything else, you’ve tried all the innovations.
Approaches that you can take. And you’re still saying that your stakeholders are really not able to come to some sort of an agreement then it seems like a lot of times those escalation paths need to exist in the organization. And your ability to escalate through your own chain of management is usually the right way, to get those things resolved.
Emal – So that’s so that’s great. I wanna touch a little bit on your experience in working with the development and the infrastructure teams, across the different projects that you’ve been on. So software developers tend to have a very unique disposition and they tend to have their own way of working.
And in most organizations, that’s the case, but in projects where you’re really developing or you’re enhancing these mission-critical systems, like the ones that you’ve had experience working that have massive reputational Liabilities, possibly attached to them. In those types of situations, the developers tend to have very, very high standards and they tend to have very high expectations of the analysts that they work with.
And so can you speak a little bit about your experiences with that? Yes. I would say that I’ve been lucky enough to work with some really good developers and because they’re very good at what they do. They expect the same level of competence from everyone around them that has generally been the case, but if I had to pick one situation, it was my method to implement right now.
Rishi – That was a very high-pressure regulatory program that had a hard. Because the regulation went live on the 3rd of January, 2018. So there was no sort of negotiation we had to get it done. There was a piece on the instrument, data determination, which was really complex. And the developers were they, they had, they had no idea of the complexity but they were, they worked very closely with me too.
To identify what exactly needed to be done. It was a sort of a symbiotic process because I needed to understand the feasibility of whatever I was going to propose so I worked very closely with them and there was a, there was a very closed feedback loop all the time. So I would go back to the requirement owners, take the requirements from them, give them to the developers, check, doable, check feasible, et cetera.
And because of this, we managed to implement or deliver a very crucial piece of functionality whereby the developers also felt a part of the solution. So they were not just writing code, but they, they, they felt like. Equally vested stakeholders, right from the beginning because their voice was heard very often.
I’ve seen projects where even when in, in some of my earlier years where I was working with senior BAS and they would treat BI, they would treat QAs or, or development professionals as separate teams. And. Sort of developing silos in their own heads mm-hmm but I’ve consciously tried to avoid that and I’ve seen that it really helps.
Emal – Okay, good. That’s good. Because those like you said, in many organizations, some business analysts will Oftentimes just treat them as a separate team, not really doing a whole lot of consultation as they’re determining the business needs and writing their functional specifications. And they will sometimes only consult the development team right at the back end when they think they have everything ready.
and not getting that development feedback right up front with a lot of what you’re producing can oftentimes create problems for you down the line that you’re, you’re not gonna be able to foresee. So making sure that the development team is looped in all throughout, especially for very complex things where.
A lot of times the development teams themselves will have a lot of questions that the analysts might not necessarily have thought of. So having that regular interaction with them and making them feel like they’ve been heard and that their concerns have been heard is very important for developers, especially in this domain.
So just looking at your resume here. So it seems here that you have a bit of a programming background as well. So you started off your career initially as a programmer analyst? Yeah, that’s right. Okay. And so you would you. Say that in the domain that you’re in that your development background helps you, in some ways, or do you think that that’s something that’s just coincidental?
Rishi – No, I would say it’s, it’s a very important thing. It’s a, it’s a great asset in two ways. So while I was when I first started my career, I started writing code I realized two things. I wanted to be in the industry, but not in this role. I saw what BAs were doing. I thought. I’m more suited to that.
So it helped me in my choice of career. So that’s there of course and has written code for a bit and I still write code in some forms. So a bit of sequel, a bit of Python, right. So that helps me understand how they think of problems and solutions. So in terms. Data structures. Right. Right. In terms of how data would be transmitted, stored, viewed what could be the practical difficulties with something that I’m, I’m proposing mm-hmm so I can’t just say, you know what, this is a requirement, go do it.
It’s not my problem, you know? Yeah. So yeah, it does help me because I’ve, I’ve been on the other side for a bit. Okay, that’s great. Going back to your experiences as a team lead now let’s say we were in the process of launching a new project that we estimated we need five total analysts and it was in an area that you have strong domain knowledge that situation.
Emal – Do you think that really not really knowing anything about any of the other analysts that are on your team, would you see yourself more as a team member in an initiative like that? Or would you see yourself as more of a team lead for that type of initiative? Well, I think it, the answer would depend on, on a couple of things.
Rishi – Firstly, what is the official position? So it quiet, it could be that the four other, the five other analysts that are working with me are equally experienced and are equally talented. And there is no clear demarcation as to, who’s going to report to whom. Right, right. So, that’s one way of looking at it.
Secondly the pieces of work that we, that we are assigned individually, mm-hmm, obviously at some point we would sit around a table and, and share what we’re going to do and how we’re going to do it. Share each other’s pieces of work. Right. If it became clear that those pieces are pretty independent and can be analyzed independently, completely, I insulated from the others then.
The question of leading as such doesn’t really arise. But if it seems that there’s a lot of synergy between the points and by just consultation, we realize that you know, one of us, it could be me, it could be someone else really has the knowledge to fast track this. Then I’d be more than happy to follow or lead as the case may be.
Emal – Okay. If I was to rephrase that question, let’s say it a slightly different. Let’s imagine that we. In the inception phase of the project where we’re still trying to get an idea of what the scope of the project is. Would you be comfortable in a setting where it is your responsibility, really, to scope out the project and to have another analyst or another two analysts, let’s say that would be reporting to you where they would be more responsible for doing the detailed specifications when the time comes.
So. During the inception phase of the project, typically what you’re doing is you’re just having them kind of tag along with you to listen to the conversations, knowing that the ramping up, that you’re doing of these other analysts on your team possibly that you’re going to need them to produce a lot of the detail specifications.
With the knowledge that they’ve gained in, doing the inception with you would you be comfortable in an environment like that? Are there some things that you can tell us that you think would help you carry out a role like that?
Rishi – Yes. So of course I would be comfortable cuz I’ve done that before. And what would help me right off the bat is to get the scoping done as quickly as possible because I realized that The scope once decided is never supposed to change, but almost always ever it changes. It never remains the same. So use your context, diagrams, use your feature lists and whatever it is that you have to do.
I would get the scope done first and, and done it really fast. Share it with the team, with the two people who are going to be specking it out, in greater detail. And. Once I know once I get feedback from them, how, how easy, how difficult it is to spec it out, to flesh the details out, to actually get functional testable requirements.
Then I think I would use that feedback to refine the scope further. So sometimes it’s, this has happened to me before where the scope as is got from a customer. Sort of starts creeping on its own when it’s detailed out. Okay. So in an environment like that, you’d be happy having two or three or one or two analysts tag along with you in these scoping sessions, to help them along.
Emal – And yeah, really part of the trouble that you may run into in this situation is that you may have some analysts who are possibly trying to get into too much detail too quickly. We and we with stakeholders, you often wanna make sure that you’re carrying out the right level of conversations with the right people.
And sometimes you may have to make sure that your analysts that are on your team are not kind of pulling the conversation in the wrong direction or too level of detail too quickly as well. So that’s good. I think those are all of the questions that I had with you. I want to thank you for attending this interview.
And is there anything else that you’d like to add before we conclude?
Rishi – No. It was great. Speaking to your email, obviously, I’ve seen a lot of your work on, on VA blocks and I think it’s, it’s fantastic what you’re doing because there are, there’s a lot of material out there which is available for intermediate or advanced business analysts, but a lot of material on your site is a great introduction for someone who wants to get into the field and has no idea about what to do.
Emal – So that’s great. I appreciate that. Yeah, it’s really good. And I, I appreciate this. To, to speak to you. So thank you for your time. Yeah, that’s good. And this was excellent by the way.
The True Value of Business Analysis.
Three short lessons to show you how business analysts link organizational silos to create business/IT alignment.
Leave a Reply