Being a guardian angel, influencer, and enforcer
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.
