RPA project results

RPA results depend on target

Results of RPA project or RPA part of wider projects can be measured in terms of:

Effort saving. Effort saving is the most often sought gain, especially in the first projects where the aim is to achieve maximum benefit at lowest cost. Effort saving is typically measured in terms of FTE or % of manual work reduction.
Capacity increase. Transaction volume processed per time unit.
Speed. When differentiated from effort saving, speed up of time spent on a process might not necessarily mean reduction of significant number of FTEs but could lead to other benefits like customer satisfaction or meeting tighter SLA. Speed can be measured as time spent on the process itself or or some idle time elimination, for example, faster time to response.
Quality and reliability improvement. Another reason of automating a process can be not connected to cost reduction at all, but tied with quality improvement leading, for example, to higher customer satisfaction or compliance. Quality improvement can be measured in % of errors.

Target metrics should be clarified in advance and preferably set in contract.

The way how results will be measured: must be determined and agreed in advance with customer clarifying the following aspects:

How results are calculated. If a POC, will measures be based only on the happy path or exceptions will also count against success measures? What is the effect of other activities preceding and following the RPA flow itself on the effort reduction? These questions and the like can undermine the results if they are not properly handled. For example, you might count how long the RPA flow built based on the described scope takes to run and compare this time to the time of original process. However, customer might add in the time that it takes to manually process exceptions and get a totally different figure.
Acquiring actual/production data in test systems. What data you are testing on? is it actual, copied from production system? is sufficient number of records available in the test system that covers all the intended scenarios? Cases are known when lack of actual data in the test system made it impossible to conduct UAT and properly demonstrate the functionality built within POC to stakeholders, ruining success of the implementation.
Planning UAT phase. On what data is it done? what test scenarios it covers - are the scenarios agreed by customer? who conducts it? If users, when and for how long are these resources committed? Are the users trained to handle the flow?
How results are presented. Live demo, video, report with statistics from UAT phase, deck with corresponding graphs, etc