RPA – Proof of Concept (POC) or Proof of Value (POV)? Who cares, just get going! Part 5 of 5

Is now the right time? There is no shame in not starting an automation program at this moment in time if it will fail. Waiting for the right moment may be the better way to proceed, to ensure your program is delivered successfully as opposed to starting at the wrong time. A POV | POC offers the opportunity to test if this is indeed the right time to begin.

“Successful automation projects often have one thing in common, the relevant teams are aligned and bought in. It is difficult to progress beyond a POC or POV if the business department, IT, governance, and finance teams are not aligned with the vision and objectives driving an automation strategy.”
Mark Barrett, Director Automation

Team Build: How might you build a cross functional team to build RPA to scale? An automation developer does not make an automation team nor an automation program. There are many different skills and roles needed to build a POC, never mind a successful automation program.

I’ve now met 150+ RPA developers but these are the 20 signs of a ‘truly exceptional’ RPA developer!
Designing the right operating model for your automation centre of expertise by Joshua Biggins IT Strategy | Business Transformation |

Developers, project managers, evangelists, automation leads, business analysts, program managers, Agile Scrum masters, AI specialists and other roles are required to make automation work.

Vendor: From a vendors perspective a POC | POV is a foot in the door to allows a vendor or System Integrator to determine if the business is serious about automation. Selecting a platform vendor to engage with is not an easy exercise.

There is a so called top ten, but there are 50 plus RPA vendors whose platforms may work in your organisation. During a POC it is recommended that you try more than one tool, as not every tool will work with your applications. Don’t simply rely on analyst reports as your mode of choosing your tool. Not all vendors put forward their product for vendor scrutiny as this costs a lot of money and time. Take your time when choosing, as the right platform will support your program, whereas the wrong platform could sink it.

“Getting the right process for your POV is key, try to keep it simple but with a clear and compelling value. Also establish your vision for automation from the outset as the POV should be the first step towards this vision. Starting simple includes the tooling and partner you select to conduct your POV. Don’t be afraid to start with a simplified tool set and then move onto more feature rich tools once the value is proven. Most vendors provide reduced functionality versions of their automation tools that can prove the value of automation, while reducing the risk of failure due to complexity. “
Mark Barrett, Director Automation

Customers please remember that a POC | POV is a two way process. A vendor or SI should be asking themselves a lot of questions to determine whether they should engage or not. For example, does the client have the right people and know how to support your program? Is it worth the hassle of engaging with a client for the money on offer or would it be better to walk away at the POC | POV stage.

“One of the main proof points in establishing organisational buy in and understanding for an RPA project is the automation demonstration or video. This is one of the most effective ways to demonstrate the power and benefit of RPA. This is exponentially more effective if based on your own applications and processes. Keep it simple though, and use tasks or a short process that will demonstrate the potential value of RPA. An experienced partner should be able to guide you through this with minimal cost and effort.”
Mark Barrett, Director Automation

DR BCP and WOW: Businesses need to understand the impact RPA | IA | DA | IA tools might have on roles | DR | BCP plans. A POV | POC gives an organisation time to work with bots so they understand the DR | BCP implications of them. Not only do the automation team get to work with bots, but the business users and process owners get to work with ‘bots in the loop’ also. DR | BCP plans will need rewritten to include bots, so remember to allocate time to include process rewrites.

Do make sure someone in the business understands end to end automated processes, as too often process owners intentionally, or unintentionally, give up control of processes. Over time when unattended bots run processes, it is easy to forget how processes work when the business is no longer touching them on a daily basis. It is sometimes recommended to include break points in processes, even if they can be fully automated, to ensure that the business does not cede ownership and accountability for their processes to an automation team. The business owns the process, an automation team simply helps automate the processes for the business.

“Similar to the benefits virtualisation had on business continuity, making it suddenly cheaper and easier to replicate technology systems for redundancy, automation creates new opportunities for enhanced continuity and recovery. It is worth including the foresight of systems failure or business interruption in the story of your POC, to ignite thinking around the additional benefits automation can bring.”
Mark Barrett, Director Automation

A well crafted POV will take 8-12 weeks. At the end of your POC you should have a well developed MVP that demonstrates the value of your program (or not!). If you have no understanding or RPA / IA then is it recommended that you engage an expert systems integrator to help.

In a large organisation, using an expert consultancy can cost between $30-$60k. However, a POC does not have to be expensive. For example, you might download freeware, buy a Winautomation licence from Softmotive or indeed your intended vendor(s) will often complete a small POC for free.

