Enterprise software project governance: what NZ businesses need to get right

Most conversations about enterprise software focus on what to buy and how much it costs. The question that gets less attention — and causes more project failures — is how to govern the build once it starts.

Complex software implementations fail for a predictable set of reasons. Scope grows without formal approval. Key stakeholders stop engaging mid-project. UAT is compressed to meet a go-live date that was set before anyone understood the complexity. The cutover is improvised rather than planned. None of these are technical failures. They are governance failures — and they are avoidable.

This guide is for NZ businesses managing a complex B2B software implementation: a custom ERP, a trade portal with deep system integrations, or a platform that will run core operations. It is not about government frameworks. It is a practical guide to the governance structures that consistently separate successful implementations from expensive ones.

Why complex software needs explicit governance

A small website project or internal tool can be managed informally. A complex B2B software build cannot. The difference is the number of decisions that need to be made during the project — and the cost when they are made badly or not made at all.

A custom ERP or integrated trade platform involves hundreds of design decisions that will not all be visible at the start: how a particular edge case in the pricing model should work, whether a workflow should follow process A or process B, what happens when an integration partner's system is temporarily unavailable. If these decisions are made ad hoc by whoever is available, they will be inconsistent. If they escalate to a decision-maker who is not engaged, they will stall. If they are not made at all, they surface as bugs and rework during UAT.

Governance does not eliminate this complexity. It structures how decisions get made and by whom — so the project can move through it rather than getting stuck in it.

The steering committee: structure and purpose

The steering committee is the governing body for the project. Its job is specific: it approves scope changes, resolves escalations that cannot be settled at the working level, and holds the go/no-go decision at key milestones — most importantly, go-live.

Three to five people is the right size. A larger committee requires consensus that is difficult to reach quickly; a smaller one (or a single sponsor) lacks the breadth to catch operational blind spots. The membership should include:

• Executive sponsor. A C-level or general manager who owns the project budget and has authority to make decisions. This person's active engagement — not delegated participation — is a strong predictor of project success. When the executive sponsor is absent or detached, scope disputes and escalations pile up unresolved.
• Business process owner. The person who runs the primary process the software needs to support — the operations manager for a warehouse system, the finance manager for an ERP, the sales director for a trade portal. They know where the current process actually breaks, and they will be accountable for adoption after go-live.
• Technology or IT representative. Someone who understands the technical environment — the systems the new software needs to integrate with, the infrastructure it will run on, the security requirements it needs to meet. In many NZ mid-market businesses this is an external IT provider rather than an internal role.

The steering committee should meet fortnightly during build — often enough to catch problems early, infrequently enough that the agenda covers real decisions rather than status updates. Status updates are the project manager's job, reported in writing before the meeting. Steering committee time is for decisions.

Change control: the most under-rated governance discipline

Informal scope additions are the leading cause of budget overruns on complex software projects. The pattern is consistent: the project starts with an agreed scope, a stakeholder adds a requirement in passing during a working session, the development team builds it, and nobody tracks the accumulation until the project is significantly over time and budget.

Change control is the process that makes this visible. Every request to change the agreed scope — however small it seems — goes through a written change request: what is being asked for, why, the estimated impact on cost and timeline, and an explicit approval decision. Approved changes are recorded. Rejected changes are recorded. Nothing is done because someone asked in a meeting and nobody said no.

In NZ businesses, where teams are smaller and relationships more informal than in large enterprises, change control can feel bureaucratic. The practical framing is simpler: a change request is documentation that a decision was made. Without it, disputes about what was agreed and what was added are resolved by whoever has the most persuasive memory. With it, the record is clear.

One practical rule: any change that touches a system integration, a pricing calculation, or a customer-facing workflow should trigger a change request regardless of how small it appears. These are the areas where the knock-on effects are largest and least visible upfront.

User acceptance testing: what good looks like

UAT is the phase where the people who will actually use the software test whether it does what they need it to do. It is distinct from developer testing (which verifies the code works as written) and from demonstration sessions (which show selected features in favourable conditions). UAT tests the whole system against real workflows, with real data, run by real users.

Several things consistently undermine UAT on NZ software projects:

