Robotic process automation (RPA) is also nowadays one of the mainstream functions of IT. So, as with other IT functions, RPA also has to have an SA as a role. But the question arises: Do we need an SA? This question has a straightforward answer, and that is: Yes! What are the valid reasons for having an SA as a role? How would we justify this role? To answer this question, we need to understand the responsibilities of an SA.

An SA is a person who is a problem solver and specializes in identifying processes that are good candidates for RPA. This person knows the ins and outs of the underlying technology, its strengths and weaknesses, and how to overcome them. An SA for RPA has extensive knowledge about the core function and automation and is a master in finding solutions, be they technical or non-technical. They understand the other IT functions and how to amalgamate them to find a viable solution for a problem. An SA is known as a jack of all trades and a master of solution design. They can be a master of other traits, such as programming, networking, infrastructure, and so on.

Having an SA on your team will give you the peace of mind to find the best solution and not the easiest solution for the problem. A good SA will approach a problem with integrity, customer focus, and frugality. They also possess some ethical and moral responsibilities. Knowing that your SA will do what is best for the processes, people, and company makes this role invaluable. An SA is also responsible for evaluating the potential of an RPA project, its limitations, and its efficacy. If something can be automated, that doesn’t mean it should be. Based on this principle, an SA can weed out processes that seem to be a good fit but are not a good fit.

For example, let’s assume you have a team working on an RPA project. There is no SA available, and the responsibility to find the best solution and technology is the responsibility of the developers. As developers are also tasked to deliver the code on time, they tend to get biased in selecting a solution that is easy and fast to develop. An easy solution is not always the best solution and is prone to introducing future issues. To avoid this, the responsibility of selecting the technology and the best solution should be decoupled and should be given to an SA. They also bring along thought leadership, which is needed to bring people, processes, and technology together.

An SA will do regress research and will try to find the best solution. They will evaluate the solutions based on future scalability, manageability, and maintainability. A proper evaluation should be done as to whether an SA is required or not based on the team’s capability and experience in design, development, and delivery. However, note that an SA can be a costly affair. Their cost can add to the budget, but not having an SA engaged in the initial stage can be costly in the long run. You need a person who can challenge the status quo. They question the team and provide guidance with respect to design principles and development standards, and can avoid cutting corners. In relation to what we discussed about the importance of the SA role, let us now look into the various ways in which an SA can bridge the gap and how they are able to help the team and project to succeed.

Now that we have established the importance of having an SA in your team, let’s talk about one of the most important functions an SA plays in the life cycle of an RPA journey—bridging the gap.

You might be thinking, what does bridging the gap mean? The phrase is self-explanatory, but to give it some context, we will use a scenario as an example.

Let’s say you are an SA and have been invited onto an introductory call by the client. The client has their subject-matter expert (SME) walk you through the current process, for which they want you to develop a solution. After listening to the SME for 15-20 minutes, you realize that there will be a need for a mechanism to read the PDF files used in the process as they are scanned images’ PDFs. Currently, as humans are doing the process manually, they don’t feel the need for any other technology other than just looking at the PDF and extracting the information.

In this scenario, there is a gap that you have identified, and you might have already started thinking about how to approach this problem. In your mind, you know that you will need optical character recognition (OCR) to solve the problem. You were about to spill the beans when you were interrupted by the vice president (VP) of IT. He said, Just so you know, we try to solve a problem not tactically, but more strategically. What he meant was for you to think of a solution that is not only used for RPA but something that can also be used as an enterprise-wide solution such as OCR, which can be leveraged in other applications and solutions as well. It can also become a service that can be called in future automation as well.

After you understood what the VP meant, you realized that the gap has increased, and you now have to come out of the RPA box and think like an integrator who will bridge the gap. In this scenario, you have the job of not only coming up with a viable solution but also bringing all the necessary teams together to turn that viable concept into a real functional solution implemented in production. This is what is not written in the job description, and neither will anyone tell you that it is your responsibility. But it is assumed that you already know what needs to be done as you are the SA.

