all right so this is a mock interview with rishi uh poptani uh rishi has close to 10 years of experience uh working in the capital markets domain as a programmer analyst and as a business analyst and uh 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 uh so with that said welcome rishi to the mock interview thank you thank you mark all right uh so richie what i'd like to do is uh 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 uh is uh being interviewed for uh 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 the contents of your resume 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 uh so as you uh pointed out i have over nine years of experience as a business analyst most of it has been in the capital market space uh in my most recent project i was working with one of the leading investment banks in europe and i was part of their ibor implementation i was the lead business analyst for a software that was responsible for the submission of interest rate benchmarks on a daily basis so the bank that i was working for uh is on the panel that's that makes regular submissions to benchmark administrators and that's why this the software is not only critical from a functional or an operational perspective it has a reputational risks associated with it as well absolutely so that seems like uh that seems like very um 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 reputational risk is involved here uh so that's great and we'll get into uh your experiences as a lead business analyst a little bit a little bit later on so that's a that's a great interview uh it's a that's a great first answer to uh that question um can you uh kind of just give me a little bit of an overview of uh the uh 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 i.t project you're always going to be involved in a project where things don't go as smoothly from your own experiences have you had any situations where things haven't gone us smoothly and can you talk a little bit about some of the things that you did in that project yes uh the way i look at it uh i am only able to make a living because things don't go smoothly because if they did i mostly people like me wouldn't be required i don't mean to be a firefighter but what i'm trying to say is uh the kind of work that business analysts do uh is fraught with ambiguity right so um and the risk is even more when the um when the projects deal with uh really important things uh like eyeball submission or the implementation of a major regulatory platform like mifid2 so on a on a regular basis i'm faced with the typical issues that business analysts face for example difficult or recalcitrant stakeholders people um i would say stakeholders who are not clear exactly on what they want yeah 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 um they it it becomes very difficult for them to prioritize their needs so that's a frequent challenge and those those priorities even once decided keep moving up and down right so that's something i have to uh to deal with uh secondly being at the crux of uh uh the development process the software development process i have to deal with uh development teams with qa professionals deployment professionals uh devops guys right and all of these guys have their own timelines their own agendas and in a lot of cases their own motivations so to balance all of these right that is something that is common that uh that's something i've experienced in all my projects so i would say that these two uh are i would say yeah these two are the biggest challenges that in general i've faced in my career yeah that's actually great because uh that answer kind of really 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 uh stakeholders who are not totally clear about their own needs first of all uh you'll have oftentimes stakeholders and organizations where you'll have the stakeholders that you have on your own project are going to have competing needs you'll experience those types of situations on a lot of projects and what i've also noticed and 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 across the entire development life cycle and delivery process which is which is very good just cycling back to the idea of working with stakeholders who have let's say very unclear needs do you can you talk to us a little bit about uh 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 they 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 uh 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 uh and to help them kind of clarify their own uh understanding of what it is that they need operationally sure uh so typically what happens with uh fairly senior people is that as you said they 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 that's right so uh some techniques or tools that i i've used successfully in the past uh are there's a set of prioritization techniques so there is something called the 100 technique so i hypothetically speak to them first list out say the top five or six things that you want to do brainstorm i will not counter question anything that you say let's just write down whatever you whatever it comes out of your mouth and then if i gave you a hundred dollars right now and ask you to spend it on just the top four out of these five or six uh what would be the amount that you would allocate to 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 uh second is uh we use something called quality function deployment it's something that uh is is very time consuming and that's why it's used only when your traditional approaches don't 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 are going to get versus what is the risk or the loss that you face if you don't do it right 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 and add to this mix the level of technical risk involved so feasibility with respect to the resources that are available right that's also important which helps us sort of get a very good handle on what needs to be tackled first yeah yeah 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 uh what things do you really want because when you force a person to really have to allocate those fictional uh you know credits then you really get forced them to to kind of think that uh think through their own priorities in a in a very in a very clear way which is which is very good um 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 of 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 expanding 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 the situation like that um what are some of the things that you can do to help resolve that that situation uh yeah so um i've faced a similar situation not not exactly the same because um frankly i've never had the uh fortune slash misfortune of dealing with two directors at the same time but yeah pre two pretty senior people representing competing interest groups so there was just on my last project where on the eibar implementation uh there are two groups that are constantly loggerheads because of the nature of the work that they're supposed to do one is uh the group that is responsible for getting the submissions out on time the second is our internal surveillance group who will do anything to slow things down 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 cross purposes right so there was a feature where uh the submission team had wanted a copy from yesterday feature so the figures that were submitted yesterday could be submitted today and uh he was uh he was really adamant that we should have it right but the so when this when these features were taken to the surveillance group for their validation they were up in 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 uh not a good feature for several reasons uh yeah so obviously arbitration is the first approach i tried to uh 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 uh and i don't clean the credit for this one of my uh reportees suggested this we we super 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 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 earth depending on the periods of stress for the bank right yeah and so in that experience did you find that both of the parties were i don't want to say happy but were they both um willing to go along with with that suggestion yes they were willing to go along and they actually uh drafted a note of appreciation which of course i duly passed on to my subordinate and i was really happy that both parties got something out of it not exactly what they wanted but uh yeah that was one recent example of how uh we dealt with competing requirements that's excellent and it's good to hear that you have stakeholder groups negotiating in the way that you did in that case because often times 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 so that's it's great now let's just imagine a the scenario 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 in handling that situation uh if that hadn't worked uh i had only one thing in mind i was going to uh escalate this to my manager and ask him to arbitrate uh because he was more likely to you know be listened to and this might seem like a vanilla solution but uh to be honest that was the only thing that that i could have done the only other thing that i could have thought of was uh in in our project right it's all revenue driven so uh sometimes it's a simple question of who's paying for the future right so if someone's paying for the feature and they're ready to have it delivered and uh it's it's the burden of not executing the feature due to uh sort of an audit step falls on the surveillance team then i would tell them look take it up with the order team or your superiors if if we produce this feature and they bin it later then uh at least it's not in our bucket yeah yeah that's good and i think that the um last option to escalate is always the option 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 innovative 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 uh your ability to escalate through your own chain of management is usually the right way to to to get those things resolved so that's so that's great um i want to touch a little bit on your experience in working with the development and the infrastructure teams in across the different projects that you've been on so uh software developers tend to have a very uh unique i would say a disposition and they tend to have their own way of working yeah and uh in most organizations that's the case but in projects where you're really developing or you're enhancing these missile 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 have tend to have very high expectations of the analysts that they work with and so can you speak a little bit to your experiences with that yes uh 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 implementation right now that was a very high pressure regulatory program that had a hard stop uh 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 instrument data determination which was really complex and uh the developers uh were they they had they had no idea of the complexity uh but they were they worked very closely with me to uh 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'll go back to the to the requirement owners take the requirements from them give it to the developers check doable check feasible etc uh if and and because of this we managed to to implement or deliver a very crucial piece of functionality uh whereby the developers also felt a part of the solution so they were not just writing code but they they felt like equally vested stakeholders right from the beginning because their voice was heard very often uh i've seen projects where uh even when in in some of my earlier years where i was working with senior bas and they would treat biz they would treat qas or or development professionals as separate teams and sort of develop silos in their own heads but um i've consciously tried to avoid that and i've seen that it really helps 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 uh create problems for you down the line that you're not going to 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 analyst might not necessarily have thought of so having that regular interaction with them and making them feel like that 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 uh would you say that in the domain that you're in that your development background helps you in in some ways or do you think that that's something that's uh that's just coincidental no i would say it's a very important thing it's a it's a great asset uh two ways so while i was uh when i first started my career i started writing code i realized two things i i wanted to be in the industry but not in this role i saw what bas were doing i thought that i'm more suited to that so it helped me in my choice of career so that's there of course and um having written code for a bit and i still write code in some forms so a bit of sql a bit of python right so that helps me understand how they think of problems and solutions so in terms of data structures right in terms of how data would be transmitted stored viewed what could be the practical difficulties with something that i'm proposing so i can't just say you know what this is the requirement go do it it's not my problem you know yeah so uh yeah it does help me because i've been on the other side for a bit okay that's great um going back to uh your experiences as a team lead now let's say if we were in the process of launching a new project that we estimated we need uh five total analysts for uh and it was in an area that you have strong domain knowledge in um in that situation do you think that uh 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 an initiative oh well i think it the answer would depend on on a couple of things firstly what is the official position so it quite it could be that um the four other the five other analysts that are working with me are equally experienced and are equally talented in and there is no clear demarcation as to who's going to report to whom right right so that that's one way of looking at it secondly uh the pieces of work that we that we are assigned individually obviously at some point we would sit around the 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 uh by just consultation we realized 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 okay okay if i was to rephrase that question let's say in a slightly different way um let's uh let's imagine that we're 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 uh in a setting where it is your responsibility really to scope out the project uh 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 uh 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 uh of these other analysts on your team possibly uh that you're going to need them to produce a lot of the detailed specifications with the with the knowledge that they've gained in in doing the inception with you uh 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 yes so um of course i would be comfortable because 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 uh i would get the scope done first uh and and done it really fast share it with the team with the two people who are going to be specking it out in in greater detail and uh once i know uh once i get feedback from them how how easy how difficult it is to spec it out to flesh the details or to actually get functional testable requirements then i think uh i would use that feedback to refine the scope further so sometimes it it 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 the scoping sessions to to help them along and really part of the trouble that you may run into in this situation is that you may have some analysts that who are possibly trying to get into too much detail too quickly uh we and we with stakeholders you often want to make sure that you're carrying out the right level of conversations with the right people and uh 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 in the wrong direction or too level of detail too quickly as well um so that's good uh i think those are all of the questions that uh 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 no it was great speaking to you iman 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 so that's great i appreciate that yeah it's really good and uh i appreciate this chance uh to speak to you so thank you for your time yeah that's good and this was excellent by the way