I get a version of the same email every few weeks. A CEO or COO of a company somewhere between €20M and €500M in revenue writes to say the board has approved a digital transformation budget, they have shortlisted two consultancies, and they would like a third opinion. Almost every time, the interesting part of the conversation turns out to be a question nobody has asked yet: what, specifically, is this transformation supposed to change about the business?
If that sounds like a trivial question, consider that it is the one whose absence explains most of the failures. The technology in these programmes is rarely the hard part. Cloud migration is a solved problem. Data platforms are a solved problem. What is not solved is the sequencing, the ownership, and the honest arithmetic of which processes are actually costing the business money today.
So this is the article I wish I could send in reply. What a digital transformation consultant genuinely does, how the engagement models and pricing work, the KPIs that tell you early whether it is working, how to run a selection process that filters out the theatre — and the three situations in which the honest answer is that you should not hire one at all. I run Lasting Dynamics and I do this work myself, so read the whole thing as coming from an interested party who would rather tell you the truth than win a bad engagement.
Michele's Take
A good consultant makes themselves progressively unnecessary. If the proposal in front of you describes an 18-month engagement with no point at which your own people take ownership, you are not buying transformation. You are buying dependency with a transformation label on the invoice.
What a Digital Transformation Consultant Actually Does
The job title is unhelpfully broad, so let me describe the work rather than the label. In a serious enterprise digital transformation engagement, the consultant is responsible for five things — and if a proposal is missing two or more of them, it is a technology project wearing a strategy costume.
- Establishing the baseline. Where the money and time actually go today: process cycle times, manual handoffs, licence spend, integration debt, the number of systems holding the same customer record. Not opinions — measurements.
- Translating business goals into a technology sequence. A digital transformation roadmap is not a list of platforms to buy. It is an ordered set of changes where each one funds or de-risks the next.
- Owning the build-versus-buy calls. Which capabilities are genuinely differentiating and should be built, and which are commodity and should be bought. I wrote a full framework for this in my build vs buy guide, and it is the decision that most often gets made by whoever spoke last.
- Designing the operating model, not just the architecture. Who decides, who owns which system, how funding works after the programme ends. This is the layer that determines whether the change survives.
- Defining the measurement. A small set of business KPIs, baselined before anything is built, reported on a fixed cadence to the same audience throughout.
Notice what is not on that list: writing code, running the PMO, or producing a 200-slide current-state assessment. Those are all real activities, but they are deliverables of other roles. The consultant's actual product is a defensible sequence of decisions and the evidence behind them.
Why Most Transformations Fail — It Is Almost Never the Technology
The widely quoted figure is that around 70% of digital transformation programmes fail to deliver their stated objectives. Whatever the true number, the pattern behind it is consistent, and in my experience the causes are depressingly repetitive:
| Failure pattern | What it looks like | The actual root cause |
|---|---|---|
| Platform-first thinking | A major platform is selected in month one, before the process work | The decision was made to satisfy a budget cycle, not a diagnosis |
| No baseline | Nobody can say what cycle times or unit costs were before | Success becomes unfalsifiable, so the programme cannot be steered |
| Transformation as a side project | Every participant has a full-time day job as well | Leadership funded the tooling but not the capacity to change |
| Process automation without process redesign | The old broken workflow now runs faster and digitally | The consultant was hired to implement, not to challenge |
| No owner after go-live | Adoption decays quietly over two or three quarters | The operating model was never designed, only the architecture |
| Big-bang scope | 24-month plan, first business value in month 18 | Political need for a bold programme beat the need for compounding wins |
Read that table and the diagnosis writes itself. Almost every entry is a governance failure that a technology decision was asked to solve. This is precisely why digital transformation strategy work has to precede platform selection rather than rationalise it afterwards — and why the most valuable thing a consultant can do in the first six weeks is narrow the scope, not expand it.
The Question That Predicts Failure
Ask your team: if this programme delivers perfectly, which number on the P&L moves, by how much, and by when? If you get four different answers from four executives, the programme is not ready to start and no consultant can fix that for you. Alignment is a prerequisite, not a deliverable.
Three Cases Where You Should Not Hire One
This is the section that costs me work, and it is the reason I bother writing these articles. There are three situations where bringing in a digital transformation consultant — me included — will waste your money, and they are common enough that I turn down engagements on these grounds several times a year.
1. You have not decided what the business is optimising for
If the executive team cannot agree whether the next eighteen months are about margin, growth, or risk reduction, no roadmap will hold. You will get a document that satisfies everyone in the room and commits to nothing, and six months later the programme will be re-scoped by whoever has the most political capital. This is not a consulting problem — it is a strategy problem, and it needs to be resolved by your board before anybody is paid to sequence technology against it. Spend the money on two days of genuinely difficult executive alignment instead.
2. Your real problem is an organisational problem
Sometimes the honest diagnosis is that two directors do not cooperate, or that a long-tenured team is protecting a process because the process is their job security, or that the last three change initiatives were announced and then quietly abandoned so nobody believes this one either. Technology cannot route around any of that. A consultant will surface it in week three and then be structurally unable to fix it, because the fix requires authority a consultant does not have. Deal with the organisation first; then digitising it becomes straightforward.
3. You need hands, not a roadmap
If you already know exactly what you want built and your only constraint is delivery capacity, you do not need a strategist — you need engineers, and paying consulting rates for that is an expensive mistake. Hire a delivery partner or augment the team; I cover the trade-offs in my guide to outsourcing software development. The test is simple: if you can already write the specification, you are past the point where advisory adds value.
Consultant vs Fractional CTO vs Big-Four Firm
These three are routinely evaluated against each other even though they solve different problems. The distinction that matters is not seniority or price — it is who holds accountability once the recommendation exists.
| Digital transformation consultant | Fractional CTO | Large consulting firm | |
|---|---|---|---|
| Core question answered | What should we change, in what order, and why | Who runs technology day to day | How do we execute at scale with external capacity |
| Typical engagement | 6–20 weeks advisory, then optional oversight | 1–3 days a week, ongoing | 6–24 months, large blended team |
| Accountable for delivery | Usually no — accountable for the decision quality | Yes, operationally | Contractually yes, via the programme |
| Best fit | Mid-market and enterprise with a real budget and no in-house strategist | Startups and scale-ups needing technical leadership | Large enterprises needing headcount and process at scale |
| Main risk | Recommendations with no owner after handover | Limited bandwidth for very large programmes | Cost, generic playbooks, junior staffing on the ground |
If you are a startup or scale-up rather than a mid-market or enterprise business, the fractional CTO column is almost certainly the right one — I wrote that comparison out in full in what a fractional CTO actually does. This article is deliberately the enterprise counterpart: bigger organisation, more stakeholders, and a decision that has to survive a board review rather than an investor update.
The blended model is often the correct answer and is rarely proposed, because it is harder to sell: a short, sharp advisory engagement to establish the sequence, followed by a named internal owner with part-time external oversight through execution. It costs a fraction of a full programme and it is the only version where capability actually stays in your organisation.
What a Real Roadmap Looks Like
A credible digital transformation framework does not begin with a target architecture. It begins with a measurement and ends with your own team owning the result. This is the five-phase shape I use, and the phase durations are deliberately short because compounding wins beat grand plans.
- Weeks 1–3 — Baseline and diagnosis. Instrument what exists: cycle times, unit costs, licence and integration spend, where data is duplicated, where humans are moving information between systems. Produce numbers, not narrative. Everything later is measured against this.
- Weeks 3–5 — Value mapping. Rank candidate changes by annual value against effort and risk, and be ruthless about the bottom two thirds. The output is a shortlist of five to eight interventions with an explicit euro figure attached to each.
- Weeks 5–8 — Sequence and operating model. Order the interventions so early ones fund or de-risk later ones, and name the internal owner of each system before anything is procured. No owner, no project.
- Months 3–6 — First delivery slice. Ship one intervention end to end, in production, with its KPI moving. This is the only credible proof that the sequence is right, and it is what unlocks the rest of the budget politically.
- Ongoing — Handover and cadence. Monthly review against the original baseline with the same audience, and an explicit reduction in external involvement each quarter. If external effort is not decreasing, the transformation is not happening.
The Six-Week Rule
Insist that the first engagement is capped at six to eight weeks and produces a decision document, not an implementation contract. It gives you a real sample of how the consultant thinks at a fraction of the risk, and any advisor who refuses to be evaluated that way has told you something useful about how they price.
What It Costs and How Engagements Are Priced
Pricing in this market is opaque, which serves suppliers and not buyers, so here are the ranges I actually see in the European mid-market. Treat them as orientation rather than quotes — sector, regulatory load and data estate complexity move these numbers materially.
| Engagement type | Typical range (EU mid-market) | What you should get for it |
|---|---|---|
| Diagnostic and roadmap | €25K–€60K | Baseline measurement, ranked interventions with value attached, sequenced plan, named owners |
| Roadmap plus delivery oversight | €8K–€20K per month | The above plus architecture governance and steering through execution |
| Fractional leadership through execution | €6K–€15K per month | Part-time accountable technology leadership, 1–3 days per week |
| Large-firm full programme | €500K–€5M+ | Blended team, formal PMO, external delivery capacity at scale |
Two warnings about how digital transformation consulting services are commonly structured. First, be suspicious of proposals where the diagnostic phase is priced near zero — it is usually being subsidised by a much larger implementation contract that the diagnosis will conveniently recommend. Second, insist on knowing which named individuals will do the work and what proportion of their time you are buying. In large firms the person who sells is frequently not the person who appears, and that single question changes more outcomes than any negotiation on rate.
The KPIs That Tell You It Is Working
Most programmes report on activity — systems migrated, users trained, milestones hit — because activity is easy to make look good. The metrics below are harder to game and they move early enough to steer by. Pick four or five, baseline them before anything starts, and report them to the same audience every month.
- Process cycle time for the two or three flows that touch revenue — quote to order, order to cash, claim to settlement. This is the number that convinces a CFO.
- Cost per transaction in the redesigned process versus the baseline, including the cost of exceptions and manual intervention, not just the happy path.
- Manual handoffs eliminated. A crude count, but it correlates strongly with both error rate and staff satisfaction, and it is very hard to fake.
- Time to change. How long from a business request to it being live. If this is not improving, you have new systems and the same organisation.
- Single-source-of-truth coverage. The share of core entities — customer, product, contract — that exist authoritatively in exactly one system.
- Adoption at 90 days post-launch, not at launch. Launch adoption measures the mandate; 90-day adoption measures whether the design was any good.
“If you cannot state the baseline of a metric, you are not going to be able to claim you improved it. Almost every transformation I have been asked to rescue was unmeasurable before it was unsuccessful.”
— Michele Cimmino · CEO & Founder, Lasting Dynamics
How to Run the Selection Process
Run this as a structured evaluation rather than a series of pitches. Ask every candidate the same seven questions and compare the answers side by side — the differences will be stark, and most of the signal is in questions three, five and six.
- Describe a transformation you worked on that did not succeed, and what you would do differently. Anyone with a genuine track record has at least one. A candidate with no failures has either not done the work or is not being straight with you.
- What would you measure in the first three weeks, before recommending anything? You are testing whether they start from evidence or from a template they already own.
- Which named individuals will do the work, and how much of their time am I buying? Get names and percentages in writing. This single question exposes the sell-then-substitute model.
- What is the smallest useful version of this engagement? A good advisor can scope down credibly. An advisor who can only sell the full programme is optimising for their revenue, not your risk.
- What would make you tell me not to do this? If nothing would, they are not advising you — they are selling to you. Listen carefully to how specific the answer is.
- How does external involvement decrease over the engagement? Ask for the shape of the taper. Absence of a taper is the single strongest predictor of a dependency relationship.
- Who owns each system when you leave, and how were they involved in choosing it? Ownership assigned at the end of a programme never sticks. It has to be assigned before procurement.
One process note: include the people who will actually operate the new processes in at least one evaluation session. They will ask better questions than the executive committee, and their reaction to a candidate is a reliable early indicator of whether adoption will happen at all.
A Note on Manufacturing and Regulated Sectors
Digital transformation for manufacturing deserves separate treatment because the constraint is different. On a plant floor the binding limits are OT/IT separation, equipment that will not be replaced for another decade, and the fact that unplanned downtime has a per-hour cost that dwarfs the software budget. The correct sequence is usually the reverse of the enterprise-IT instinct: instrument and observe first, integrate second, and only then automate decisions. Any consultant proposing to start with a platform rollout on a live line has not run one.
In regulated environments — banking, insurance, healthcare, pharma — the equivalent constraint is that every architectural choice carries an audit consequence. Retrofitting compliance is dramatically more expensive than designing for it, which is the argument I make in detail in my guide to legacy modernisation for banking and insurance. If your sector has a regulator, put that constraint into the roadmap in week one rather than discovering it during the first audit.
This is also where a smaller, senior advisor tends to genuinely outperform a large firm. Sector-specific constraints are not in anybody's generic playbook, and the difference between an advisor who has personally shipped in your regulatory environment and one who has read about it is visible within the first two meetings.
What I Would Tell You Over Coffee
Start smaller than the board expects. The instinct in a company with an approved budget is to commission something proportionate to the budget, and that instinct is responsible for a large share of the failures in the table above. A six-week diagnostic that produces one sequenced plan with the first slice scoped for delivery will teach you more about your own organisation than a two-year programme, and it costs about 5% as much to be wrong.
Then insist on the taper. The measure of a successful engagement is not what the consultant delivered — it is what your organisation can now do without them. Every mechanism in this article, from naming system owners before procurement to reporting against a pre-programme baseline, exists to make that transfer of capability structural rather than aspirational.
And be honest about which of the three no-hire cases you might be in. If it is executive misalignment, an organisational problem, or a straightforward need for delivery capacity, a consultant will spend your first two months documenting something you already know. I would rather tell you that now than bill you to discover it.
Michele's Take
The best digital transformation engagements I have run all looked underwhelming on paper: narrow scope, short timeline, boring first deliverable, one clearly named internal owner. They worked because the plan was falsifiable and someone inside the business was accountable for it. Ambition belongs in the destination, not in the size of the first contract.