A process model is a phenomenal tool for analyzing and isolating problems in workflow. Obviously, the ultimate outcome of the analysis will be a set of requirements that any solution has to meet to eliminate the problems and/or some Quick Fixes that will temporarily alleviate the symptoms. Failing that, the requirements can at least define how the future solution has to minimize the impact of problems that may be out of your scope to solve.
The technique we introduce here is an extremely simple concept – but its impact can be overwhelming. We have used this technique in Requirements Gathering Workshops for many organizations around the globe and the reaction is always exhilarating. When the participants actually SEE where the problems are caused and what their impact is, they get excited about the concept of using a process model before they make any changes to their workflow. We will share a true story that drives that point home in a later post.
So How Does the Problem Statement / DFD Overlay Work?
Obviously, you need three things to identify problems on a process model:
- A process model at the appropriate level of detail
- A list of “problems” that may or may not be associated with the depicted processes on the diagram
- A group of people who are actively involved in and understand the process, the process model, and the listed problems.
Since a lot of business problems are actually related to data issues, we recommend using a data flow diagram for this exercise as opposed to an activity diagram. We will explain the rationale behind this and compare the merits of these two modeling techniques in a separate post.
Remember, the only symbols we allow on a DFD are the “roundtangle” representing a function or process, an arrow representing data in motion, an open rectangle representing a “data store” or data at rest, and a square (with or without a shady side) representing external entities. By definition, the external entities are out of scope of your project.
A Problem Statement List
As far as the problem list goes, we highly recommend applying “Gaus/Weinberg Problem Definition” augmented by “Aristotelian Problem Symptom Reduction” to create your list. If you use any other technique, we strongly suggest that you make sure to remove everything that is “Out of Scope”, all “solutions in disguise”, and all problems that are really symptoms of listed problems before you try posting the problem numbers on the diagram.
BTW, the easiest way to recognize a “solution in disguise” is if the “problem statement” contains a phrase like “We don’t have …’”, “We need …”, “There is no way to …”, or something similar. These statements define potential solutions to a problem, not the actual problem the proposed solution would solve. The question is not whether the proposed solution is good, bad, or indifferent but you really need to understand the problem before you select a solution.
Where Could the Problem be Caused?
The purpose of the exercise is to determine where the problems are caused and where the impact is felt, not to decide how to solve them. If you include potential solutions, you will falsify the picture. It is also important that the problems are numbered and that the numbers are identifiers (meaning you should NEVER renumber your problem list once you have started this activity or the relationship between problems and processes will be lost).
If the group that is going to perform this activity is not the group that created the DFD and the list of problems, be sure to review the problem statements with them to ensure that they all understand what the problem really is. Also review the rules governing a DFD immediately before you start the activity. Remind them that
- external entities are truly out of scope for your project
- processes transform data, meaning the data coming out has to differ from the data going in
- data, like water, flows in one direction only
- data on a data flow or in a data store cannot change without a process
What you are going to do is write the number of the problem on the diagram wherever the group feels it COULD be caused. Explain that any given problem can be related to a process if errors in the process could cause the problem. It could be related to a dataflow (if the data on the flow gets corrupted or is not available when it is needed). The problem could also be caused by a data store that does not contain current, accurate data at the time it is accessed. Emphasize that the problem should only be assigned to an External Entity after they have exhausted all other possible locations on the DFD.
One Problem At a Time
Once the stage is set, the process really is simple. Take one problem at a time. Ask the group where that problem is located on the diagram, meaning which process, dataflow, or data store could cause it. A strange phenomenon happens when you try this. People who are very familiar with the process are most likely to point to one or two processes, dataflows, or data stores on the diagram and indicate those as the source of the problem. All too often, these experienced SMEs have a preconceived notion of the cause of every problem whereas they are subject to ignore other potential causes. If that is the case, we recommend challenging them to explain why the problem could not be anywhere else.
Those who know less about the process are more likely to put the problem in many more places. There is nothing wrong with that result, either, they are simply indicating their insecurity. In this case, we suggest asking these SMEs to explain HOW the problem could be caused in each area they identify. Members of the group with more knowledge about the process have to then explain how that problem could not possibly be caused there or accept the location as a possible source.
Keeping the Results Visible
Once the group is satisfied that they have identified all of the potential causes of that problem, move to the next problem on your list. Obviously, it is possible that someone will jump back to a problem already addressed to add it to a hitherto unidentified process, dataflow, or data store, There is nothing wrong with that, the goal is to get as complete of a picture of the potential causes to each problem as possible in the allotted time.
As the work progresses, you will typically start to see areas on the DFD where problems seem to congregate. If any area starts to become overshadowed by the problem statements surrounding it, that indicates an area that is sorely in need of further analysis OR that you do not have anyone in the group who knows enough about that area.
Once you have exhausted your problem list with the exercise, we recommend letting the results sink in to all participants. If you have the technology, create a poster-sized printout of the diagram with the list of problem statements and hang it on a wall in clear sight of all participants. That visible representation of the process and the problems can go a long way toward identifying the right requirements for improving the business process.
Once you have a list of the requirements for change, you might even consider performing the same activity with the numbered Requirements Statements and comparing the two models. This will help you determine before you spend the resources to create the solution whether the defined requirements will actually solve the identified business problems. That outcome alone could just pay for the entire project.
