agilemindsv2

Agile Consulting Firms in the UK: How to Vet One Before You Sign

Mon, 31 Aug 2026 10:00:01 GMT

There are hundreds of agile consulting firms and agile consultancies operating in the UK, and most pitches look the same by the third meeting. Here's a practical checklist for telling them apart before you commit budget, not after.

Check the CVs, Not the Case Studies

Case studies are marketing. CVs are evidence. Ask for the actual CV of whoever will be in the room with your team, not a company-level bio. Look specifically for years of hands-on delivery experience, not years of coaching certifications; the two aren't the same thing, and a firm that can't quickly produce this is often staffing more junior people than the pitch suggested.

Ask Who Owns the Outcome

Some agile consulting firms will tell you their job is to facilitate, running ceremonies, coaching the team, staying neutral on outcomes. That's a legitimate model for some engagements. But if your project is already at risk , "neutral facilitation" isn't what you need. You need a firm willing to own the outcome and tell you plainly when something isn't working, even if it's uncomfortable.

Look for Conflicts of Interest

Ask directly whether the firm has commercial relationships with the software vendors they recommend. Referral arrangements are common across agile consulting companies and rarely disclosed unless asked. A technology-agnostic firm has nothing to gain from steering you toward a particular tool, which means their recommendations are about your project, not their revenue.

Get the Exit Plan Upfront

A good agile consultancy should be able to tell you, before the engagement starts, what "done" looks like and what happens when they leave. If the answer is vague, or if every conversation seems to lead toward extending the contract, that's worth noticing before you sign, not three months in.

Test Them on a Real Scenario

Rather than asking hypothetical questions, describe an actual problem from your project and ask how they'd approach it. Firms that lean on generic frameworks will give you a generic answer. Firms with genuine delivery experience will ask follow-up questions before answering, because they know the right approach depends on specifics they don't have yet.

Watch How They Handle "No

Ask what they'd do if, after the first two weeks, they concluded your original brief was wrong. A firm that says "we'd deliver what was scoped anyway" is an order-taker. A firm that says "we'd tell you, and reset the plan together" is an advisor. The second is harder to find among agile consulting firms, and worth more.

Frequently Asked Questions

How many agile consulting firms should I get proposals from? Three is usually enough to spot real differences in approach without spending weeks in a procurement process. More than that tends to produce diminishing returns and near-identical pitches.

Should I be wary of firms that only do agile coaching? Not automatically, if your need genuinely is framework adoption, a coaching specialist can be the right fit. Be wary if your project is already at risk and the firm's only offer is coaching, since that's treating a delivery problem as a methodology problem.

Is there a real difference between an "agile consulting firm" and an "agile consultancy"? In practice, no — the terms get used interchangeably in the UK market. What matters isn't the label, it's whether the firm behind either name diagnoses your actual problem or just sells you a framework regardless of what's wrong.

The First Conversation Is Always Free

Run us through the checklist yourself. We provide one day of senior practitioner time, free, no obligation.

Book Your Free Project Assessment

Agile Project Management Consultancy: Six Questions to Ask Before You Hire One

Sat, 29 Aug 2026 09:00:09 GMT

If you're evaluating agile project management consultancies, you've probably noticed most of them sound identical. Same claims, same buzzwords, same case studies with the client name blurred out.

These six questions cut through that faster than any pitch deck will.

1. "What's Your Practitioners' Average Experience Level?"

A lot of agile consultancies staff engagements with recently certified coaches, people two years into their career, running a framework they learned from a course rather than from delivering under pressure. Ask directly: how many years of hands-on delivery experience does the person joining our team actually have? At AgileMinds, the answer is always 15+ years, because anything less isn't senior enough to challenge a struggling project.

2. "Do You Get Paid More If We Buy a Specific Tool?"

Some consultancies have referral arrangements with the project management software they recommend. That's not disclosed unless you ask. A technology-agnostic consultancy has no stake in which tool you use, the recommendation serves your project, not a vendor relationship.

3. "What Happens If the Framework Isn't the Problem?"

This is the question that separates a genuine advisor from an order-taker. If your real issue is scope creep, a disengaged sponsor, or a team that's been burning out for months, a Scrum rollout won't fix it. Ask what the consultancy does when the diagnosis doesn't match what you asked for. If the answer is "we deliver what was scoped," that's a warning sign.

4. "Can You Show Me Outcomes, Not Just Adoption?"

Plenty of agile consultancies measure their own success by adoption: did the team start running standups, did velocity get tracked? Ask instead for outcomes: did the project actually deliver, on time, at the quality the business needed? Adoption without delivery is a process win dressed up as a business result.

5. "What's the Embed Time, and What Happens After You Leave?"

Some consultancies run a short workshop and disappear, leaving your team to sustain the change alone. Others embed for months without a clear handover plan, creating dependency instead of capability. Ask for a specific embed timeline and what "done" looks like, a team that can run without them, not a retainer that quietly continues.

6. "What Do You Do When You Disagree With Us?"

The honest answer should be some version of "we tell you." A consultancy that only confirms what leadership already believes isn't adding anything you couldn't have worked out yourselves. Challenge, delivered constructively and early, is worth more than agreement.

What Good Answers Sound Like

You're not looking for a consultancy that avoids every uncomfortable answer. You're looking for one willing to give them, specific experience levels, no hidden tool commissions, a plan for what happens if the diagnosis changes, outcomes over activity, a defined embed period, and a track record of telling clients things they didn't want to hear.

Frequently Asked Questions

Is AgileMinds an agile project management consultancy? We're a project management consultancy that works alongside, not instead of, whatever delivery framework your team already uses. We're framework- and technology-agnostic, focused on outcomes rather than methodology adoption. Naturally, with a name of Agileminds, we’ve done a lot of agile too!

How long should I expect an agile consultancy engagement to run? It depends on the scope, but any consultancy that can't give you a defined embed period and handover plan upfront hasn't scoped the work properly yet.

The First Conversation Is Always Free

Ask us these six questions yourself. We provide one day of senior practitioner time, free, no obligation.

Book Your Free Project Assessment.

Agile Consultancy: What the Terms Actually Mean (And What to Ask Before You Hire One)

Wed, 26 Aug 2026 08:00:00 GMT

Search "agile consulting" or "agile consultancy" and you'll get thousands of results. Most of them sell the same thing: a two-day Scrum certification, a Jira setup, a slide deck about sprints.

None of that tells you whether your project will actually finish.

We get found under these search terms a lot, our name causes that. But it's worth answering properly, because the confusion is real and it costs people time. Here's what "agile consulting" actually means, why the label is doing you a disservice, and what to ask before you bring anyone in.

The Terms Have Been Hollowed Out

In 2001, "agile" meant a specific way of thinking about software delivery: short cycles, working software over documentation, responding to change over following a plan. It was a philosophy for teams building products.

Twenty-five years later, "agile consulting" mostly means something else. It means a firm that will:

Certify your team in Scrum or SAFe
Configure your project tracking tool
Run retrospectives for a few sprints
Hand you a framework and leave

Fine. If your problem is "our engineering team hasn't adopted a delivery methodology yet," a framework-focused agile consultancy is the right call.

But most organisations searching for "agile consulting" don't have that problem. They have a project that's behind schedule, over budget, or losing the confidence of the board. A framework won't fix that. A framework was never designed to.

What You're Probably Actually Looking For

If you're typing "agile consultancy UK" into Google at 11pm, here's what we've found the real question usually is:

"Who can come in, tell me the truth about why this project is struggling, and get it back on track?"

That's not agile coaching. That's project recovery. It's a different discipline, and it's worth knowing the difference before you sign anything.

Both have their place. But if your project is already at risk, hiring a consultancy to teach Scrum ceremonies is treating the symptom, not the cause.

What to Ask Before You Hire an Agile Consultancy

Three questions separate a framework vendor from a genuine delivery partner:

1. "What happens if the methodology isn't the problem?" A framework-first agile consulting firm will still sell you the framework. A practitioner-led firm will tell you, before you pay them, if your issue is scope, sponsorship, or resourcing instead.

