We recently discussed use cases and their place in the custom software development process. In this article, I’d like to delve into the workflow diagram and why I feel it plays a vital role in making sure complex development projects proceed efficiently and end successfully.
Again, to make sure we’re on the same page here, let’s settle on a definition. This one from SmartDraw does a good job of making it clear:
A workflow diagram depicts a series of actions that define a job or how work should be done. A workflow diagram visualizes how tasks will flow between resources, whether they’re machines or people and what conditions allow the sequence to move forward.
So, essentially, we’re talking about a flowchart. But this flowchart is specifically designed to map out each unique business process or subprocess that the software being developed needs to affect in some way. The main purpose of creating these diagrams – especially early in the development process – is to ensure that everyone on both sides of the project understand and agree to what the current process is and what the ideal future process will be.
Once that’s accomplished, it allows us as developers to analyze the differences and determine the most effective way to make the software do what the client needs it to do.
Isn’t a workflow diagram just like a use case?
While workflow diagrams and documented use cases will often overlap in some of their details, the purpose and value of these two kinds of documents are very different.
The use case allows us to dive into why the user is using the system. What they want and need to get out of their effort, and – by extension – what options, features, and design elements will most effectively support that user experience.
The workflow diagram, on the other hand, focuses on how the user and the system (or the system and other systems) will need to interact to accomplish the ideal outcomes described in the use cases.
This subtle difference actually reveals a lot of information that we can’t glean strictly from examining use cases.
Example of a generic workflow diagram
Sample workflow diagram for a manufacturing company (via Wikipedia)
This image provides a very simple example of what a high-level workflow diagram may look like for a custom software development project for a manufacturing company.
As you can see, each major business process that will be impacting the system (or that the system will need to either read from or write to) is represented using various colored shapes in the middle portion of the diagram. Then, around the outside in blue callouts, each element of the process is labeled and defined.
This example offers an extremely minimal view of a simple ordering process, but it helps illustrate the balance we often need to strike between detail and simplicity. While “less is more” applies to many aspects of software development, this one included, a workflow diagram that is too short on detail and explanation won’t be useful at all.
If we were to create a diagram at this level of simplicity, it would likely be a parent diagram for presentation purposes with each subprocess broken down in greater detail on subsequent workflow diagrams.
Why a workflow diagram is so vital
When working on large, complex software development projects – especially custom applications designed to support multiple backend business processes – it’s vital to ensure that all the stakeholders are on the same page as early in the project as possible. We need to make sure we (as developers) fully understand the current process in all its detail, as well as the ideal process the client has in mind.
Only when both are fully understood, documented, and agreed upon, can we move forward with confidence knowing the application we’re developing is going to successfully accomplish the client’s every need and desire.
Creating use cases, workflow diagrams, and other necessary planning documents early in the process helps us avoid needless delays and rework later on, generally speeding up the entire project in the long run and often costing less as a result.
They also serve well to clearly highlight bottlenecks in the current business processes, inefficiencies that can be resolved, and offer a significant help to the client in terms of informing change management that they’ll need to take on as the new system approaches launch.
For all these reasons, we tend to place a very high value on including workflow diagrams in the initial planning phase of every complex custom software development project. We feel it’s a vital tool we can use to arrive at a better overall product in the end.
