The advisory market covers so much ground that two organisations using it can mean entirely different things — one means replacing a core platform, another means changing how decisions get made, a third means putting a customer portal in front of an unchanged back office. All three are legitimate programmes. None of them is the same purchase.

This guide is written for the executive who has to commission the work and defend it afterwards. It sets out what advisory engagements actually consist of, how to scope one so the deliverable is a decision rather than a document, the engagement models available, what the first ninety days should produce, and how to measure whether the money achieved anything.

Key Takeaways

  • Advisory work should end in decisions and sequenced commitments, not in a strategy document.
  • The three failure modes are consistent: no executive owner, a scope defined by technology rather than outcome, and no measurement baseline taken before work starts.
  • Sequence by dependency and by evidence — the first delivery should prove the approach on something that matters and can fail safely.
  • Buy advisory and delivery separately when you can, so the party recommending the work is not the only party able to price it.
  • The measurement baseline has to be captured before the engagement begins; retrofitted baselines are unusable.

What You Are Actually Commissioning

Four distinct pieces of work sit under the heading, and clarity about which you need shortens every subsequent conversation.

Diagnostic. An assessment of where the organisation is — systems, data, processes, capabilities, and the gap between what leadership believes is true and what the estate actually does. Short, typically weeks, and the deliverable is a shared factual picture rather than a recommendation.

Strategy and sequencing. Deciding what to change, in what order, with what dependencies and what it costs. This is where most value is created or destroyed, because sequencing errors are expensive and difficult to reverse.

Delivery. Actually building and implementing. The largest cost by a wide margin, and the part most often scoped last.

Operating-model change. Altering how the organisation decides, funds, and governs technology work. The hardest to buy and the most frequently omitted, which is why so many programmes deliver new systems into unchanged decision-making and see the benefit evaporate.

A common and costly pattern is buying strategy from one firm and discovering that delivery was assumed to be theirs too. Separating the two purchases — or at least pricing them separately — keeps the party recommending the work from being the only party able to price it.

Infographic showing the four distinct pieces of transformation work — diagnostic, strategy and sequencing, delivery, and operating-model change — with typical duration and who should own each

Scoping So the Output Is a Decision

The most common complaint about advisory engagements is that they produce a document nobody acts on. That is a scoping failure more often than a quality failure.

Scope against decisions. Before the engagement starts, write down the specific decisions the work must enable — whether to replace or wrap the core platform, whether to consolidate two overlapping systems, whether to build a capability internally or contract it, what the first year's sequence is. Each decision gets a named owner who will make it and a date by which it will be made.

An engagement scoped this way produces different behaviour. The consultants are working toward a decision meeting rather than a deliverable date, the evidence gathered is the evidence needed for those specific choices, and the end of the engagement is visible from the start.

Two further scoping disciplines are worth insisting on. Require that the work states what it is not covering — the systems, business units, and questions deliberately excluded. And require an explicit list of assumptions, revisited at the end, because the assumptions that turned out to be wrong are usually the most valuable output of the whole exercise.

Engagement Models

Fixed-scope diagnostic. A defined assessment for a defined fee over a defined period. Low risk, easy to compare between suppliers, and a reasonable way to test a relationship before committing to anything larger.

Retained advisory. Ongoing access to senior input, usually a fixed monthly fee for a defined amount of time. Suits organisations with an internal programme that needs periodic challenge rather than external delivery. Its failure mode is drift — a retainer with no defined decisions attached becomes a subscription to meetings.

Programme-embedded. Consultants working inside the delivery programme, often in leadership roles. Effective and expensive, with the specific risk that the organisation stops developing its own capability because the external team is doing the thinking.

Outcome-linked. Fees tied to defined results. Attractive in principle and difficult in practice, because transformation outcomes usually depend on decisions and behaviours the consultant does not control. Where it works, the outcome is narrow and measurable — a migration completed, a cost line reduced, a process cycle time halved.

Whichever model, insist on knowing who is actually staffed on the account. The gap between the people at the pitch and the people on the engagement is the single most common source of dissatisfaction in this market. Our red flags and green lights for choosing an advisory partner goes through the diligence in detail.

What the First Ninety Days Should Produce

A useful engagement produces four things in its first quarter, and their absence is diagnostic.

A factual estate picture. What systems exist, what they cost, what depends on what, and where the data actually lives. This routinely surprises leadership, which is itself informative.

A measurement baseline. The numbers the programme will be judged against, captured before anything changes. Cycle times, cost lines, error rates, whatever the programme claims it will move. A baseline reconstructed afterwards is not a baseline, and its absence is the reason so many programmes cannot demonstrate benefit even when they delivered it.

A sequenced plan with dependencies. Not a list of initiatives — an ordered plan showing what must happen before what, and what the first delivery is. The first delivery should matter to the business and be able to fail without endangering it.

Named decisions and owners. The decisions identified at scoping, now with evidence attached, an owner, and a date.

If ninety days pass and these four do not exist, the engagement is not behind schedule; it is pointed in the wrong direction. Our notes on what advisory delivers in its opening phase work through the same ground from the practitioner's side.

Sequencing: Dependency and Evidence

Two principles govern the order of work, and they occasionally conflict.

Dependency. Some things genuinely must come first. Data quality before analytics. Integration before process automation across systems. Identity before self-service. Ignoring dependency order produces initiatives that stall at eighty percent complete waiting for something nobody scheduled.

Evidence. Early deliveries should generate proof that the approach works, because programmes are funded by confidence as much as by budget. That argues for choosing something visible and achievable first.