2. "Who's actually doing the work?" Ask for the CV of the person embedding with your team, not the case study on the website. Many agile consultancies staff junior coaches on senior-sounding contracts. At AgileMinds, every practitioner has 15+ years of delivery experience. No graduates, no exceptions.

3. "Are you selling me a tool as well as advice?" Some agile consulting firms take referral fees from the project management software they recommend. That's a conflict of interest you're paying for without knowing it. We're technology-agnostic, every recommendation serves the project, never a vendor relationship.

Why This Matters More Than It Sounds

Here's the uncomfortable part. Boards and COOs often bring in agile consulting as a first step, watch three months pass with a lot of new terminology and no visible progress, and only then call in a recovery team, by which point the project is harder and more expensive to save.

Inaction dressed up as methodology adoption is still inaction. If your project is already showing signs of trouble, missed milestones, disengaged sponsors, scope that keeps moving, the framework conversation can wait. The recovery conversation can't.

We've delivered over £2B in programmes across 23 years, with a 94% project success rate. Halfords, Tesco, and Experian didn't call us for Scrum training. They called us when failure wasn't an option.

The Quick Version

"Agile consulting" and "agile consultancy" are broad, overused terms. Read past the label.

If your team needs a delivery framework, a coaching-focused firm is the right fit.

If your project is at risk, you need practitioners who diagnose and stabilise — not just facilitate.

Ask who's doing the work, what they'll tell you if the framework isn't the issue, and whether they have a stake in the tools they recommend.

Frequently Asked Questions

What's the difference between agile consulting and a project management consultancy? Agile consulting typically teaches and embeds a delivery framework (Scrum, SAFe, Kanban) with a team. A project management consultancy like AgileMinds diagnoses and delivers outcomes across the full project, methodology included, but not the starting point.

Is AgileMinds an agile coaching company? No. We're a project management consultancy specialising in recovery, PMO setup, interim leadership, and transformation delivery. We're technology- and framework-agnostic, which means we recommend whatever gets your project delivered, not whichever methodology we're certified to sell.

How do I know if I need agile consulting or project recovery? If your team hasn't settled on a delivery approach yet, agile consulting helps. If a specific project is behind schedule, over budget, or losing stakeholder confidence, that's a recovery problem, and it needs practitioners, not a framework.

How much does project recovery cost compared to ongoing agile consulting? It varies by scope, but recovery engagements are typically fixed-length (3–6 weeks) and priced to stabilise a specific programme, not an open-ended retainer. A free assessment gives you a clear scope and cost before you commit to anything.

The First Conversation Is Always Free

Whatever you call it, agile consulting, agile consultancy, project recovery, the first step is the same. We provide one day of senior practitioner time, no fee, no obligation. We'll tell you what's actually going on before you spend a penny.

Book Your Free Project Assessment today.

A Practical Guide to Technical Delivery: What CTOs Actually Need From a PMO

Sun, 23 Aug 2026 13:54:51 GMT

Delivery bottlenecks and scope creep are eroding the roadmap, and the standard fix every engineering leader has heard is "bring in a PMO." Most engineering leaders have also watched a PMO slow a technical team down instead of speeding it up. The difference isn't whether PM discipline exists. It's what kind.

Why engineering teams resist it, correctly

Generic PMOs import ceremony from non-technical portfolios: status decks nobody reads, RAG ratings that don't map to sprint reality, reporting cycles that lag a week behind what the team already knows. Engineers push back on this correctly, it's overhead that doesn't serve delivery, and treating that resistance as a discipline problem rather than a design problem is usually where things go wrong.

The resistance tends to escalate predictably once it starts. A team asked to maintain a status report that duplicates information already visible in their own tooling will, reasonably, start updating it less carefully over time, because the effort isn't rewarded with anything useful coming back the other way. Leadership then reads the increasingly stale reporting as evidence the team needs more oversight, not less, and adds another layer of process on top, which makes the underlying resentment worse and the reporting even less reliable. The cycle is self-reinforcing, and it's rarely obvious to anyone inside it that the root cause was a design choice made months earlier, not a discipline failure by the engineers.

What actually helps a technical roadmap

PM discipline that works for engineering teams speaks the team's own language, dependencies, technical debt, capacity against committed work, and reports it upward in terms a board can act on, without forcing engineers to translate their work into a format built for a different kind of project. This sounds like a translation problem, and it partly is, but the more important part is sequencing: knowing which dependencies genuinely block which work, so that a roadmap reflects the order things can actually happen in rather than the order stakeholders would prefer them to happen in.

Why technology-agnostic matters more here than anywhere else

Most PMO providers arrive with a preferred tool already decided, a preferred instance of Jira, a preferred reporting layer bolted on top. For an engineering organisation, that's not a neutral convenience, it's a collision. The team already has tooling, workflows, and habits built around how it actually ships code, and a PMO that insists on its own tool forces engineers to maintain two systems of record: the one they trust, and the one that reports upward.

Being technology-agnostic isn't a general principle in this context, it's the specific reason a technical PMO can sit on top of what a team already uses instead of replacing it.

This distinction matters enough to be worth stating plainly: a PMO's job is to make delivery legible to people who need to make decisions about it, not to change how engineers do their work.

The moment a PMO starts dictating which ticketing system, which branching strategy, or which sprint length a team should use, it has stopped serving delivery and started competing with the people actually doing it.

The cost of getting this wrong

APM's 2025 survey found that almost three-quarters of full-time UK project professionals say their mental wellbeing has been negatively affected by their main project, per the APM Salary Survey 2025 . A PMO that adds ceremony without removing friction doesn't just slow a roadmap down, it compounds directly into the retention and wellbeing problem most engineering leaders are already fighting. Right-sized PM discipline is a retention question as much as a delivery one, and the connection is more direct than it might seem: engineers who leave rarely cite process overhead explicitly in an exit interview, but the pattern of departures often clusters around teams carrying the heaviest reporting burden relative to their actual output.

Where to start

Lightweight cadence. Reporting derived from what the team already tracks, not a parallel system to maintain. Escalation paths that remove blockers in days, not sprint cycles. The measure of a good PMO for an engineering organisation isn't how much process it adds, it's how much friction it removes.

Agile Minds builds PM discipline around how engineering teams actually work, not around a template borrowed from elsewhere. If your roadmap keeps slipping despite a PMO already in place, we should talk .

Everything a COO Needs to Know Before Signing: Questions to Ask a Recovery Consultancy

Sun, 23 Aug 2026 13:54:49 GMT

Costs are escalating. A high-visibility project is at risk. The board is watching, and someone needs a credible pair of hands, fast. Under that kind of pressure, it's easy to hire the first consultancy that sounds confident. Confidence isn't the thing worth screening for.

A handful of direct questions, asked before any contract is signed, tend to separate the consultancies that can actually help from the ones that only sound like they can.

How fast, specifically

Vague answers, "quickly," "as soon as possible" aren't answers. A real answer is a specific range, held consistently across every conversation. Ours is three to six weeks, every time, because it's a commitment we can hold ourselves to rather than a placeholder. It's worth noticing, too, whether the answer changes depending on who's asking, a consultancy that quotes a tighter timeline to a nervous sponsor than to a sceptical procurement lead is telling you something about how it handles pressure more generally.

Who actually shows up

Many consultancies staff recovery work with junior consultants supervised remotely by someone senior. It's worth asking directly for the specific experience of the person who will actually be embedded, not the firm's average. Every practitioner we embed has fifteen-plus years of experience, because a programme in crisis isn't the place to learn on the job. A useful follow-up question here: ask to speak to the actual person before signing, not an account lead who will hand the work off afterwards. A consultancy confident in who it's deploying will have no issue with this. One that hesitates usually hasn't decided yet, which means the answer to "who's coming" is still genuinely unknown.

Whether the advice is actually independent

If a consultancy sells a platform, a methodology, or a staffing model, its recommendation is rarely fully independent, watch for hesitation when this gets asked directly. Being technology-agnostic means every recommendation serves the client, never a vendor relationship the consultancy is incentivised to protect.

