How to make process management fail

(This is a translated version of my German blog post you can find here:

Process management initiatives regularly fail due to the same causes. The causes are also generally known, but there are no application-oriented recommendations that can also be implemented in practice. In this article, we therefore also address the sources of error in the construction and operation of process management, which we encounter over again in everyday consultant work.

These are:

  • Bad anchoring of process management

“Our head of finance, Christian Müller, will deal with the processes in the company as part of a project and thus make the necessary improvements so that we can continue to operate successfully on the market. He is a competent man, he will think of a good course of action.” Such or similar statements startle the qualified process consultant. Based on this statement, one can assume a wrong understanding of the process and there are already numerous pitfalls why the efforts will not lead to success. We now want to identify them in detail.


Process improvements can be achieved in the short term “as part of a project”, but sustainable process management will not work in this way. An analogy: While a project is more like a sprint in which you have to achieve a set goal within a defined time and cost frame, process management is more like a marathon or better a never-ending tour. Process management has no end, so it has different methods other than project management. The regular review of all company activities through internal and external audits are just as much a part of this as the scouting of promising methods and technologies for process improvements, the regular adaptation to new company goals and the effectiveness review of previous measures. Process management has no end, process management is a never-ending way to improve business performance. Therefore, anchor process management as a long-term function in your company!


“Our Head of Finance …” will almost certainly not be successful if he is to accompany a process initiative in the long term alongside his regular job in line organization. Rather, responsibility should be created that in the long term drives process management across departments. It should not only be thought at short notice, the as-is process should be included and optimized, but rather it should be about adapting the process organization to the strategic requirements of the business model, developing the arsenal of methods in the area of analysis and process design for the company, and regularly increasing the process performance monitor, identify outliers, develop measures and implement them with priority. Both organizational as well as technical issues have to be dealt with. Depending on the industry, machine-related topics or IT topics can be on the agenda, which in the best case in the interests of the company are aligned with organizational issues in the sense of the corporate strategy. The tasks listed here are incomplete, but make it clear that process management does not work alongside, but requires the appropriate resources.

In addition, it should be noted that a responsibility (position or department), which is now nominally responsible for the topic of process management, alone can hardly have any effect. Rather, the second syllable of the term process management makes it clear that it is a management topic that no manager in the company can avoid. Just as personnel management cannot only be the subject of the human resources department, process management cannot be exclusively the subject of a process department of whatever name. All managers and key people in the organization must therefore be involved in process management (e.g. through training, reports, participation in improvements, etc.). These managers are also the multipliers that are needed to actively involve employees in continuous improvement. They need an addressee for their own suggestions for improvement. The managers accept these suggestions with respect and then present them to the management, which in turn evaluates and prioritizes them. The proposer must always be informed of the current status (including acceptance and reasoned rejection). The communication effort should not be underestimated and must be coordinated professionally.

Unclear objective

“… provide the necessary improvements …” But which are necessary? This is derived from the corporate strategy, which ideally should also specify which detailed goals a single process pursues. An example: As part of an optimization in a science publisher, parts of the management team were involved in optimizing the editorial process. Due to numerous technical and human interfaces, it took three whole workshop days until the net processing time could be reduced to a minimum. As part of a final presentation to the top management, the board was impressed by the methodical approach to eliminating unnecessary time wasters, but found that the design of a new editorial process did not support the company’s goals. From the company’s point of view, it was not the processing time that had to be optimized, but rather the process quality, because the company positions itself in the scientific field as a quality provider that only offers scientifically sound manuscripts that have been subjected to numerous reviews, that withstand several orthographic tests and meet other test criteria. The process had to be optimized for quality and not for time. The knowledge of those involved was therefore that every process needs a goal so that it can be ‘managed’ well.

However, this applies not only to the individual process, but also to the overall process management. It must be clarified which contribution to process success the process management is aiming for. The work basis is therefore always the company’s vision and goals. From this, structure and process organization with their respective objectives are derived (structure follows strategy). Without a specific objective, the choice of measures is rather random. Clarify these goals and write them down!


“… deal with the processes in the company …” Which processes should you deal with exactly? As a rule, more processes run in the company than is commonly believed. In the best case, some are identified and maybe even documented, but as a rule, all of them are not compiled completely and without contradiction. Where do you start now? Again, there is a reference to the company’s goals. These specify which processes are to be considered with high priority. A company that strives for cost leadership therefore has different process priorities than a quality leader. Define the criteria according to which you want to prioritize. Prioritization based on added value makes sense and should be requested by the company management.

Management attention

“… continue to operate economically successfully on the market …” Do you really want to make the future of your company dependent solely on Mr. Müller and his process project?

The greatest leverage unfolds when process management and the associated organizational improvements are not immediately needed. Practice shows, however, that process initiatives are often implemented when either too rapid growth has taken place and the organization is now to be followed up, or the company is experiencing economic difficulties in which internal synergies and potentials are now to be leveraged. In such exceptional situations, many managers recognize the need and pay close attention to the initiative. In calm waters, the management often “forgets” the possibilities and withdraws the management attention from the topic. Don’t make this mistake. Process management, or more general and comprehensive “operational excellence”, belongs on the top management agenda every day. You can’t do that? Then make your process manager part of the top management!

Bad preparation

“… he will think of a good course of action.” However, the procedure is also derived from the goals that are being pursued. It can also be seen that the company has not yet defined or even developed the framework in which such initiatives can run successfully. The following hypotheses are in the room: 1. The goals of the project are not sufficiently defined (see comments above), 2. No roles and competencies are defined (who defines the specific procedure? Who has the necessary competencies?), 3. Which meta processes can be used (for example, for the approval of process definitions or the release of necessary investments, 4. Which additional methods (e.g. for process analysis, process design, process controlling) are used and who masters them?), 5.) How should process documentation be carried out? (Nobody will do that on paper anymore today, but how then? Which software tools are required?)

