What Five Years of Enterprise Delivery Taught Us

Isaac: In five years, I've never seen a project fail because the brief was wrong. I've seen projects struggle because the brief was incomplete, ambiguous, or based on assumptions that turned out to be incorrect. But the brief itself was always a reasonable starting point.

The failures happen in the space between the brief and the build. In the interpretation. In the details that nobody thought to specify because they seemed obvious. In the stakeholder who had a different picture in their head from the one described in the document.

Discovery closes this gap. Not by writing a better brief, but by building shared understanding between everyone involved. The brief is a starting point. Discovery is where alignment happens.

Rainui: Enterprise projects are political. Not in the cynical sense. In the human sense. The CFO who's cautious about the budget has a board meeting next month where they need to justify the spend. The operations manager who keeps changing requirements is watching their team struggle with the current system and feeling responsible. The IT director who's slow to approve integration access is worried about the security incident that happened last year.

Understanding the human context behind stakeholder behaviour changed how I approach every project. When you understand why someone is resistant, you can address the actual concern rather than just the stated objection.

Isaac: Our best projects delivered working software to real users within six weeks. Our most challenging projects saved everything for a single big launch after six months.

Small releases build confidence. The client sees progress. Users give feedback that shapes the next iteration. The team maintains momentum because they can see the impact of their work. And if something goes wrong, the blast radius is small.

Big launches create anxiety. Months of work are evaluated in a single moment. Users encounter everything at once and are overwhelmed. Bugs that would have been caught in an incremental release are now critical issues in a go-live scenario.

We now structure every project around early, small releases. Even if the first release is limited in scope, getting something live and generating feedback changes the dynamics of the entire project.

Isaac: When we build a system for a client and it succeeds, they inevitably want the next one. The second project should be easier because we know the client, understand their domain, and have established trust.

In practice, the second project is often harder. The client's expectations are higher because the first project went well. The scope tends to be more ambitious. And the assumption of shared understanding means less discovery time, which sometimes means less alignment.

We've learned to treat every project as if it's the first, even with long-standing clients. The discovery discipline doesn't get lighter. The scope conversations don't get shorter. The rigour stays the same.

Rainui: When we moved from studio work to enterprise, I expected design to matter less. Enterprise users care about functionality, right? They'll tolerate an ugly interface if it does the job?

Wrong. Enterprise users care deeply about the quality of the tools they use every day. An interface that's clunky, confusing, or ugly creates friction that compounds across hundreds of interactions daily. The projects where we invested most heavily in design quality had the highest user adoption rates. Every single time.

The form factor changed. The aesthetic is different from consumer design. But the principle is the same: design that serves the user's needs produces better outcomes than design that satisfies a requirements checklist.

Isaac: I underestimated this for the first two years. I thought the work was building software. The work is building software and communicating about building software in equal measure.

Weekly status updates. Transparent risk conversations. Demo sessions where the client sees real progress. Honest conversations about trade-offs and timelines. The projects where communication was excellent succeeded even when technical challenges arose. The projects where communication lapsed struggled even when the technology was solid.

We now invest as much planning in communication cadence as we do in sprint planning. It's not overhead. It's how trust is maintained and decisions are made well.

Isaac: Enterprise procurement cycles are measured in months. Decisions involve committees. Budget approval has its own timeline. Everything moves slowly.

Until it doesn't. A regulatory deadline appears. A competitor launches. A board member asks a pointed question. Suddenly the timeline is compressed and everything that was glacial becomes urgent.

The teams that survive this compression are the ones who did the preparation work during the slow phase. Discovery completed. Architecture defined. Team allocated. When urgency hits, they're ready to execute. The teams that spent the slow phase waiting are the ones who struggle when the deadline arrives.

Every project gets discovery. No exceptions. Not a reduced version. Full discovery. It's the highest-return investment in any project.

Design and engineering together. From day one. This isn't negotiable. The quality of the output depends on these disciplines being integrated, not sequential.

Honest timelines with visible buffer. Clients respect honesty. They don't respect surprises. Buffer isn't padding. It's honest accounting for uncertainty.

Small releases, continuous feedback. Get working software in front of real users as early as possible and keep the feedback loop running throughout.

The work is the marketing. In a market as small as NZ, every project is a reference. Deliver well and the next project finds you.

We're heading into 2020 with more ambition than we've ever had. The enterprise market in NZ is maturing. The problems are getting harder. The stakes are getting higher. And the practice we've built over five years is ready for what's next.