This matters more than it might initially appear, because the bias rarely shows up as an obviously wrong recommendation, it shows up as a consistent, subtle tilt towards whatever the consultancy happens to sell, dressed up in the language of best practice.

What "success" is actually measured against

"High success" isn't a number. It's worth pushing for the figure and the baseline it's measured against. Ours is 94%, measured against programmes that were genuinely at risk when we started, not a cherry-picked baseline. A success rate measured against every engagement a firm has ever taken on, including the straightforward ones, tells you very little about how that firm performs under genuine pressure. Ask specifically what counts as "at risk" in their number, and what counts as "success" on time, on the revised plan, or against the original commitment.

Whether disagreement is welcome

This is the question most often skipped, and the one that matters most under pressure. A consultancy that only ever agrees with its client isn't advising, it's order-taking, and order-takers rarely raise the uncomfortable thing early enough to act on it. Being an advisor rather than an order-taker means saying so when a decision looks like it's heading toward the same failure mode that caused the crisis in the first place, even when it isn't what the room wants to hear.

One practical way to test this before signing anything: ask the consultancy to describe a time they told a client something the client didn't want to hear, and what happened next. The answer tends to be more revealing than any reference call.

What's left behind

Recovery that collapses the moment the consultancy exits was never recovery, it was a temporary patch. It's worth asking directly what capability gets left behind, and who owns it once the engagement ends. A consultancy genuinely focused on handover will have a specific answer to this, named people, specific documentation, a defined point at which responsibility formally transfers. A vague answer here usually means the engagement was designed around the consultancy's continued presence, not its eventual absence.

Benchmarking the answers against reality

It helps to know what "good" looks like at scale before scoring anyone's answers. NISTA's latest Annual Report on the UK's largest, most scrutinised portfolio of government projects, 213 projects worth close to £1 trillion, still shows a majority sitting at Amber delivery confidence, not Green, per the NISTA Annual Report . That's the benchmark for closely governed and still difficult. Any consultancy claiming recovery is simple, fast, and guaranteed regardless of context is describing something that doesn't match reality at any scale.

Where to start

Agile Minds offers a free, two-week assessment before any of this becomes a commercial conversation.

If your programme needs a straight answer rather than reassurance, we should talk .

The Complete Guide to Resourcing Your Project: Interim vs Permanent PM

Wed, 22 Jul 2026 07:57:16 GMT

A senior resource gap opens on a critical programme, and someone has to decide fast: recruit permanently, or bring in an interim? The wrong call costs months either way, a rushed permanent hire who isn't the right fit, or an interim brought in too late to matter.

The decision is usually rushed because it's framed as a binary choice. It works better as a diagnosis.

Defining the nature of the gap

The question worth answering first isn't "interim or permanent," it's whether the role is a genuine long-term addition to the organisation or a specific, time-bound need. Ongoing ownership, institutional relationships, a seat at the table for years: that's permanent territory, and interim resourcing was never designed to substitute for organisational growth.

A critical programme with no senior owner right now, a leadership gap while recruitment happens properly, a turnaround needing experienced hands immediately: that's interim territory, and a permanent hire for a temporary problem is expensive in both directions, slow to fill, and awkward to unwind.

The distinction sounds obvious when stated this plainly, and it usually is obvious, once someone actually asks the question deliberately, rather than defaulting to whichever hiring process happens to be fastest to start. Most organisations don't lack the judgement to tell the two apart. They lack the moment of deliberate pause in which to apply it, because a resource gap on a live programme creates its own pressure to move immediately, and moving immediately usually means reaching for whatever hiring process is already familiar rather than the one that actually fits.

What the market is actually paying

Permanent hiring has its own pressure right now. APM's 2025 Salary and Market Trends Survey found average UK project management salaries rose 10% in a single year, to £52,500, with senior and specialist roles considerably higher, per the APM Salary Survey 2025 . That's a tightening market, and it cuts both ways. It makes permanent hiring for a genuine long-term role a sound investment, because good people are increasingly hard to find. It also makes a slow, uncertain permanent search a worse gamble for a time-bound gap, "we'll find someone quickly" is a harder promise to keep in a rising market than it was two years ago.

It's worth being specific about what "harder to keep" means in practice. A rising market doesn't just mean higher salaries for the person eventually hired, it means a longer search, more competing offers for the strongest candidates, and a higher chance that the process drags into its fourth or fifth month while the gap it was meant to fill continues to cost the programme momentum every week it stays open.

The switching cost nobody puts in the business case

The real risk isn't picking interim or permanent. It's guessing wrong and having to switch mid-crisis. A rushed permanent hire who leaves within a year costs the recruitment fee, the onboarding time, and the momentum lost while they ramped up, twice, once for them and once for their replacement. An interim brought in for what turns out to be a permanent need simply delays the real hiring decision while the gap persists underneath. Neither mistake shows up in the initial comparison. Both show up in the delivery timeline six months later.

There's a subtler version of the second mistake worth naming: an interim who is genuinely excellent can make a permanent hiring decision feel less urgent than it is, precisely because the immediate pain has gone away. The gap hasn't closed, it's been covered, and organisations that mistake coverage for resolution often find themselves extending an interim engagement repeatedly rather than confronting the underlying, unaddressed permanent need.

What "interim" should actually mean

Interim shouldn't mean whoever's available. It should mean a senior practitioner with fifteen-plus years of experience, based in the country they're working in, able to embed within three to six weeks, not a graduate running a template while a permanent hire is found. The difference matters most in exactly the situations where interim resourcing gets used: a genuine crisis has no tolerance for a learning curve, and an interim who needs weeks to become useful has failed at the one thing interim resourcing is supposed to guarantee.

Where to start

Don't ask "interim or permanent" first. Ask whether the gap is about to close on its own once the crisis passes, or whether it's a permanent hole in the organisation. The answer to that question answers the hiring one.

Agile Minds provides senior interim project managers, embedded fast, for exactly this kind of gap. If you're not sure which one you're looking at, we should talk .

A Practical Guide to Scheduling Delivery Capability: How Long Does PMO Setup Take?

Thu, 16 Jul 2026 07:54:51 GMT

This is a subtitle for your new post

"How long will this take?" is usually the second question after "how much." It deserves the same specificity. This guide walks through the realistic 3–6 month timeline for PMO Setup & Maturity, phase by phase, so you know what to expect before you commit.

Step 1 (Weeks 1–2): Assessment

This is the free part. Two weeks of senior practitioner time spent understanding what's actually happening across your projects today. No PMO gets designed before we know what it's replacing or reinforcing.

Step 2 (Weeks 3–6): Design

A right-sized PMO for a 50-person engineering org looks nothing like one for a 400-person operations business. This phase builds the governance model, reporting cadence, and escalation paths specific to your organisation, not a template pulled from the last client.

Step 3 (Months 2–4): Pilot and calibration

The PMO runs live on a subset of your portfolio before it's rolled out fully. This is where most off-the-shelf PMOs fail, they skip the pilot and discover the gaps after full rollout, when they're expensive to fix. We calibrate here instead.

Step 4 (Months 4–6): Embed and hand over

Full rollout across your portfolio, with the PMO run by your own people before we step back. We build a delivery capability that lasts; the goal was never to make you dependent on us.

Step 5: Check what could slow you down

Three things reliably stretch a PMO build past its estimate. Run this check before you start:

Stakeholder alignment speed. If department heads can't agree on what "on track" means within the first two weeks, design stalls waiting for consensus.
Data availability. A PMO's reporting is only as good as the project data feeding it. If that data doesn't exist yet, week three becomes an unbudgeted data-cleanup exercise.
Existing tooling debt. Migrating years of scattered spreadsheets and disconnected trackers into one reporting model takes longer than building the model itself.

None of these are reasons to delay starting. There are reasons to know about them at week one instead of month four.

Step 6: Know where the profession is heading

This shift toward more rigorous PMO design is happening industry-wide, not just at AgileMinds. APM's 2025 survey found uptake of its Project Management Qualification has risen 50% in two years, and its entry-level Project Fundamentals Qualification has risen 38%, per the APM Salary Survey 2025 — UK organisations are visibly investing in more credentialed project capability. A PMO built on a template from five years ago is already behind where the profession itself has moved. Your design phase should reflect that shift, not just your organisation's own history.

