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?

What makes a good PDD?

  • Flow

    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.

  • Screenshot


    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.

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.

Success Accelerator

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.