Initial observation
Understanding the status of several jobs at once meant gathering updates from different people and sources.
Case study · Sector: Construction & Technical Services
Quotes, jobs, materials, crews, and changes all moved forward in parallel, but the real picture of what was going on stayed scattered across messages, spreadsheets, and people. Before deciding what needed attention, someone had to manually piece together what was actually happening.
A recognisable way of reaching clarity
The information needed to track jobs, crews, materials, and changes was spread across different channels, forcing management to ask around and reconcile updates before it could even tell where a blocker was.
What relationships kept the problem in place?
Updates happening across different channels
No one sees the full picture
Changes live in messages and in people's heads
Context gets lost between the office and the site
Visibility depends on asking around
Problems reach management already behind schedule
The path from first impression to the real problem.
We didn't start by picking a solution. We started by testing whether the apparent problem was the right one.
Editorial reconstruction of the reasoning, based on the documented challenges, goals, and results. Not a literal transcript of the Discovery sessions.
Initial observation
Understanding the status of several jobs at once meant gathering updates from different people and sources.
First hypothesis
IncompleteA central dashboard could solve the lack of visibility over the operation.
Why it looked right
The most obvious difficulty was that there was nowhere management could quickly check the status of each job.
What changed our reading
The source information was still being updated in messages, spreadsheets, and conversations.
Statuses such as awaiting materials, approval, in progress, or complete weren't being logged consistently.
A dashboard would only ever show stale information if the update process kept happening outside of it.
Why we changed direction
The problem didn't start with visualisation. It started the moment a change happened on site and never turned into shared operational information.
New direction
Instead of starting with the management dashboard, the focus shifted to statuses, ownership, updates, and exceptions across the life of each job.
Deep-dive notes
What principle answered each pattern?
Principle 01
Principle 02
Principle 03
What changed in the way of working?
From
Asking several people just to understand the status
To
Seeing exactly where the operation needs attention
Status lived in messages and people
Status travels with each job
Management had to ask to understand
Management sees where it needs to act
Problems surfaced late
Deviations become visible earlier
What was underneath the symptom?
Symptom
Lack of control over the jobs
Real problem
The operation's status doesn't exist as shared information
Principle
Make progress visible the moment it changes
“Operational visibility doesn't start with a dashboard. It starts when every relevant change leaves behind a status that whoever needs to decide can actually understand.”
Related idea
Why the status of a job site still depends on askingA job site is rarely short on information. It has too much of it, scattered across too many places — and that's what forces someone to ask before anyone can decide.Explore the reasoningNext case study
Sector: E-commerce & RetailWhen growing the catalogue makes it harder to find what to buyThe context changes. The method holds.