The People, Process, & Progress Podcast - Escalation in Projects Is a Tool, Not a "4 Letter Word" | PPP #59

Episode Date: November 22, 2020

I share escalation tips with reference to some tools found in the Project Management Body of Knowledge (PMBOK) 6th Edition.

Welcome to the People Process Progress Podcast, where we understand that people are our most important asset. We emphasize and share examples of the importance of shared process so that we can move ourselves, our teams, and our organizations toward progress. I'm the host of the show, Kevin Pinnell. To learn more about me and the show, go to peopleprocessprogress.com. But for now, let's get on with another great episode of the People Process Progress Podcast in 3, 2, 1. Hey everybody, welcome to People Process Progress episode 59. Escalation is not a four-letter word. What do I mean by that? Well, in the project management world and even public safety and other stuff I've talked about, particularly projects,

escalation is a call for help. For Merriam-Webster, it's defined as to escalate means to increase in extent, volume, number, amount, intensity, or scope. Escalation in project management is asking for help. It's saying there's a problem that I can't solve. There's money we'd not authorized to spend. There's scope that is creeping, meaning this isn't the intent of the project. It's going to push the schedule. Maybe the quality is going to be impacted, but escalation shouldn't be viewed as a negative thing. A lot of people see it that way as, oh, I failed or I have to ask for help. It should be on me, but that's not true. So if you're hearing this, if you're hearing me, please know that escalation is a valuable tool in the toolbox for any project manager, any leader on the street, anyone in the team.

It's a way to get you more resources. What I want to use kind of as a guide and talk through is on page 442 of the sixth edition of the Project Management Body of Knowledge is Escalate, right? And Escalate's only in like two or three places in this whole book, which is kind of surprising, but not surprising. This is where kind of that book and the real world clash or have a mismatch, I would say, because escalation in the real world doesn't happen as often as it should. And that can lead to communication gaps, coordination gaps, those kind of things in a project. So I'm going to go through the paragraph that's on that 442 right now and just give you my two cents based on what I've seen in the project and program management world. So the first line of this says that escalation is appropriate when the project

team or the project sponsor agrees that a threat is outside the scope of the project or that the proposed response would exceed the project manager's authority. I am on board with this, right? Typically, it means that the scope, schedule, or budget, or cost, right? That's kind of those triple constraints we know in project management are potentially impacted or are impacted. We should be managing these before they're impacted, right? When there's still risks. Risks, remember, haven't happened. Issues is something that's going on right now. We should be looking ahead for those and escalating risks before they become issues. So this first opening on this paragraph, I'm all on board with. It means, hey, I'm the project manager. I'm not authorized to spend a bunch of extra money or push our schedule or change our

scope or affect negatively our quality. So I'm going to ask for help as soon as possible, or I'm going to help someone else on the project team ask for help. Sometimes as the PM, you have to ask that person's manager for help because that person is not doing well. Now, when you do that, you do that in conjunction with the person, right? You talk to them. You try and work it out. You work with them as much as possible until you can't, until you're at an impasse or until they're stuck and say, look, I'm going to see if I can get you more time, free up some, you know, get someone else to help us. But you've got to do it. Let's get into the second sentence of this paragraph here. So it says escalated risks are managed at the program level, portfolio level, or other relevant part of the organization and not on the project level. I emphatically disagree with this wholeheartedly

project management body of knowledge. If you don't expect your project managers and project level people to manage risks and escalate issues, then that's a bad expectation. Now, are the decisions made at a higher level? Sure. But what I don't want to give the impression for folks, whether you're a brand new project manager, an associate, or a senior project manager, is that you just say, hey, here's an issue, and then you expect someone else to run with it. You own that risk. You escalate it. You own the escalation until the decision's made or not by your leaders. Then you bring it back and you close the loop. That's where I disagree with that statement.

