Do you still manage processes?
Larger companies devote a lot of time and energy to maintaining processes. Periods of 2 or more years – from the idea for a process to its first publication – are not uncommon. But if the time periods are so long, do the boundary conditions that were assumed at the beginning still apply at the time of publication? Does the process, which an often illustrious circle of initiates thought about at the green table, still address the original problems at all? And how do those involved know that the process, which has been worked out in many small sessions, will work?
Processes in the field
I have essentially made two observations on processes in operational practice:
- Employees do not know the defined process.
- Employees know that there is a process, but do not stick to it, because from their point of view it is useless, cumbersome and sometimes even pointless.
An employee of a larger company once put it this way: “We have already experienced so many process improvement measures that did not work. We just keep working here as we think it should.” First of all, let’s be clear: processes always exist, whether they are documented and managed or not. The questions we are dealing with here are:
- Is a process worth regulating, i.e. is it important that a regulation promotes repeatability and continuous improvement of the process?
- Does a process have to be regulated centrally, so is it necessary for all employees with a similar task to work on it in the same way?
- How much of the process must be regulated, i.e. is it sufficient to provide a framework or do details also have to be regulated?
- Who is responsible for the process? The one who is given a goal by his boss or the one who benefits from a really functioning process and therefore has a real interest in it?
Processes and conflicting goals
When working with processes, conflicts of objectives always arise, because the more processes regulate, the more freedom they restrict.
Especially in large companies, this leads to real processes that are over- or under-regulated: Either the processes regulate too much and thus restrict the employees so much that they look for ways to do their work successfully anyway. Or they regulate too little, e.g. if a process only exists to fulfill the formalities of quality management. In such cases the necessary commitment is lost, the employees do not take the process seriously.
Process management thought differently
But how could the process work be organized instead? So that employees recognize the process as “their” process? To answer this question, it is a good idea to consider a process as a piece of software. Just as you today develop software in cooperation with its users in a user-oriented way, you can also do this with a process. The following aspects are essential:
- Involve the users of the process as customers in the development via a product owner. The product owner collects the needs of these users so that they can form the basis for the process development process. And he focuses on the question of how the process improves the added value of your company: No matter whether a process is a core or a support process, it must ultimately serve the added value. If this is not clear during its development, the meaning of the process can never be communicated to the user.
- Put together a development team that includes representatives from those areas that can contribute technically to the design of the process. This, together with close user contact, ensures that the necessary discussion of content takes place efficiently and effectively. Make sure that this team has the required competencies and give it the necessary trust and freedom.
- Let the team work on the process in small steps and short cycles. This means that results can often be validated with users. Their feedback can be immediately used for the further development of the process. You avoid costly errors and corrections while ensuring that results work for those who have to live with them.
- Consider everything that belongs to the process as a whole. The product that the team has to realize consists not only of the process itself, but also of all the methods and tools that go with it. After all, users do not have to be equipped with paper, but with real help on how they should work in the future. And it is of no use if the process would theoretically work great, if there are practically no tools to make it possible at all.
- Use the modern communication channels for the integration of users. Group chats, discussion forums, survey tools and in-house “Facebook Look-Alikes” are wonderful ways to clarify and validate ideas. Wikis, on the other hand, can display the current state of the results and refer to further content, tools and methods; users who subscribe to them are automatically informed of updates.
As you can see, much of the software development can also be used with the development and optimization of processes. Of course, some aspects are somewhat different, so you should consult an expert who has experience with this kind of process work and can support your team accordingly.
Gerhard Schneider has published another article in the t2informatik Blog:
Gerhard Schneider has been dealing with the diverse questions of requirements management in large companies for over 20 years. With his experience as an entrepreneur, founder and coach, he can help people to develop themselves and their companies in a future-proof way by designing and introducing processes within the framework of product development. In doing so, he takes care to develop the familiar structures and behaviours into an attitude that is consistently oriented towards people, the appreciation of their achievements and constructive communication, and that demands and rewards independent thinking and action, commitment and responsibility.