Want the real number for your organisation, not the range?

Where to start

The honest range is three to six months, and the honest way to find your own number inside that range is a proper assessment, not a guess dressed up as a quote.

Agileminds builds PMOs designed around the organisation they serve, not a template. If you want the real number for yours, we should talk .

Everything You Need to Know Before You Budget: The Real Cost of Project Recovery

Wed, 15 Jul 2026 13:48:20 GMT

Most consultancies won't answer the cost question directly. Ask, and you'll typically get "it depends" and a form to fill in. It does depend, but that's not an excuse to be vague about what it depends on.

If you're a COO trying to build a business case for the board, three variables actually set the price, and none of them are secret.

What actually drives the number

Programme size is the first. A single at-risk workstream costs less to stabilise than a portfolio of twelve, scope drives everything downstream. A workstream with one team, one sponsor, and one clear deliverable is a contained diagnostic exercise. A twelve-workstream portfolio with overlapping dependencies and multiple sponsors is a different order of problem entirely, because stabilising one workstream in isolation without understanding its dependencies on the other eleven risks solving the visible symptom while the underlying cause resurfaces somewhere else three months later.

Embed duration is the second: recovery engagements typically run three to six weeks, and a straightforward stabilisation, credible plan, honest reporting, a functioning team, costs less than a six-week turnaround with practitioners embedded across multiple workstreams. The difference between the two isn't really about calendar time so much as coverage, how many people need to be physically present, in the room, for how many of those weeks, before the organisation can run the plan on its own.

Seniority is the third, and the one most likely to be quietly reduced to save money. We only deploy practitioners with 15+ years of experience, never graduates running a template, and that's a deliberate cost floor, it's also why the fix tends to hold. It's worth being honest about why seniority costs more and is still worth it: a junior consultant working from a template can produce a plan that looks credible on paper. A senior practitioner who has seen a dozen versions of this specific failure pattern before knows which parts of that plan won't survive contact with the actual organisation, and can say so in week one rather than

week five.

What that seniority actually costs, in public numbers

You don't have to take a consultancy's word for what senior delivery talent costs in the UK market. The Association for Project Management's 2025 Salary and Market Trends Survey, the UK's largest annual study of the profession, puts the average project management salary at £52,500, up 10% on 2023, with practitioners in consultancy and energy/utilities sectors averaging £62,500, per the APM Salary Survey 2025 .

Embedded recovery work commands more than that average because it's compressed: fifteen-plus years of pattern recognition delivered on a timeline measured in weeks, not spread across a year.

There's a useful way to think about what's actually being purchased here. A permanent hire's salary buys a year of their time, spread across whatever the organisation needs that year. A recovery engagement's cost buys weeks of concentrated attention on one specific problem, from someone whose entire value is having seen that problem before. The hourly economics look expensive next to a permanent salary until the comparison is corrected for what's actually being delivered in that window.

The cost that never makes it onto an invoice

Every cost conversation focuses on what recovery costs. The number that's harder to see, and usually larger, is the cost of inaction. A project drifting for another quarter doesn't just slip its date, it compounds in several distinct ways.

The team burns out chasing an unrealistic plan, because nobody has told them the plan is unrealistic, so they keep trying to hit dates that were never achievable in the first place. The best people quietly start looking elsewhere, because skilled practitioners can generally tell when a programme has lost its way faster than the sponsors funding it can, and they don't wait around to find out how it ends. Stakeholder trust erodes in a way that outlasts the project itself, a sponsor burned once by an over-promised, under-delivered programme brings that scepticism into the next funding conversation, and the next, long after the specific project is closed. And the eventual fix costs more because the drift has to be unwound before recovery can even begin, every extra week of a bad plan being followed is a week of decisions made on false assumptions that now need to be found and corrected.

By the time a board asks how much it will cost to fix, the more useful question is how much it has already cost to wait.

Why nobody publishes a rate card

A three-week reporting fix and a six-week multi-team turnaround are different projects with different costs, and any headline number would be wrong for most people who read it. That's not evasion. It's the same reason a surgeon doesn't quote a price before the scan — not because the price is a secret, but because quoting it before the diagnosis would mean quoting the wrong number to almost everyone who asked.

Where to start

Cost climbs with the number of embedded practitioners, the complexity of stakeholder alignment, and how far a programme has already drifted before anyone calls for help. It does not climb because of methodology, tooling, or brand name.

Agile Minds gives every prospective client a free, two-week assessment before any number gets discussed. If you need a figure you can actually take to the board, we should talk .

Our Guide: How to Build the Right Delivery Model for Your Agile Project

Tue, 14 Jul 2026 08:28:59 GMT

Most organisations don't fail at delivery because their project managers are poor. They fail because they're delivering the wrong things, in the wrong order, for reasons nobody can quite remember.

Walk into any large UK organisation and ask a simple question: "Which strategic outcome does this project serve?" You'll get one of three answers. A confident, specific response. A vague gesture towards "digital transformation" or "operational efficiency". Or an awkward silence, followed by "it was approved before my time."

If you're a CIO or operational director, the second and third answers should worry you far more than any red RAG status. A late project can be recovered. A project that shouldn't exist at all is pure waste, of budget, of scarce delivery capacity, and of the organisation's finite appetite for change.

This guide sets out a practical approach to closing the gap between strategy and delivery: how to make sure every project in your portfolio earns its place, and how to sequence delivery so the right things land at the right time.

Why the gap opens up in the first place

Strategy and delivery drift apart for predictable reasons, and it's worth naming them because most organisations exhibit at least two or three.

Strategy is written for the board, not the portfolio. Many strategies are compelling documents that describe ambition beautifully but offer nothing a portfolio manager can actually use. "Become the most customer-centric provider in our sector" is a fine aspiration, but it doesn't tell anyone which of the forty projects competing for next year's budget should win.

Projects are approved on momentum, not merit. Business cases get written to justify decisions already made. A senior sponsor wants it, a supplier has proposed it, or it's simply next in a queue that formed years ago. The investment committee becomes a rubber stamp rather than a filter.

Nobody owns the middle layer. The board owns strategy. Project managers own delivery. The translation layer between the two—where strategic outcomes get decomposed into a coherent, sequenced portfolio — is often nobody's explicit job. In organisations with a strong PMO it might live there; in many it simply doesn't exist.

The portfolio never gets pruned. Projects are far easier to start than to stop. Strategies change, markets shift, and priorities move, but the portfolio carries on regardless, accumulating initiatives like sediment. The result is the familiar "zombie project": still funded, still consuming people, long since detached from any current strategic intent.

None of this is a failure of intelligence or intent. It's a failure of mechanism. The fix is to build the connective tissue deliberately.

Start with outcomes, not projects

The single most useful discipline you can introduce is this: no project exists until a strategic outcome demands it.

That means doing the translation work properly. Take each strategic objective and decompose it into a small number of measurable outcomes — the specific, observable changes that would tell you the objective is being achieved. If the strategy says "grow our commercial energy business", the outcomes might be "reduce customer onboarding from six weeks to five days", "launch flexibility products to 200 industrial customers by 2027", or "cut cost-to-serve by 15%".

Outcomes have two properties that make them the right unit of currency. They're measurable, so you can tell whether delivery is actually moving the dial. And they're stable enough to plan against — outcomes typically survive for two or three years even as individual projects come and go beneath them.

Once the outcomes are defined, the question for every project — existing or proposed — becomes brutally simple: which outcome does this move, by how much, and by when? If the answer is unconvincing, the project doesn't belong in the portfolio, however elegant the business case or however senior the sponsor.

This is what's often called the golden thread: a traceable line from board-level strategy, through defined outcomes, down to individual projects and the benefits they deliver. When the thread exists, prioritisation decisions become debates about evidence rather than contests of seniority. When it doesn't, the loudest voice wins.

Selecting the right projects

