I have over 30 years experience in IT, working as a technical writer, a process analyst, and a business analyst.
Workflows are Us
When I work with processes, I usually do a a flowchart to study the existing steps in the process (some call this an “As-Is” flow). I then study the flowchart to identify duplicated actions, missing actions, etc. Once I have the list of gaps, I do a new flowchart that includes the changes I found that were needed (some call this a “To-Be” flow).
This is how processes get improved, and sometimes how we start the software creation process. The high-level flow charts are invaluable.
Swim Lane Diagrams
As part of the Business Analysis process, we often use “swim lane” diagrams which are flow charts showing who does what. The horiontal rows show which part of the flow is done by which group.
Here is a great example of making and delivering a pizza, done as a swim lane diagram:
Notice that these lanes are places and activities not people. Most of the swim lanes I do identify the person or person(s) doing something. They show ownership of a step/task.
Building a swim lane to show a process will sometimes show you how broken it is! Or how overly complex. But it also could be the order of your lanes. The process will reveal which lanes should be in what order.
Process Flows and Requirements
Anyway, for some reason, I just LOVE process analysis. I think it just feels good to me to nail stuff down and identify gaps and make stuff better.
Process flows are also used to identify which things or tasks need requirements written for them, and sometimes the task boxes are numbered so that a requirements document can reference them.
I have done this kind of work off and on for many years and it sort of rubs off on you, and you tend to analyze how things are done in the real world too. I have a background in Usability and Human Factors, so I am often evaluating how things are done and how…
