Initial Thoughts on Principles of Process Design.
Good process is critical for organizations at scale. When things are small, you can get away with informal processes. One person can see the entire user journey, and there is not enough data for anyone to get lost.
But, as an organization scales, processes can make or break the effectiveness of the organization. With good processes, one can literally see 10x improvements in how much can get done, and how easy it is to get done, especially with there is technology involved.
But, most of the process workflows that I have seen while consulting for organizations of all shapes and sizes are quite disappointing. They are unclear, not well thought-out, and do not make it clear why the process is designed the way it is. The worst thing is that these documents are separate from the real day-to-day process that is actually implemented in the organization.
This means that the official version of the process says that B should be done when A happens. But, in reality, C is what happens, and that is not written anywhere!
The solution here is not to update the documents all the time, but to build the process directly into the workflows themselves, which means that the workflow becomes obvious without any specific written documentation on how something is done.
This may sound counterintuitive, so let me give you an example. If you have an intake form for customer data, you may have someone who needs to review the form entry and then decide who it needs to be assigned to. An example may be initial sales enquiries by customers. However, with some clever routing rules based on the information provided by the customers, this is something that can be done automatically. For instance, if the potential customer states on the form that their organization has over 1,000 employees, this lead should be automatically routed to an enterprise sales representative, not a mid-market sales representative. This is totally doable with common calendar booking Software-as-a-Service (SaaS) offerings.
And so, suddenly you do not need anyone to check which leads are being routed to who, and you do not need any documentation for this either — the configuration of your SaaS calendar software is the documentation!
And so, all of this got me thinking, what are the fundamental principles of process design? This is a large topic, and I don’t believe I can give it justice while having a coffee, so these are my initial set of thoughts.
So, what is a process? In essence, this is a set of steps with a defined start and finish and a whole bunch of rules and instructions on what to do between the start and the end.
Additionally, a process is a specific set of steps for items within a defined category of work. You cannot expect to have one process for vastly distinct things, so you must expect that you will have multiple different processes for different areas of the organization. You will have one process to handle payments, another to handle support queries, another for hiring, another for sales, and so on.
Sometimes, the end of one process will be the beginning of another process, so we can consider that some processes are interlinked. A good example here is that when a candidate in the hiring process is successfully hired, this should trigger the onboarding process.
So, let’s focus on the granular level. What happens when an item (i.e. the candidate in the hiring process, the lead in the sales process, or the invoice in the payment process) moves from one step to another?
Well, first of all, we should ask why it has moved forward in that step. What preconditions caused it to move? In other words, what has changed to move this item forwards in the process?
And once it has moved forwards, these are some of the key considerations:
- What are the next granular steps required to then move this item to the next main process step?
- Is there a specific time limit for this to be completed?
- Is there a specific individual or team that needs to be assigned this item?
- Are there any systems that need to be updated at this point? Ideally, this is automatic, but sometimes retyping information is fine, especially in environments where not a lot of items are processed, and the cost of setting up automation is more than the cost of doing things manually.
- Who decides when this item is ready to be moved onto the next step?
So this starts to give us an idea of how we can start to set up processes. Eventually, I’d like to turn these initial thoughts into a step-by-step guide on process design — so a process for process design!
