Our best RPA engineer at Offshore almost quit! Here’s why.
One of the first things we did when we started Accelirate was setup an offshore delivery center and hire Perdie, the best RPA engineer out there. Having built successful technology offshoring companies, we were eager to apply the cost-arbitrage model in RPA as well. (What can I say, when you have a hammer everything is a nail)
A few weeks back, when Perdie called me to inform about his decision to quit, he was quite direct, he just didnt have enough exciting work in his plate. He complained that all the action was onsite, and he hardly got any significant projects assigned. Why was our most qualified engineer so underutilized? Perdie it seems was well prepared and had some notes to share:
- In his first week, we got Perdie excited about this upcoming project within the customer service department of one of our clients. However, before Perdie could start, one of our onsite engineers completed the much-needed bot in 4 hours. Perdie was still involved but only to the extent of ensuring the bot is running 24/7 for the next few days processing a backlog that the customer service team would have taken weeks to works on.
- The first project that Perdie finally got to work on involved an intricate cash reconciliation workflow. Perdie even put his work-life-balance principles aside and stayed late to work with the SMEs in their morning to better understand the process. 2 weeks, a frustrated Perdie and a few annoyed SMEs later, we deployed our onsite engineer to whiteboard process and design the bot and the end-user experience in a couple of days. The engineer than went ahead and build the bot in another week leaving Perdie to support the operation of the bot in our night time.
- The last project was the final straw that broke Perdie’s back. The client engaged us to automate a complex process on a tight budget. While the client provided his SMEs and an experienced Analyst, he requested we develop the Bot offshore. Proper methodology was followed, appropriate signoffs were made and very soon our Perdie was happy to finally write some code and build his bot. Things went smoothly even when we were in the first few days of UAT. But then there was this one activity involving a series of calculations on which the SMEs and end users just couldnt agree upon. In a classic example of the kid’s telephone game, the SME said something, the analyst assumed something else and Perdie would deliver something totally different. They persevered and delivered the project but not having all three in one room resulted in a 10-week project taking 15 weeks. It would now take the Bot
While above challenges are not new with offshoring, what is it about RPA projects that this happens more often?
- Rapid changes in today’s business environments, tighter coupling with business users, lean delivery timelines and smaller teams are factors that make RPA engagements unique.
- Communication is typically with the business users who have very little time and requires personalization of relationships to foster quick resolutions which can rarely happen from a remote location.
- Cost savings gained can quickly erode due to the communication and productivity losses associated with the offshore development model.
Reading through Perdie’s notes one can only sympathize with him. So, given the above factors is the role of the offshore RPA Engineer on the verge of extinction?
By the way, Perdie still works for Accelirate, and is still one of our best RPA engineers. He and his team work on more strategic initiatives of developing new RPA frameworks for our or Client’s COEs as well as supporting engineers and infrastructure during our off hours.