Method to Madness

Everything we do has a method attached to it. We rarely notice it, because most of the time the method is invisible — it’s just “how things are done.” But the method is doing all the work. It’s the difference between success and failure, between efficient and exhausting. Not the effort. Not the intention. The method.

There’s an old phrase for what happens when the method is wrong: madness. Not clinical madness — organisational madness. Repeating the same motion, harder each time, while the outcome stays the same or gets worse. Most people in that position assume they need more effort, more hours, more headcount. Rarely do they stop and ask whether the method itself is the problem.

If you’re struggling to achieve something — a goal, a habit, a project — the honest first question isn’t “why aren’t we trying harder.” It’s “is our method actually built for this.” Every system you trust without thinking about it — your self-help routines, the education system, political and economic institutions — is running on a set method. When conditions change and the method stops working, the institutions that survive are the ones that notice and adjust. The ones that don’t, keep applying the old method to a new problem and call the resulting failure something else — bad luck, bad people, bad timing.

Here’s the part that matters most for anyone sponsoring a transformation program: methods are supposed to scale in complexity with the task.

A simple task needs a simple method. Filing an expense report, onboarding a new starter, closing a routine purchase order — off-the-shelf process, no customisation required, and it works.

A complex task needs a complex method. Multiple departments, competing priorities, real interdependencies — you need more structure, more coordination, more deliberate sequencing than the simple case.

A very complex task needs a custom method — one designed specifically for that task, in that environment, under those constraints. Not borrowed. Not adapted from a template. Built.

This is where most transformation and ERP programs go wrong, and it happens quietly, long before go-live. A sponsor inherits — or approves — a delivery method that was designed for a different kind of complexity. A PMO template built for a single-site rollout gets applied to a multi-entity, multi-legacy-system transformation. A governance cadence designed for a project with one clear owner gets applied to a program with three business units that each think they own the outcome. A change-management approach that worked when the org had one operating model gets reused for a program that’s trying to standardise five.

None of this looks like a method problem while it’s happening. It looks like a resourcing problem, a vendor problem, a timeline problem, a people problem. Steering committees ask for more testers, more change managers, more weeks. What’s actually missing is a method that was built for the constraints of this specific environment — this data quality, this stakeholder politics, this level of organisational readiness — rather than a method that was good enough for the last program someone on the team delivered.

The struggle sponsors feel with transformation projects, ERP implementations, anything genuinely complex, is rarely a struggle with the technology. It’s the product of getting the method wrong before anyone realised they’d gone too far to change course cheaply.

So if you’re a sponsor sitting inside a program that feels harder than it should, here’s where to look before you ask for more resources or more time. Trace the method you’re actually running — not the one in the charter, the one people are actually following day to day. Ask where it came from: was it designed for this program’s specific complexity, or inherited from something simpler and never re-scaled? Then find the place where the team is already straining against it — the recurring friction everyone’s been quietly working around instead of naming. That friction point is usually where the method stopped matching the task, and it’s cheaper to fix now than after another two rounds of “more resourcing.”

The method is not visible until it fails. The question worth sitting with is whether you’d recognise the failure as a method problem — or whether you’d reach for more effort first, the way most of us do.