The programme has no measurable definition of success
Objectives are stated as capability rather than outcome, so nobody can say at any point whether the programme is ahead or behind.
Digital transformation consulting
Transformation programmes rarely fail on technology. They fail because the operating model, the funding model and the sequence were never made to agree. We work with executive teams to make them agree, and to define success in terms that can be measured before the programme ends.
Business challenges
Transformation advisory is commissioned when one of these has become visible at board level.
Technology changed, ways of working did not
New platforms were adopted while funding cycles, approval paths and team structures stayed as they were. The result is modern infrastructure operated at the previous speed.
The portfolio has grown past what can be maintained
Overlapping systems accumulated through acquisition, departmental purchasing and successive initiatives. Maintenance consumes the budget that change would need.
Annual funding cannot fund iterative delivery
Budget is committed yearly against a fixed scope, so learning during delivery cannot change the plan without a governance exception.
Dependencies were discovered rather than planned
Workstreams were scoped independently and now block one another. Sequencing is being renegotiated in steering meetings rather than designed up front.
Benefits were claimed but never measured
The business case assumed commercial gains that no one instrumented, so the next programme is approved on the same untested basis.
Business outcomes
What changes when strategy, sequence and funding are decided together.
- Transformation objectives expressed as outcomes that can be measured during delivery, not after
- A sequence where each increment delivers value independently and dependencies are planned rather than discovered
- A funding and governance model that can accommodate what is learned during delivery without requiring a formal change-control exception every time
- A portfolio position stating explicitly what is invested in, what is merely sustained, and what is being retired
- An operating model whose decision rights and funding cadence match the delivery speed the technology now permits
Why transformation advisory, specifically
The hard part is deciding the sequence and holding it against pressure.
Most organisations know roughly what they want their technology estate to become. What is genuinely difficult is the order: which changes unlock others, which can be deferred without cost, and which must not start until something else is finished.
Get that wrong and the programme delivers a sequence of individually reasonable projects that together produce little, because the enabling work was scheduled after the work it was supposed to enable.
We are engaged to set that sequence, define success in measurable terms, and make the funding and governance model capable of supporting it. We do not resell software or take vendor commissions, so a recommendation to buy less, or to stop a workstream, is available to us.
Our consulting approach
Four commitments that shape every transformation engagement.
Outcomes before initiatives
Every workstream is traced to a measurable business outcome. Work that cannot be traced is either enabling work that should be named as such, or it should not be funded.
Sequence is the deliverable
Dependencies are mapped before scheduling. The order in which change happens usually matters more than which specific changes are chosen.
Constraints are inputs
Funding cycles, procurement rules, regulatory position and available skills shape what is achievable. A roadmap that ignores them will be renegotiated within two quarters.
Instrument before you claim
Benefits are measured from a baseline captured before the change. A benefit claimed without a baseline cannot be defended and will not be believed at the next funding round.
Enterprise transformation strategy
Strategy here means a small number of decisions that constrain everything downstream: which capabilities differentiate the business and therefore justify building, which are necessary but undifferentiated and should be bought, and which should be retired.
We express those decisions with their reasoning and their expiry conditions, so a future team inherits why rather than only what.
Target operating model
The operating model determines how quickly decisions are made and how much coordination each change requires. Modernising platforms without changing it produces cost without speed.
We define team boundaries against the systems they own, the decision rights each level holds, and the interfaces between product, engineering and operations.
- Team boundaries aligned to system ownership rather than to function
- Decision rights stated per level, so escalation is a path rather than a habit
- Interfaces between product, engineering, security and operations made explicit
- Skills and capability gaps named, with a plan rather than an assumption
Technology roadmap
A roadmap is a sequencing artefact, not a list of intentions. Ours states what happens in what order, what each step depends on, and what becomes possible once it completes.
Increments are sized so each has an independent business case. A roadmap whose first measurable value arrives eighteen months out will not survive its second budget review.
Application portfolio rationalisation
Most estates carry overlapping systems that accumulated rather than were chosen. Rationalisation asks a disposition question per application: invest, sustain, consolidate or retire.
The assessment considers business criticality, technical condition, total cost and the risk of continuing — and names retirement candidates explicitly, because portfolios rarely shrink by accident.
- Disposition per application with the reasoning recorded
- Overlap identified across departments and acquired estates
- Total cost of ownership including the maintenance that is not budgeted as such
- Retirement candidates named, with the dependencies that block them
Architecture position for the programme
A transformation needs an architectural position early, even where the detailed design comes later. Without one, each workstream chooses independently and the estate that results is the one the programme was meant to replace.
We set the constraints that matter across workstreams: where data is mastered, how systems integrate, which platforms are standard, and which decisions are reserved. Detailed design is enterprise architecture consulting, and it is usually worth running alongside rather than after.
- Data mastery decided across workstreams rather than per project
- Integration approach set before workstreams choose independently
- Standard platforms named, with a documented exception path
- Reserved decisions listed, so teams know what they may not choose
Process and workflow automation
Automating a process that should be eliminated makes a poor process faster and harder to change later. We assess whether the process is necessary before assessing how to automate it.
Where automation is right, the constraint is usually integration and exception handling rather than the happy path, so those are designed first.
Data-driven decision making
Transformation programmes are frequently steered on activity metrics because outcome metrics were never instrumented. We identify the small number of measures that would actually change a decision, and establish where each comes from and who owns it.
Where the data foundation is the constraint, that is data engineering work and usually needs to happen first.
Organisational change and adoption
Adoption failure is the most common way a technically successful programme produces no benefit. Systems are delivered, and the people expected to use them continue with the previous process because it still works and is familiar.
We plan for the retirement of the old path as an explicit deliverable, because a new system that runs alongside the one it replaces produces two costs and one benefit.
Governance and funding model
Annual fixed-scope funding and iterative delivery are structurally incompatible: one commits scope a year ahead, the other expects scope to change as evidence arrives. Programmes caught between them spend their governance capacity on change requests.
We design governance that reviews direction at intervals rather than approving scope once, and a funding approach that allocates to outcomes and durable teams rather than to project scope.
- Decision forums with stated authority, so escalation has a destination
- Funding allocated to outcomes and persistent teams rather than to fixed scope
- Stage reviews that can stop or redirect work, not only approve continuation
- Architecture decisions recorded so governance reviews reasoning, not just status
Security, risk and regulatory position
Transformation changes where data lives, who can reach it and which third parties are involved. Treated as a late review, that becomes a blocker at exactly the wrong moment.
We establish the regulatory boundary and data-residency position before architecture, and name the risks each increment introduces or retires. Detailed control design is security architecture work.
Vendor and sourcing strategy
Sourcing decisions are architecture decisions: they determine which capabilities you can change quickly and which require a contract negotiation.
We assess build, buy and partner options against switching cost and strategic importance. Because we neither resell nor receive commissions, the recommendation carries no margin for us — including when it is to reduce the number of suppliers or to insource.
Enterprise delivery model
Transformation is delivered by the organisation, not by the advisory engagement. The delivery model therefore has to be something the organisation can actually run: team structures that persist, a cadence that matches the funding cycle, and reporting that answers governance questions without a separate reporting effort.
We define how workstreams coordinate, where dependencies are resolved, and which decisions are made at team level rather than escalated. Programmes that escalate every cross-team decision spend their capacity in meetings.
- Persistent teams aligned to outcomes rather than temporary project structures
- Dependency resolution at the lowest level that has the authority
- Reporting generated from delivery systems rather than assembled manually
- A cadence matched to the funding and governance cycle
Practices we hold programmes to
A small number of practices separate transformation programmes that deliver from those that consume budget. None is novel; the difficulty is holding to them once delivery pressure arrives.
Increments must be genuinely independent. Enabling work must be scheduled before the work it enables. The old path must be retired rather than left running. Benefits must be baselined before the change. And the programme must have a defined condition under which it stops — because a programme that cannot be stopped is not being governed.
Benefits realisation and measurement
A benefit that was not baselined before the change cannot be evidenced afterwards, and the next business case is then built on the same assumption rather than on the result.
We define the measure, capture the baseline before delivery starts, and state the interval at which it will be reviewed — including the condition under which the programme should be stopped.
Programme risk management
Transformation risk concentrates in dependencies, in adoption and in the assumption that enabling work will be ready when it is needed.
We maintain risk at the level where it can be acted on: named owner, the increment it threatens, and the decision that would retire it. A risk register with no owner and no trigger is a document rather than a control.
What you receive
Decision artefacts, not a slide deck. Each is intended to survive a change of sponsor.
- Transformation strategy with the capability decisions and their reasoning recorded
- Target operating model: team boundaries, decision rights and interfaces
- Sequenced technology roadmap with dependencies and independent increments
- Application portfolio disposition covering invest, sustain, consolidate and retire
- Governance and funding model designed for iterative delivery
- Benefits framework with measures, baselines and review intervals
- Programme risk register with owners and retirement conditions
Engagement models
Initial project design
Engaged before significant code exists, when structural decisions are still cheap to change. Produces the target-state architecture, the technology selection rationale, and a sequencing plan the delivery team can execute.
Mid-project assistance
Engaged when delivery has slowed, costs are rising, or a design that fitted the original problem no longer fits the current one. Diagnostic first: we establish what is actually causing the drag before recommending change.
Ongoing support
A named architect available as the system evolves, covering design review, technology decisions and course correction. Delivered under a subscription rather than a fixed project scope.
Enterprise delivery
How a transformation engagement runs, and where it hands over.
Free first consultation
An overview of the objectives and the current estate, and an honest assessment of whether advisory is what you need.
Current state and constraints
Portfolio, delivery performance, funding cycle, regulatory position and the capability actually available.
Target state and options
Capability decisions, operating model options and their implications, with the alternatives recorded alongside the recommendation.
Sequencing and business case
Dependency-led roadmap with increments that each stand alone, and the measures that will evidence them.
Governance establishment
Decision forums, funding approach and reporting that reviews direction rather than only status.
Advisory through delivery
Your teams execute. We remain available for sequencing decisions, architecture review and course correction.
Technology landscape
Transformation is largely a decision discipline. These are the categories the decisions concern.
Enterprise architecture tooling
Capability mapping, application portfolio catalogues and dependency modelling.
Integration platforms
The middleware and API layers that determine how expensive each new connection is.
Workflow and process automation
Orchestration across systems, with exception handling designed rather than assumed.
Analytics and reporting
The measurement layer that makes outcome-based governance possible.
Collaboration and delivery tooling
Work management and documentation that governance actually reads.
Identity and access platforms
Usually the first shared dependency a transformation encounters.
Industries served
Sector determines the regulatory and operational constraints the transformation has to satisfy.
Industry
Healthcare
Clinical safety, data protection and systems that cannot be taken offline for change.
IndustryBanking & Financial Services
Regulatory reporting and change control that must be evidenced.
IndustryInsurance
Legacy policy and claims platforms constraining the pace of everything else.
IndustryRetail & E-commerce
Channel consolidation and seasonal constraints on change windows.
IndustryManufacturing
Plant systems, ERP estates and a change calendar set by production.
IndustryTelecommunications
Large programme portfolios with deep inter-dependency.
IndustryGovernment & Public Sector
Procurement cycles and accountability requirements that shape sequence.
IndustryEducation
Constrained budgets and academic-calendar change windows.
IndustryEnergy & Utilities
Regulated assets and operational systems with no downtime tolerance.
IndustryLogistics
Partner integration and operational continuity during change.
Why NG&NR
Independent of vendors
We do not resell software or take commissions, so recommending fewer suppliers, less licensing or stopping a workstream costs us nothing.
Advisory, not programme staffing
We are engaged for direction and sequencing. Where the need is delivery capacity, we say so — that is a different and usually cheaper purchase.
Sequencing over ambition
We would rather deliver a smaller roadmap that survives its second budget review than a larger one that does not.
Named accountability
A named architect owns the technical position for the engagement and remains the point of contact.
Frequently asked questions
Deciding which capabilities to build, buy or retire; defining the operating model that will run them; and sequencing the change so each step delivers value independently. It is a decision discipline rather than a technology purchase.
Enterprise architecture answers how systems should be structured. Transformation advisory answers what should change, in what order, funded how, and measured against what. They overlap and are frequently run together, but the deliverables differ.
Three places, in our experience of the discipline: success was defined as capability rather than outcome; enabling work was scheduled after the work it was meant to enable; and the old process was never retired, so the organisation paid for two ways of working.
Partly, but it constrains what is achievable. Annual fixed-scope funding commits scope before evidence exists, so learning during delivery requires a change-control exception. Where the funding model cannot change, we sequence within it and say plainly what that costs in adaptability.
That depends on sequencing, which is precisely what the engagement decides. We size increments so the first measurable outcome arrives within a funding cycle rather than after one, because a roadmap that produces nothing measurable in its first year rarely survives to its second.
Yes, as independent counsel. We assess build, buy and partner options against switching cost and strategic importance. We do not resell and take no commissions, so the recommendation carries no margin for us.
Clarity on the outcomes that matter, authority to decide sequence, and willingness to retire things. Transformation without retirement is accumulation, and accumulation is what created the current estate.
By baselining before the change. We define the measure, capture the current value before delivery begins, and set the review interval. A benefit claimed without a baseline cannot be defended at the next funding round.
No. We provide the strategy, sequence, operating model and governance design, and remain available for decisions. Programme management is a delivery role that belongs inside your organisation, where the authority sits.
Then that is what we report. Reducing scope, consolidating suppliers or stopping a workstream are legitimate outcomes, and because we hold no vendor commissions they cost us nothing to recommend.
An architectural position is needed early, even if detailed design follows. Without one, workstreams choose independently and reproduce the estate the programme was meant to replace. The position can be lightweight; it cannot be absent.
Advisory is priced on seniority and time, usually as a defined assessment followed by optional ongoing support through a subscription. Pricing is transparent and includes GST. The first consultation is free.
Next step
Arrange a transformation workshop
A free first consultation covering your objectives, your current estate and where sequencing is likely to be the real constraint.
No cost, no obligation. Pricing is transparent and includes GST.