6 Principles for Better Process Design
Everyday struggles with lack of processes 🧩 Apollo 13 and its successful failure 🧩 Why we need processes 🧩 Six principles for better process design
We live in a world where processes direct us at every step.
Simply going out to the supermarket means we engage in:
social norms regarding appearance and behavior,
traffic regulations,
supermarket layout, customer service, financial transactions,
etc.
And that’s just for a routine errand.
How do we ensure that all these processes add value to our lives?
Read on 👇
📂 Office Administration at Its Finest
Every few years, I go to my bank to pick up my new debit card. Their procedure for storing and finding these cards never ceases to amaze me! And they haven’t changed it for more than 15 years, since I first became their client.
The procedure goes like this:
Step 1: They check in their computer system if the card is physically in their office or still in transit. It’s always in their office. Since this is one of the cards I don’t use so often, I usually go to pick it up months after it’s been delivered.
Step 2: They start searching for my card. And that card can be literally anywhere! Huge office, top-to-bottom shelves on each wall. All shelves full of massive folders, and all folders full of documents, cards, and whatnot. One would think that the cards are only in one specific folder on one specific shelf in one specific corner, but no. They are all over the place. Especially if the cards were delivered more than a few weeks ago (because at first, the piles of freshly delivered cards reside on everyone’s desk 🙄).
The last time I was there, I spent close to an hour waiting for them to find my card. First, it was only one lady searching, then two, then three. They went through all the folders, and when they reached the end and didn't find it, they started all over again. Luckily, I was in no hurry.
Toward the end of this ordeal, I couldn’t help but ask the lady I first spoke to: “Excuse me, I work as a Business Process Manager. Purely from a process perspective, I’m really curious: Why don’t you mark in that computer system of yours where the card is physically? Office okay, but then maybe also shelf, folder name or number, pages ordered alphabetically, something of the sort?”
Now, you might think that she was super impressed by my suggestion. Or that she told me to mind my own BPM business. But it was neither of the two. She simply didn’t understand what I was saying 🙈
Still, I have to give credit where credit is due: Chaos has its wonderful sides too! If you don’t know what the right thing to do is, you also don’t know what the wrong thing to do is. When you’re supposed to be following procedures to the letter, and those procedures don’t cover all edge cases, you can make the mistake of actually helping a client. Which they have 😉
🚀 Apollo 13’s Successful Failure
“Houston, we’ve had a problem...”
I’m sure you’ve heard these words before. They were originally spoken on April 13, 1970, by the Apollo 13 astronauts who had an oxygen tank explosion 322,000 km away from Earth on their way to the Moon. The mission had to be aborted and the main focus shifted to bringing the crew safely back home.
Both the astronauts and the ground controllers in Houston faced several formidable challenges, which they effectively addressed and overcame. As a result, this incredible story is labeled a “successful failure” because of the experience gained.
The most notable achievement of mission control was crafting and testing highly innovative procedures to pass to the crew. Remarkably, some of these procedures were finalized in a fraction of the typical timeframe (hours and days, instead of months).
The Apollo 13 mission showcases human skill and adaptability in extreme conditions. The exceptional engineering, problem-solving, and creative thinking of all involved contributed to the successful outcome. This story also emphasizes the importance of effective planning and thorough preparedness for the unexpected.
💡 The Role of Processes
Business processes (aka Ways of Working) are created for three main reasons:
to optimize work,
to minimize risk,
to ensure a certain level of quality,
and to do so consistently (as a minimum) or increasingly better (as a target).
Additionally, due to their nature, business processes are used for:
establishing the communication and cooperation between parties and
training new staff or delegates.
Therefore, when designing business processes, we need to ensure they are indeed meeting all of these requirements.
Below are six principles I adhere to in order to achieve that.
✍️ Process Design Principles
1️⃣ Process Flow First
The process descriptions I write always begin with a process flow. When I start working with a company to describe its processes, there's something already happening (i.e. the business already delivers products and/or services to its customers). First, I map out the process flow, and then I add the other details to the process.
To create the process flow, I collaborate with Subject-Matter Experts (SMEs) who own (or will potentially own) the process. They share their expertise on how the process should work, and I add my knowledge on how the process should be designed and connected to other processes (both horizontally and vertically).
I usually approach SMEs in smaller groups or individually, if possible. I only gather everyone in one room when I have a nearly finished process flow that needs fine-tuning. I do this because involving too many people in defining a process makes it harder to reach an agreement and takes longer to complete.
2️⃣ Number of Process Steps
If there are fewer than ~5 process steps, it might be better to combine this process description with a nearby horizontal or vertical one. If there are more than ~20 process steps, some steps could possibly be grouped together or made into a separate process or procedure. In both cases, three factors help me decide which way to go:
Process Interfaces: If a process has fewer than 5 steps, its description may still be valuable if it highlights connections between processes that don't fit elsewhere. For instance, if a small team performs a task that affects many other processes on the same logical level.
SIPOC Diagram (again related to process interfaces): This tool is excellent for outlining all process connections. I often create a SIPOC diagram alongside the process flow to gain insights. Specifically, it helps me determine how detailed the process description should be. As a rule of thumb, I don't go deeper than the SIPOC diagram. I simply use all the "P"s of the SIPOC to create the process flow. If I need to add a step between two "P"s to ensure the logic stays intact, I do so. But if we’ve defined 10 steps between two consecutive "P"s, I either group them or make them a separate procedure.
Process Purpose: When listing process steps, I always consider how they contribute to the process purpose. If their contribution isn't clear or direct, I might move those steps to another process with a more suitable purpose statement.
See my post about process purpose:
3️⃣ Setting Boundaries
Process descriptions are closely linked to the process scope and, if the process scope is aligned with the organizational structure, then to that as well. For instance, if a Team Manager is designing a team process, they cannot assign steps in their process to another team. They can assign steps only to their team because, as per the organizational structure, they have authority over their team only.
To solve such issues, two Team Managers (aka Process Owners) need to agree on how to handle the process interface they share. Once they decide, the activities within the interface are explained in the process of the team that does them. The other team's process description just links to these activities, without describing them again (to avoid duplication).
Following the same logic, we don't link multiple processes together; we only focus on our process and its interfaces. For instance, if stakeholder requirements go through Process A, then Process B, and finally reach our Process C, we define only the link between Process B and Process C. The interface between Process A and Process B is out of Process C's scope or mandate and, therefore, shouldn’t be included in the process description.
4️⃣ Simplicity Is King
I try to write process descriptions in simple language. I explain all abbreviations and other specific terminology either inside the process description, in a separate terminology index, or in a company-wide glossary. My rule of thumb is that if I 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’ve had colleagues arguing that we can’t 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: Process descriptions should be as easy to grasp as possible because they will be read by many people with different backgrounds.
5️⃣ Keeping It Relative
Needless to say, I write the process descriptions for the people executing the process. This seems like an obvious point, however, I’ve 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. I try to look through their eyes when I’m describing what happens (or should happen) in reality.
6️⃣ 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 all the arguments of why it shouldn’t 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’re not documented. So at first, I try to be descriptive, i.e. documenting what happens in reality. Five process steps down the road and the SMEs tell me: “OK, so this is how it happens in reality, but we all know this shouldn’t be the case. It’s simply wrong to do so and we don’t 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, I have to consider the internal and external standards that the process and its description must comply with. I also have to keep in mind both horizontal and vertical processes to which the process connects (or should connect). To put all the pieces of this puzzle together, SMEs and I often need to decide whether to document a part of the process as-is or as it should be. Essentially we end up with a mixture of both in each process description.
To start designing your processes, download my free Process Template.
And that’s how we design processes that add value. And in doing so, we ensure that we are ready to face any unexpected challenges that come our way.
Thank you for reading 💝
Till next time,
Irina
Whenever you’re ready, contact me so I can help you:
Implement global standards, frameworks, and methodologies and get your IT or Software Development organization certified.
Improve your management practices.
Navigate freelancing / solopreneurship if you’re new to it.