Getting to Production Fast with RPA

Okay, exit real quick. Cool. (silence).

So thanks, Steven, for joining us this morning on YouTube Live. Today, you are talking about getting to production fast with RPA and the appropriate corners that you can cut and the corners that you should not cut. Why don't you tell us a little bit about yourself to start, and then we'll jump right into the presentation.

Yeah, sounds good, Krista. I've been at BP3 for three years working as a software engineer, sending projects to production in custom app development, BPM and now RPA.

So you took a project to development or to production, from development to production within a couple weeks recently, and so these were the lessons that you learned, right?

Yes, Krista, and we just kicked off another one with the goal of, again, getting a two week from drawing board to production.All right. Well, tell us what we need to know.

Sounds good. So how to get a bot to production time now. There's an old adage in software that you can have, fast, good or cheap. Pick two. If you scale your team, utilize the right people, the project might cost more, but the quality of work will be higher and the ramp up and development time faster. If you cut corners and features, you can get into production faster with a different solution, but a solution. What happens when you're fast, & fast becomes the leading motivator? What happens if it's an emergency? In the current climate, many of our companies are just trying to get solutions out the door, because every day that passes is incredibly costly. This was the case for both of the bots that we just talked about. So what happens if you fall into the third category? How can you prioritize fast while controlling costs and quality as much as possible?

Prioritizing fast is all about who you are working with. Start by building the right team for the job. It's about knowing what corners you can cut, what features must be in the first go live, and what can be set aside to follow up releases or work arounds. Prioritizing fast means iterating heavily and shortening the feedback loop. Time now projects are going to resemble a drastic form of agile, as opposed to a more traditional waterfall approach. Moving fast also requires solid engineering practices. With a high number iterations, keeping technical debt to minimum and building it the right way the first time will allow the solution to better respond to changes in defects.

Prioritizing fast is all about your team and building your team properly. Your team should consist of an executive to make decisions and provide cover. They don't need to be in all the meetings and do not need to be involved in development, but they need to be able to say yes and sign off on decisions and changes fast. Your tiger team will also need subject matter experts. For RPA, they should be people who currently perform tasks and people who are able to explain why things are done the way they are, because that will probably change. Your tiger team will need a project manager to act as a traffic cop, keeping everything organized and providing updates and documentation to all interested parties. This will also reduce the workflow or the amount of work for the developers.

Finally, your tiger team will need senior developers who know the tools they are working with, the problem space, and who will be able to identify what can be cut and what can't from an engineering perspective. But beyond all of that, your team needs trust; trust that everybody on the team knows what they are doing, and trust enough in each other to check egos at the door.

Cutting the right corners and iterating heavily. Projects that need to be launched now have plenty of opportunity for rough edges. There's a reason that this problem became a priority and could not continue the way it was. An incomplete solution today, a more complete solution on Friday, and a complete solution in two weeks is better than just a complete solution in two weeks. With RPA, the more use cases it can handle now, the later the workload on the manual team and the more time they will have to address the cases you haven't covered yet.

‍
For each step in the process, look at how much value provides and how much time it will take to automate, and how much time is lost if it isn't automated. If the problem can also be handled a different way outside of RPA, manual tasks or batch processing can be used as a stop gap. And continue to iterate heavily. Never stop developing and push code in completed chunks to users as soon as possible. For every bit that is completed, passing it up earlier gives the users greater ability to give feedback. Subject matter experts are already on the tiger team, so utilize them to help. They can find defects in cases the developers miss and free up time for developers to work on what's next or solidify what they have already built. With RPA and attended RPA, identify the low risk errors and put an error handling, so you can come back and lock it down…