Though it seems and looks like it is fairly simple, the task has multiple action items. You need to design the solution and do a proof of concept (POC). Then, you need to identify all the processes, people, and technology you will need to make this solution a reality. After your POC is approved, you will have to identify all those teams that are needed for this mini-project of yours.

This brings us to a very important point, and that is: an SA should possess knowledge of not only programming and technology but also networks, security, infrastructure, and industry standards. Having this knowledge will help you define the infrastructure needed for the solutions—for example, What kind of security should be in place? What kind of infrastructure is needed?; so on and so forth.

That is why I can’t emphasize enough that an SA should be a jack of all trades. An SA should be up to date with the current technologies and should have enough knowledge to have a serious discussion with the other teams so that they can understand the requirements and recommend the right course of action. It also helps to know the client technology stack so that you can easily and efficiently design the solution based on what is already available in-house rather than go on a shopping spree.

Frugality should be one of the strongest traits of an SA. You, as an SA, are hired to do the job using the tools and technologies available. Anyone can google and say that XYZ vendor has a product that we are looking for and that we can go and buy off the shelf. Well, that costs a lot of money, and everyone knows that there is always a readily available product on the market. But you are hired so that they don’t have to invest in something new and still end up owning it. So, always try to find a solution that is economical. It’s not that SAs don’t use or suggest self-solutions, but that is only when there is a dire need for it for a faster go-to-market (GTM) strategy and budget is not a constraint. We will talk about this in detail in the Design principles section of Chapter 5, Designing a Framework for Consistency and Resiliency.

When it comes to the responsibilities of a project or program, a project manager comes to mind. Similarly, when we are working on a project that has a lot of unknowns and we need someone we can trust, then an SA comes to mind. RPA SAs are no different. They are just like a new flavor of the same brand of candy that you like and have been eating and loving your entire life. Now that we have established how important the role of an SA is for any project, and in this book’s context for RPA projects, let’s also understand the few hidden talents that SAs should possess to increase their role’s efficacy.

As we progress in the RPA project, we kind of realize that two specific roles have the responsibility and are held accountable for the successful delivery of the project. The first is the project manager and the second is the SA. The former takes care of all the logistics and runs the project as per time and budget. The latter is responsible for designing and implementing a robust solution. For a robust design, an SA should act as an influencer and an enforcer.

To understand this better, let me present you with a scenario. An existing client approached you and asked for a meeting. In the meeting, he showed his interest in RPA and requested you do an introductory presentation to the CEO and CIO of the company. While you were walking them through the presentation and explaining how RPA works, you were asked a question by the CTO: Tell me how you will help us in the RPA tool selection. This is where you become an influencer. Your role is now to help the client, who has little knowledge about the different tools in the market and doesn’t know which criteria should be used for a tool selection. Being an influencer is using your knowledge and experience in different RPA tools to help the client reach a decision. Your input, suggestions, and recommendations are what the client is looking for, and that is how an SA becomes an influencer. The moral of this scenario is that an SA should at least be an expert in two or more RPA tools.

Now that, based on your recommendation, the tool of choice has been selected and implemented, your role switches to that of an enforcer. Let’s try to understand the enforcer part through another scenario. When working on an RPA project, an SA works with many different teams. Among all these, the development team is the most important one that will help your dream come true. The SA, being the guide, has the responsibility to explain to the developers what needs to be done and how to approach a problem. The SA’s strategy should be to teach developers how to approach a problem and not to provide a readymade solution. If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime. This is why we need an enforcer who can put a guide rail of standards, processes, and procedures to the developers so that only the approved solution gets developed and deployed. The enforcer makes sure that the guidelines are met and followed.

This brings a question to mind as to why an SA has to do that. Well, for the simple reason that an SA is designated to find the best solution and not the easiest solution. The SA needs to keep in mind scalability, maintainability, sustainability, and usability. To keep the development in check and maintain consistency and quality, the SA becomes an enforcer of rules, best practices, and coding standards. These standards come from various sources—some are from the client, some are from RPA vendors, and some are from their own experience.