With outcomes as your anchor, project selection becomes a filtering exercise rather than a beauty parade. A few principles make it work in practice.

Score everything against the same criteria . Build a simple scoring model: strategic contribution, financial return, risk, delivery confidence, and dependency on other work. Keep it light, five criteria scored one to five is plenty. The point isn't false precision; it's forcing every proposal through the same gate and making trade-offs visible. A project scoring highly on strategic contribution but poorly on delivery confidence prompts a useful conversation. A project scoring poorly on everything prompts a shorter one.

Make "no" a normal answer. An investment committee that approves 95% of what it sees isn't governing; it's processing. Healthy portfolios reject or defer a meaningful proportion of proposals, and they do it early — before business cases consume weeks of effort and sponsors become emotionally invested. A two-page strategic outline, assessed against the outcome framework, should be the first gate. Most bad ideas can be killed there for the cost of an hour's discussion.

Review the existing portfolio with the same rigour as new proposals. Run every in-flight project through the same filter at least twice a year. Some will have drifted from their original intent. Some will be serving an outcome the strategy no longer prioritises. Stopping a project mid-flight feels expensive — sunk costs, awkward conversations, disappointed teams, but continuing to fund work that no longer matters is more expensive still. The organisations that do this well treat project closure as a sign of portfolio health, not delivery failure, and they say so publicly.

Watch for the strategy-shaped hole. Filtering isn't only about removing weak projects; it's about spotting what's missing. Map your portfolio against your outcomes and you'll almost certainly find outcomes with little or nothing delivering against them, usually the harder, less glamorous ones. An honest gap analysis is worth more than another status report.

Delivering at the right time

Choosing the right projects is half the job. Sequencing them is the other half, and it's the half most organisations neglect.

Sequence by dependency, not by enthusiasm. Projects rarely stand alone. A customer analytics initiative depends on the data platform being in place; a new operating model depends on the systems consolidation finishing first. Map these dependencies explicitly and let them drive the roadmap. It's common to find organisations attempting phase-three work on phase-one foundations because the exciting project got funded before the enabling one.

Respect the organisation's capacity to absorb change. This is the constraint that delivery plans most often ignore. Your operational teams can only take so much change at once, new systems, new processes, new structures, before performance suffers and adoption fails. If three major initiatives all land on the same contact centre in the same quarter, at least one of them will fail, regardless of how well each was delivered. Build a change-impact view across the portfolio: who is affected, when, and how heavily. Then sequence accordingly, even if it means slowing something down.

Match ambition to real delivery capacity. Most portfolios are planned as if the organisation has 30% more capable people than it actually does. Architects, product owners, change managers, and experienced delivery leads are always the bottleneck, and spreading them thinly across too many initiatives guarantees that everything moves slowly. Fewer projects, properly staffed, will deliver more strategic value per year than a sprawling portfolio of half-resourced ones. This is uncomfortable arithmetic for stakeholders whose projects get deferred, but it's arithmetic all the same.

Deliver value in slices, not monuments. Long projects are where strategic alignment goes to die. A three-year programme approved against 2024's strategy will be delivering against a different world by 2027. Break delivery into increments that produce measurable outcome movement every three to six months. This does two things: it gets value flowing earlier, and it creates natural decision points where the organisation can redirect, accelerate, or stop based on what it's learned.

Governance that asks strategic questions

Most project governance is delivery governance: is it on time, on budget, are the risks managed? Necessary, but nowhere near sufficient. Strategic alignment needs its own questions asked at every review:

Is the outcome this project serves still a priority?
Is the project still the best way to move that outcome?
What has the last increment actually delivered, in outcome terms rather than milestone terms?
If we were making this investment decision today, from scratch, would we?

That last question is the most powerful and the least asked. It cuts through sunk-cost reasoning and forces a fresh look at whether the project still earns its place. Boards that ask it regularly run smaller, sharper portfolios.

It also matters who's in the room. Strategic portfolio reviews need the people who own the outcomes — typically your executive peers, not just delivery leadership. When operational directors sit alongside the CIO in prioritisation decisions, alignment stops being an IT problem and becomes what it always should have been: a whole-business discipline.

Measure outcomes, not outputs

Finally, close the loop. Delivering a system is an output. The 15% reduction in cost-to-serve it was supposed to enable is the outcome, and it usually arrives months after go-live, if it arrives at all.

Track benefits against the original outcome commitments, with named owners, well beyond project closure. Publish the results, including the misses. Nothing sharpens future business cases like the knowledge that someone will check whether the promised benefits actually materialised. Over time this builds something genuinely valuable: an evidence base showing which types of investment actually move your strategic outcomes, and which merely promised to.

Where to start

If your portfolio has drifted, and most have, resist the temptation to redesign everything at once. Three moves deliver most of the value:

D efine your strategic outcomes properly, with measures and owners. This is a matter of weeks, not months, and everything else depends on it.
R un the current portfolio through the filter. Every project answers the question: which outcome, how much, by when? Expect to stop or reshape 20–30% of what you find. That capacity is your reinvestment fund.
R ebuild the roadmap around dependencies and change capacity rather than approval dates. Fewer things, in the right order, properly resourced.

None of this requires new tooling or an army of consultants. It requires clarity about what the strategy actually demands, the discipline to say no, and governance willing to keep asking whether each project still deserves its place. Get that right, and delivery stops being a cost centre that occasionally disappoints the board, and becomes the mechanism by which the strategy actually happens.

Agile Minds works with UK organisations to recover struggling programmes and realign delivery portfolios with strategy. If your portfolio has drifted from your strategic intent, we should talk.

Jaguar Land Rover: An Agile Framework Built to Last

Mon, 01 Jun 2026 10:43:30 GMT

The Context

Digital customer journeys, electric vehicles, autonomous driving, connected cars. The complexity facing automotive manufacturers had multiplied. Government legislation and shifting public sentiment around fossil fuels added more variables. The industry’s environment was now unpredictable in a way it had not been before.

JLR recognised this. The business needed to be more flexible and bring solutions to market faster. Not just vehicles, but the systems, factories, and digital products that surround them.

The Challenge

Most agile transformations fail because they start with the framework and end with a PowerPoint deck. Teams are trained, posters go up, and six months later the organisation is delivering exactly as it did before.

JLR did not want that. They wanted agile that actually changed how work got done. Which meant starting with a real product, not a workshop.

What We Did

We identified a real pain point: dealer reserved stock. A dealer could reserve a vehicle, but if it did not sell it sat on the forecourt and lost value over time. We built an iOS application in sixteen weeks that let dealerships across the country search and reserve stock from one another.

That was the vehicle for the framework. While building the app, we developed JLR’s agile delivery framework. We worked through the implications for governance processes, internal standards, and how remote teams should be managed. We defined the role of the product owner, built the digital backlog, and worked out how applications were released into live.

Then we established agile guilds to own the framework, refine it, and make sure it was adopted across the organisation.

The Result

JLR had a working agile framework, proven on a real product, with internal guilds in place to keep refining it after we left.

That is the test of any framework: does it survive the consultants going home? In this case, it did. Because it had been built around real delivery, not a theoretical model.

What Made the Difference

We built the framework through a real product, not in a workshop. Teams learned agile by delivering, not by listening.

We established agile guilds inside the organisation, so the practice had owners after we left.

We adapted the framework to JLR’s reality, including governance, remote teams, and release processes. Not a generic model. A working one.

Services Utilised

Agile Framework Design
Agile Coaching
Product Owner Establishment
iOS Application Delivery
Agile Guild Setup
Governance Redesign

If your agile transformation has produced training certificates but not faster delivery, the framework was never the answer. The work is what teaches teams to work differently.

Free Project Assessment & Audit, Tailored to You

Think something might be off? Not sure where your project really stands? We come in, assess what's happening, and give you a clear and honest picture at no cost. Every engagement starts with understanding your specific situation, because no two organisations are the same.

Totally free. No commitment needed.

Free Project Assessment & Audit, Tailored to You

Not sure where your project really stands? We assess what's happening, and give you a clear and honest picture at no cost. Every engagement starts with understanding your specific situation, because no two organisations are the same.

