Effective RPA Development Team Composition
What do the most effective RPA development teams look like? As an RPA consultant, I’m exposed to tons of RPA teams and projects and the best teams do have something in common.
The ones that do the best are primarily 70-80% non-technical, with the remaining members having some technical (programming or software development) background. If the development team is primarily outsourced (i.e. external consultants) it’s best to have at least one or two team members from the actual company itself developing alongside the contractors.
Business Focused Teams
This situation happens when RPA is primarily driven by business and not IT.
Most RPA platforms offer a ‘no-code’ or low-code style of development, which is true for about 95% of your automation work. But there will always be those 5% edge cases that are better solved (or can only be solved) by actual programming. Examples of this include dealing with foreign language MS Office documents, or trying to ‘kill’ an unresponsive application.
These kinds of highly technical humps can stall development teams comprised of purely business-focused RPA developers. That’s why I’d encourage these teams to work with IT and bring in one or two software development savvy people to join the RPA centre of excellence.
Technical Focused Teams
If your RPA is IT driven, you may end up in a situation where all of the RPA development team comes from IT.
A highly technical RPA team has a few drawbacks. First of all, they like to rely more on calling external scripts (for example, calling Python through the command line) to complete automation work. Process steps turn into a ‘black boxes’ which are harder to maintain, understand and test by the business team, who will sign off on them. If multiple steps happen inside the script, the ability to audit and debug the steps are reduced. You’ll need to implement a separate logging solution within your code to keep track of which steps succeeded and which steps failed inside the code.
A second issue is that technical teams don’t always have delivering businesses value as the number one priority. They may choose to automate processes based on their own criteria, (e.g. simple processes, or processes that cause the least amount of headaches technically), which has low ROI and weakens the value proposition of RPA as a new endeavor to the company.
The Right Mix
The right answer lies somewhere in between. High performing teams tend to focus on having team members coming from the business itself, but with some technical teammates from IT who can help them overcome difficult technical problems.
