Complexity Is the Default. Simplicity Is a Discipline.
No executive sets out to build a complicated program. Nobody opens a steering committee and says, “let’s make this harder than it needs to be.” And yet six months in, the program has fourteen workstreams, three parallel decision paths, and a status report that takes twenty minutes to read and tells you nothing.
Complexity doesn’t arrive by design. It arrives by default. It’s what happens when nobody actively works against it. Simplicity isn’t a natural state you fall into — it’s a discipline you hold, deliberately, against every day pulling in the other direction.
Here’s what that discipline actually requires. Skip any one piece of it, and you don’t get a slightly more complicated version of the same program. You get a different program — one that drifted there without anyone deciding it should.
Understand the problem before you solve it
Ask why more than once. Most teams stop at the first plausible answer, because the first plausible answer lets them start building. The vendor says the finance module needs sixty custom fields. Ask why. The answer is usually “that’s what the last system had.” That’s not a reason — it’s inertia wearing a reason’s clothes. Ask again and you find the actual requirement: three fields, and fifty-seven habits nobody’s questioned since 2014.
Skip this, and you inherit every unexamined assumption the previous system ever accumulated. You call it a “like-for-like migration.” It’s actually a copy of someone else’s drift.
Get clarity before you commit
Before a program starts, you need the big picture named out loud — who the stakeholders actually are, what the end goal is, what’s really motivating the sponsor to fund this. Not the version in the business case. The real one. And you need clarity on the assumptions underneath it, validated, not assumed to be true because they were written down with confidence.
Skip this, and the program runs on a shared fiction. Everyone nods at kickoff because everyone assumes someone else checked the foundation. Eighteen months later, you discover the “end goal” finance was building toward was never the one operations had in mind.
Hold the discipline in execution
Keep an open mind. Take risks deliberately — experiment, learn, refine — rather than betting the whole program on the first design. Balance design, quality, and service against each other instead of maximising one at the expense of the other two. Think end-to-end, not module by module. And challenge the status quo instead of accepting a vendor’s or a predecessor’s answer at face value just because it arrived with confidence.
Skip this, and you get a program that optimises locally and fails globally — a beautifully configured module sitting inside a process nobody stepped back to question.
Protect it through how the team operates
None of the above survives without structure — clear owners, a decision-making cadence, transparency about what’s actually happening rather than what looks good in the report. And it survives longest when the team values collective effort over individual glory, and holds one perspective above all others: the end customer’s. Not the sponsor’s comfort. Not the vendor’s delivery milestone. The person who has to use what you built. They are your judge, whether or not they’re in the room.
Skip this, and you get exactly what most ERP programs produce: a status report that stays green while three people privately know it isn’t, no one accountable for the decision that mattered, and a system that technically went live and quietly serves no one particularly well.
None of this is complicated. That’s the point, and also the trap. Every one of these disciplines is simple to state and effortful to hold — which is exactly why organisations don’t hold them. Complexity isn’t something you build. It’s what accumulates in the space where discipline was supposed to be.
