Poor process, also not followed
As a manager or an employee, no matter what company you are in, I am sure you have experienced poor processes which are also not followed. People often go off and do their own thing – but why does this happen? I will explore why companies have poor process, also not followed.
Best efforts
Most often, people are trying to do the processes, or follow their best judgement, and they are not deliberately avoiding process. They think they are doing the right thing, or they are trying to cope with the systems, processes, lore and myths of their team or department. They may have been influenced by their peers, previous jobs, or a manager who encourages them to step outside formal processes. People often will do what they think is the right thing to do – and when that process has come from a previous job, it can be at odds with that the company wants to achieve.
Optimised for the wrong people
Instructions and processes that are not written for the people who will follow the process – instead they are just a series of screenshots taken by a person who does not understand the business process, or even worse, written for an auditor or compliance – instead of to empower and support an employee. Processes written by a desk-bound bureaucrat who does not really understand the real practicalities of the business issues or the tools or the customers. This can make a process hard to follow, and so easy to skip or bypass.
Bifurcated (Split in two) processes
This happens when a departmental manager or other strong personality decides their way is better, resulting in two (or more) documents or practices for the same process. This can also happen when old processes are still followed when a new system is implemented – particularly if it is a manual, off-system, or Shadow IT process. Then there are people who follow one process, even a formal document, but have no idea that they process they are following is the “wrong” one.
Poor engagement
New employees are not trained or onboarded correctly, and they are instructed by a colleague who shows their own process, which may have diverted from the official process. Sometimes this even ends up with a new employee doing a bit of trial and error to complete a process that they have not been trained on or given instructions for – and when it works for the new employee, they follow their own discovered process.
Processes not fully understood, so steps are skipped
Overly prescriptive processes or documentation that has no context can lead to people becoming numb to the steps, and stepping over “obvious” steps. I once saw a process document that had a whole page with a single screenshot and single step of “press OK on this screen” – the more documents are like that, the less people will actually read them.
Process bloat
When employees get overwhelmed with the number of processes and instructions – they think they have all the instructions and guides they need to do their job, but there is yet another document that documents additional steps or another split process. They don’t actively seek out sub-processes and edge case documentation, particularly when the employee believes that the process or document they follow has all the information that they need.
Not optimised for search or discovery
Cannot find the documents or instructions for the process. This can be a real blocker for following documented processes or procedures. Is your documentation hidden away in a project folder from the implementation? A likely cause is that the documents are not optimised for search, so unless the new employee knows exactly what the file name is, or key terminology, search will not surface the instructions.
Additionally, some documentation can be heavy and create “noise”. When there are six pages in every process that show version history, term definitions, related documentation and regulations, and the like – some people will just “tune out” and not read all the document. This can lead to people missing important information.
Assumptions
Managers do not check on process compliance, because they assume that everyone is doing it properly – because “everyone knows” how to follow the process. Employees also follow a process because they assume that it is correct – often based on intuition, or logic. Sometimes there is no documentation at all, because there is an assumption that there is only one way to do something. Ill-informed users can be really creative in finding a way to do something, often wrong!
Manager interference
Strong personalities can come in to force where a manager will insist that the formal process or document is not valid, and their way should be followed. What is an employee going to do – tell their manager they are wrong?
Most people are not deliberately malicious and are not fighting a process – it is most likely that the process is not correctly set up for the people to do their job. So, when creating your own processes and documents, ensure that you consider how it could be bypassed and done wrong, from the above examples.
How to design a process that gets followed
Diagnosing a poor process is the easy part. Here is what I do to build one that people actually follow.
- Write it with the people who do the work. Walk through the real task before you document it. Capture how the work is done today, including the workarounds, then decide which workarounds are better than the official route (adopt them) and which are unsafe (design them out).
- Keep it to one page: the happy path plus the exceptions. List the steps, then a short “if this happens, do that” for the common exceptions. Link to the detailed procedure for the few who need further detail. A process nobody reads is not a process.
- Make the right way the easy way. Pre-fill what you can, set sensible defaults, remove steps that add nothing and automate the rest. When people go around the official route, ask what the route costs them. People take the path of least resistance, as I saw in How many inboxes do you have?
- Name one owner, one source of truth and a review date. If a new starter cannot find the current version in two minutes, the process is already failing.
- Check by sampling, not by assuming. Each quarter, pick a handful of recent cases and trace them through the process. Where they deviated, ask why. Deviations are design feedback, not a disciplinary matter.
A quick health check for any process: Who performs it? Who owns it? When was it last tested? Where does it live? What happens when it goes wrong?
A good process works the way good leadership does. It lets people do the right thing without being supervised, which is the point I made in My aim as CIO is to do less.
