How to Build a Risk-Escalation Decision Log for Project Managers in 21 Days

F2 how-to guide for project managers and risk owners

A project can have a risk register, a review meeting, and an escalation policy while important decisions remain invisible. The problem appears when a warning signal is discussed informally, a temporary deviation becomes part of the plan, or a risk owner says that someone else is deciding. The project continues, but nobody can reconstruct who knew what, when the exposure changed, or why the team accepted the next step.

A risk-escalation decision log closes that gap. It is not another activity tracker. It records the condition that triggered concern, the decision threshold, the accountable decision owner, the evidence considered, the boundary placed on the work, and the date on which the exposure must be reviewed again. The method below gives a project manager a 21-day way to build that discipline without turning risk management into paperwork.

Andreza Araújo has consistently connected safety leadership with the quality of ordinary operating decisions. In A Ilusão da Conformidade (The Illusion of Compliance), the central warning is that a completed process does not prove that the work is controlled. A decision log is useful for the same reason. It makes the decision visible, not merely the existence of a form.

What you need before starting

Choose one live project with meaningful interfaces, such as construction, commissioning, maintenance, a technology implementation with physical work, or a major process change. The method is strongest where schedule pressure, contractor coordination, design uncertainty, and changing work conditions can alter the exposure.

Before opening a new log, gather the project risk register, the current change records, the list of risk owners, and the last two formal review minutes. You do not need a perfect register. You need enough material to compare declared risk with the decisions that the project is actually making. If the existing register is too broad to use, start with one material exposure rather than trying to repair every line at once.

Keep the log separate from personal medical information, confidential investigation details, and disciplinary records. It should contain operational facts and decision evidence, while sensitive case material remains in the system designed to protect it.

Step 1: Define what belongs in the log

Write a one-sentence rule that explains when a project decision must be recorded. A useful starting point is this: record any decision that changes the exposure, the control, the sequence, the authorization, the resource level, or the person who owns the next action.

This rule prevents the log from becoming a diary of every conversation. It also catches decisions that are often hidden inside schedule recovery, design clarification, contractor coordination, procurement substitution, and temporary work arrangements. The question is not whether the team called the item a risk. The question is whether the decision changed the conditions in which people will work.

Andreza Araújo’s safety leadership work places responsibility in the operating system rather than in slogans. Use that principle here. If the decision can change exposure, it deserves an owner and a traceable rationale.

Step 2: Create the minimum decision fields

Build a simple table with fields that force clarity without encouraging long narrative. Each entry should answer six questions in plain language.

• What changed or what signal was observed?
• Which exposure or critical control could be affected?
• What decision is required, and by when?
• Who has the authority to make that decision?
• What boundary or interim control applies while the decision is open?
• What evidence will show that the decision worked?

Add the date, project phase, affected work group, status, and next review date. Avoid a field called “comments” as the main record. A comment box hides missing decisions because it lets the writer describe uncertainty without assigning responsibility.

Step 3: Translate warning signals into decision questions

Project teams often escalate a label instead of a decision. “High risk,” “urgent,” and “needs management attention” sound serious, but they do not tell the owner what must be decided. Rewrite each warning as a question that can be answered.

For example, replace “lifting plan concern” with “Can the planned lift proceed before the ground-bearing capacity and exclusion zone are verified?” Replace “temporary access issue” with “Which access route is authorized until the permanent route is installed and inspected?” A decision question makes the missing evidence visible, which helps the right role enter the discussion.

Use evidence from the field, design, schedule, permit, equipment status, competence record, or contractor interface. James Reason’s work on latent failures remains useful here because a visible warning can be the last expression of several earlier weaknesses. The log should therefore capture the condition that made the decision necessary, not only the person who raised it.

Step 4: Set escalation thresholds before the next crisis

Define three practical thresholds for the project. The first is a local correction, where the supervisor or work package owner can restore the expected condition without changing the approved plan. The second is a project escalation, where the project manager must decide because scope, sequence, resources, or interfaces will change. The third is a leadership or technical escalation, where the exposure exceeds the project’s authority or the available evidence is not sufficient to proceed.

Do not make the thresholds depend only on a risk score. A low numerical score can still require escalation when a critical safeguard is uncertain, when work is proceeding outside the approved sequence, or when the decision would create a precedent for later work. Record the reason for escalation in operational language.

