If your systems are
under real strain —
start here.
Four real systems, documented honestly: where they broke, what it took to hold them, and what changed because of specific decisions — not because everything finally became clear.
Read the one closest to what you’re navigating. If it names your situation, the thinking behind it goes considerably deeper than the case itself.
Each case follows
the same honest pattern.
Problems are rarely well-defined when the work begins. Systems rarely start clean. Clarity rarely exists upfront — it has to be built, decision by decision, in conditions that do not wait for certainty.
None of these are presented as finished successes. They are presented as evidence of judgment under real constraint — which is the only kind of evidence that actually means something in a consulting conversation.
Scale named honestly. Geography, regions, and the size of the operation — stated plainly, without naming the organisation.
Real constraints, not generic ones. The specific things that made each system hard to build at the scale it was built for.
Decisions, and the reasoning behind them. Not just what was built — why it was built that way, and what alternative was rejected.
Outcomes scoped to what was actually observed. No inflated claims. No results beyond what the documented work covers.
Most are shaped in reality — where data is incomplete, processes are fragmented, and decisions carry consequences long before anyone can be certain they are right.
Systems in Practice exists because that reality is rarely written down honestly. Case studies get polished into success stories after the fact. What actually happened — the wrong turn, the constraint nobody saw coming, the decision made without enough information — gets edited out.
This is the unedited version. Four systems, documented at the level of detail that actually transfers — not motivational, but useful to someone facing a version of the same problem.
Four systems.
Four different kinds of hard.
Each case sits in a different part of the PM Pathfinder model — data, signal, commercial intelligence, and governance at scale. Read the one closest to what you are navigating, or read all four to see the pattern across them.
Real systems, mapped to
the Signal → Perception loop.
Every case here is a real-world instance of the model — proof that the loop is not theoretical. Two stages don’t have a documented case yet. That’s not a gap in the model. It’s where the next cases will sit.
Decision and Perception are where the next two Systems in Practice cases will live — the gap is the roadmap, not an oversight.
What these cases
collectively taught me.
Every one of these systems looked like a technology problem from the outside. None of them were. The hard part was always organisational — getting people to trust a new source of truth, agree on what a word like “done” means, or admit a process that had worked “well enough” no longer did.
None of these systems arrived finished. Each one became reliable through a cycle of building something real, watching where it broke, and correcting it — usually more than once. The version that eventually worked rarely resembled the version that launched first.
The honest version of a case is always more useful than the polished one. A system that “just worked” teaches nothing. A system that struggled in a specific, nameable way — and what it took to hold it — is the only kind of account that actually transfers to someone else’s problem.
Let’s talk about
what you’re actually facing.
These cases are the documented version. The conversation is where we get specific to your system, your constraints, and what’s actually possible from where you’re standing right now.