Methodology Choice, Scaling, and Who Actually Decides
The deck's stated objective: examine and understand implementation methodologies; discuss executional challenges with enterprise-wide digital transformations. Where the article gives the discovery-driven philosophy and the case gives the ANZ story, the deck supplies the mechanics — the actual menu of rollout strategies, the classical-vs-agile methodology debate, and the decision-rights frameworks needed to argue precisely about what ANZ got right or wrong.
The "tree swing" cartoon opens the deck: nine different pictures of the same request — how the customer explained it, how the business consultant described it, how the project leader understood it, how the analyst designed it, how the programmer wrote it — versus what the customer actually needed.
The deck's framing device for the whole session: every implementation failure is a gap between some stage's understanding and the next stage's, compounding by the time software ships.
Implementation Strategy — The 4Ps
Big Bang (Plunge)
Implement all at once
Cut over the whole new application, organization-wide, on a single date. ANZ's "early 2018, entire organization" target and 13,000-person goal reads as this strategy applied to an operating-model change, not just software.
Pilot
One department or location first
Test acceptance and usefulness in a contained setting before deciding whether to scale. Bray's 2016 Apple Pay sprint functioned as a de facto pilot for agile methods — but wasn't a formal pilot of the NWOW operating model itself.
Phased
Roll out incrementally by department/location
Extend based on demonstrated acceptance. NWOW's actual result — strong in technology (9,000+ people), stalled elsewhere — looks like an accidental, unplanned phased rollout rather than a deliberate one.
Parallel
Run old and new systems side by side
Usually paired with Big Bang as a safety net until cutover. Not really available to ANZ — you cannot run an "old org chart" and "new org chart" side by side the way you can run two IT systems.
Classical vs. Modern Implementation Methodology
The deck's central tension: should software development (or, by extension to ANZ, organizational change) follow a logical, documented sequence of steps, or remain flexible and allow people to exercise discretion? Classical methods (CMM, Waterfall) answer the first way; modern methods (RAD, Agile) answer the second.
| Project Task | Waterfall | Agile |
| Users Needs | Up front and discontinuous; user reps and IT managers | Constant interaction between actual users and developers |
| Document Requirements | Fully elaborated, written requirements | High level; more verbal communication |
| Scheduling | Plan a one-time delivery; long-term | Continuous short-term planning |
| Prioritization | One-time only, usually at beginning | Reprioritize at every release |
| Validation | Quality Assurance (QA) responsibility | Users and developers' responsibility |
| Changes | Formal change control meetings | Informally adjust at every release/iteration |
CMM — 5 Levels
Initial → Repeatable (process) → Defined (engineering) → Managed (quantitative) → Optimizing (change). Best-documented method in the world, appeals to organizations wanting control and certification — but "in the wrong situation and hands may stifle innovation."
Requirements/Implementation Tradeoff
A "shortest possible schedule" exists below which completion probability collapses and cost rises — the deck's chart shows freezing requirements too early (or too late relative to implementation start) drives this same cost-schedule penalty.
Read directly onto ANZ: Waterfall/CMM = disciplined, well-documented, essential for big mission-critical projects. Agile = lean, minimalist, fast, essential in uncertain environments. The deck's own closing line: leaders must decide which methodology, and how much of it, fits their organization's strategy, structure and culture — NWOW applied agile's culture and structure company-wide without first testing whether every function's conditions actually favored it.
The Productivity Dip — "Escape from Alcatraz"
MIT CISR's J-curve (J. Ross): Plan (plot) → Implement (run and dive) → Stabilize (resurface) → Improve (swim) → Transform (run). Relative productivity dips below zero immediately after implementation, before eventually exceeding the pre-transformation expectation line. The framing question for class: was ANZ's May 2019 pause the expected, healthy dip in this curve — or evidence the swim never started?
Agile Mechanics — SCRUM
Roles
Product Owner & Scrum Master
Self-governing, multidisciplinary teams of 3–9. The Product Owner sets vision/roadmap and owns results; the Scrum Master coaches agile technique and removes impediments — structurally close to ANZ's squads and tribes.
Cadence
User Stories → Sprint → Retrospective
Rank-ordered ideas broken into 1–4 week Sprints, tracked on a Kanban board, opened with a Daily Standup and closed with a Sprint Retrospective (what worked, what didn't, how to improve).
Challenges
Over-reliance on tools; low psychological safety
Teams chase sprints/dashboards while missing agile's real driver — how people work together. Without trust, dissent goes unspoken and rapid prototyping breaks down. This maps directly onto Carnegie's "frozen middle."
Satire, But Sharp
"Have We Taken Agile Too Far?"
"We don't have project plans, we are Agile!" / "Once we are Agile, we'll no longer need Project Managers." / "I thought we were Agile, so why is leadership giving us deadlines?" — a checklist of agile-as-excuse, worth testing ANZ's own language against.
When Agile Actually Fits — And a Cross-Session Bridge
Favours Agile
Volatile market conditions, feasible customer collaboration, complex/unknown problems, modular work customers can use incrementally, and interim mistakes that only cost learning, not catastrophe.
Favours Waterfall/Discipline
Stable markets, clear/stable requirements, familiar work with known solutions, work that can't be used until complete, and mistakes with severe consequences — arguably contact centres, branches, and dealing rooms.
Direct bridge to Session 3 (DeepSeek/DBS): the deck puts DBS Bank — the Session 3 case — side by side with ANZ on six dimensions: leadership commitment (deep/sustained vs. moderate/tactical), agile integration (strategic/holistic vs. structural/partial), cultural shift (broad/behaviour-driven vs. patchy/process-driven), capability building (high investment vs. slower/inconsistent), implementation pace (phased with maturity vs. fast then paused), and customer focus (embedded vs. secondary). The deck's own conclusion: without core success factors — leadership commitment, strategic alignment, organizational change — even well-intentioned agile and digital transformations will struggle to scale, regardless of geography. Use this table to argue ANZ's problem wasn't agile itself; DBS proves agile scales when leadership commitment and pacing match.
Scaling and Who Decides
Agile at scale asks whether whole business segments — not just teams — can learn to operate this way; the deck's own warning is that dozens of new agile teams get "bottlenecked by slow-moving bureaucracies," and that annual budgeting should be complemented with a "venture capital-like" funding approach — precisely the funding-model mismatch Venter named in the ANZ case.
Bottlenecks
Global vs. Local · Centre vs. BU · Functional vs. Functional · Inside vs. Outside
Four recurring sources of decision-authority gridlock in large rollouts (Rogers & Blenko, HBR) — worth testing against ANZ's tribe/squad/divisional-manager structure.
RAPID
Recommend · Agree · Perform · Input · Decide
A decision-rights framework (Rogers & Blenko): the 'D' is the single accountable decision maker; 'A' roles hold veto power. Useful for asking who actually held the 'D' on NWOW's pace — Elliott, Venter, or the tribes themselves.
Group Decision-Making Quality (Russo & Schoemaker; M. Roberto)
Four-step cycle: Framing → Gathering Intelligence → Coming to Conclusions → Learning from Experience — with intellectual conflict (assumption testing, a positive input to decision quality) kept distinct from interpersonal conflict (which erodes understanding and commitment if unmanaged). High-quality decisions and implementation require both good analysis and genuine buy-in — a decision point is reached only when disagreements become shared understanding, not when dissent is simply overruled.