Use the same thresholds across the project only when the work conditions justify it. A confined-space entry, a temporary electrical arrangement, and a design change may need different evidence and different decision owners, even if a matrix gives them the same color.

Step 5: Assign the decision owner, not only the action owner

An action owner fixes something. A decision owner has the authority to decide whether the work can proceed, under what boundary, and with which evidence. Those roles may be held by the same person, but they are not interchangeable.

For each open entry, name one decision owner and identify the technical role that must provide input. Do not assign “the project team,” “EHS,” or “the contractor” as the owner. A group can contribute evidence, but a group cannot provide a reliable escalation path.

Link the log to the project’s risk register when the decision changes the exposure or control description. A risk register explains the broader risk picture, while the decision log shows how the project acted at a specific moment. The two records should agree, but they should not duplicate one another.

For a deeper operating model, compare this method with the risk-owner review for high-consequence work and use the decision log to prepare the next review.

Step 6: Put an interim boundary around open decisions

An unresolved decision must not become permission to continue normally. Write the temporary boundary in a form that a supervisor and contractor can understand at the point of work. The boundary might limit the task sequence, restrict access, require a second verification, hold a load below a defined condition, or pause the work until a specific control is available.

State who can remove the boundary and what evidence they must review. A temporary control without an owner becomes a permanent workaround. That is why the log needs both a decision date and a boundary review date.

When a process, design, material, or sequence has changed, connect the entry to the project’s change review. The guide on management of change and different safety review states can help the team decide whether the issue requires a formal change process rather than a local note.

Step 7: Verify the decision with evidence from the work

Close an entry only when the evidence shows that the decision changed the relevant condition. A meeting minute, a completed training record, or a signed approval may prove that a conversation occurred, but it does not prove that the control worked.

Choose evidence that matches the decision. A field verification may confirm an exclusion zone, isolation, access route, or equipment condition. A design review may confirm that the changed specification protects the intended boundary. A work observation may show whether the revised sequence is practical under real conditions. A contractor interface review may confirm that responsibilities remain clear after mobilization.

If the evidence is mixed, leave the entry open and record the next decision. Closure is not a reward for administrative completion. It is a claim that the project has enough evidence to manage the exposure within its authority.

The related explanation of event-tree branches and control escalation is useful when the team needs to test whether a safeguard can actually stop the unwanted sequence.

Step 8: Run the 21-day review and improve the rule

Use the first three days to define fields and thresholds, days four through fourteen to record live decisions, and days fifteen through twenty-one to review patterns. Do not wait until day twenty-one to discover that the log is too vague to use.

At the review, ask which signals were escalated late, which decisions had no clear owner, which interim boundaries lasted longer than planned, and which evidence repeatedly failed to demonstrate control. Look for repeated conditions rather than counting entries. A larger number of entries can reflect better visibility, while a small number can reflect silence or weak escalation.

Update one project rule based on the review. You might clarify who owns temporary work, add a design role to a threshold, change the review cadence for a high-consequence interface, or require field evidence before a specific decision is closed. The point of the 21-day cycle is to improve the decision system, not to create a permanent spreadsheet ritual.

How should a project manager know the log is working?

The log is working when a new warning signal reaches the role that can decide, the project can state the boundary while the decision is open, and the closeout evidence describes what changed in the work. It is not working when every entry ends with “monitor,” when ownership moves between departments, or when the record shows approvals without field verification.

A strong log also improves the quality of project conversations. People can challenge a decision without relying on memory, seniority, or the loudest voice in the room because the threshold, evidence, and authority are visible. That is consistent with Andreza Araújo’s broader position in Sorte ou Capacidade (Luck or Capability), which treats adverse outcomes as connected to the conditions and decisions that shape work, not as isolated bad luck.

Final checklist for the first 21 days

• Define the project conditions that require a logged decision.
• Use fields that identify the signal, exposure, authority, boundary, and evidence.
• Write escalation thresholds before the next urgent decision.
• Assign one decision owner for every open entry.
• Place a temporary boundary around unresolved exposure.
• Close entries only with evidence that matches the decision.
• Review repeated conditions and change one project rule on day 21.

Project managers who want to strengthen the connection between compliance, leadership, and operating decisions can explore Andreza Araújo’s books and practical resources through the Andreza Araújo store. The next useful step is to choose one live project decision and make its owner, boundary, and evidence visible before the next review.