Diagnose and Reframe

30 min

Pain Point Types

Learning objective: Build a taxonomy of waiting, rework, error, search, duplicate entry, handoff, and judgment load.

Turn scattered complaints from the interview notes into seven classifiable pain-point types: waiting, rework, error, search, duplicate entry, handoff, and judgment load. Once classified, pain points of the same type can be discussed together, rather than handled one at a time in isolation.

• Waiting, extended case: a committee resolution has to wait for the next meeting to be confirmed, leaving the case completely stalled in between.
• Rework, extended case: budget-allocation forms often get bounced back for refiling because a field's definition is unclear.
• Error, extended case: manually calculating travel-reimbursement amounts, the currency conversion is often wrong.
• Search, extended case: staff have to dig up a three-year-old memo just to confirm how a similar case was handled before.
• Duplicate entry, extended case: a new student's information gets typed once into the enrollment system and again into the housing system.
• Handoff, extended case: cross-office approval cases often get stuck because no one knows whose desk it is on.
• Judgment load, extended case: every disciplinary case needs staff to compare it clause by clause against policy and judge which clause applies.

Key takeaway: Classifying pain points into seven types reveals which problems belong together, instead of being solved piecemeal.

35 min

Evidence and Baseline

Learning objective: Turn "slow, error-prone" into frequency/time/error/rework/volume evidence, and label it observed or estimated.

Vague adjectives (slow, often, a lot) must become specific numbers: how often (frequency), how long (time), error rate, rework rate, and volume. It must also be honestly labeled whether the number is observed (actually measured) or estimated (the interviewee's guess), both are useful, but their confidence level differs and should never be conflated.

1. 1Record the original words
   First write down the interviewee's exact phrasing (e.g. "often", "quite a bit") without rushing to translate it into a number.
2. 2Ask the quantifying follow-up
   Ask "roughly how often?", "about how many last month?", "if you had to guess a number, what would it be?"
3. 3Confirm the source
   Ask "how do you know that? Is there a system log you could check?" to tell observed apart from estimated.
4. 4Attach the label
   Write the converted number together with its observed/estimated label, never leave the number standing alone.

Key takeaway: Turn impressions into numbers, and honestly label them observed or estimated, that is the core of evidence awareness.

35 min

Root Cause vs Symptom

Learning objective: Use a lightweight why-chain, and treat any root cause as a hypothesis until there is evidence.

A symptom is the visible surface problem (e.g. "approval often drags on"); the root cause is what actually produces it. A lightweight why-chain (asking "why" a few times) digs deeper layer by layer, but every layer is only a hypothesis until evidence supports it. Never jump to a conclusion after asking "why" just once.

• Common trap one: asking "why" once and writing the answer straight into a report without probing further.
• Common trap two: blaming the root cause on "someone not being careful" instead of looking at the process or system design.
• Common trap three: extending each hypothesis layer by pure reasoning, without ever checking it against evidence.
• Common trap four: stopping the why-chain at the second layer while claiming the root cause has already been found.

Key takeaway: Root-cause analysis is a process of layered hypotheses checked against evidence, not a conclusion reached after asking why once.

30 min

Opportunity Boundary

Learning objective: Set an explicit start, end, in-scope, and out-of-scope, so an entire organization is never treated as one Use Case.

Interviews and process analysis can easily expand until "the whole department's workflow needs to change", a scope too broad to become an actionable Use Case. The opportunity boundary must explicitly state: which step it starts at, which step it ends at, which sub-processes are in scope, and which are explicitly excluded.

• Warning sign one: someone says "while we're at it, let's fix the next department's process too", a sign scope is quietly expanding.
• Warning sign two: the in-scope list keeps growing while start and end still are not pinned down.
• Warning sign three: someone suggests "let's just replace the system while we're at it", smuggling in a separate, bigger project.
• Warning sign four: the out-of-scope field is empty, a sign no one has seriously thought about where the boundary is.

Key takeaway: An explicit start, end, in-scope, and out-of-scope keeps a Use Case from swallowing an entire organization.

50 min

Process Discovery Sprint

Learning objective: Complete a current-state map plus a pain/evidence map that someone who was not part of the interview can still understand.

This is the course's capstone activity: integrate everything from the previous nine lessons (interviewing, process mapping, handoff/decision spotting, pain classification, evidence and baseline, root-cause analysis, scoping) into two formal artifacts: the Current-State Process Map and the Pain Point Map. The completion bar is that someone who was not part of the interview can understand the process and its pain points.

1. 1Assemble the current-state map
   Arrange the interview findings into a sequence with a clear start/end, each step labeled with actor/system/input/output.
2. 2Mark handoffs and decision points
   Flag where handoffs, queues, approvals, and duplicate entry occur on the map.
3. 3Assemble the Pain Point Map
   Classify each pain point and attach frequency/time/error/rework/volume evidence, labeled observed or estimated.
4. 4Have a non-participant read it
   Find someone who was not part of the interview to read both artifacts and flag anything confusing or unclear.

• Does the map's start/end match the opportunity boundary written in Lesson 9?
• Can every pain point be traced back to a specific step on the map, rather than listed out of thin air?
• Is every root cause clearly labeled "hypothesis" rather than stated as a settled conclusion?
• Does the owner field name a specific person or unit, rather than just "everyone"?

Key takeaway: The Process Discovery Sprint's completion bar: someone who was not part of the interview can still understand the process and the evidence behind each pain point.