There are some unwritten rules that apply to the creation of any process description. Here are the 6 principles I adhere to. What are the rules that guide you?
Process Flow First
Every process description starts with a process flow. If you enter a company aiming to describe its processes, there is always something already happening. Capture that in a flow first and only then add the other details from the process template.
In order to design the process flow, you will need the Subject-Matter Experts (SMEs) who own (or will potentially own) the process. They will provide the know-how on how the process should work and you will provide the know-how on how the process should be designed and connected to all other processes (horizontally and vertically).
A word of caution: do approach your SMEs in smaller groups first or individually, if possible. Get them all in one room only when you have a nearly finalized process flow, which needs polishing out. The reason being that the more people there are in defining a process, the harder it is to reach an agreement and, thus, the longer it takes to finalize the task.
Count Those Process Steps
If there are less than ~5 process steps, perhaps this process description should be merged with an adjacent horizontal or vertical process description. If there are more than ~20 process steps, perhaps some steps can be either grouped or taken out and described as another process or procedure. In both of these situations, there are three things that can help you decide which way to go:
- Process Interfaces: If the number of steps is less than 5, the process description might still add value if it highlights process interfaces that it does not make sense to explain somewhere else. For example, there is a small team performing a specific task, which feeds into a lot of other processes on the same process level.
- SIPOC Diagram (in a way, related to the process interfaces again): This is a great tool for defining all process connections. I would even recommend creating a SIPOC diagram in parallel to designing the process flow, as it can provide a lot of insight. Specifically, it can answer the question of how deep in detail one needs to drill down when creating a process description. My recommendation would be: no deeper than the SIPOC diagram. Make a collection of all “P”s from the SIPOC and this should be your process flow. If the logic breaks somewhere and you need to add an additional step in between two “P”s, then go ahead and do so. However, if there are 10 steps in a row that happen in between two consecutive “P”s, either group them all under one process step or take them out in a separate procedure description.
- Process Purpose: While listing the process steps, it always helps to keep in mind how those steps are contributing to the process purpose. If it is not clear or they are not directly contributing, then it may be best to take those steps out in another process, which will contain a more fitting purpose statement. More about the Process Purpose you can find here.
Know Your Limits
The process design is very tightly connected to the process scope and, if the process scope is aligned with the organizational structure, then to that as well. Example: If you are a Team Manager and you are creating a team process, you cannot assign steps in your process to another team. As per the organizational structure, you have authority over your team only. Therefore, you cannot mandate another team to perform your team’s process steps.
Such issues are resolved by the two Team Managers (or Process Owners) agreeing on how to handle the process interface they have. The activities in this interface then become part of the respective process (i.e. of the team who performs them) and each process description only links to the other, without describing further its process steps.
Following that same logic, you cannot link other processes between each other; you have to focus only on your process and its process interfaces. If, for example, there are stakeholder requirements, which go through Process A, then through Process B, and then come to your Process C, you have to define only the interface your Process C has to Process B. The interface between Process A and Process B is outside of your scope or mandate and, therefore, it should be outside of your process description too.
Simplicity Is King
A process description should be written in a simple and straight-forward language. All abbreviations and other specific terminology must be explained somewhere: either inside the process description, in a terminology index, or in a separate company-wide glossary. Theoretically, if you take a random person from the street and show them the process description, they should be able to understand it and follow each step as described. I have had colleagues arguing that we cannot achieve this when writing e.g. SW Architecture documents: that random person should have at least some understanding of software. While this is certainly our desired state, the main point still stands: make your process descriptions as idiot-proof as possible.
Keep It Relative
Needless to say, the process description should be written for the people executing the process. This seems like an obvious point, however, I have seen a lot of process descriptions that can only be understood by their authors or by the Business Process Managers and internal/external process Auditors. While no target group should be excluded, the main customer of the process description is the person responsible for performing each step of the process. Try to look through their eyes when you are describing what happens (or should happen) in reality.
Prescriptive vs. Descriptive
One question that often pops up is: “Are we making this document prescriptive or descriptive?”. The honest answer to this question is: “it’s both”. I know myself all the arguments of why it should not be both, and yet, unfortunately, it very often is.
As I already mentioned, a company that is out there on the market already operates in a certain way and delivers something to its customers. That means some processes are already in place, even if they are not documented. So at first, you try to be descriptive, i.e. documenting what happens in reality. Five process steps down the road and the Subject-Matter Experts (SMEs) tell you themselves: “OK, so this is how it happens in practice, but we all know this should not be the case. It is simply wrong to do so and we do not want to document it like this. Let’s document it as it should be”. And that does it.
On the flip side of this coin, you have to keep in mind the internal and external standards that the process and its description should comply with. And also, you have to keep in mind the horizontal and vertical processes, which your process connects (or should connect) to. In order to put all the pieces of this puzzle together, sometimes you and your SMEs need to make a decision on whether to document something as-is or as it should be.