Case Studies

You've probably read enough case studies to know they can be polished to the point of useless. These aren't that. All client work is shared anonymously, but the results are real, what happens when competing priorities get cleared, decisions stop stalling, and teams are finally able to follow through.

Case Study: Government Ministry — From Tech Gating to Business Alignment That Sticks

A provincial government ministry had a rigorous approval process. The problem was it answered the wrong question. Projects were being evaluated on technical merit while leadership was asking "is this work actually connected to our priorities?" Nobody could answer that clearly, and momentum kept dying in the gap between the two.

The fix wasn't more governance. It was a lightweight business architecture layer that gave both technical and business teams a shared language for decision-making, one that could be built incrementally and updated as the organization evolved.

The result: every project traceable to a strategic objective, faster business case creation, and a model that kept getting stronger over time instead of becoming shelf ware.

The lesson that transfers: Work that can't be traced to a real priority will always compete for attention. Not because people aren't trying, but because the system has no mechanism to protect what matters most.

Doubling Throughput Without the Chaos: A Behaviour-First Reset in Financial Services

wo mission-critical delivery teams in a high-compliance financial environment had been through a "transformation." It didn't take. Sprints ran like waterfall. Priorities shifted mid-cycle with no protection. Approvals bottlenecked. Confidence eroded. The teams were working harder and delivering less.

No new framework was introduced. No process was overhauled. The reset focused entirely on behaviour, how priorities were protected, how decisions were made, and how accountability was reinforced under real delivery pressure.

The results over six months:

  • Month 3: Throughput doubled. All mission-critical deployments hit as planned.
  • Month 4: Throughput up 150%.
  • Month 5: Throughput up 200%.
  • Month 6: Sprint commitments completed with zero carryover. Planned vs. actual delivery fully stabilized.

The lesson that transfers: "Agile" terminology can mask waterfall behaviour. The workflow reveals the truth. When you fix the conditions, protected priorities, clear decision ownership, reduced handoffs, delivery becomes predictable again even when everything around it keeps changing.

From “Doing Agile” to Progress You Can Trust

A 300-person organization was doing everything right on paper. Events running. Tools in place. Metrics tracked. And yet delivery kept falling short, hotfixes on the main revenue application were constant, and PII incidents were raising the stakes every quarter.

The problem wasn't process. It was the operating conditions underneath it, a roadmap teams had stopped trusting after years of pivots, decisions that defaulted to leadership instead of the people closest to the work, and workflow gaps that kept creating rework nobody was tracking.

No framework was replaced. The assessment identified the specific behavioural and operational gaps creating the drag, and targeted changes were made directly to those.

The results:

  • 70% reduction in hotfixes on the main revenue-generating application
  • ~75% of two years' worth of work completed in under a year

The lesson that transfers: "Doing agile" and making progress are not the same thing. When the behaviours underneath the process don't change, how decisions get made, how priorities are protected, how leaders actually show up, the process becomes a costume over the same old system.

.

Breaking Siloed Delivery Patterns with Targeted Team Training

Product, dev, and QA weren't failing. They were stuck in a handoff system that made collaboration harder than it needed to be and nobody had named it clearly enough to fix it.

Targeted team training created real early gains. Communication improved. New practices took root. Teams that had been working in isolated loops started solving problems across boundaries.

Then leadership changed. Restructuring hit. Momentum stalled.

The organization paused further training and that decision tells the most important part of the story. Training can open the door. It cannot hold it open. When leadership behaviour and system-level reinforcement aren't there to sustain the gains, the environment eventually wins.

We publish this case study because it's honest. Not every engagement produces a clean before-and-after. But every engagement teaches something worth sharing and this one is clear: if you want training to stick, the conditions around it have to be ready to hold it.

The lesson that transfers: Leadership sets the ceiling. In high-flux environments, what leaders do daily determines whether progress continues or quietly reverses.

The Hidden Cost of the Business–Technology Gap

In 2013, I analyzed the root causes behind the friction that slows most organizations down, not the visible friction of missed deadlines and budget overruns, but the quieter kind. The gap between how Business and Technology understand each other.

What the research showed wasn't a tooling problem or a process problem. It was trust, value, and shared language. When Business doesn't understand how Technology works, delays stop feeling like delivery issues and start feeling like reliability issues. When Technology can't translate its work into business terms, it appears expensive and slow, even when the work is essential.

The cycle is predictable: low understanding erodes trust, low trust slows decisions, slow decisions create reactive delivery, reactive delivery confirms every negative assumption both sides already held.

This insight shaped everything that followed, the behaviour-first approach, the focus on decision systems, the Stop Competing™ System itself. Predictable progress isn't a process problem. It's a relationship and operating system problem.

The lesson that transfers: If Business and Technology aren't sharing a common language, they're not just communicating poorly, they're optimizing locally and failing together.