While developers are well equipped to manage any trick situation, sometimes they get tangled in office politics. This is when an SA has to switch to their guardian angel hat and come to the rescue. The development team does not always report to the SA, but they are still responsible for their actions in the project. As SA is held responsible—they also have to defend the team when needed. This is not always practiced but is a good way to build trust in the team and helps keep its morale up. A healthy team can work miracles. Keeping this in mind as a mantra, every SA should be ready to speak on their team’s behalf. SAs are more senior than developers and have more industry experience. That helps them to articulate things better and present them in a simplified manner. This also helps to prevent a crisis.

That being said, SAs are not called guardian angels just for defending the developers but also are of great help if the team is short of hands or needs an extra set of eyes to review the code and provide suggestions. This is when the code is broken, and no one has any clue why it is not working. The SA, as stated earlier, has knowledge of not only development but also other functions of IT, and they can easily decouple themselves from the problem and step back and try to gauze it holistically. This helps them to identify issues that others might have not even thought of. Also of note is the fact that they have seen so many similar issues and problems in their life that they can quite easily put their finger on the real issue.

When it comes to being a guardian angel, influencer, or enforcer, the SA has to be completely involved in the day-to-day activities of any given project. There are many scenarios where you as SA might have to work in parallel on multiple projects, and when you are stretched thin, you can’t be any of the three. So, keep yourself up to date with your projects and have a daily connection with your team so that you get all information firsthand.

As the name itself suggests, SAs have ownership of their solution. It’s their creation. They designed it and they will be the ones who will have the final say. This has its own pros and cons. A solution is generally based on a quick POC. As the POC is not detailed enough, there might be challenges that are faced by the developer in the later stages of development. This is when the SA is called and asked for an alternative way to get the specific task done. Owning the solution means that no one else can make any changes to it unless it is reviewed and approved by the SA—their blessing is needed. That doesn’t mean recommendations are not welcome. The SA should practice a collaborative approach to recommendations and work toward the greater good.

Ownership comes with a lot of glory and fame. Your name is registered in all the documents as an SA, and everyone knows that you were the key to success. But don’t get too excited—the road to fame always goes through a tough path. Let me walk you through a scenario where you are working on finding a solution that you did not design earlier, just to give you a glimpse of what kinds of curveballs you can face while designing a solution.

You have been asked to design an RPA solution where the process involves thousands of Excel sheets. These sheets have many different templates, and those templates are used by customer care and other teams. These Excel templates are stored on a network drive accessible to all teams from many different geographical locations. As we know, once an Excel sheet is open, it gets locked, so there are multiple versions of the same sheet being created by each user. This flaw in the process is due to a limitation in Excel and the fact that the existing process was designed 15 years ago; it never went through digital transformation. You have been asked to automate this process so that bots and humans can work in conjunction with each other.

You start thinking of various viable solutions, but then you realize that those solutions are more time-consuming and need more investment and effort. You keep scratching ideas and you end up nowhere. Then, you get the idea of splitting the problem into small achievable goals. You go to a whiteboard and draw the existing process and then gaze at it for a few minutes. You immediately realize that this process has two main clients to cater to—one is humans and the other is bots. Even if you are the SA responsible for automation, this doesn’t mean you need to solve all problems and issues pertaining to the process. SAs have to work within the scope of the project. The expectation is to design a solution that can be scaled, managed, reused, and does not disrupt the existing process. You decide that before the automation, you will simplify it from a bot’s perspective. You design a workflow that extracts the Excel template into an XML file. This is called decoupling. Once you do that, the human side of the process and the bot can co-exist.

But the question is: why would you go to such lengths to get this done? The answer is that you are the solution owner. You are responsible for designing and owning that till it is deployed to production and even after that. Having the mindset of an owner will take you to those uncharted territories of your mental creativity and unlock them. As the SA, you won’t think about why you should do this, but you know that you are the only one who has to do it.