While the decision's made at a higher level, the project owns it. The project owns the risk that's escalated so that it doesn't become an issue. The third sentence here is the project manager determines who should be notified. I agree with that about the threat and communicates the details to that person or part of the organization. So I agree with that, right? You're the project manager. You've identified the threat, the risk, something that's going to become an issue or has a high chance to. You need to get it to the right people. You need to help your team members get it to the right people or get it to you if you're that person and really facilitate that discussion. It is important that ownership

of escalated threats is accepted by the relevant party in the organization, right? So I agree with this piece too. If you are escalating a risk, let's say, hey, we're going to go way over budget because the price in the industry just went up for these widgets. You need to own it and track it, get it to the people who can say, yep, you can have more money or find another vendor, whatever the solution is. And again, close the loop. You're the project manager for a reason. It's to help people communicate, facilitate process. Threats are usually escalated to the level that matches the objectives that would be affected if the threat occurred, right? So when you escalate these threats, when you escalate a risk that may happen or a threat to the project. Right. Those are kind of used interchangeably here. You need to get it to the person that can actually make the decision.

So if you escalate to a person who's still not authorized to approve more budget and just stick with the budget theme, then you haven't mitigated the risk or accepted it or avoided it or whatever you're going to do with that risk. Right. You need to get it to your C-suite, whatever level in the decision matrix. And you should know that, right? As the project manager and your team should know that, meaning at this level, we're authorized to spend this much. At this level, we have to ask for leadership. At this level, we have to go to our steering committee, know those kind of tiers of decision-making that will help you escalate appropriately and escalate early and often if you need to. That doesn't mean ask the CEO ground-level decisions all the time,

but if you have a committee or a council or some group that consists of leaders that can make decisions that can get you more time, more people that can say, push back to the vendor partners or to your own people or something and say, no, you do need to focus on this. You do need to put more time. We'll get that workload off your plate. That's who you need to get it to is to the decision makers. The last sentence here is escalated threats are not monitored further by the project team after escalation, although they may be recorded in the risk register for information.

Coming back with an emphatic disagreement here, if you are the project manager in the project team and you're not monitoring the escalated threats or risks, that's bonkers to me, right? You brought it up. You need to get it ready and deliver it to a good escalated, you know, place, meaning here's something we identified. Here's a short, a few bullets about it. Here's what it affects negatively or positively. Here's who we believe the owners are. And here's what we need your help with. Short, succinct stuff and ask that's directly to the folks that are in positions to make decisions and help you get more money or more time or increase the scope so you don't negatively affect your

quality. But you absolutely monitor that as the project team. I'm very surprised to see that in the project management body of knowledge. This isn't a bust on that book, right? It's the core book for waterfall stuff for the PMP certification, but it's also kind of a good standard reference. And escalation has been a tool I've used quite a bit over the past few months or years. And I just wanted to reiterate and share with folks, because some folks are really afraid of it. And this is a good standard. It's an industry standard book, the PMBOK 6th edition here. But again, you as the project team, as the project manager, absolutely are going to start and monitor and bring back and

close the escalated threats. Now, you may be told by your leaders, hey, we got it, we'll come back to you. But that doesn't mean you just wash your hands of it, right? That means they own the decision piece, they bring it back. So certainly monitor any escalated threats, risks. If they become issues, you know, then you hopefully have escalated those. And it's not a surprise to any of the leaders that you're going to ask stuff for or that's going to see kind of the yellow or red light on your project. But I hope this was kind of a quick tip. Again, I've heard escalation and seen escalation be looked at as a negative thing, but it is not. Certainly if you escalate too late or if you've escalated

an issue or a risk that's been sitting there brewing for a while, that could be negative. But please think about escalation as something you want to do to get help for you, for your project team, for your people, for your leaders. It will help them, right? Leaders don't want to be surprised by things that become issues and then it's too late. So ask early when you have a risk or a threat that you think is going to severely impact your project. Remember those triple constraints, right? Scope, cost, schedule don't negatively affect your quality. Thank you all so much again for listening, for visiting peopleprocessprogress.com. Please listen to the next episode where I have a great conversation

with my friend and mentor and former leader in emergency medical services, Rob Lawrence. So stay safe, everyone out there. Wash those hands and Godspeed.