Disruptive Escalation

Are we asking the right questions?


By Carlie Cornell, PMP

North Texas, USA



Escalation is not a poisonous snake to be avoided at all costs. It is a tool project managers can learn to use for the betterment of their projects. Project management.com (2017) says, “Project escalation is both an art and a science – it is also a risky art as escalation can lead to personal clashes and backfires.” Maybe it is poisonous after all, even if it is not a snake, and must be handled with care. But done well, escalation can lead to successful delivery of a previously troubled project and it can enhance the reputation of the project manager who knows when and how to escalate.

This paper will examine two cases studies in which a disruptive escalation interrupted project progress, but eventually enabled the project teams to deliver successfully. The first case study is a story of a team that spun its wheels and delivered nothing for weeks, sliding gradually from green to yellow to bright, burning red. We will look at how we measured that slide and how we halted it and got the team back on track. The second case study looks at a project that the sponsoring CIO called “the worst project ever.” We will study how the project earned that moniker and what the team did to turn things around.

What is escalation?

Escalation is a process used to call attention to activities or issues that have the potential to harm a project, if not resolved. Such harm can include delay of project timelines, cost overruns, jeopardizing the quality of project deliverables and other damage to project outcomes (Puleo, 2016).

We would like to call attention to the first few words of this definition. If escalation is a process, it makes sense that we should define our process before we need it. If your organization or PMO does not have a pre-defined escalation process, you should create one in your project plan. If you have a defined process, you may wish to elaborate or make it more specific in your project plan.

Some of the elements you might want to document include:

  1. Whom you need to escalate to per topic or area, at each level of escalation.
  2. Levels of escalation: a scale of severity of risk will likely drive this. You may also wish to consider difficulty of resolution as a factor in escalation level.
  3. Triggers that will drive a need to escalate.
  4. Measurements that will alert you to developing problems.

(projectmanagement.com, 2017)

An example of an escalation matrix is included in Appendix A.

Disruptive or obstacle removal?

Not all escalations are disruptive. In fact, in our experience, most are not. For example, today, one of our team project managers escalated the problem that one of her team members still did not have access to tools used by her team to one of the development managers. The manager reached out to the support team and authorized the access. Within an hour access was granted…


To read entire paper, click here


Editor’s note: Second Editions are previously published papers that have continued relevance in today’s project management world, or which were originally published in conference proceedings or in a language other than English. Original publication acknowledged; authors retain copyright. This paper was originally presented at the 11th Annual UT Dallas Project Management Symposium in August 2017. It is republished here with the permission of the authors and conference organizers.

About the Author

Carlie Cornell

Texas, USA



Carlie (Gehle) Cornell, PMP, has managed projects and programs, using plan-driven and agile approaches for product development and information systems software teams since 2004. As a PMO leader, she has trained and managed project managers, business analysts and business process analysts from IT and business organizations. She has been recognized as a top performer and received a Chairman’s Award in recognition of her project and program management efforts. Most recently she slipped over to the dark side to manage development resources directly. Now, she collaborates with the PMO team to ensure that strategic projects have proper staffing.

Carlie Cornell can be contacted at [email protected]