The Process Definition Document
What is a PDD?
The Process Definition Document (PDD) is the most important element of the Define phase and it provides the foundation on which to build an automated solution. The PDD is the document that describes the manual process with enough precision for it to be used to train a digital worker. It does not describe the future automated process but explains the AS IS process so that later, in the Design phase, an automation scope can be defined and a TO BE solution can be proposed.
Why is a PDD is needed?
- To define the current process.
- Agreement on the process definition is a vital starting point for automation.
- To help estimate the work involved in automating the process.
- A PDD is used to analyse complexity and evaluate delivery requirements, and a poor PDD may lead to an incorrect delivery estimates.
- To enable design.
- Without an accurate PDD automation scope cannot be determined and a solution design to cover that scope cannot be created.
- To assist development.
- Without the correct level of detail, developers will need more help from Subject Matter Experts (SMEs).
- An inaccurate PDD could lead to an incorrect automation that requires excessive correction during testing and implementation.
- As a basis for testing.
- Test plans should be based on the details documented during the Define phase.
How to gather information for the PDD?
Current documentation is always the first place to start when creating a PDD, and potential sources include training manuals, procedural documents and how-to guides. And if the documentation is of a high enough quality and at a low enough level of detail, it may already be good enough.
However, the reality is that the documentation will probably have been created with the human workforce in mind, and as such is unlikely to contain the 'keystroke' level of detail needed by an unthinking digital worker. Potential issues with existing documentation are as follows.
- Outdated : has the process changed since the document was created?
- Inaccurate: does the documentation accurately describe how the process is worked today? If not, then why?
- Imprecise: documentation is often not at the level of detail and clarity required for automation
- Unclear: documentation can be vague and difficult to understand
Due to these possible problems, it is always good practice to walk through the process with SMEs, even if the documentation seems to be of good quality.
Often the best place to find out about a manual process is from the staff currently working it. Simply sitting and watching an SME perform the process gives you the opportunity to:
- Make notes
- At the level of granularity required for an automated project
- Take screenshots or recordings
- With permission from the Business
- To assist or include in the PDD
- Ask questions, such as:
- Do you always do these exact steps for every case?
- What are the most common scenarios you see?
- Are there any exceptions to the rule, any cases that you don't work or pass onto another team?
- Are there any rare scenarios and how different are they?
- Are there any awkward cases that are difficult to resolve?
- How consistent are the applications? Are there ever any strange pop-ups or error messages?
- How reliable are the applications? Can they be slow or do they ever crash?
- Do you see the same amount of work every hour/day/week/month, or are there busy periods?
- When does the work arrive and when does it need to be done?
It is strongly recommended to witness the process being worked by different SMEs. People might work the same process differently and sitting with only one SME raises the risk of documenting an incorrect procedure.
What makes a good PDD?
-
High level flow diagrams
Flow diagrams make a PDD easier to read and understand:
• They enable high-level discussion and evaluation of the process.
• They provide non-developers with an overview of the process without needing to go into the detail.
• Diagrams join the component parts of the process (the keystrokes, the rules and decisions, the inputs and outputs) and illustrate entire scope of the process.
• Diagrams help to ensure the entire process has been documented - if a high level diagram cannot be created then probably there are elements of the definition that are unknown or missing. -
Screenshots
Images of the application undoubtedly make a PDD easier to understand and provide the following advantages.
• The PDD can be followed without needing access to the applications
• Screenshots make it easier to estimate development effor - the number of screens and their complexity can be visualized
• Screenshots reduce ambiguity from the key stroke mapping, especially on complex screens
• Screenshots alongside keystroke mapping reduce the need for SME assistance during development
• Validating a PDD in a walkthrough presentation is far easier with screenshots
PDD Pitfalls
PDDs are not always easy to get right but as mentioned above, they play a critical role in RPA. An incorrect definition will almost certainly result in problems, often costly ones, either further on in the delivery sequence or later when the solution has been implemented into Production. In short, time and effort spent on the PDD is never wasted and the success (or failure) of an RPA solution is founded during the Define phase. However, difficulties are not uncommon when creating a PDD and below are a few examples of common challenges and mistakes.
- Problem: The process is very large and will take long time to document
- Solution: Breaking up a process for automation often makes it easier to document, develop and test.
- Problem: You are constantly finding out about new scenarios every time you watch the process being manually performed. The number of scenarios seems endless and it feels like you are documenting a moving target.
- Solution: Use the 80/20 (or Pareto) principle, where often it can be found that the majority of results can be obtained from a minority of work types. In other words, focusing on the most beneficial scenarios and de-scoping the rest will make the process easier to document without overly compromising the automation benefits. However, make it very clear in the PDD which scenarios are in scope for automation and those which aren't.
- Generalized, high level instructions, where a documented step actually represents a sequence of multiple undocumented steps.
- Vague or incomplete references to other documents or data sets.
- Ambiguous or unclear instructions that could be misinterpreted.
- Instructions that include TO BE 'solutioning' rather than simply documenting the AS IS manual process.
- Missing detail and assuming the reader has the knowledge to 'read between the lines'.
- Explaining only the most common scenarios and ignoring rarer cases and exceptions.
- Diagrams and screenshots that are hard to relate to the textual descriptions of the process steps.
Validating a PDD
It is essential that the definition documented in the PDD is checked and formal agreement is reached in order to conclude the Define phase. Presenting the PDD in a workshop is an effective method for achieving accuracy and reaching consensus before a final sign-off.
A walk-through is a method of testing that a PDD is accurate and includes all the steps required to work the process. In simple terms this is done by treating the PDD as an instruction manual and using it to work the process. Some teams dub this activity as 'PDD UAT'.
Ideally this should be done 'live' with the actual applications, or else it could be simulated. Either way, the document should be analysed and discussed in a group session so that everyone can verify and agree that it correctly defines the current process. In particular, a walk-through is an excellent method of identifying issues such as:
- Any sections that are vague or difficult to understand. If an expert has to explain what the document is saying, then that would suggest the PDD needs improvement.
- Incorrect or questionable procedures. The walk-through may provoke debate as to the accuracy of the definition that the Business will need to resolve.
- Incomplete or missing detail. The walk-through may reveal to the SME that there are gaps in the detail.
- Happy path bias. Often documentation focuses on the 'happy path', where everything works perfectly, but a digital worker also needs exact instruction for the 'unhappy path' when exceptions occur.
It may be necessary to revise the PDD and repeat the walk-through but even so, that would be cheaper and quicker than correcting development misunderstandings or applying fixes to a poorly performing automation.
A less formal walk-through can also be useful at different times, for example:
- When drafting a PDD to check it progressing well
- When reviewing an automation candidate as part of an opportunity assessment
- When briefing developers about to embark on building a solution
- When briefing testers to familiarise them with a manual process
The process definition should be agreed and signed off by the Business to ensure it has been documented correctly. This is a critical milestone in the delivery cycle, bringing with it the following decisions.
- Assurance that the definition is correct
- Consensus that the defined scope is representative of the manual process
- Agreement that the definition describes the optimum procedure for working the process
- Closure to the Define phase and permission for the Design phase to begin
Blue Prism’s Success Accelerator program combines various levels of mentorship and access to our Expert Services, Technology Ecosystem and Certified Partners based on the size and maturity of your digital workforce operations.