SAs and the multiple hats they wear

In the IT industry, there are a few roles that, when defined and written on paper, are very different when compared to reality. An RPA SA’s role is no different. During the entire life cycle, an SA has to play many different roles. These roles are like switching hats as they have to switch them multiple times in a day or week. For example, an SA will wear a consultant hat in the initial stages of the project where they are talking to the business. They help the client identify the right process or help them select the right RPA tool or vendor, or maybe just help them understand what RPA all is about. This might be the role they played in one of the meetings, and on the same day, they again have to switch their hat from a consultant hat to an SA hat when talking to the development team or having a technical discussion with the CIO’s team. This clearly shows that an SA should be a master of switching profile and tone as per the situation, project phase, and requirements. Similarly, while talking to the development team, an SA has to be very technical and should be able to talk in a language that the developers can understand. For example, just saying that getting the data from queues and converting it into an Excel report is not detailed enough. An SA would have to tell the team to extract the data from queues in a tabular format and maybe store it in a dataset or collection. Use that to format the data and arrange the columns as per the report template agreed upon earlier. Then, write the data to an Excel file that has a specified file naming convention.

Let’s now deep dive and find out more about the multiple hats an SA has to switch between phases or situations so that it can give us a clear picture and highlight some focus areas.

Being a consultant

When you get engaged in the early stages of an RPA project or program, you are expected to talk in layman’s terms or in business terms. The reason is that you will most likely be talking to a business or non-technical group that is more interested in learning about the technology and how it is applied to different LOBs rather than the technical aspects of it. They want to hear from you about your experiences with other clients. Do not talk in your regular technical language—as they say, know your client (KYC)! Knowing your client and audience always helps in tailoring your conversation, which then makes more sense to them rather than becoming a boring conversation. This doesn’t mean that you have to drop all your knowledge, but play it by ear. Listen to what is being asked and who is asking the question. Tailor your answer accordingly—this gives you a better response and a fruitful conversation. Always try to use examples in your talking points. Prepare some PowerPoint slides that you can walk them through, as a picture is worth a thousand words. During your conversation, you might get a few technical questions, so being prepared is the key.

In the next stage, you will be given a process that has already been selected and vetted to be a viable candidate for automation. This stage is more of an assessment of the process.

Being a business analyst

You will most likely be accompanied by a business analyst (BA) who may or may not have experience working on RPA projects but knows how to talk to SMEs and gather requirements. If you are lucky enough to be accompanied by a BA who is seasoned in RPA projects, then you can sit back and relax at this stage and just be in listen-only mode. But if that is not the case, then you have to change your hat and wear a BA hat. This is where it becomes tricky. You need to go against your technical thought process and think like a BA. Asking the right questions to the SME is a trick of the trade. Having an experienced BA in RPA is a blessing. Knowing your BA’s skill set and background helps you be prepared for these situations where you have to step up to bridge the gap.

BAs can definitely break the ice, but then extracting the right information from the SME is the key. Also, time is of the essence in this phase. You get very limited time from the SME. They are very rare, and their time is precious. You can’t ask for their time whenever you feel you need them. So, asking the right question is the key to the success of this phase. Some questions you might want to ask are as follows:

• What is their team’s size?
• How much time does it take for them to complete the process?
• Can they show you how they do the process, and can you record it? This is called a time and motion study, which is a very crucial step in finding all the small steps to a mouse-click level. This will help you find the average handling time (AHT) of the process.
• What is the daily, weekly, and monthly volume of the transaction?
• Is there any peak time during the year?
• Which service-level agreements (SLAs) do they have to follow?
• Last but not least, what are the pain points for the process?

This is not an exhaustive list, but just gives you an idea of how you have to get involved and play the role of BA when you are not accompanied by an experienced one. We will revisit this topic in detail in the process design document in Chapter 6, Need for Documentation and Working with SIT/UAT Scripts .

It’s not only your job to get the functional requirements (FRs) but also to find out the non-FRs (NFRs). There might be a few things that might have been bothering the SMEs for a long time, and you need to convey the message that you are here to at least try to solve them while trying to automate the process. This is called a strategic approach toward the RPA project that has greater success not only in the near future but for years to come.

Being an SA

This is your primary role. This is a hat that you wear all the time. Once you are done with the other temporary hat, you go back to wearing the SA hat. Remember that you are and will always be an SA and will be addressed with the same name, but the expectations from you will be much more than an SA. You are expected to be a magician who can perform many tricks. I sometimes fail to understand why everyone thinks that SAs will have the solution not only for technical but also for functional and operational challenges.

For instance, you are in a meeting and the project manager is figuring out the change management activities, and they look at you and ask, What do you think? Well, you are not an expert in change management activities, but still, they are directing that question to you as they have a firm belief that you can either tell them exactly what to do or at least will share a few stories from your past experience. Though these situations are sometimes confusing and you might ask why this type of question keeps coming to an SA, they have great significance. Now, I am going to reveal a secret that will help you prepare for an SA interview.

This type of question is asked of you because the project manager has been briefed about you as well. You are not only the one who reviews and understands the strengths and weaknesses of the team members; other team members also do the same. Remember how you went on and on about all the different roles that you played—and let me remind you, that was the reason you were chosen for the SA’s position. So, technically, you brought this upon yourself!

An SA is an important position that we already understood, but it also comes with responsibilities. These are responsibilities that you signed up for when you took over this project. They are moral and ethical responsibilities. You pledge that you will adhere to the policies and procedures of the client. You might also have to undergo a few pieces of training before or during onboarding. Take those responsibilities seriously. They can be as follows:

• Don’t send any emails to your personal or employer email.
• No documents should be shared outside the client’s domain.
• Do not use a virtual private network (VPN) from unauthorized machines.

