Trigger and Threshold Matrix: Keep the Gain After the Project Team Leaves

The Trigger and Threshold Matrix sets the threshold values that trigger monitoring alerts, reviews, or escalations for each controlled metric. That is the whole job. You name the metric, you set the point where good becomes watchful, you set the point where watchful becomes urgent, you state the action, and you name the review level.

Use it in the Control phase of RDMAICS, after you have proved the improvement works and before the project team disbands. This is the moment where most gains quietly leak away. The team stops watching, nobody else was told what to watch, and six months later the process has drifted back without anyone noticing the exact week it happened.

The matrix exists to remove that ambiguity. It converts a vague instruction to keep an eye on things into a numbered rule that a person who never attended a single project meeting can still follow. If the number crosses the line, the stated action happens, and the stated review level owns it.

It also pairs naturally with the Sustain phase. The thresholds you set here become the agenda items for later reviews. Without them, the Sustain phase has nothing concrete to review against.

Everything below uses the sample data that loads with the tool. It is a fictional case, built to show the mechanics rather than to describe any real organisation.

The scenario is a finance and payments process. Four metrics have been placed under control after an improvement project: field error rate, cycle time in hours, on-time payment percentage, and duplicate rate. Each has a green, amber and red threshold, a trigger action, and a named review level.

Those four metrics are not a random set. They cover quality at the point of entry, speed through the process, the customer facing outcome, and the financial risk of paying twice. Between them they would catch most of the ways this kind of process goes wrong. That breadth matters more than metric count.

The input table is deliberately narrow. For each row you give a metric name, three threshold bands, a trigger action, and a review level. Nothing else. The discipline comes from filling every cell, not from adding columns.

In the sample data the bands read like this. Field error rate is green at or below 6 percent, amber between 6 and 8 percent, red above 8 percent. Cycle time is green at or below 3 hours, amber between 3 and 4, red above 4. On-time payment is green at or above 97 percent, amber between 93 and 97 percent, red below 93 percent. Duplicate rate is green at or below 0.1 percent, amber between 0.1 and 0.2 percent, red above 0.2 percent.

Notice the direction changes. Three of the four metrics are lower is better. On-time payment is higher is better, so its green band sits at the top and its red band at the bottom. The tool does not assume a direction for you. You write the band as you mean it, including the comparison sign.

The trigger actions in the sample are deliberately different from each other. Field error rate triggers investigate at amber. Cycle time triggers escalate at red. On-time payment triggers root-cause at red. Duplicate rate triggers immediate hold. Review levels follow the same logic: Green Belt, AP Manager, Sponsor and Finance.

The result panel is a completeness check as much as a summary. The sample data returns 4 metrics, thresholds set at 12 of 12, with a trigger action at 4 of 4, and 4 review levels. The tool states that every metric has all 3 thresholds set.

Twelve of twelve is the figure to watch. Four metrics times three bands equals twelve required values. A gap there means a metric has a band with no definition, which in practice means nobody knows when to act on it. The same applies to the trigger action count. Four of four means every row has a stated action.

Below the summary, each metric is laid out as a card showing its green, amber and red thresholds and its trigger action. The cards make the matrix readable for someone who will never open the input table. You can print them, paste them into a control plan, or read them straight into a handover meeting.

The tool also offers an AI review that explains the result back to you in plain language. Use it as a second pair of eyes on the structure, not as a substitute for your own judgement about whether the numbers are right for your process.

The matrix is not reporting. It is a decision tool, and the decisions it forces are the ones project teams usually avoid.

The first decision is where good stops. Setting field error rate green at or below 6 percent is a commitment. Anything above that is no longer business as usual. The second decision is how much warning you want. The amber band of 6 to 8 percent buys you two percentage points of early notice before red.

The third decision is speed of response. Compare duplicate rate with cycle time. Duplicate rate triggers an immediate hold, which means the process stops. Cycle time triggers escalate at red, which means a conversation. Those are different levels of urgency written into the same table.

The fourth decision is ownership. Field error rate sits with a Green Belt. Cycle time sits with the AP Manager. On-time payment sits with the Sponsor. Duplicate rate sits with Finance. The review level tells you whose calendar the breach lands on.

The most common mistake is leaving an amber band empty. Teams set a target and a failure point, then skip the middle. Without amber you only ever find out once the process has already failed. The 12 of 12 count in the sample data exists to make that gap visible.

The second mistake is overlapping or gapped bands. If green stops at 6 percent and amber starts at 7 percent, a reading of 6.5 percent has no home. The sample data touches at the boundary instead, with green at or below 6 percent and amber from 6 to 8 percent, and each band carries an explicit comparison sign.

The third mistake is giving every metric the same trigger action and the same review level. If every breach escalates to the Sponsor, the Sponsor will stop reading the reports. The sample spreads four actions across four review levels for a reason.

The fourth mistake is setting thresholds at whatever the process did last month. A threshold is a decision about what you will accept, informed by capability and by customer requirement. Do not let a single good month set a limit the process cannot hold.

A matrix that lives only in a project folder does nothing. The point of naming review levels is so that the rules survive the people who wrote them.

Attach the four cards to the standard work for the process. Put the threshold values into whatever reporting or dashboard the team already reads, so the colour appears without anyone having to calculate it. Then state the trigger action next to the number, in the same place, so the reader does not have to look it up.

Give the handover meeting a short script. For each metric, read the green band, the amber band, the red band, the trigger action and the review level. Four metrics takes a few minutes. That short exercise is often the only time the receiving team hears the rules stated out loud.

Set a date to revisit. Thresholds are not permanent. If field error rate holds comfortably below 6 percent for a long stretch, the green band may be too loose to detect drift.

The tool records thresholds. It does not measure anything. It will not pull live data, it will not compare current performance against the bands you set, and it will not tell you which metrics are green or red today. Those four cards describe rules, not readings.

It will not tell you whether a threshold is correct. Setting cycle time green at or below 3 hours is your judgement. The tool will accept 3, or 30, with equal willingness. Nothing in the completeness counts checks whether a number is achievable or whether it reflects what the customer needs.

It will not detect gaps between bands, conflicting comparison signs, or metrics written in the wrong direction. The 12 of 12 count confirms that twelve cells contain text. It does not confirm that the twelve values form a coherent scale.

It will not make anybody act. A review level is a name in a table until a manager treats it as an obligation. The tool gives you the rule. Holding the gain still depends on the people who agreed to it.

Finally, it will not choose your metrics. Four rows in the sample case cover entry quality, speed, outcome and financial risk. Deciding which four matter in your process is upstream work, done in Measure and Analyse, and no threshold matrix can repair a poor choice made there.