Totally free. No commitment needed.

Halfords: One Digital Front Door for Two Brands

Mon, 01 Jun 2026 05:27:55 GMT

The Context

A case study covering the creation of a brand new website for Halfords.

Halfords is the UK’s largest automotive retail business, comprising of a number of automotive and cycling brands. Built around two distinct brands: Autocentres , one of the UK’s leading independent operators in vehicle, servicing, maintenance and repairs and Halfords Retail , the UK’s leading retailer of motoring, cycling and leisure products with a large network of stores around the UK and Ireland.

The Challenge

Having operated two distinct digital channels and websites, the retailer wanted to combine the customer experience into a single digital presence for both brands. The customer would be able to shop across both brands into a single joint shopping basket.

The Solution

Salesforce Commerce Cloud was selected as the target platform.

We established an integration team, to enable the new platform to interface with a significant number of legacy applications. The first goal of the team, was to build the platform based on Microsoft Azure Cloud services. Once complete, and handed over to Halfords Support, the next job was to build over 100 API-based interfaces, a new security model and a new performance monitoring suite.

The project was completed successfully in 9-months.

Services used:

New team, to enable the delivery of a micro services platform.
Co-located remote teams to enable the delivery of the 108 interfaces
Scrum and Kanban delivery models
Continuous integration
Automated testing

Free Project Assessment & Audit, Tailored to You

Totally free. No commitment needed.

Free Project Assessment & Audit, Tailored to You

Totally free. No commitment needed.

E.ON: Building the Virtual Power Station

Fri, 29 May 2026 15:24:40 GMT

The Context

E.ON is one of the Big Six UK energy suppliers and part of the global E.ON group. The team had developed a proof of concept for a virtual power station: a network of commercial energy consumers whose demand could be scheduled to off-peak times. Lower bills for the customer. Predictable demand for the grid.

The business case was proven. What they needed next was an MVP that could move into pilot quickly, before the commercial window closed.

The Challenge

A traditional build would have taken too long. Sequential requirements, design, build, and test would miss the market. The team needed pace and rigour at the same time, with business, IT, academic, and manufacturing partners all in the same room.

What We Did

AgileMinds led the move from POC to MVP and embedded the agile practices that would carry the product into pilot.

We assembled a single co-located team across business, IT, and external partners. We confirmed the Product Owner, ran workshops to collate requirements, refined the features into prioritised user stories, and built an MVP definition the board could fund. Agile coaching, sprint planning, and team facilitation happened inside the work, not before it.

The Result

The MVP was approved, funded for pilot, and rolled out across UK sites. The product was commercialised through E.ON in Sweden, and the cross-functional team won the RITA RealIT Award for IT innovation.

The solution is now actively used across E.ON’s network. That is the truest test of any MVP: does the work survive contact with the market? In this case, it did.

What Made the Difference

A single co-located team that collapsed the distance between business, technology, and partners. Decisions were made in hours, not weeks.

Requirements built through workshops and user stories, not hundred-page documents.

Agile practice was embedded inside the work, so it stuck after we left.

Services Utilised

Project Management
Agile Coaching
Sprint Planning
Agile Training
Team Facilitation
Rapid Prototype Development

If you have a proven concept that needs to become a commercial product, the next three months will determine whether it lands or stalls. The first conversation is always free.

Book a Free MVP Acceleration Conversation .

Free Project Assessment & Audit, Tailored to You

Totally free. No commitment needed.

The Hidden Cost of Project Team Burnout (And Why It’s Worse Than Missed Deadlines)

Sun, 24 May 2026 16:38:11 GMT

When a project slips, the cost is visible. A delayed launch. A revised forecast. A frank conversation at the steering committee.

When a project team burns out, the cost is invisible. Until your best project manager hands in her notice three weeks after go-live and takes seven years of institutional knowledge with her. Gallup research has found that burned-out employees are 2.6 times more likely to actively seek another job, and that burnout is a leading driver of voluntary turnover in knowledge work.

The slipped deadline can be recovered. The departed practitioner cannot.

The Three Hidden Costs Most Leaders Underestimate

1. Loss of institutional knowledge

Senior practitioners carry context that isn’t written down. They know which supplier consistently misses estimates. They know which sponsor needs a draft a week before the meeting. They know which workstream is technically green but politically fragile.

None of that is in the project handover document. When a burnt-out senior leaves, that knowledge leaves with them. Their replacement spends six months learning what their predecessor already knew, and the next project pays the cost.

2. Cascading attrition

Burnout doesn’t happen in isolation. The first person to leave is rarely the most burnt out. They’re often the most marketable. Their departure increases the load on those still there, accelerates the burnout of the next tier, and triggers the next resignation.

By the time leadership notices a pattern, three or four resignations are already in motion. Replacing them takes nine months at mid-market salaries. Onboarding them to the same level of context takes longer than that.

3. Quality erosion before the resignation

Long before a burnt-out senior leaves, their work changes. Reviews get lighter. Risks get under-flagged. Status reports get more optimistic. They’re not gaming the system. They’re running on fumes. Harvard Business Review’s research on burnout makes the point clearly: burnout is a workplace problem, not a personal one, and the warning signs show in the work long before they show in the person.

That quality erosion is the most expensive cost of all, because it gets baked into projects that won’t fail until six months from now.

Why Project Teams Burn Out Faster

Large enterprises have depth. Bench resources. Specialist teams. A bad month for one project manager does not derail the entire portfolio.

Most organisations are different. The same five people are juggling fifteen projects. Each person is the only one who truly understands their workstream. No one can take a fortnight off without something slipping. There is no slack in the system.

Add a transformation programme on top of that, and the maths stops working. The same five people are now running fifteen projects plus their part of the transformation, and being told it’s a great career opportunity.

It is not. It is the precondition for institutional knowledge walking out the door.

Four Things That Actually Reduce Burnout

1. Bring in experienced reinforcement, not graduate support

A junior PM added to an overstretched team adds load. They need supervision, context, and review. A senior practitioner added to the same team removes load. They can take a workstream off the senior who was carrying it, and the team can breathe again.

The instinct to “add capacity cheaply” is the most expensive form of false economy in project resourcing.

2. Cut the portfolio before you cut the people

If your team is running fifteen projects and burning out, the answer is not better time management. It is fewer projects. A portfolio review that ends with three projects deferred and two killed will do more for retention than any wellbeing programme.

3. Protect senior time

Your most experienced practitioners should not be filling in status reports, chasing inputs, or facilitating governance forums that should run themselves. That work needs to be done, but by someone else. Free up the seniors to do what only they can do.

4. Notice the early signs

The first sign of burnout is rarely tears or resignation. It is a quietly missed review. A risk that didn’t get raised. A meeting that didn’t get the usual challenge. Train yourselves and your sponsors to notice the drop in sharpness, because that is the leading indicator. By the time someone tells you they’re burnt out, you are already months behind.

The Real Maths of Burnout

Replacing a senior project manager in the organisation costs between six and nine months of their salary in recruitment, lost productivity, and onboarding time. Replacing the knowledge they carried costs significantly more, and is rarely recovered.

Reinforcement, by contrast, is a fraction of that cost, and it is preventative rather than reactive. The question is not whether you can afford to bring in experienced help. It is whether you can afford the resignation that will follow if you don’t.

If your project team is running on the goodwill of three or four people, that goodwill has a shelf life. The first conversation is always free.

Book a Free Resource Health Check . No fee. No obligation.

Free Project Assessment & Audit, Tailored to You

Totally free. No commitment needed.

How to Recover a Failing Project Before It’s Too Late (And the Warning Signs Most Boards Miss)

paul@agileminds.co.uk (Paul Thomas) — Mon, 04 May 2026 17:34:22 GMT

Failing projects don’t announce themselves. By the time a board paper flags red, the slippage has been building for months. Sometimes longer. The team knows. The PMO knows. The project manager has been quietly working weekends to stop the wheels coming off.

The board is the last to find out. And by the time they do, the recovery options have already started narrowing.

