Directors’ Closure Review

Closing the Loop on Root Cause

The Problem

Root cause analysis was happening at Western Governors University. What wasn’t happening was follow-through. After a high-severity outage, the responsible engineering team would identify the root cause and list action items to prevent recurrence. Those action items would sit in a ticket. The ticket would age. Nobody checked whether the fixes were actually made. And when the same root cause produced another outage months later, the cycle repeated. Conducting root cause analysis is a pointless exercise if the root cause is never actually addressed.

The Solution

Brian Jolley, Director of Service Management at Western Governors University, established the Directors’ Closure Review (DCR). The mechanics were straightforward but the accountability was real.

The Five Whys. Each high-severity outage required a root cause analysis using the Five Whys method — not just to find the root cause, but to reveal what specific actions would permanently prevent recurrence.

The Panel. A monthly panel of IT directors — from Product, Support, Engineering, Infrastructure, Security, Vendor Management, and other departments — convened to hear each Software Engineering Manager (SEM) present their findings. Directors could debate the thoroughness of the analysis, ask questions, and push back if the work was lacking.

The Accountability. Action items had to include a self-imposed due date set by the SEM. Those dates were tracked. Due dates could not be changed without director approval. High-severity outage action items were not to be late — and late items counted against the team’s scorecard score.

The Consequence of Underpreparation. If an SEM came to the panel underprepared, they were told to reschedule. The age of their open outage ticket continued to climb, holding their scorecard down. There was no path to a good score that didn’t go through doing the work thoroughly.

The Cross-Functional Value

The DCR panel regularly surfaced issues the owning team had missed on their own. The security team would discover access control issues. DBAs would identify inefficient or overly chatty database calls. Occasionally, the panel discovered that someone had pushed code to production outside the Request for Change (RFC) process — a serious violation that could result in termination. Going around the Change Advisory Board was considered a subversive act at WGU.

Systemic Issues Beyond IT

The DCR didn’t only fix IT problems — it exposed organizational boundary issues that no single team could see. Sometimes a root cause originated from a department outside IT entirely. A content change with a bad character sequence could cause data corruption downstream through systems that had no idea the change was coming. An academic department could issue curriculum updates, demand integration of outside software, or allow direct modifications to course content — all without IT involvement.

When a root cause came from outside IT, the DCR created action items for VP-to-VP escalation — raising the problem to a level where cross-departmental authority existed to address it. The directors couldn’t fix it. But they could make sure the right executives knew it needed fixing.

The Results

Brian Jolley’s Directors’ Closure Review produced hundreds of completed improvements across dozens of applications over its years of operation at Western Governors University. Combined with the scorecard system, it created a closed accountability loop: outage occurs → root cause identified → action items defined → due dates set → progress tracked on scorecards → directors review completion → recurrence prevented.

The frequency and duration of high-severity outages dropped from weeks to hours within four months of implementation.

Why It Worked

Peer accountability. Being presented to a panel of directors and their bosses is a different kind of motivation than a ticket sitting in a queue. The SEMs knew their work would be examined by people who understood the systems well enough to spot shortcuts.

Cross-functional perspective. A single team’s self-assessment has blind spots. A room full of directors from different disciplines catches what one team can’t — security gaps, database inefficiencies, unauthorized changes, upstream dependencies.

Scorecard integration. The DCR didn’t exist in isolation. Late action items hit scorecards, scorecards were reviewed weekly, and scores affected team autonomy. The feedback loop was tight.

Escalation path. For systemic issues that crossed departmental boundaries, the DCR created a formal path to VP-level attention — preventing the most damaging pattern: a root cause that everyone can see but nobody has the authority to fix.

Connected Work

The DCR was downstream from Outage Response (which standardized how outages were detected and documented) and fed directly into the Scorecard system through the Open Problem Resolution Tasks indicator. Together, these three initiatives created the accountability infrastructure that made measurable improvement possible at Western Governors University.