For business analysts, a Process Flow is one of the most straight-forward models to interpret: Process Step 1 is related to Process Step 2, relating to Decision 3, which leads to either Process Step 4 or Process Step 5. Not much mystery there, right? While the flow may be easy to follow for you, there is nothing easy about structuring these flows in a way that is simple for other people to understand.
Let’s just say you have spent an hour with a subject matter expert (SME) going through all of the ins and outs of a process you want to model. You took great notes on all of the various details and have painstakingly translated each process step into its associated box, each decision into a lovely decision diamond, one connecting to the other until you have a complete model with 30 objects, boasting end-to-end coverage of the entire process. Everything seems to be right with the world, until you sit down with your SME to review your work of art and they can’t make heads or tails of the process you are describing. To them, your Process Flow looks more like a Jackson Pollock painting than the process they spent an hour describing to you. The verdict: unreviewable!

To keep this from happening to your Process Flow, keep it simple! Any given Process Flow should have approximately 7 steps (plus or minus 2); meaning, the overall amount of process steps and decisions should be limited to between 5 and 9 steps. This way, you can start out reviewing a generalized version of a process in the first level of the flow (L1) and dive into the details of a step in a separate level two (L2) Process Flow. Each L2 process step could even have its own level three (L3) process flow related to it, if necessary.  You can go down the rabbit hole as far as you want, but it makes the most sense to stop at the level of detail necessary to start pulling out your functional requirements. As we saw above, there is such a thing as too much detail!

While the L1, L2, L3 Process Flow structure sounds obvious enough, in practice, this can be really tricky to build. After struggling with this myself, I was given the following sage advice that I found really helpful: Imagine each process step as a person doing a job.

Let’s say, for example, we want to model the process a magic shop goes through to price a pair of wacky X-Ray Glasses (Hey, at least it isn’t another example based on a retail website, right?) First, we need to understand the cost associated with making these glasses (Production Costs). They aren’t selling these X-Ray specs for charity, so they can’t charge less than it costs to make the glasses. Next, they need to understand what your average-Joe magician might be willing to pay for the pleasure of seeing through walls (Demand). Are there comparable X-Ray Glasses selling elsewhere? How much demand is out there for goofy glasses? Finally, the magic shop needs to be able to determine how many pairs are currently collecting dust in the storeroom (Available Stock). If they have a bunch lying around, they had better be priced to move.

So, based on the above scenario, it is clear that the magic shop has a variety of questions associated with each aspect of the pricing process. Instead of attempting to capture every aspect of the process in a single flow, imagine each step (Production Costs, Demand, and Available Stock) as a person. Start out by imagining each step of the above three step pricing process as a person doing a specific task.

As you build your L1 flow, imagine yourself going to each person and asking for pricing information: Siegfried knows the production costs, Roy knows the amount of customer demand that’s out there, and Harry H. knows how many X-Ray Glasses are sitting around in the stockroom. This would represent your L1 process flow.

To get to the L2 process flow, imagine yourself asking Siegfried how he arrived at the production cost? He might say, “Well, the mini vacuum tubes cost 300K, the tungsten anode costs 46k, glasses frames cost 10 cents. Add them all up and you have X-Ray Glasses.” This information would constitute your L2 process flow.   If there are sub processes within the L2 flow, model them in a L3 flow, and so on, until you have a series of models that has enough detail to identify requirements.

When the time comes to sit down and review these flows and the associated requirements derived from the flows, it will be easy to step through the overall L1 flow first, and then visit each step in greater detail, using the L2 flows. Trust me; your stakeholders will thank you for not having to rely on their X-Ray Glasses to interpret your Process Flow.

Want more requirements development techniques? Check out ArgonDigital’s comprehensive list of business analysis tools online.