Everyone knows what it means to escalate an issue, but all escalations are not created equal. There is a lot of judgment and discretion that must be applied in order to not escalate too early and ‘cry wolf’ or to escalate too late and ‘miss the boat’.
How do you know when to escalate an issue? Do you use objective criteria that you follow and apply across all groups? Or, do you follow more of a subjective, gut feeling that is based upon past experience with different teams?
By it's definition an issue is already creating an impact and therefore depending on the level of impact can depend on who it is escalated to within the business/porject.
Obviously in an ideal world this type of communication would have been agreed up front, in a realistic world - you do take a judgement based on the level of impact on who really needs to know. But ultimatelyt as it is creating an impact it should be escalated even if it is for informaiton only (e.g. within a projects change budget/tollerance).
Any issue arsing during a project execution phase will have a direct impact either on cost or schedule or both. As long as we have a mitigation plan to solve such issues, we must first try and resolve at our level, assuming the issues are internal within the project team. If issues are due to external exigencies, we must assess the impact of such issues and escalate to appropriate level as defined and agreed in the Project Communication Plan. It is always a best practice to communicate the issues to the respective assignee duly explaining the impact of such issues and give a target date within which the issue has to be resolved in order to minimise the impact. If the issues are not resolved within the timeline, then the escalation mechanism comes into effect. Saving Changes...
I'm going to chime in and say I'm not sure what it really means to escalate an issue.
It may just be the result of the project environments I've worked in, but I've always made a point to be rather embedded with my sponsor and key stakeholders - status happens weekly and any issues get brought up and discussed then.
It's more of a collaboration and brainstorming session on the issues that arise to come up with solutions as a team - I don't see where the term 'escalation' would ever be used.
Can someone give me an example where escalation happens? I'm not being a smart-alec, I really just don't see the need for it based on my experience...
On the project I'm working on, we have various different levels of teams and plans - overall the team is about 40 people. Workstream leaders manage their own teams and plans, risks and issues. They escalate to me if there is something they think I should know about i.e. something that is outside their tolerance levels to address such as something that will cost more to put right or take longer, or that will have an impact on another workstream and they can't sort it out between the two workstream leads such as they need a steer on prioritisation.
I can resolve most of these issues myself. When I need a steer on prioritisation, I take an issue to the project sponsor. An example would be this week when we hit a problem that will potentially impact our delivery date. There is nothing that he can practically do to fix it, but I wanted him to be aware that there is a problem that we are working on in case it can't be resolved and we do have to put in place contingency plans.
I think escalation means getting someone above your pay grade to help you fix an issue that is not within your ability to resolve yourself, or flagging up a problem to someone with more authority than you so that you continue to work in a 'no surprises' culture.
To answer Jennifer's question - it's gut feel, every time! Saving Changes...