This is the last Before You Deploy field note. It is also the pattern underneath the earlier ones: SELL! tried to finish the platform in one programme, then discovered the organisation would not wait.
To see why SELL! ended up with deny policies and a laptop repo, rewind to the programme plan that started it all.
SELL! is a fictional company. Any resemblance to a real platform team’s war story is the point.
Setting the Scene
Q4 board week at SELL!. The original plan was beautiful. Nine months of build: full management group hierarchy, complete policy set, ExpressRoute, subscription vending, FinOps tooling, NZISM mapping, documentation, training. Launch scheduled for Q4.
Kiri, the executive sponsor, has been asking the same question since the first quarterly review.
No workloads until every workstream is green.
- Hold the ready for first workload gate until networking and vending are both complete.
- Absorb mid programme requests into the current increment.
- Report status, not demos.
- Treat shadow IT as a compliance problem, not a delivery signal.
The Pilot: The Programme Plan Works Perfectly
Steering, month three. Kiri looks at the rag chart. Workstreams are amber or green. She asks the question out loud:
“What has the business received for nine months of spend?”
Sam talks to the slides. The foundation is nearly ready. Tui’s questionnaire is parked until launch. Ross is still waiting on the batch. There is no demo. There is no workload. Launch is still “when everything is perfect.”
The rag chart is tidy. The organisation is already elsewhere.
- Kiri asks what the business has received.
- The answer is the foundation is nearly ready.
- Two units have already opened their own subscriptions.
- The government contract date has not moved.
The Increment Nobody Shipped
This is how landing zones die: not in a failed deployment, but in a cancelled programme.
Board Week: Nothing to Show
Q4 arrives. The platform is not “done.” Security review found gaps. The network design changed twice. The vending pipeline has one blocker left. Meanwhile:
- Two business units have spun up their own subscriptions through the EA portal
- A government contract deadline forced a flat, ungoverned subscription “temporarily”
- Kiri asks, 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”
Post-Slip: The Cracks Widen
Steering still hears “nearly ready.” Then the first budget round gets tight, and the cracks widen.
Shadow IT Issues
NZ organisations are pragmatic to a fault. They get pragmatic, as Part 2 put it, and they open a subscription when the governed path is still nine months away. If there is no governed path in month six, someone creates one in month six. 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 Issues
An executive who approved a nine month platform programme will be asked about it in every quarterly review. A spend line with no visible output is the first cut when the budget round gets tight. Incremental delivery is sponsorship insurance.
Deadline Issues
Contracts arrive with hard dates. Business units do not delay revenue for your platform. Plan for the deadline that arrives mid build, because it will.
| Symptom | What to do instead |
|---|---|
| Perfection delays launch. Every month increases shadow IT and erodes sponsorship. | Deliver in iterations: core guardrails, identity and networking, vending, advanced policies, then
FinOps. Hit a ready for first workload milestone fast, and ship something valuable every four to six
weeks. References: Why Landing Zones Fail · CAF: Migrate methodology · WAF: Safe deployment practices |
The Lessons We Can Learn
Each increment must deliver something a workload team can use, not just platform internal progress. The weeks below are the counterfactual: the programme SELL! should have run, not the Q4 they got.
Increment 1 (weeks 1 to 6): minimum viable guardrails. Management groups, identity foundation, billing structure, a small policy set in audit mode. Ships: the first subscriptions under central visibility. Value: a single billing view for the CFO.
Increment 2 (weeks 7 to 12): first golden path. Basic subscription vending, baseline tagging, budgets, central Log Analytics. Ships: the pilot workload team lands their first environment. See Part 3.
Increment 3 (weeks 13 to 18): network that works. Hub network and hybrid connectivity scoped to the pilot’s actual requirements. Ships: production traffic on the platform. This milestone buys the next two quarters of funding.
Increment 4 (weeks 19 to 24): compliance depth. Deny policies promoted from audit, NZISM mapping, exception register with SLA. Ships: audit evidence or questionnaire answers that unblock an enterprise deal.
Increment 5+: automate and scale. Self service vending, drift detection, FinOps dashboards, DR design, wave two teams.
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.
The two business units already running rogue, and the flat government subscription, are not a compliance sideshow. They are the Increment 3 and later migration backlog. The government contract deadline is your first vending customer, not a reason to wait. Bring those estates onto the path as soon as Increment 2 can issue a subscription.
Incremental delivery has a failure mode too: increments that never accumulate. Perpetual Increment 1 churn, no compliance depth, no wave two. If Increment 4 never arrives, you have split the work up and still delivered a platform nobody can evidence. The aggressively early gate exists so increments stack.
| Symptom | What to do instead |
|---|---|
| Steering gets status reports. "Nearly ready" for three consecutive quarters. | Every increment ends with a demo the business can see: a deployed environment, a cost dashboard, a
signed off evidence pack. Tangible beats complete. References: CAF: Strategy methodology · WAF: Operational Excellence principles |
Operations: The Missing Ready For First Workload Gate
Ready for first workload is a milestone with a date, and it is aggressively early. Nothing on the roadmap takes more than six weeks without being decomposed. Mid programme requests go to the backlog with a documented trade off, not into the current increment. Track shadow IT as a leading indicator: unmanaged subscriptions during the build mean increments are too far apart.
Incremental delivery means publicly accepting imperfection. Increment 1 has thin guardrails. Increment 2’s vending may be semi manual. Someone will call it “not ready for production.”
The honest answer: it is incrementally ready for production, with each gap documented and scheduled. The big bang alternative is fully ready for production at a date that keeps slipping, while ungoverned estates grow around it. NZ organisations rarely survive the second option.
| What they did | Should have done |
|---|---|
| Held all value until every workstream was complete. | Set a ready for first workload date six weeks out and defended it. |
| Reported status instead of showing deployed artefacts. | Ended every increment with a demo a workload team was using. |
| Absorbed scope into the current programme whenever someone asked. | Parked mid programme requests on a backlog with explicit trade offs. |
| Treated shadow IT as disobedience. | Treated unmanaged subscriptions as a signal to shorten increments. |
The Moral
A landing zone that ships nothing is not a foundation. It is a case for cancellation. SELL! held all value until every workstream was green, then discovered the organisation would not wait.
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 Before You Deploy, seven field notes expand the failure modes from Why Azure Landing Zones Fail Before They Begin:
- Part 1: No business context
- Part 2: Governance as a blocker
- Part 3: Building alone
- Part 4: Undefined subscription strategy
- Part 5: Datacentre thinking
- Part 6: IaC without discipline
- Part 7: Big bang delivery (this note)
Operating model belongs with the programme story in The Operating Model.
The common thread: a landing zone is a product, with NZ users, NZ obligations, 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.
An incremental roadmap sized for NZ teams is a fractional deliverable. See Fractional Cloud Architecture and Advisory.
Design accordingly.
One Block · build from here