After 21 years of being called in when projects must not fail, the pattern is always the same. The warning signs were there. They were just being explained away.

Why Most Recovery Efforts Start Too Late

There is a window of roughly the first 90 days of drift, when a failing project can still be recovered with the team in place, the budget largely intact, and the scope mostly preserved. Outside that window, recovery means something harder. Re-baselining. Re-scoping. Hard conversations with the steering committee about what the programme will actually deliver.

The cost of inaction compounds quickly. A project that slips by three weeks in month one slips by three months by month four. Burnout sets in. Your strongest people start updating their CVs. Suppliers start hedging their commitments. The longer the drift, the fewer levers you have left to pull.

Most boards don’t intervene because the warning signs look like normal project noise. They’re not. They’re a pattern.

Seven Warning Signs Your Project Is Failing

These are the signals we see, in this order, almost every time we’re called in for a rescue.

1. Status reports stop telling you anything new

The RAG status has been amber for six weeks. The narrative is identical week-on-week. The risks list hasn’t been updated. When a status report becomes a ritual rather than a tool, the project has stopped self-correcting.

2. Milestones quietly move

Not once. Repeatedly. A delivery date slips from June to July, then July to September, with no formal change control. The team has stopped believing the plan, so they’re managing to a private timeline rather than the published one.

3. Your best people are working the hardest

Two or three names appear in every escalation. They’re in every workshop. They’re fixing other people’s deliverables in the evening. When delivery depends on heroics from a small group, you don’t have a project. You have a temporary arrangement that will collapse the moment one of them leaves.

4. The PMO has stopped pushing back

A healthy PMO challenges plans, flags risks, and refuses to accept poor-quality status updates. When the PMO is reduced to chasing inputs and producing decks, governance has quietly broken down. The board is now reading a summary of a summary.

5. Suppliers and partners are going quiet

Slower response times. Vague commitments. A reluctance to commit to dates in writing. Suppliers know when a programme is wobbling, often before the client does, and they protect themselves accordingly.

6. Decisions take three meetings

Issues that should take a day to resolve are bouncing between forums. Nobody is empowered, or nobody wants to own the call. Decision latency is the cleanest leading indicator of programme failure we know of.

7. The benefits case has gone quiet

Nobody is talking about the outcome any more. Conversations are about scope, dates, and budget. The inputs. When the team stops referencing why the project exists, the project has lost its anchor.

How to Recover a Failing Project: The First 30 Days

Recovery doesn’t start with a new Gantt chart. It starts with telling the truth.

Week 1: Stop and assess

Pause non-critical workstreams. Run a structured health check covering scope, plan, resourcing, governance, supplier performance, and benefits alignment. Talk to the practitioners, not just the leads. They’ll tell you where the project actually is. Produce one document, no more than ten pages, that names the gap between where the project is and where the board thinks it is.

Week 2: Re-baseline honestly

Strip the plan back to what can credibly be delivered with the team you have. If scope needs to come out, name it. If budget needs to grow, say so. If the original benefits case can no longer be met, raise it now, not in six months. A re-baselined plan that the team believes in is worth more than an aspirational plan that nobody trusts.

Week 3: Fix governance

Tighten the decision-making loop. Reduce the number of forums. Empower a single accountable owner for each workstream. Set a cadence the board can rely on, with status reports that show movement rather than narrative.

Week 4: Stabilise the team

Identify the two or three people the project cannot afford to lose. Take pressure off them. Bring in experienced reinforcement where the gaps are real. Make it visible to the team that the project is being run differently from now on. That visibility is what restores momentum.

When to Recover, and When to Stop

Not every failing project should be saved. Some have lost their business case. Some have technology choices that can’t be unwound at an acceptable cost. Some have lost the trust of the sponsor permanently.

An honest recovery assessment names both options on the table. Recover, or wind down with dignity. It gives the steering committee the evidence to choose. The worst outcome is a project that limps for another twelve months before being quietly cancelled. The cost of that drift is almost always greater than the cost of stopping now.

What Changes When the Right Help Arrives

Three months in. The plan is credible. The team is steady. Suppliers are responding again. The board paper tells the truth, and the truth is improving week by week.

That is what recovery looks like. Not a hero project manager riding in to save the day. A small, experienced team embedded alongside yours, working the plan, restoring confidence, and finishing what others started.

Your project may not be failing yet. But if three or more of the warning signs above are familiar, the next ninety days will determine whether it can still be recovered. The first conversation is always free.

Free Project Assessment & Audit, Tailored to You

Totally free. No commitment needed.

Why PMOs Fail: The Five Reasons Mid-Market PMOs Get Shut Down in Year Two

paul@agileminds.co.uk (Paul Thomas) — Mon, 04 May 2026 17:34:22 GMT

More than half of PMOs set up in organisations are quietly disbanded, restructured, or absorbed into another function within two years. Academic research published through the Association for Project Management has tracked this pattern for over a decade: PMOs are often short-lived, and their value is difficult to evidence.

Not because the discipline of project management is broken. Because the PMO was set up to fix the wrong problem, with the wrong remit, reporting to the wrong person.

After 21 years of being called in to either rescue a PMO or replace one, we see the same five reasons it goes wrong. None of them are technical. All of them are solvable.

Reason 1: It Was Set Up to Solve the Wrong Problem

The most common origin story for a failing PMO is this. A high-profile project failed, a board asked why, and someone said “We need a PMO”.

That is the wrong answer to the wrong question. A PMO is not a fix for one bad project. It is a permanent capability for governing many projects. If you build one in reaction to a single failure, you build it to perform the autopsy, not to prevent the next one.

The PMOs that survive year two are the ones that were set up with a clear charter: which projects they govern, what decisions they own, and what outcomes they are accountable for. The APM Body of Knowledge sets out three core benefits a PMO must deliver: deployment support, process improvement, and resource flexibility. If your PMO charter doesn’t name those outcomes, it doesn’t have one.

Reason 2: It Was Staffed Too Junior

If the executive view of a PMO is that it produces reports, then it will be staffed by people whose job is to produce reports. Those people cannot challenge experienced project managers. They cannot validate the inputs they receive. They cannot tell the board what the real risk picture looks like.

The PMO becomes a copy-and-paste function. Its outputs are no better than its inputs. And when the outputs are poor, the executive concludes the PMO is not adding value. That conclusion compounds the problem, because nobody is going to invest in a function that has already been written off.

A PMO needs at least one senior practitioner who has actually delivered programmes. Without that, the function cannot do the one thing it exists to do: ask harder questions than the project managers it governs.

Reason 3: It Has No Real Authority

PMOs are often launched with a polite mandate. They can request information. They can recommend standards. They can produce reports. What they cannot do is stop a project, escalate over a sponsor’s head, or force a change in resourcing.

Without authority, the PMO has no leverage. Project managers learn quickly which reports they need to fill in and which they can ignore. The PMO becomes administrative theatre. Visible, expensive, and unable to change anything.

The fix is not bureaucratic. It is governance design. The PMO needs a sponsor at executive level, a defined remit, and a small number of decisions it owns outright. Once those decisions are real, the rest of the function gains traction.

Reason 4: It Measured the Wrong Things

Many PMOs report on activity. Number of projects in the portfolio. Percentage of templates completed. Hours logged against governance forums. None of these tell you whether the portfolio is healthy.

A useful PMO reports on outcomes. Are the projects delivering the benefits they were funded to deliver? Are the dates being held? Are resources being used where they create the most value? Those are the metrics a board cares about. Anything else is noise dressed up as rigour.

If your PMO dashboard can’t answer a single board-level question without footnotes, it is measuring the wrong things.

Reason 5: It Couldn’t Adapt

Organisations grow, restructure, and pivot. The APM Golden Thread research (commissioned by APM and conducted by PwC Research) shows the project profession now contributes £186.8 billion annually to the UK economy, a 19% increase in five years. The pace of change is real. A PMO built rigidly around one methodology, typically the one its first head championed, will struggle to keep up.

New projects arrive that don’t fit the template. Teams find workarounds. The PMO becomes a gatekeeper to a process that no longer reflects how the business actually works.

