Big Bang Over Incremental Delivery

The programme plan is beautiful. Nine months of build: full management group hierarchy, complete policy set, ExpressRoute, subscription vending, FinOps tooling, NZISM mapping, documentation, training. Launch is scheduled for Q4.

Q4 arrives. The platform is not live. Security review found gaps, the network design changed twice, and the vending pipeline has one blocker left. Meanwhile:

• Two business units have spun up their own subscriptions through the EA portal
• A project running a hard government contract deadline has deployed into a flat, ungoverned subscription “temporarily”
• The executive sponsor is asking, in every steering meeting, what the business has received for nine months of spend
• The answer, each time, is “nothing yet, but the foundation is nearly ready”

This is how landing zones die: not in a failed deployment, but in a cancelled programme.

Why Big Bang Fails Harder in NZ

Shadow IT fills every vacuum, faster than you think. NZ organisations are pragmatic to a fault. If there is no governed path in month six, someone creates one in month six, and once a business unit has a working subscription, a deadline, and a production customer, “migrating to the platform” becomes a second programme nobody funded.

Sponsorship has a half life. An executive sponsor who approved a 12 month platform programme will be asked about it in every quarterly review. NZ organisations run lean; a spend line with no visible output is the first cut when the next budget round gets tight. Incremental delivery is your sponsorship insurance.

The deadline will not wait. In NZ’s economy, contracts arrive with hard dates: a government RFP milestone, a peak season for a primary sector exporter, a retail Black Friday. Business units do not delay revenue for your platform. Plan for the deadline that arrives mid build, because it will.

Every month of delay increases the eventual migration cost. Everything deployed outside the platform during the build is later re work that competes with new platform features for the same scarce NZ engineering capacity.

The Fix: An Incremental Roadmap That Ships Value Every 4 to 6 Weeks

Each increment must deliver something a workload team can use, not just platform internal progress. A worked example for a mid size NZ organisation:

Increment 1 (Weeks 1 to 6): Minimum Viable Guardrails

• Management groups, identity foundation, billing structure
• A small policy set, in audit mode
• Ships: the org’s first two subscriptions under central visibility. Value: cost visibility and a single billing view for the CFO.

Increment 2 (Weeks 7 to 12): First Golden Path

• Basic subscription vending (manual trigger pipeline is fine)
• Baseline tagging, budgets, central log analytics workspace
• Ships: the pilot workload team (see Part 3) lands their first environment. Value: a real team, really onboarded, with a real story to tell.

Increment 3 (Weeks 13 to 18): Network That Works

• Hub network, hybrid connectivity, firewall, scoped to the pilot’s actual requirements
• Ships: the pilot’s production workload goes live on the platform. Value: production traffic. This is the milestone that buys the next two quarters of funding.

Increment 4 (Weeks 19 to 24): Compliance Depth

• Deny policies promoted from audit, NZISM control mapping, exception register with SLA
• Ships: audit evidence pack, or the security questionnaire answers that unblock an enterprise deal. Value: revenue enablement, not just risk reduction.

Increment 5+: Automate and Scale

• Self service vending, drift detection, FinOps dashboards, DR design
• Onboard wave two of workload teams

Notice what this sequence does: by week 18 there is a production workload on the platform. A big bang programme would not have shipped anything until month nine, and would have been fighting shadow IT the entire time.

Rules That Keep It Incremental

• Every increment ends with a demo to the business, not a status report. Show a deployed environment, a cost dashboard, a signed off audit pack. Tangible beats complete.
• “Ready for first workload” is a milestone with a date, and it is aggressively early. Everything after it is improvement, not launch blocking.
• Nothing on the roadmap is allowed to take more than six weeks without being decomposed. If a workstream cannot be, it is hiding a decision nobody has made yet, usually networking or identity.
• Resist scope gravity. Mid programme requests (“add a second region”, “full forced tunnelling”, “support this one team’s unusual architecture”) go to the backlog with a documented trade off, not into the current increment.
• Track shadow IT as a leading indicator. If unmanaged subscriptions appear during the build, that is the market telling you your increments are too far apart. Shorten them.

The Uncomfortable Trade

Incremental delivery means publicly accepting imperfection. Increment 1 has thin guardrails. Increment 2’s vending is semi manual. Someone will call it “not production grade.”

The honest answer: it is incrementally production grade, with each gap documented and scheduled. The big bang alternative is fully production grade at a date that keeps slipping, while ungoverned estates grow around it. NZ organisations rarely survive the second option. The capacity, the sponsorship, and the market do not allow it.

The test: at any steering meeting, can you point to something a workload team is using this week? If the answer has been “not yet” for three consecutive quarters, the programme is not building a landing zone. It is building a case for cancellation.

Series Wrap Up

Across this series, eight failure modes, and every one of them fails before the first deployment:

1. No business context — architecture without NZ regulatory and commercial grounding
2. Governance as a blocker — deny first platforms that breed shadow IT
3. Building alone — no pilot partnership, no real world validation
4. Undefined subscription strategy — boundaries nobody can defend or bill against
5. Datacentre thinking — network designs inherited, not chosen
6. No operating model — an orphaned platform with no named owners or funded run years (pilot overview section 6; narrative follow up in The Operating Model)
7. IaC without discipline — a repo that stopped describing reality twelve months ago
8. Big bang delivery — perfection that never ships while the organisation routes around it

The common thread: a landing zone is a product, with NZ users, NZ obligations (Privacy Act 2020, NZISM, CPS 234, HIPC), NZ market constraints, and NZ scale resourcing. Teams that treat it as an infrastructure project deliver infrastructure nobody uses. Teams that treat it as a product deliver a platform the organisation actually adopts.

Design accordingly.

Have you watched a landing zone fail before it began, in NZ or anywhere? What was the root cause?