The Pro's and Con's of PDD

Help
1

On a current project there is a debate whether our requirements should be documented in the PDD format. There is a thought that PDD is too “waterfall”. Note that I disagree. Even if “requirements” felt like waterfall the dev and project itself can still be agile. As such I would like to compile a list of PROs and CONs. Has anyone ever compiled such a list? Any thoughts?

2

I see PDD as a document which RPA team creates as per their understanding of the process.

PDD once is finalized is to be reviewed by the business holder so that they can give you a signoff saying yes , you have understood our requirements correctly.

I see this as a Pro

–
Mukesh

1 Like
3

As far as i know user stories for scrum …can be obtained from PDD files.

1 Like
6

Hi @jOeyO

About the PDD creation, I also see it as a document which BA’s and solution architects get involved in documenting the process that needs to be automated. This is what is later used by the RPA team and the solution architects to build the SDD and to continue with the development.

I personally do not agree on the fact that PDD is “waterfall”. We should consider this as a part of the entire project, which is usually agile. We really should not think that each part of it waterfall and the next part is agile etc.

Pros of creating a PDD is:

  1. Helps to get an idea about the entire process in every possible detail
  2. Helps to keep the team on track through out the entire life cycle of the project
  3. Helps team mates to decide the scope of work, and to decide how the process should be broken down into smaller segments when developing
  4. Also acts as a training material for new/ existing team mates
  5. Keep track of the requirements that change over the time
  6. Conflict resolution is a good advantage. This helps to clear out doubts that pops up time to time

Cons:

  1. Time consuming

These are some points that I can think of :slight_smile:

6 Likes
7

I completely agree Lahiru.

In addition to what you’ve mentioned above, it’s extremely important to capture potential system/business exceptions and how your customer wants them handled (in writing). We wouldn’t want to make an incorrect assumption that “oh they don’t need to see this” or “I can just retry this” without understanding and documenting the potential downstream impacts.

Also, if your team has to come back to this automation in a few weeks/months/etc, it will save you a TON of time not to have to figure out exactly what the process is doing and why it’s taking certain actions based off the automation alone.

I think one of the biggest benefits is the reduction in time spent on future updates/enhancements because you can quickly read through your existing documentation and make adjustments where needed.

5 Likes
8

Hey @chenderson

Good set of points bro!! :smiley:

5 Likes
9

Thanks everyone for your feedback!

2 Likes