How to Use Process Decomposition Diagrams in Your Business Analysis Report

The process decomposition diagram (often called a decomp) explains the breakdown of processes within a project or business area or functional area. The purpose is to show all the processes and identify relationships and dependencies among them. Note that a decomp doesn’t drill into the how; it merely outlines the what.

The process decomposition diagram actually functions very similarly to an org chart in that the processes in this diagram relate to one another like the people on an organization chart relate to each other: Just as all the workers reporting to one manager make up all the work under that manager, all the processes under a higher process make up all the work of that process.

Processes that have processes underneath are called parent processes. Processes that report into another process are called child processes. Designating parent and child processes follows a couple of guidelines:

• If you break down a parent process, you must break it into at least two children; otherwise it’s not a true parent.

• All the child processes together must completely describe all the activities in the parent process.

The diagram doesn’t follow any defined sequence. For instance, you don’t have to check the weather before you plan the flight. Similarly, you can check the weather in any of the locations in any order; you don’t have to check it from origin to en route to destination because bad weather at any point along the route prevents you from flying that route.

Credit: Illustration by Wiley, Composition Services Graphics

Here are some times you can apply this technique:

• When you’re working on a large project and need to understand the size of the work effort: Knowing all the processes you have to document can help.

• When you’re validating with your stakeholders that you have captured all the processes you’ll document: Stakeholders can very easily see whether you’ve missed a process.

• When you’re eliciting processes in scope from your stakeholders: The stakeholders are able to interact with a diagram structure they’re very familiar with (in the company’s org chart).

Some pros and cons to this technique include the following:

• Pro: The decomp diagram is useful on larger projects (those with more than five processes to study and document) because it gives you a snapshot of the big picture. On a large effort, it is easy to forget which parent each child process belongs to and how each child relates to each other. This opens the door to repeating processes for one or more parents.

• Pro: It’s a great tool early on in the scoping phase because it gives you an idea of how many processes you have to define, which is important for time and resource estimates.

• Pro: It’s a great technique to get your stakeholders involved in if you have sticky notes handy. Give your stakeholders the scope of what you’re decomposing and a pad of sticky notes, and have them write down the processes (one per sheet) and then post them on the wall.

• Pro: Stakeholders can use the diagram to find missing processes.

• Con: Stakeholders may get caught up in how a process is performed rather than what’s being performed.

• Con: The diagram doesn’t show solutions or sequence of processes. Let your stakeholders know you’ll get there. First you have to make sure you have defined them all.

Always remember to be flexible! If your stakeholders really want to talk about sequence, let them go there. On projects where stakeholders work better talking about the details, Kupe discusses the details and then starts circling steps in a process to identify parent and child processes to build the decomp.

How to create the process decomposition diagram in business analysis

1. Choose one of three ways to build your decomp: top-down, bottom-up, or event-driven.

   That’s right; you can use three methods to create your diagram:

   • Top-down: Start with the high-level processes (requirements) you identified during scoping if you have them (if you don’t, elicit them from your stakeholders). From there, keep drilling down until you get to processes that contain a how; that’s your stopping point.

   • Bottom-up: Think of all the detailed tasks you have to do in the area of study (or scope) and then find common groupings. When determining the groupings, a process may fall into different headings; the goal is for the team to determine the best approach. Remember, what you want to do is make sure you don’t miss any processes.

   • Event-driven: Think of all the triggers (directives that lead to a series of actions) and the tasks that follow.

2. Take notes and make a rough sketch.

   Remember a great technique is using sticky notes to build this diagram.

3. Build the actual diagram and validate it with the stakeholders,

   

   Credit: Illustration by Wiley, Composition Services Graphics

How to document the processes for business analysis

When you have your decomposition diagram created, you’re only halfway done. The diagram shows you the processes, but you still have to actually document the details. For each process, you have to define what attributes and information make up each process by answering questions such as the following:

• Who are the external agents involved in the process? Who currently performs the process today? How do they do it? Who uses the output of the process?

• What causes the process to start? What is the trigger?

• What happens after the process is complete? What are the postconditions?

• What data does the process use? Who creates the data? Is it created, read, updated, or deleted?

• How often is the process performed? How long does it take? How efficient is it?

The company’s culture determines if, how, and where you document this information, but if you want a starting point, you can download the Requirements Package Template.