The PMOs that survive are the ones that flex . They have a core of non-negotiables: governance, reporting, risk. Around that core, they keep a wider layer of practice that adapts to the type of project being delivered. Waterfall where it fits. Agile where it fits. Hybrid where it has to.

What a PMO That Works Actually Looks Like

It has a clear charter, written and signed off by an executive sponsor.

It is staffed with at least one senior practitioner with real delivery scars.

It owns specific decisions, not just the production of decks.

It reports on outcomes the board cares about, not on activity it can measure.

It flexes with the business, instead of fighting it.

Building that takes three to six months of focused work, not a software rollout.

If your PMO is approaching its second birthday and the board has started asking what it’s for, that conversation is the warning sign. There is still time to reset it before the function is dismantled.

Book a Free PMO Assessment. No fee. No obligation.

Free Project Assessment & Audit, Tailored to You

Totally free. No commitment needed.

Why Digital Transformation Fails: It’s Not the Technology, It’s the Middle Management

paul@agileminds.co.uk (Paul Thomas) — Mon, 04 May 2026 17:34:22 GMT

Boards approve digital transformations. IT delivers them. Consultancies design them. So why does McKinsey research consistently show that around 70 per cent of large-scale transformation efforts fail to meet their original objectives?

Not because the technology was wrong. The platforms are mature. The integrators are competent. The business cases were defensible at the point of approval.

Digital transformations fail in the middle layer of an organisation. The heads of function, the operational leads, the team managers. The people who are expected to absorb the change while still hitting last year’s targets. That layer rarely gets the support to do both.

The Top Floor Decides. The Shop Floor Adapts. The Middle Carries the Cost.

Look at how most transformations are structured. A board sponsor sets the vision. A programme team designs the future state. IT builds the platform. Training is rolled out to end users.

Now look at where the friction lands. The head of operations is being asked to learn the new system, retrain her team, hit quarterly numbers on the old system while the new one rolls out, and represent the change positively to her people. None of which she was resourced for.

She is not resisting. She is overwhelmed. And when overwhelmed middle management quietly de-prioritises the transformation in favour of the day job, adoption stalls. Without adoption, the benefits case collapses. McKinsey’s own transformation practice names a lack of engagement across the organisation as one of the most consistent reasons transformations underperform.

Three Reasons the Middle Layer Gets Left Behind

1. The transformation is treated as a technology programme

If the project plan reads like a system implementation, with phases for design, build, test, go-live, and hypercare, there is no workstream that owns the human change. The assumption is that training plus communications equals adoption. It doesn’t.

Real adoption requires people to change how they do their work. That requires time, support, and permission to slow down temporarily. None of which appear on a typical implementation plan.

2. The middle layer wasn’t involved in design

Programmes that go straight from board sponsor to technical design skip the layer that knows how the work actually gets done. The resulting solution is theoretically correct and operationally awkward. The people being asked to use it can see the friction immediately, and they were never consulted about it.

Once that gap is visible, trust in the transformation drops. Workarounds appear. Shadow processes emerge. The shiny new platform is technically live and operationally bypassed.

3. There is no slack in the system

Organisations run lean. The same managers who own the day-to-day are the ones being asked to own the change. There is no spare capacity to absorb the cost of transition. So either the day job gives, or the change gives, and the day job almost always wins, because that’s what their compensation is tied to.

If the programme didn’t plan for backfill, secondments, or temporary reinforcement at the operational layer, it didn’t plan for adoption.

How to Land Digital Transformation in the Middle

Treat adoption as a workstream, not an afterthought

Give it a senior owner. Give it a budget. Give it a plan that runs alongside the technical build, not after it. Adoption isn’t something you sprinkle on at go-live. It is built into the programme from week one.

Involve middle management in design, not just delivery

The people who run the operation should help shape the operation’s future. Not in a token workshop. In the design decisions that affect their daily work. The cost of involving them is a few weeks of their time. The cost of not is two years of slow adoption.

Resource the transition honestly

If the change is large enough to need a programme, it is large enough to need temporary capacity at the operational layer. Interim project managers, secondments, backfill: whatever it takes to give middle management room to lead the change rather than survive it.

Measure adoption, not implementation

Going live is a milestone, not an outcome. The real measure of transformation is whether the new way of working has displaced the old one twelve months after go-live. If it hasn’t, the platform may be running, but the transformation hasn’t happened.

The Pattern We See Most Often

Halfway through a transformation, the programme is technically on track. The platform is being built. The board reports are green. But there are quiet signals from the operation. Questions that aren’t getting answered. Training dates being pushed. Change champions going silent. The middle layer is starting to disengage.

That is the moment to intervene. Not at go-live. Not in hypercare. Now. The cost of fixing adoption mid-programme is a fraction of the cost of fixing it after launch, when habits have set and the platform has already missed its first benefits milestone.

If your digital transformation is technically on track but operationally quiet, that quiet is the warning sign. We help mid-market organisations land transformation where it has to land: in the layer that has to live with it.

Free Project Assessment & Audit, Tailored to You

Totally free. No commitment needed.

agilemindsv2

Agile Consulting Firms in the UK: How to Vet One Before You Sign

Check the CVs, Not the Case Studies

Ask Who Owns the Outcome

Look for Conflicts of Interest

Get the Exit Plan Upfront

Test Them on a Real Scenario

Watch How They Handle "No

Frequently Asked Questions

The First Conversation Is Always Free

Agile Project Management Consultancy: Six Questions to Ask Before You Hire One

1. "What's Your Practitioners' Average Experience Level?"

2. "Do You Get Paid More If We Buy a Specific Tool?"

3. "What Happens If the Framework Isn't the Problem?"

4. "Can You Show Me Outcomes, Not Just Adoption?"

5. "What's the Embed Time, and What Happens After You Leave?"

6. "What Do You Do When You Disagree With Us?"

What Good Answers Sound Like

Frequently Asked Questions

﻿

The First Conversation Is Always Free

Agile Consultancy: What the Terms Actually Mean (And What to Ask Before You Hire One)

The Terms Have Been Hollowed Out

What You're Probably Actually Looking For

What to Ask Before You Hire an Agile Consultancy

Why This Matters More Than It Sounds

The Quick Version

Frequently Asked Questions

The First Conversation Is Always Free

A Practical Guide to Technical Delivery: What CTOs Actually Need From a PMO

Why engineering teams resist it, correctly

What actually helps a technical roadmap

Why technology-agnostic matters more here than anywhere else

The cost of getting this wrong

Where to start

Everything a COO Needs to Know Before Signing: Questions to Ask a Recovery Consultancy

How fast, specifically

Who actually shows up

Whether the advice is actually independent

What "success" is actually measured against

Whether disagreement is welcome

What's left behind

Benchmarking the answers against reality

Where to start

The Complete Guide to Resourcing Your Project: Interim vs Permanent PM

Defining the nature of the gap

What the market is actually paying

The switching cost nobody puts in the business case

What "interim" should actually mean

Where to start

A Practical Guide to Scheduling Delivery Capability: How Long Does PMO Setup Take?

This is a subtitle for your new post

Step 1 (Weeks 1–2): Assessment

Step 2 (Weeks 3–6): Design

Step 3 (Months 2–4): Pilot and calibration

Step 4 (Months 4–6): Embed and hand over

Step 5: Check what could slow you down

Step 6: Know where the profession is heading

Where to start

Everything You Need to Know Before You Budget: The Real Cost of Project Recovery

What actually drives the number

What that seniority actually costs, in public numbers

The cost that never makes it onto an invoice

Why nobody publishes a rate card

Where to start

Our Guide: How to Build the Right Delivery Model for Your Agile Project

Why the gap opens up in the first place

Start with outcomes, not projects

Selecting the right projects

﻿

Delivering at the right time

Governance that asks strategic questions

Measure outcomes, not outputs

Where to start

Jaguar Land Rover: An Agile Framework Built to Last

Free Project Assessment & Audit, Tailored to You

Free Project Assessment & Audit, Tailored to You

Halfords: One Digital Front Door for Two Brands

The Context

The Challenge