You’re ramping up on a new project and you want to better understand how the business operates. Or maybe you’re trying to explain the flow of events when using a system. Or you could be trying to analyze who does what and how they interact with each other. These are all possible scenarios where adding some sort of diagram will help to clarify what you know and help you determine what might be missing.
There are various types of diagrams and techniques, some with more formal usage conventions than others. And there are some pretty slick tools that can help you simulate processes…but what if you don’t know how to use the formal techniques yet? What if you don’t have fancy tools?
You can still be very effective using two basic shapes and some arrows.
With a rectangle and a diamond, you can clearly visualize just about any series of steps whether they be business process, system flow, or data flow between systems. (Yes some of you are cringing because you would use different shapes, but hang in there with me. A lot can be communicated with just these two shapes; and even if this picture was only worth 700 words (instead of the proverbial 1000 words), isn’t that better than no diagram at all?) And when you connect the rectangles and diamonds with arrows, you are able to represent the order, or flow, that the various steps must follow.
Note: Some of these diagram examples are large and I had to shrink them to get them to fit. To see the diagram in more detail, just click on the image and you’ll be able to see it at full size.
The rectangle is the meat in this meat and potatoes combination. This is where the action happens. Whether you’re trying to see major areas of functionality and how they relate to each other, or very detailed steps for proceeding through a process, each piece is represented by a rectangle.
And you’d put the words right inside the rectangle that it is meant to represent. So if you have a general order processing system you’re wanting to understand, you might have separate rectangles for Ordering, Billing, and Shipping.
This is where the arrows come in. By connecting each box with an arrow, you now clearly see which comes first, and there is no confusion that Billing comes before Shipping.
This is a very high level process flow, and you would want to break each of these down into more detail in additional diagrams. These additional diagrams are your sub-processes, and breaking down the processes in more and more detail is called Process Decomposition. (I can’t say that word without thinking of compost, but that’s just me.) So for example, as you start breaking down the Shipping process, it might look something like this:
As you can imagine, each of these could now also be broken down into even more detail, further decomposing the process.
What happens, though, if your process has some options or variations? What if there is some decision that has to be made in order to know what the next step is? This is where the Decision Diamond comes in handy. The diamond provides a juncture where you can have more than one possible next step. Think of it as an intersection and you have to choose which way to turn to keep going.
Just like the rectangle, the decision you have to make is written right inside the diamond, and is usually written in the form of a question. There are a couple ways to think about wording the diamond.
A very common decision diamond is one where the possible answers are Yes or No. In this case, you would have one arrow coming out of the diamond that tells you where to go if the answer is Yes, and a separate arrow coming out of the diamond that tells you where to go if the answer is No. (Note that the Yes and No are written right on the arrow itself.)
If we expand on the Shipping example from above, what happens if you don’t have the item in stock? Then you wouldn’t be able to move simply through packing the order and loading it on the truck. There is another possible alternative here. One way you might see this represented then is as follows:
One thing you may have noticed is that I added an additional process rectangle before the decision diamond to “Check Inventory”. Remember I said that the rectangle is where all the action happens? Well…work doesn’t happen in the diamonds. The diamond needs some information going into it to help you determine what happens next. It is just a directional sign. So before the diamond can ask “Inventory in Stock?”, the process of Checking the Inventory had to occur.
Now, in order to complete this Shipping sub-process, we have to resolve what happens for those orders where we needed to order more inventory. At this level of detail, I might just use an arrow to return back to the “Check Inventory” step. While I might have to wait some period of time, ultimately the next thing I’m going to do is check inventory again, and hope that next time I get to the “Inventory in Stock?” diamond I can answer Yes and proceed to pack the order.
Yes, you can loop back through this process multiple times, and unless you call this out in the diagram (and/or supporting business rules) this loop could go on forever. (So, you probably wouldn’t really leave it like this.)
In addition to a Yes/No diamond, you might have a decision diamond that is not answered by a Yes or No. For example, maybe I handle the actual mailing of the package differently depending on the shipping method. If the customer selected priority shipping, I put the box in a stack to get picked up for the airport. If the customer selected regular shipping, I load it directly on the truck. And if they selected Pick Up, I give the box to the will call department. The resulting process might look something like this:
There are no rules regarding how many options can come out of the diamond, but just keep in mind that these should all be paths based on a single decision. If there is more than one question involved, consider breaking it out into multiple decision diamonds. For example:
Bonus: The Pill
One bonus shape to help you clearly define the beginning and end of a flow: You can use the Pill shape to represent the start and end points. Sometimes there may be multiple points in the flow where you would consider the process complete. Maybe not all of the steps are required all the time so you can represent when the process is considered finished. Using a Pill with the word End in it, lets you (and anyone reading the diagram) know that this is an acceptable end point. You always start with the Start Pill, and you must end on an End Pill. (Don’t leave any paths in limbo.)
Documenting the Diagrams
The cool thing about these basic shapes is you can use these on whiteboards when facilitating meetings and just draw them. (Or use a big sticky note to represent each rectangle and draw the arrows in between.) But when you want to include these diagrams in your documentation and save them for the future, you’re going to want to create them electronically. (Taking a picture with your cell phone is a great way to capture the results from your meeting, but that’s not what I mean by creating them electronically.)
Most companies these days have the Microsoft Office suite of products, and if you have the right version, you usually have Microsoft Visio. Visio has become the de-facto tool for all sorts of diagrams and it has MANY shapes you can use for diagramming including all of the ones mentioned above. You are able to drag-and-drop the shapes right onto the page and connect them together with arrows. (So many tips to share for using Visio – which I’ll put together in future posts or a whitepaper.)
While definitely not desired, if you don’t even have Visio and just need to knock out a very basic diagram, (I cringe even suggesting this, but…) you can use the Drawing tools in Microsoft Word to draw out some rectangles and connect them with arrows. The diamonds might take a little work, and I surely don’t recommend this as a first option. (It shouldn’t be hard to convince your company to invest in Visio as a basic tool to be able to get your job done, so please go that route. You can even download a free trial version from Microsoft in a pinch.) But I did want to point this out in case you truly, absolutely don’t have any other option.
In future posts, I’ll continue to build upon these basics to give you more tips and techniques for using diagrams to help with your analysis work. It’s not only a great way to communicate information easily, it honestly helps you evaluate and analyze if you’re missing anything. When you diagram out any statement that says “If x, then do y”, this should be an indicator that you need a decision diamond to ask if you have x. If yes, do y; but what if the answer is no? Now you can follow up and get that missing piece of information.
What kinds of diagramming questions do you have that I can help you out with? How could you add diagramming to your analysis and documentation to help clarify the expected actions and behaviors?