RPA Top Tips: Discovery and PDD Writing

As those of you who are familiar with Robotic Process Automation (RPA) projects are aware, there are several phases to work though before launching a Bot. The RPA journey begins with the Discovery Phase, which culminates in the issue of the Process Design Document.

The importance of the Process Design Document (PDD) cannot be stressed enough as it the record of steps currently performed as part of the candidate process chosen for automation and its companying rules, as well as what these steps will be after automation. Done properly, it will instill confidence that the candidate process is understood and will be correctly automated to achieve their end requirements.  The PDD serves as the handover point from the Business Analyst to the Development Team to move into Solution Design and Build.

Torch Solutioneers™ top 5 tips for a successful Discovery Phase and PDD writing are:

1. Keep the Discovery phase short and sweet
Delays are the curse of any project and dragging projects out removes the wind from your sails.

Keeping the Discovery to two weeks allows for people to find time in their diaries while starting the project at a decent pace and maintains the momentum. Everything is still relatively top of mind for the writing of the PDD and the project remains a priority on peoples’ minds.

 

2. If you can record it, it can be believed
Recording the candidate process accurately is an absolute must during Discovery. In addition to being able to refer to a recording at any time, without the delay of waiting for a follow-up email, having the customer share their screen while going through the process is invaluable. This is something that has been enhanced by meeting remotely and using Zoom to share and record the actual work when it happens. Some RPA software has the ability to do process mapping from recordings, making the PDD documentation even easier.

 

3. Keep it simple, …
RPA is still a relatively new concept for the Medium to Large enterprise market, and like any business tool, it comes with its own terminology. It can be easy to forget that not everyone knows all the acronyms and concepts when you are emersed in something daily. Overwhelming a customer with highly technical language will only delay PDD acceptance.

4. Getting your point across
You can’t replace a manual process with a Bot unless you have a clear understanding of what that process is, and you can’t be sure you’ve got it right until your customer confirms it from the PDD.  Having a visual and text breakdown of the process, both As-Is and To-Be, ensures your best chance of getting the concept across minimising the change of misunderstandings and possible redesigns or even worse, wasted developers time on re-dos.

 

5. Let every proceeding project improve the next one
Use the learnings about streamlining your Discovery and improving the clarity of the PDD by actually doing something about them, and not just talking about them at the end of a project.  We do a monthly retrospective to talk about the learnings from each project and improve. Add helpful hints into your PDD template as you go so that they are there for next time.

Make note of customer feedback, and don’t forget to check in with your developers as well as they use the PDD too. Setting up a good Discovery and PDD will make the Build phase of the project that much easier or more efficient.

As with many “Top Tip” articles, these may all seem to be obvious. The real test is moving away from the “of course I know this” to “I have done this”.

Are you up for the challenge?

ARCHIVED POSTS