Pilot Stage: At this point, an automated process is introduced into production for the first time, according to the organisation’s implementation model. This means the organisation and RPA partners apply defined requirements, a detailed solution design, test scripts and cutover/handover plans to the selected process. Pilot performance is monitored in accordance with its exit criteria. In addition, all internal and external stakeholders are surveyed for feedback. This input is the basis for documenting lessons learned and revising methodology and frameworks before advancing to ramp up.

“Check all exits because this application is about to take off. The wheels are being lifted for the first time and all our hard work is flying through the sky. We are being closely monitored on how the systems function because we don’t want to crash and burn when we’re on the long hall flight. The drinks on board aren’t great but that’s ok, we’ll hire a barista and make things better next time. Overall adding to the customers experience whilst on board our aircraft. We learn and improve that continuous iterative approach to product deployment is key to achieving the best customer experience.”
Jessica Levett, RPA Architect

Lessons Learned: The proof of concept phase is the most important part of your program as this is one of the times that you will learn the most. Do take time to document all of the positive and negative lessons learned from the POC so that these are not forgotten.

“Assuming an organisation does go ahead with a proof of value then…..during the development, deployment and production phases make copious notes of what went right and what did not meet expectations. After at least a month of going live, hold a retrospective on the same and try to answer the questions laid out in the first part of this article.”
Kieran Gilmurray, Global Automation Lead

Retrospective: A retrospective at the end of an automation POC is an excellent opportunity to reflect prior to proceeding forwards at pace. It is recommended that RPA programs are built out using Agile or DevOps or a combination of both, and that Agile retrospective ceremonies happen every two weeks. This ensures lessons are learned and brought forwards into the next RPA program phase.

“A proof of concept should complete with an open and honest ‘lessons learned’ exercise. As we know, this exercise examines what went well, what was a challenge, what was the experience like and how would taking a slightly different approach improve matters?

In my experience, a good ‘lessons learned’ process will lead to; changes to the design document framework (PDD and SDD); changes to the inter-department communications that are needed, they should be earlier and very transparent; changes to the development approach – RPA lends itself very well to a test driven development approach; Ideas for the organisation development best practises document. This is super important, and often ignored. If you don’t do this, just wait and see how heavy the future maintenance overhead will be!”
Dermott Caroll, RPA and IA Consultant

Be fully engaged in the POC, even if you have handed it over to a systems integrator who has been has been brought on board to deliver the POC: Regardless of whether a systems integrator is running an organisations POC or not, you need to be intimately involved in every aspect of your POC. An organisation should have; tested the product or products; implemented Agile ways of working; developed a pipeline of processes to kick forward with; started to build a run or playbook; used Design Thinking or Lean for Digital; engaged with CISO and other internal teams; created a video of your win with your happy customer talking to it, and begun to form a communications program having identified your key stakeholders; developed an understanding of the roles you will need in your RCOE and lots, lots more.

Measuring the success of your POC: It is relatively simple to conduct a POC, but measuring and extrapolating the results is often the key issue. Contrary to reports out there, there is no single set of criteria that works for all. Thus, please take one step back and determine what success means to you (Simply ‘cost savings’ is meaningless). Productivity, compliance, system integrations, revenue acceleration, etc. One quick tip is to link it to existing organizational KPIs, because newly fabricated measures often don’t reflect much.

Martin Lau, Global Automation Lead at P&G

Remember that there are multiple benefits from RPA that are not simply financial, some are ‘exhaust fumes’ on the back of profits.

Higher quality work produced by your teams
A reliable software workforce that works 24/7
Improved consistency in outputs
Significantly lower operating costs
Lower workload on staff, leading to higher productivity
Work getting done much faster than people are capable of
The ability to focus efforts on critical issues

Does your organisation run POC | POVs before implementing new technology and if yes, then what are your organisation’s best practice advice?

#intelligentautomation #bots #rpaworks #digitaltransformation #roboticprocessautomation #rpa #cognitiveautomation #digitaldisruption #digitalworkforce #processautomation #digitalfuture #digitalstrategy

Other articles: If you like this article then you may find these eight articles of use too.

If this could benefit someone else tag them and share this.

Free to reuse: We are a community of RPA and Intelligent Automation experts with years of real world experience. We have stories to tell and the scars to show for it. We share our collective wisdom for free to simply provide as much value as we can to you. Therefore, if you want to post this article on your LinkedIn page then please feel free to do so. The more information we share within the RPA community the more likely businesses are to succeed with this excellent technology.

Further Help: If I can help you in any way please do reach out.

Note: The views expressed above are our views and not those of my employer or the employers of the contributing experts.