Where they conflict, dependency usually wins, but the resolution is to find a dependency-respecting piece of work that is also visible. Almost every estate has one — a process that is manifestly painful, well-bounded, and sitting on foundations that need building anyway.

The anti-pattern is the eighteen-month foundation programme with no user-visible output. It may be technically correct and it rarely survives a change of sponsor. Where legacy systems are the constraint, our assessment of what an ageing estate actually costs is a useful input to that conversation.

Infographic showing the four outputs a transformation engagement should produce in its first ninety days — estate picture, measurement baseline, sequenced plan, and named decisions with owners

Funding and Governance Decide More Than the Plan Does

Two structural choices shape a transformation programme more than any decision inside it, and both are usually made by default rather than deliberately.

How the work is funded. Annual capital budgeting forces a programme to specify three years of work in order to be approved, then punishes it for changing course when the first increment teaches something. Funding a persistent team against an outcome, reviewed quarterly, produces different behaviour: smaller commitments, faster learning, and a plan that can absorb what discovery reveals. Organisations that keep the old funding model and adopt incremental delivery get the overhead of both and the benefit of neither.

Who decides. Most enterprises have decision rights distributed across business units, with technology holding a coordinating role and no authority. That arrangement is survivable for run-the-business work and fatal for change that crosses functions — which is what transformation is by definition. The programme needs an executive owner with the standing to resolve a dispute between two business units, and that person needs to be named before the first workshop rather than sought after the first disagreement.

A third choice sits underneath both: what happens to the operating model itself. Programmes that deliver new systems into unchanged governance, unchanged funding cycles and unchanged decision rights reliably under-deliver, because the systems get used the way the old ones were used. If nothing about how the organisation decides has changed by the end, the benefit will be whatever the technology produces on its own — usually a fraction of the case.

Where Legacy Systems and Data Constrain the Plan

Ambition is rarely the limiting factor. Two constraints are, and both are discoverable in the first month if anyone looks.

Legacy platforms set the pace of change. A core system that takes a quarter to change safely constrains every process that touches it. The productive response is not always replacement — it is usually decoupling, so that the parts of the estate that can move quickly are no longer held to the speed of the part that cannot. That work is unglamorous, invisible to the business, and on the critical path of nearly everything else.

Data quality determines what is possible. Every proposal involving analytics, automation or personalisation assumes data that is complete, current and agreed. In most enterprises at least one of the three fails, and the gap surfaces mid-programme as an unbudgeted workstream. The discipline that prevents it is narrow: for the first increment, work backwards to the specific data it needs and fix exactly that, rather than either ignoring the dependency or trying to solve the enterprise-wide version of it first.

Both constraints argue for the same sequencing rule. Choose a first delivery that matters to the business, work backwards to the minimum foundation it requires, and build only that. The general problem gets solved by repetition, shaped by real usage — slower on paper, faster in practice, and considerably easier to keep funded.

The Three Failure Modes

No executive owner. Not a sponsor who receives updates — an owner who makes decisions, resolves conflicts between business units, and carries the outcome. Programmes without one stall at the first cross-functional disagreement, which arrives early.

Scope defined by technology. "Migrate to cloud" and "implement a data platform" are activities, not outcomes. They can be completed in full while the business is no better off. Outcome-defined scope — reduce quote turnaround, cut the cost of a transaction, close the books faster — keeps the technology subordinate to the point of doing it.

No baseline. Without one, the programme cannot demonstrate benefit and will be judged on impressions, which favours whoever presents best rather than whoever delivered most.

A fourth deserves mention because it is quieter: the unchanged operating model. New systems delivered into old governance, old funding cycles, and old decision rights tend to be used the way the old systems were used. If nothing about how the organisation decides has changed, expect the benefit to be smaller than the business case.

Measuring It

Measure at three levels and resist collapsing them into one number.

Outcome measures are the business results the programme exists to produce — cost, cycle time, revenue, customer retention. Few, slow-moving, and the ones that actually matter.

Capability measures show whether the organisation can now do things it could not before: release frequency, time to provision an environment, proportion of processes with straight-through handling, time to answer a data question. These move earlier than outcomes and predict them.

Programme measures — spend against plan, milestones, adoption — tell you whether the work is happening. They are the easiest to collect and the least meaningful in isolation, which is why they dominate steering committees.

Report all three, and be explicit that capability measures lead outcome measures by quarters. A programme showing capability improvement and flat outcomes at month nine is usually on track. One showing neither is not, whatever the milestone chart says.

Choosing a Partner

Beyond the usual diligence, three tests separate suppliers.

Ask for a worked example on an estate resembling yours, including what they found that they had not expected and what they got wrong. Firms that cannot describe a mistake either have not delivered much or are not being candid.

Ask who is staffed on the account, by name and by allocation. Then ask what happens if those people leave.

Ask what they will not do. Firms with a real point of view have work they decline. Those that will do anything are describing a capacity business, which is a different purchase.

IdeaGCS works across the advisory and delivery boundary through its modernisation engineering services, with delivery capability supplied through its wider service lines.

Conclusion

Transformation advisory earns its fee when it produces decisions, a sequence, and a baseline — and when someone senior owns the result afterwards. It fails predictably when the scope is written in technology terms, when nobody owns the decisions, and when nobody wrote down where the organisation started.

Buy the diagnostic before the programme. Separate advisory from delivery where you can. Sequence by dependency, choose a first delivery that is both foundational and visible, and measure capability alongside outcome so the twelve-month conversation has evidence in it. Talk to IdeaGCS if you want an engagement scoped against decisions rather than deliverables.