The hard part was never the technology

After a couple of decades shipping systems, the pattern is boringly consistent: the technology is rarely the thing that decides whether a project succeeds. The platform almost always works. The integration almost always gets built. And yet plenty of perfectly good systems quietly fail to make any difference at all.

What decides it is whether people actually change how they work, and that has very little to do with the stack you chose.

Where projects actually stall

Not in the build. They stall at the point where a new system meets an old habit, a half-defined process, or a team that was never really asked whether the change made their day better. You can deliver flawlessly against the spec and still land something nobody wanted to use.

The uncomfortable bit is that this is usually visible early. The warning signs are human, not technical: a sponsor who can’t articulate the outcome, a process that “everyone just knows”, a rollout plan that’s really just a go-live date.

What if the existing process is actually just broken?
All you’re doing is digitising a broken or hugely inefficient paper process.
Inevitably (and trust me, I’ve been there) all you’ll end up with is an even worse, albeit now “digital”, version of the process that you were trying to fix.

What I do differently now

• Design the process before the configuration. The tool should fit the work, not the other way round.
• Treat adoption as a workstream with an owner, not a line on the closing slide.
• Get the people who’ll live with the system into the room early, while their feedback can still change something.
• Measure whether behaviour actually changed, not whether the project closed on time.

None of this is glamorous, and none of it shows up in a vendor demo. But it’s the difference between a system that ships and a system that sticks. The technology was always the easy part.