I feel badly for my kids…I really do. Like every parent everywhere, I repeat the same phrases and advice over and over… and over again. Among my favorites (for example when complaining about a sibling’s behavior) are “solve the problem” and (when talking about something worrying them) “how likely is it that will actually happen?”
Tedious, right? And it is even worse, because these are the very same things I say to the people on my services team as they try to sift and prioritize the issues that they face every day in their work with customers. But I am a services guy at heart, and these catechisms do get to the heart of many oft-occurring problems.
Here is another. When they were younger and one of my kids would come to me with a bad result, let’s say a bad grade on a report card, I (without fail) would ask them what they were going to do about it. And without fail, they would say that they were going to “try harder”. And that predictable exchange would allow me to explain that I was sure they were already trying pretty hard, and that “trying harder” was not going to work very well. And then I would ask them what they were going to “do differently”. As I said, my poor kids. No one should have to endure having a software services leader for a father!
What does all this have to do with project escalations? Well, as with a bad grade, trying harder is simply not going to work to get a project on track. You need to do something different (and differently) if your goal is to reset a project. Of course the critical question is “what is the thing we have to do differently?” And the answer to that is both predictable and infuriating: It depends.
The point is that if your team uses the word escalation casually and simplistically, where every project with issues or in the yellow is just described as “escalated”, you are not doing much to solve the problem or recognize a pattern. For those things to happen, we need to know why a project is escalated and at what level it is escalated. Because those two parameters will almost always define the necessary course of action.
Let’s start with the escalation level first. I typically use a four-level escalation model, with a definition of what circumstances – and what level of unhappiness on the customer’s part – determine which level is which.
For example, a customer simply annoyed that something they want is not in scope might be a level 1, and a customer who has sent a message to my CEO on long-simmering project issues might be a 4. The risk in the level 1 escalation is some impact on our relationship, the risk in the level 4 escalation might be losing the business and a lawsuit. So yes they are both escalated, but the actions that are called for to regain control and rebuild the relationship are entirely different. Here is a simple example of an escalation scale.
As you can see, we are well beyond Green, Yellow and Red here. These four escalation levels convey more information than simply describing a project as “escalated” or coding it yellow or red.
As I implied above, the level of escalation and the underlying causes are critical pieces of information because they drive the specific actions that need to be taken to regain trust and reset the project.
That means that the most important part of a formal escalation model is the set of actions that will happen once a project is declared to be at a given level of escalation. Remember, trying harder is not going to work, so we need to take some specific steps. Here is a simplistic example escalation matrix:
As noted, this is a very simplistic model. But as an illustration, you can see that if I have a level three escalation that is rooted in schedule issues, there are specific protocols to follow and steps to take. But if I have different level three escalation that is rooted in a product issue or bug, there would be separate additional actions that I need to take to address that issue (such as wrapping in a product person into the project).
By encoding escalations in this way, we not only get a set of prescribed actions, we get the benefit of being able to discern patterns more easily. We may see that the majority of our issues are schedule related, and use that information to make changes to how we set project schedules. Or we might see a repeated pattern of issues around scope, which would be a signal that tells us we need to work harder to communicate scope boundaries during the sales process and during the project kickoff.
Lets face it, escalations happen and will happen. OF COURSE we want to avoid them. But just as importantly, we need to manage them. Otherwise, we can get a severe case of the “escalation blues”.
The escalation blues are that situation in which there are many projects spinning out of control, each with issues competing for the team’s time and attention and sucking the optimism and energy from the team. The antidote is to get past the sense that “OMG we have SO MANY projects in escalation!” and to a level of specificity where we can say “we have 6 projects in escalation, four at level one, 1 at level 2 and 1 at level 4, and there is a product issue underlying four of them”.
Once you have that level of information, escalations become a manageable part of delivering projects, and while not desirable, can act as a set of signals about what your company needs to do to drive major improvements in customer happiness, and to take your product and projects to the next level.
#escalationshappen #crushthoseprojects. #workrails