Why do people struggle to follow processes?
- Written by Gerry Sweeney on Aug 27, 2018
Many a great manager has asked themselves the time-honored question; How do you make people follow procedures and not miss things? Having more or less documented the processes, and having put them into your knowledge base tool, and having created internal training courses to make sure everyone is aware of the procedures and so on. Despite all this effort, still the most basic things get missed. There is no glaring flaw in the process, and it seems random, sometimes its done, sometimes not, and when you ask why (assuming you or someone else has the time to monitor the process) there is always an excuse, everything from "I did not know" to "Oh, I forgot!"
The answer to this is quite simple, you are dealing with people, and people are fundamentally variable in their behaviors, they are not robots, and even the best people will make mistakes from time to time. Processes are typically designed based on logic and flow, and most often without considering the human factor, because how do you account for the fact that a particular step in your process might get missed because of an unexpected event in a co-workers life - and that is where even the best most elegantly written procedures can fail.
I wanted to share my thoughts on the things you should be considering to make your processes work better.
You cannot rely on documenting your process
Most people do not read documents, that's a fact. If you give someone a documented procedure, they will read it once and file it away. What you can be sure of though, is no one will have the process document in hand while they follow the process day-to-day. Now that is not to say you should not document your processes, you absolutely should, and you should accept that the development of your process document serves two primary purposes. Firstly, it is your design document, its the physical manifestation of your thoughts and your process design, its the basis upon which you get organizational buy-in, its the thing that you "sign-off" before your process goes into operation. Secondly, it is the "reference" to your process and its intent, its the thing you fall back to when the procedure is not working, and you need to change your process. Improving a process means, changing the document, and re-training people - in that order.
Simplify your procedure portfolio
We have all seen the case where over time an organization builds a mountain of processes and procedures, where each process makes sense in isolation, has already been approved and has a rational reason for existing. You must work to reduce and simplify the things people are expected to follow. If you have an extensive process portfolio, people will struggle with the library of process documents, let alone the procedures themselves. The truth is, processes work in an industrial setting, say manufacturing where you are re-creating the same widget over and over again, but in the case where you are dealing with knowledge workers, then process that aim to make your workers into robots are significantly less effective.
Allow Yourself to be Agile
I have heard many times people refer to being agile as a lazy way of managing, or as a way to avoid having to follow a process. The essence of being Agile is allowing your workers to think for themselves, to break away from what can be restrictive shackles of command and control and to "trust" your people will do the right thing. It is a cultural thing because it requires your people to exhibit fundamentally different behaviors, and they need to be allowed to behave in that way. But if you are pragmatic, being Agile can absolutely (and should) co-exist in a process controlled environment. The smart organization will know how to blend the two, in essence, be Agile where its possible, but rely on a smaller and more simplified process portfolio where its necessary to meet organizational efficiencies, regulatory or compliance needs.
The go-to solution for continuous process failure is automation, but even today people, in particular, the people who are tasked with the design and deployment of processes misunderstand how Automation fits in. In the world of IT, there are so many tools that are touted to automate everything, like software deployment or patches or creating user accounts or whatever, so it is easy to assume that automation is all about these types of things. Now while automation can easily be applied here, it is worth taking a moment to think about the three words "Business Process Automation" and what they mean. A great way to start to think about this is to think of your processes as concerning automating "human activity only," in other words, take the robot players like the IT automation tools out of the equation and work only with human activity. Then you introduce a new idea into your thinking "Human Task Orchestration," and this is the most powerful weapon at your disposal when it comes to ensuring your processes are correctly followed. A useful business process tool (like Hornbills obviously) will differentiate between human task orchestration and systems automation. A well-designed process and the right business tool will make it possible for people (actors) to participate in a given process - without the need to understand the bigger process picture, they just need to do the tasks assigned to them, and the process will take care of orchestrating who has to do what, and when.
In summary, people are always going to make mistakes, the thing to do is to recognize and accept that, and design your processes to be tolerant of that fact. Automate the mundane work; when you have that tedious job that has to get done to keep the lights on, remove the thinking required and give people a list (of insular tasks) to work through, most people work a lot better with a simple list of jobs before them. Life will be a lot better for everyone if you get your process strategy right.