Not complying with these policies can end badly for you, your team, and your company. So, try to show leadership and lead by example by following these policies and procedures and encouraging your team to do the same.

Being a developer

Everyone knows you are an SA. No one expects you to develop unless it is evident. But again, it is expected of you to roll up your sleeves and get your hands dirty when the team needs you. Don’t shy away and say it’s not your job or that you didn’t sign up for this. You can’t even get away with saying you don’t know how to. This is a very common situation that will come up multiple times during the project life cycle.

Let’s visualize this through a scenario. You are working on a complex project. You have designed a solution that uses technologies that your developer is not familiar with. It is not a new technology; it is just that your developer has never worked on it. Now, you have two options: one, do it yourself, and second, teach and guide the developer to get it developed. The choice of option depends on many factors. Do you have time to spend doing it yourself? Can you guide the developer, and then they can pick it up? What are your developer’s background and experience? You are the best judge and can answer most of these questions by having a conversation with the developer and analyzing the situation. This is also one of those teaching moments when you help in grooming and developing talent.

You analyze the situation and decide to take this on yourself and get your name assigned as a developer. You have switched your hat again from SA to the developer. You took the responsibility to get that piece of code or module written and at the same time teach the developer how to do it so that in the future, they are ready for this type of work. This is another example where an SA bridges the gap. You develop the code and then do a knowledge transfer (KT). This step is very important, both for the continuation of the code maintenance and for you to switch your hat back to an SA.

Likewise, you have to change your role to a developer when you have to do a POC. Though the scope of a POC is very small and has time constraints, there are still development activities that you need to perform. A POC is a key step in proving the technical feasibility of the solution and proof of value. This step is generally performed in the initial phases of the project when you don’t have a developer or a team at your disposal. You have to do the heavy lifting and spin the POC. This is inevitable, and your chances of getting a developer at this point are pretty slim. The expectation is also that you are capable of developing a functional POC on your own—after all, you were once a developer yourself. This again ties to the answer you gave during your interview when asked that if a situation arises and you have to develop, are you comfortable doing it, and you answered: Yes!

An SA is also known for being a developer’s developer. The developer always looks to you to get an answer to their queries, fix and review their code, and help them overcome any impediments. You are again their savior and guardian angel. This is why when a responsible, accountable, consulted, and informed (RACI) chart is prepared, your name comes under responsible and accountable for all development activities during situations where you are racing against time and either development is not yet completed or system integration testing (SIT) has unearthed a lot of bugs that need attention before the code can be considered ready for UAT. These are the phases an SA should keep an eye on, and they should be ready to roll up their sleeves and get their hands dirty.

Being a delivery facilitator

When it comes to the smooth delivery of a project, there are always challenges. There are so many moving parts that it sometimes gets challenging. Having a set of eyes to achieve the ultimate goal is always appreciated. For this reason, it is considered an all-hands-on-deck kind of situation as everyone is considered to participate and take it to the victory line. An SA, being a senior resource, has a lot of say and can sometimes help in making critical decisions in a time of need. They are the ones who are involved in the day-to-day activities and have a more holistic view of the project, though SAs are not responsible for the delivery, as that would be the responsibility of the delivery manager and the project manager.

That being said, an SA can be of great help in making quick decisions. Let’s see a scenario where an SA helps in making some decisions that can become a big impediment in the delivery process. When it comes to full-life cycle projects such as RPA projects, there are a lot of requirements that are functional in nature. These can be requirements from the SME, info security, or any other team from the client side. So, you are working on a project and everything is going great, and suddenly, one day, you receive a meeting request from the client to discuss some new changes that came up recently. You join the call, and after setting the stage, the client tells everyone that there is a new mandate from the corporate that they are moving away from the traditional file storage system that was used to be the network drives to cloud-based storage.

Clients further explain that there is an enterprise-wide solution from Microsoft Office 365 that gives you the opportunity to store your files in a Microsoft Teams folder structure, which makes it more convenient for collaboration with humans. Now, because the bot you are developing will have to use the same location because maintaining two different file locations is not cost-effective and cumbersome, the process needs to be modified. The client asks what you and others on the call think, and you decide to take it offline and come back to them in a couple of days.

Now, this is a very common scenario, where we see that the existing process is being modernized by banking on the current RPA opportunity. As we can see, it is the future of all other upcoming projects you might have to work on, so avoiding this is not an option. You try to run some numbers based on the new requirements and the effort it will take from your team and the client’s team to come up with a game plan.

As you can see, the SA has to step up and help in even making a decision in this critical situation as they are the one who has that holistic view of all that is currently going on in the project from the timeline, delivery, resources, and other perspectives. A decision has to be made quickly and should also be within the budget and timeline. There might be a little wiggle room for you to ask for a few extra days for development and accommodate the requirements. Things such as this always fall on SAs’ shoulders, though we can argue that the project manager could have pushed it back based on the scope and given that we have already advanced in the development phase. It is always advisable to try your best to accommodate things that are not in the good-to-have category but can be a deal-breaker. Clients also know what they can live with and what is inevitable. As we can see, this is an enterprise-wide change, and 99% of the time, these can’t be pushed back. A more realistic solution would be to come up with a solution and let the client know what it will take to accommodate this new requirement and help them make a decision.

You need to present a solution that is feasible based on the timeline, budget, and delivery. Always try to evaluate these ad hoc requests based on good-to-have versus a deal-breaker or showstopper. These scenarios are some of the nuances you might face during the entire delivery of the project, and they can arise in any phase of the project. This is how an SA becomes a facilitator in decision-making and the smooth delivery of the project.