All of these factors should ideally already be defined BEFORE an improvement project or these questions should be answered, otherwise the participants will rub themselves down in coordination with adjacent areas, without investing their commitment in the actual work results.

Line managers are not process managers

“He is a competent man …” in finance, but does he have the skills to be a good process manager? This requires pronounced analytical skills, but also visionary imagination, knowledge of basic design principles in process design and both empathetic skills in interpersonal relationships as well as technical skills in the implementation of IT solutions. In addition, he is at best a strategically thinking head. Finding the employee who combines all these abilities in one person is always a challenge. Few can combine all of these skills. We cannot assess whether Mr. Müller is the competent man for process management. But at this point we can point out this special requirement profile.

In addition to the topics mentioned, there are also a number of topics that hinder or complicate the development of process management. These are:

Too much depth, too little width

Depending on how the company sees itself in relation to its own employees, it can be seen in practice that process documentation sometimes resembles an atomic detailed description. Every finger movement, every turn of the head (we exagurate little here) finds its way into a process model. The result is “model monsters”, models that no one wants to deal with due to their complexity and size. The employees surrender. However, it is apparently assumed that every detail must be documented, otherwise the executing employees would not know what else to do. This is nonsense! It can be assumed that employees will take the right measures if there are problems in the process. Nevertheless, finding the right level of detail is not easy. As a rule of thumb we recommend: as many details as necessary, as little as possible. The employees will make it clear how they will have problems of understanding. You can then add details for clarification if required. In a first step, it seems advisable to work with simple process descriptions, which may seem a bit too superficial, but are consistently coordinated with adjacent process areas. Building a coherent process system appears much more valuable from an overall company perspective. A detailed description can still be made later if problems arise. However, this requires appropriate monitoring of process problems.

Too much width, too little depth

The other extreme can also be observed. The wish is expressed that all processes in the company should be recorded and documented. Due to the number of processes, the person responsible has to limit himself. In particular, initiatives that strive for ISO XY certification tend to generate many superficial models. However, these often have no relation to actual practice and therefore do not go into the details (and are therefore not a tool for the employees). Here, the process manager is occasionally obliged to cause problems with processes, sometimes to go deep, if it should apply that process management not only means documentation for the purpose of certification, but that serious improvements should also be brought about.

The nerdy thing

And then there is the topic of business IT alignment! How can it succeed that IT does not lead a parallel life and brings its knowledge and experience into the further development of processes. Well, it’s not easy, but one approach could be to promote professional and technical exchange based on a common modeling language such as BPMN. It makes sense not only to see IT as a vicarious agent, but to invite IT to help develop the business model together. This is often a new and unfamiliar role, but with a bit of practice, the nerds bring in ideas on how to implement faster, better, easier, cheaper processes to support the business model. Therefore, of course, the collaboration between the department and the IT department has to change. We should say goodbye to phase-oriented development projects in which a technical solution is presented after months that would have been needed months ago, but today no longer meets the changed market requirements. A more agile collaboration is required here, which can also endure trial and error. Here you reflect on the beginnings of your company. At the beginning it was also tried out and then touched up. Take a similar stance in your processes.

We always meet the above-mentioned topics with our customers. Sometimes more pronounced, sometimes less. But these issues always lead to process management initiatives stuttering and unable to develop the desired appeal. We hope that we have given some information to those responsible. MINAUTICS will be happy to advise you on how you can also successfully implement process management in your company!

Fore more thoughts on BPM in German visit

Originally published at



Business and IT consultant with a decade full of BPM history, focussing on model based process management.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Björn Richerzhagen

Business and IT consultant with a decade full of BPM history, focussing on model based process management.