From the home office: ISR colleagues open up and report on their experiences with escalation management in their projects.
The #TeamISR has mastered the basics of project management methods in their everyday project work.
In previous blog posts, we have provided exciting and, above all, personal insights intostakeholder analysis,personal Kanban, thetimeboxing method, andvirtual communication management
. This blog post is different: instead of just one person providing insights into escalation management in projects, we have a whole group of colleagues sharing their thoughts. But why did we choose this topic? Bernward Ketteler (Service Manager) sums up our motivation well and also makes a confident statement: "Most project participants are afraid of escalation. I have a different attitude." We want to take away your fear and ensure that you associate something positive with escalation management from now on – just like we do at ISR!
Escalation management? What do we "project nerds" mean by that?
What we do not mean: Minor conflicts that can be resolved through joint discussions within the team at the operational level. These conflicts are not dealt with in escalation management.
What we mean: When a hierarchical level cannot solve a problem itself, we refer to this as escalation management. Many people have a negative perception of escalations. However, it actually just refers to a project automatism that specifies who, when, and in what form an escalation-relevant issue is passed on to the next higher decision-making level (see Figure 1). In this context, you often hear one or the other person involved in the project say, "We have to escalate this!"
Figure 1:Escalation pyramid
How do you escalate correctly?
Most of the time, escalation-relevant issues arise at the operational project level , as there are often insufficient resources, scope for action, or authority to initiate measures to remedy the problem or to make a critical decision independently and in line with defined competencies. Accordingly, the administrative level is contacted. If the scope for action is still insufficient, then the help of the strategic level . However, escalation should only take place once the project team has exhausted all other possible options. Once a higher authority becomes involved in the project, the team, including the project manager, is usually no longer able to interact without outside help. "Emotions must be left out of the equation, if possible, so that difficulties can be analyzed, identified, and then resolved in a factual and constructive manner" (Sandra Bartke, Senior Consultant). At ISR, we have established internal escalation guidelines for escalation management, which arefreelyaccessible to project colleagues onConfluence.
Mark Hommolas (Head of Business Unit – Business Process Automation) statement on escalations: "Escalations are unpleasant for most people and represent a danger or threat. But this is exactly the wrong approach, because escalations are an important organizational tool for resolving deadlocked situations in projects at a higher level. And that's where these decisions belong. It would be much worse if the decision were made at the level below and then it became apparent far too late that the wrong decision had been made."
The three phases of escalation
Following interviews with ISR colleagues about their experiences and insights into escalation management, three phases emerged (see Figure 2).
Initiation phase (Phase 1):
“Escalations in projects are not necessarily a bad thing. To create clarity in difficult project situations, it is always good to address issues openly and communicate clearly with everyone involved.” (Birger van der Spek, Business Team Lead, Business Process Automation)
Escalation phase (Phase 2):
"If, despite transparency, the project is unable to resolve the situation and make a decision, active escalation, e.g., to the responsible steering committee (strategic level), can help! The project is relieved and can continue working according to clear guidelines after the decision has been made." (Birger van der Spek, Business Team Lead, Business Process Automation)
It is important here that each escalation is prepared using an appropriate decision template and made available to the decision-making group.
"In addition to addressing existing problems, the focus is of course also on planning the next steps. This planning must be coordinated and supported by all project managers. All parties involved must also be willing to contribute to a solution. Steps that have been initiated must be monitored. Close communication between the individual parties during the escalation and monitoring of progress are important here." (Sandra Bartke, Senior Consultant, Business Process Automation)
Reflection phase (Phase 3):
"I also think it makes sense to compile lessons learned after the escalation." (Sandra Bartke, Senior Consultant, Business Process Automation)
During the reflection phase, the decision made is reviewed and, if necessary, adjustments can be made. However, this does not mean that decisions made should be immediately questioned. We simply want to emphasize that decisions require reflection in order to be accepted by the entire project team and to pave the way for future decisions.
Figure 2:Phases of escalation management
Which conflicts and problems should be escalated?
There are certainly differences from project to project, but the following situations should definitely be decided via the defined escalation path:
- Resource conflicts (e.g., budget, time, personnel)
- Quality issues (e.g., non-compliance with standards)
- Conflicting priorities (e.g., focus on project A or B)
- Conflicting goals between different stakeholders (e.g., client and contractor)
- Strategic decisions (e.g., expanding the project offering to a new target group)
Bernward Ketteler (Business Team Lead, Business Process Automation) explains: "If the project cannot move forward on its own, the project team can seek help at another level. That is exactly what 'escalating' means. Help can then come in the form of additional material resources or time, or simply prioritization over other tasks or projects."
When? Cuando? The timing of the escalation is crucial!
"Addressing potential conflicts early on and communicating openly are very helpful in the event of escalation" (Sandra Bartke, Senior Consultant, Business Process Automation). However, you should also be aware that escalating too early can lead to accusations against the project manager, and escalating too late can lead to unwanted time and budget overruns. We are confident that the following project situations are very good indicators of a necessary escalation and thus represent a benchmark for a good time to take action.
- When the area of competence at the level where the problem occurred has been exhausted.
- When problems are repeatedly discussed within the team.
- If there are relevant deviations from the defined solution concept.
Ideally, such timings have already been established as standard practice in your company. Feel free to do some research. If this is not the case, we recommend that you address the topic of "escalation management" in your company and establish appropriate escalation guidelines.
What did you learn today about escalation management? An overview.
- Escalation management refers to a defined and deliberate process within a project for delegating decisions to the next higher level.
- Escalation management can be divided into three phases: initiation, escalation, and reflection.
- The right timing of escalation is crucial.
- Escalations in the project should be viewed positively , because escalations involve decisions relevant to the project and thus guarantee the success of the project.
Are you still afraid of project escalations?
Then feel free to contact us! We have a few more ideas and suggestions on how to deal with this often unpleasant topic. Finally, here is an encouraging statement from Sandra Bartke (Senior Consultant, Business Process Automation): "Escalation is not about finding someone to blame, but about finding a practical solution that all parties can agree on."
Mark Hommola
Head of Business Process Automation
Business Process Automation
mark.hommola@isr.de
+49(0)151 422 05 426
