Communicating project issues is challenging. Exactly when should we escalate? Who to, and how much of a chance to correct things should be given first? This is why some projects create control limits around critical parameters and develop escalation plans to communicate exceptions and agree on the next steps.

However, on most small to medium size projects, these escalation plans are often missing or left to the project manager's discretion. This creates further problems if the response is too late, not far-reaching enough, or not aligned with sponsor expectations.

Also, what are the expectations for communicating delays, risks and issues at the team level? Do we want to hear when something takes a couple of hours longer than planned (probably not), a couple of days (probably, yes), or a couple of weeks (no, we should have been informed much earlier!)

A "Definition of Broken" (DoB) helps identify and trigger previously agreed exception plans. It is a list of events that allows us to flag and start addressing a problem without the emotions and delays of arguing if it is significant, warrants immediate action, whose responsibility it is, etc.

Just as you do not want to invent a fire evacuation plan during an actual fire, so should exception plans be created before problems arise.

Origins

Agile approaches often use a "Definition of Done" (DoD) to describe the attributes that constitute acceptable. For an increment of software, this may include items such as:

• Coded
• Tested
• Refactored
• Integrated
• Reviewed
• Accepted by customer
• …

Some teams also use a "Definition of Ready" DoR to describe the desired state of requirements. For example, this could be an appropriately sized user story that meets the INVEST mnemonic attributes. Similarly, “Goldratt’s Rules of Flow” describes creating a Full-kit that lists all the items required before starting work on something. Then a sprint or iteration transforms the selected items that meet the DoR into increments that satisfy the DoD.

A Definition of Broken (DoB) is a shorthand way of referring to tolerances and exception procedures. Creating a DoB allows us to objectively describe future issues and resolutions before the stress of a problem clouds people's judgment. I have used DoBs with teams for over ten years and found them valuable shorthand terms for significant impediments.

PRINCE2 popularized tolerances and exception plans procedures in the 1990s. While PMI literature does reference risk tolerances and escalations, the PRINCE2 coverage is much broader. Tolerances can be set up around spending trends, quality metrics, sponsor confidence, widget output, or any project parameter you like. The example below shows a tolerance range around projected spend at +10% and -20%.

So, tolerance is an agreed range of variation, like a control range. However, unlike control ranges, tolerances are paired with an exception procedure to be executed if the tolerance range is breached.

The Downsides of Tolerances and Exception Plans

While it would be helpful to create tolerances and exception plans for a wide variety of project variables, project managers typically do not have time to document them all and get approval from the necessary stakeholders.

As a result, the good practice of defining tolerances and exception plans is often omitted from projects that do not mandate them for safety, regulatory compliance, or quality reasons. Project managers are too busy to create them, and sponsors don't want to review a long list of "What if this happens…" procedures.

Definition of Broken (DoB) Can Help

This is where a Definition of Broken (DoB) comes in, as a lightweight pre-approved emergency response plan. Without all the documentation and signoffs, critical issues that would require sponsor or steering committee intervention can be agreed to in advance. Then, should any of these events occur, there is much less debate before action is taken. This pre-approved action plan speeds remediation and increases the likelihood of recovering from a significant issue.

A Couple of Examples

On a project to implement a 3^rd party membership management software package and write new custom code to link the membership system to various in-house developed systems, DoBs were created for likely but high-consequence scenarios. These DoB situations triggered an escalation report to the project steering committee and automatic inclusion as a discussion item at the weekly sponsor review meeting.

Example 1: Vendor Schedule Delay

The vendor's implementation plan showed the core member billing module configured, installed and tested by the end of May.

DoB Trigger: "Billing module not operational on June 30^th" 

(This was a month after the vendor planned to do it. So the vendor was happy to agree to the DoB trigger. Predictably, come June 30^th, the billing module was installed but still not operational. Having the DoB clause with an approved escalation plan meant no debate or weaseling opportunities for the vendor. The item was escalated, bringing in new vendor staff to expedite the issue resolution.

Example 2: Integration Team not Available

Since the micro-services group was a critical dependency, it seemed prudent to get pre-approval to resolve any delays.

DoB Trigger: "The project team waits more than two weeks for an integration or test- environment to be created."

(In this event, the issue will be raised with the Integration director and escalated to the steering committee. Due to many projects requiring work from the Micro-services team, this happened on three occasions. Fortunately, the team anticipated the delays, and the escalation resulted and quicker turnarounds than other projects experienced.

How is this Different from Basic Risk Management?

DoBs certainly overlap with risk management. The critical difference lies in the socialization and pre-approval of the escalation procedures to expedite action. Having a risk occur and turn into an issue then requires communication and issue escalation.

Using the risk response route is akin to sending a high-importance email to everyone at the affected location that there is a fire and they must evacuate. Then hope they read it, take it to heart, and act on it with the appropriate urgency. Having a DoB with a pre-approved escalation plan is more like sounding the fire alarm. It has been discussed and approved before; now we just need to do what was agreed. Since issues are like fish smells (they get worse the longer you leave them), things we can create upfront to speed resolution are often worthwhile. 

How to Implement DoBs

First of all, we need to be realistic about the effectiveness of DoBs. If we try to create too many, we will not gain the agreement or buy-in for the resolution we need to make them effective. I suggest no more than 5-10. Likewise, they need to be based on critical-consequence threats, not minor impact problems. If we cry-wolf too often, we will be correctly ignored. So, only use them for issues that would threaten the success of the project.

For serial, plan-driven projects, DoBs can be added to the project charter and updated at phase boundaries. Wording can be as simple as:

"The following Definition of Broken (DoB) items identify scenarios that would trigger immediate escalation to the sponsor and addition to the issues list reviewed at biweekly steering committee meeting:

• Building permits not obtained by June 15^th
• The pumping station is not operational at full capacity by year-end
• Telemetry software not completed and accepted by Feb. 28^th“

For hybrid and agile projects, DOBs can be drafted alongside the Definition of Done (DoD) and reviewed and updated at retrospectives as necessary. They can be recorded in the team charter you posted somewhere visible. "Our Definition of Broken (DoB) items that signifies immediate team resolution comprises:

• Customer satisfaction ratings less than 80%
• Servers not installed and acceptance tested by May 1^st
• Page load speeds over 3 seconds
• Critical bug cycle time > 2 days
• Team eNPS below 30”

Parting Thoughts

If the Definition of Done (DoD) is a broadly accepted and understood concept in your organization, consider discussing a DoB. Maybe it makes sense to try them? The criteria can be agreed upon with vendors and team members, product owners, business representatives and any group with a stake in the project.

The goal is not to set traps for future punishment but to promote constructive dialog and consensus about what constitutes a significant problem. Then collaboratively define the escalation procedure and gain agreement to expedite these issues, should they ever occur.

The process has a subtly different effect than documenting risks which is often not a collaborative process agreed to by both the triggering and impacted stakeholders. Creating a list of DoBs and making it visible can change behavior and impact outcomes.

Also, discussing issues and escalation plans with sponsors can uncover priorities not identified in the chartering process. The more we learn about what constitutes success, acceptable variation, or failure, the better we can navigate project decisions and direction to better outcomes. 

Note: I first wrote about the Definition of Broken (DoB) in my book Beyond Agile.