Let’s face it, processes are boring at best necessary yes, but not something that gets people out of bed in the morning.
Maybe it is the control it tries to exert on the masses like an authoritarian adult trying to keep the kids under control. We are all a rebellious lot and the same goes for our rocky relationship with processes. Unfortunately, we can’t really live without them. The best and brightest might, because they will do the right thing in spite of process, but for the other 90% of us and for the sake of scalability, there needs to be clear guidelines.
Common process pitfalls
There are some common pitfalls for business around processes.
1. People need to feel that it ‘works’ for them. In other words, they have to see that a process makes a difference, for the better, to their day-to-day operations. There is no point in creating elaborate, complex processes just for the sake of it, or to make you feel that you’ve earned that ITIL badge, or justify that expensive BPM course.
The whole purpose of a process is to break down something complex, into manageable steps for everyone to understand and follow, thereby ensuring consistent work practice.
2. If you cannot measure whether process is being followed, there is no point in having it. You won’t be able to confirm that it is working, and you won’t be able to improve, because you won’t have any baseline. Without continually refining and improving your processes based on real world feedback they will become obsolete, because people will either not follow them at all, or create their own ‘parallel process universe’.
3. People need to understand how a process supports the organization’s policies. If the process doesn’t enable compliance to company policy it is doing more harm than good this is pretty obvious, but it is surprising how many times this happens, especially at micro or team level. People do what they consider to ‘work’ for them, but in the process they have cut the oxygen cord to the mothership…
So, what are some strategies and practical tips to ensure processes become stepping-stones instead of stumbling blocks for your organization?
Below I will briefly outline each of the components, with a common example to clarify the concepts from a practical/real world perspective.
Company Policy & Process
Start with your company policy; make sure that your process 100% supports it. The next step is to outline and briefly describe each step in the process so that people can see how and what each individual step is about and how it supports the company’s policies. Without this as a starting point your process is not worth the paper it is printed on…please don’t laminate it and stick it next to someone’s cubicle. It won’t make any difference.
Example: Company policy specifies that customers can raise a major incident or outage, and that the company will respond within 30 minutes of the incident being logged.
To reflect this policy, a major incident process step must exist in the company’s incident management process.
Once you have described the steps in your process you should be able to easily identify the different work Instructions you could create to guide and educate staff on the process. Work instructions are critical for training and reference in case someone doesn’t understand how to put something into practice. Work instructions will potentially drive back towards fueling your continual improvement.
People will often not question high level process, or make suggestions at a high or abstract level about how they can improve their day to day operations. However, put something practical and lower level that they deal with every day in front of them, and they will very quickly tell you why it doesn’t work. You can then simply ask them what should be done differently with the work instruction as a practical reference, which then feeds back to process improvement. This takes continual improvement to the people, instead of leaving it with the analysts.
Example: A work instruction exists that outlines the steps a Support Consultant will follow in order to manage a major incident to completion, including escalation and communication channels within the business.
And, finally, for each step, document the business rules. Why is this important? To make sure you can map your processes to technology, and to ensure technology (ITSM software and tools), supports your business. This is a critical success factor, especially when choosing a new or improving an existing ITSM solution.
Example: A business rule specifies that an email alert is triggered to an executive email group when a major incident is logged, and again 15 minutes prior to the SLA of 30 minutes being breach if no contact has been made to the customer.
Tip: Be careful not to document the business rule in too technical terms, i.e. how it relates to the technical aspects of the ITSM tool make sure it is independent from how it is implemented in the tool. For example, don’t document the triggers and tool configurations you need to deliver the rule, otherwise your process documentation will have to be revised should your ITSM tool be updated or changed.
As the saying goes, a picture is worth a thousand words, so let’s summarize with a diagram:
- Make sure your process backs your policies.
- Describe your process steps.
- From the process step’s description, derive work instructions for each step.
- Document the business rules related to each step.
And, finally, give your most important asset in continual improvement (yes, people), something practical to chew on, namely work instructions, thereby providing them with easily identifiable building blocks in your continual improvement framework.