Skip to content

Pain Point Entry (PPE) - “Jim Is the Process”

1. What Was Going On

It’s mid-season at USA Clay Target.

Every Saturday night around 9pm, season scoring must be run. This is not optional. Scores must be processed, published, and correct, or the organisation looks incompetent at best and unreliable at worst.

At present, this entire operation depends on one person: Jim.

Jim is very good at this. Jim is also very human.

No one else can reliably run the process end to end. This has been accepted as “normal” for years, largely because nothing has gone catastrophically wrong yet.

The organisation is currently one bad flu away from chaos.

2. The Conversation That Triggered This Step

The conversation didn’t start as a process discussion. It started as concern.

Someone asked a simple question:

“What happens if Jim can’t run scoring one Saturday?”

The room went quiet.

A few answers were attempted:

  • “He always has.”
  • “We’d figure it out.”
  • “Let’s not worry about that right now.”

None of these were answers.

Eventually, someone said:

“We should probably write this down as a problem.”

This suggestion was met with the enthusiasm usually reserved for filing taxes.

Nevertheless, a PPE was requested.

3. The Artifact

Below is the Pain Point Entry as it was submitted. No interpretation. No fixes. No heroics.

# Pain Point Entry (PPE)

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

---

## 2. Who Is Affected?
* Operations
* League participants
* Leadership

---

## 3. Initial Evidence (If Any)
* Season scoring has been run exclusively by the same individual for multiple seasons
* No documented process exists that enables others to execute scoring independently

---

## 4. Reporter Information
* **Name:** Jim
* **Team/Department:** IT / Operations
* **Date Logged:** 2025-01-18

---

## 5. Additional Notes (Optional)
If the scoring process is delayed or missed, scores cannot be published on time and downstream reporting is impacted.

4. What Almost Went Wrong

Several things tried very hard to sneak into this PPE:

  • Proposed solutions (“we should automate this”)
  • Judgement (“this is a bad practice”)
  • Hero narratives (“Jim does everything”)
  • Technical details (“the script, the database, the cron job”)

All of these were removed.

The PPE was forced to answer one question only:

What is the problem, as observed?

Not why it exists. Not how to fix it. Not how impressive Jim is.

Just the problem.

5. The Decision

Decision Question Is there a clearly stated, business-relevant problem here?

Decision Made Proceed.

Why This Was Good Enough The PPE:

  • described a single-point-of-failure risk
  • avoided proposing solutions
  • framed the issue as business continuity, not inconvenience

It didn’t explain everything. It didn’t need to.

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

Now Allowed

  • Validate whether this risk is real and repeatable
  • Look for evidence beyond “everyone knows this”

Still Not Allowed

  • Designing systems
  • Writing requirements
  • Automating anything
  • Turning Jim into a service

This was still a problem definition, not a project.

7. Why This Step Matters

This is the moment where an unspoken assumption became an explicit risk.

Until now, the organisation was relying on:

  • tribal knowledge
  • goodwill
  • and Jim’s continued availability

The PPE didn’t solve the problem.

It did something more important: It made the risk visible and discussable without drama.

Everything else depends on that.

8. Sarcastic Footnote

If this step had been skipped, the next artifact would have been a diagram explaining why Jim needed to clone himself.

Science has not yet delivered.