Skip to content

Problem Evidence Validation (PEV) - “It’s Not Just Jim Being Dramatic”


1. What Was Going On

The PPE had been logged.

This alone did not convince anyone that a real problem existed.

From the outside, nothing appeared broken:

  • scoring was getting done
  • results were being published
  • no disasters had occurred

The pressure now wasn’t operational - it was credibility.

If this was just Jim being cautious, leadership didn’t want to spend time or money fixing a non-problem. Before anything moved forward, the team needed to answer a simple question:

Is this actually a risk, or just institutional paranoia?


2. The Conversation That Triggered This Step

The first reaction to the PPE was predictable.

“Has this ever actually failed?”

This was followed by:

  • “He’s always been available.”
  • “We’ve done it this way for years.”
  • “It works fine.”

Someone eventually asked the more uncomfortable question:

“How do we know it works fine if only one person can do it?”

That was enough to trigger a PEV.

Not to prove Jim was right - but to prove the problem existed independently of him.


3. The Artifact

Below is the Problem Evidence Validation as it was recorded.

No conclusions. No fixes. Just evidence.

# Problem Evidence Validation (PEV)

## 1. Problem Restatement
The weekly season scoring process depends on a single individual to execute and complete it correctly.

---

## 2. Evidence Collected
- Season scoring has been executed by the same individual for every scoring cycle in the past several seasons
- No secondary operator has independently completed the full scoring process
- No documented runbook exists that enables another individual to perform the process unaided

---

## 3. Observations
- Knowledge of the scoring process is largely implicit and undocumented
- Access to required systems and data is not broadly distributed

---

## 4. Affected Roles / Departments
- Operations
- IT
- League Administration

---

## 5. Validation Sources
- Operations staff
- League administration
- IT staff familiar with scoring dependencies

---

## 6. Confidence Level
High

4. What Almost Went Wrong

Several people tried to turn this into a causality exercise.

  • “We just need better documentation.”
  • “This is really a training issue.”
  • “If Jim took a vacation, we’d sort it out.”

All of these statements may or may not be true.

They were also irrelevant at this stage.

The PEV was narrowly scoped to one question:

Does the organisation rely on a single individual for a critical operation?

The answer was yes.


5. The Decision

Decision Question Does evidence confirm that this is a real, repeatable business risk?

Decision Made Proceed.

Why This Was Good Enough The evidence:

  • was observable
  • was repeatable
  • did not rely on opinion

No hypotheticals were required.


6. What This Unlocked (And What It Didn’t)

Now Allowed

  • Assess impact and urgency
  • Discuss cost of inaction
  • Frame the problem in business terms

Still Not Allowed

  • Proposing solutions
  • Designing systems
  • Writing requirements

The problem was now real - but not yet actionable.


7. Why This Step Matters

This step separated inconvenience from risk.

Until now, the problem could be dismissed as:

  • habit
  • preference
  • personality

The PEV made it clear that the dependency existed regardless of who held the role.

That changed the conversation from “Jim’s process” to “company exposure.”


8. Sarcastic Footnote

At this point, someone suggested that Jim “just not get sick during the season.”

This was not adopted as a mitigation strategy.