Keeping the mindset of an owner always gives you the anchor that will keep you going on at times when you think going forward is impossible. The owner is also responsible for any decision, changes, and outcomes of the solution. Be always ready to own them as well and know that it is inevitable. This is a great responsibility and comes with its own challenges, but then you are the one who will be basking in the glory of success once your solution gets to see production. Now, you have already realized that you are not the person who is going to put your solution into production. You have many teams involved in this life cycle.

As an owner, it is your responsibility to see that the solution you designed and the solution that is getting deployed in production are the same. For this reason, you have to be involved in the day-to-day operations of development, testing, user acceptance testing (UAT), and deployment phases. You can’t lose your focus as there will be questions, comments, suggestions, and cutting corners to get the job done. Owning the solution doesn’t mean only owning a diagram on a piece of paper but owning it from an implementation perspective as well. If the team has challenges, then you should know how to help resolve them. Guiding the team in the entire development phase is also your responsibility, or else you shouldn’t be surprised if the end product is different from what you initially designed.

At times, you will face some situations where developers are frustrated to know you designed a solution the way you did, even when there are easier solutions to the given problem. Well, always keep in mind you have designed it that way as it is one of the best ways to do it rather than it being the easiest way, and thinking in that way makes you an SA. Not only developers but other teams might also crib for the same reasons, and you have to defend your solution like your baby—that is what I call ownership.

When I say defend, that doesn’t mean you have to say it is my way or the highway, but always be prepared with rational reasoning and an explanation of why you did what you did. Having the pros and cons or a comparison metric always makes a difference and helps people understand. When you have to defend or explain yourself, talk with facts and figures—just saying that you are the SA and you can do whatever you want doesn’t work and will just be rude. As I mentioned earlier, SAs have to work with many teams, and having the right attitude is the key to having synergy.

Now, let’s talk about some of the challenges aspiring SAs and new upcoming SAs might face. They still tend to be in the persona of their earlier role, and as they might have not faced these types of situations, it is tough to react in the right way. The best thing to do when you go to a meeting where your design is going to be questioned is to be prepared and have all the facts ready to discuss. Now, as we discussed earlier, having the right mindset and attitude helps in confronting this kind of situation. If you made a mistake, own it. Trying to rationalize a mistake is like adding fuel to the fire. It also tarnishes your credibility as an SA. It goes without saying that the more knowledgeable you are, the humbler you become. Ownership is not only for the name and fame but also for your mistakes. A humble acceptance makes you a better SA and helps build a rapport with others.

To summarize, an SA is the owner of the solution, but at the same time, has to get feedback and blessings from other teams and stakeholders to get the design approved. They have to be patient and humble and have an open mind to suggestions.

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.

To summarize, an SA is one of the most important roles in an RPA project. We saw how an SA can be helpful for not only bringing integrity to the team but also bridging technical and functional gaps in the team. Other than their primary role and responsibility, they have to take on extra responsibility to make sure that the end goal is achieved. Only results matter—keeping that attitude, the SA helps the developer overcome technical impediments and at the same time helps the team as a guardian angel, influencer, and enforcer of best practices. They also keep the team moving forward in the right direction by guiding them and keeping them focused. They are the owners of the solution so as to make sure that it gets implemented to its utmost extent. They help in filling other people’s shoes, such as being a consultant, developer, and delivery facilitator. This gives us a clear picture of what it takes to be an SA. An SA has to possess many skills so that they can be used as a trump card whenever needed.

Having an SA on the team gives peace of mind and helps make sure that the project goes smoothly. This is why SA selection should be exhaustive.

In the next chapter, we will talk about a case study of a banking organization, which will be our reference point and help build a story for future scenarios. This will also help to visualize an end-to-end RPA engagement unclear for understanding the length and breadth of an RPA project.