• Insufficient time. When earlier phases run late, UAT is the buffer. Two weeks of scheduled UAT becomes five days. Issues are found in production instead of testing.
• Wrong participants. UAT is assigned to senior people who test the main workflow but miss the edge cases that front-line staff encounter daily. The warehouse supervisor who processes the actual exception orders, the accounts person who handles the non-standard invoicing — these are the testers who find the issues that matter.
• No test scripts. Unstructured testing covers what testers happen to think of. Structured test scripts — specific scenarios derived from documented requirements — cover what the system is supposed to do. For a complex build, structured scripts will find two to three times the issues that unstructured testing finds.
• No defect triage. UAT generates a list of issues. Without a clear triage process — what is a blocker, what is a post-launch fix, what is a misunderstanding — teams either hold up go-live for every minor issue or proceed with blockers they have not identified as such.

For a complex ERP or trade platform, two to four weeks of structured UAT is realistic. Budget for a fix cycle within that window — UAT is supposed to find things.

Go-live risk management

Go-live is the highest-risk point of any software implementation. Several things happen simultaneously that have never happened before: the new system takes live transactions, the old system stops being the system of record, and staff are operating in a new environment under normal business pressure.

Managing this risk requires three things.

A documented cutover plan. Not a slide deck — a hour-by-hour checklist of every action required to transition from old to new. Who runs each data migration step and in what sequence. What verification checks confirm each step completed correctly. When the rollback window closes (the latest point at which you could abort and return to the old system). Who is on call for the first 24 hours. Go-lives that are improvised produce improvised problems that are harder to diagnose under pressure.

A defined rollback position. Before go-live, the steering committee should have agreed on the specific conditions under which they would roll back — return to the old system and reschedule. These conditions should be defined in advance, not negotiated in the heat of a difficult go-live evening. Common rollback triggers: the new system cannot process the core transaction type, a critical data migration step failed verification, a key integration is not functioning. A rollback is not a failure — it is the correct decision when the alternative is going live with a broken system.

A stabilisation window. The 30 to 90 days after go-live are not normal operations. Issues surface that UAT did not find — edge cases in real transaction volumes, integration timing issues that only appear under load, workflow gaps that emerge when all user types are in the system at once. The development partner should have a defined support arrangement for this window, with clear response-time commitments for blocking issues.

NZ-specific considerations

Several governance patterns that work well in large enterprise settings require adjustment for NZ mid-market businesses.

Teams are smaller, and the same people often wear multiple hats. The operations manager on the steering committee is also a UAT tester and often a key subject-matter expert during build. This is manageable, but it means time commitment needs to be planned explicitly — not assumed to fit around a normal workload. The governance structure should be proportionate to the project: a $300,000 custom platform needs more structure than a $50,000 internal tool, but neither needs a twelve-person committee.

The IRD seven-year record-keeping requirement is a practical consideration for any implementation that touches financial data. The go-live plan should include how historical data is preserved — either in the new system, in the old system (kept read-only), or in an archive — and how it can be accessed for a tax audit. This is not a technical afterthought; it is a legal requirement that needs to be in the project plan before build starts.

For systems that connect to Accredo, MYOB, Xero, or other accounting platforms, the integration go-live and the platform go-live should be coordinated — and the integration partner should be part of the cutover planning and the stabilisation roster. Integration issues are the most common source of post-go-live escalations, and they require access and expertise that the development partner cannot provide alone.

Governance is not overhead — it is how projects stay on track

The businesses that experience the worst outcomes on complex software projects are rarely the ones with the most ambitious scope. They are the ones where governance was treated as optional overhead, where the steering committee stopped meeting after month two, where change requests went undocumented, where UAT was compressed, and where go-live was treated as a date to hit rather than a risk to manage.

Good governance does not guarantee a smooth project. But the absence of it reliably predicts the specific kinds of problems — cost overruns, schedule slippage, post-go-live crises — that damage relationships, erode confidence in the investment, and take months to recover from.

If your business is at the stage of planning a significant software implementation — or managing one that is off track — the discovery phase guide covers what should be locked down before build starts. For the data migration dimension, the ERP data migration guide covers what actually moves and how to prepare. If you want to talk through what governance looks like for your specific project, reach out to the Zeabyte team — we build and operate custom ERP and operational software for established NZ businesses, and have managed complex integrations and go-lives for clients running Accredo, MYOB Acumatica, MYOB Exo, CSB-System and more.