agilemindsv2

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

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.

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

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

What We Did

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

The Result

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

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

What We Did

The Result

What Made the Difference

Services Utilised

Free Project Assessment & Audit, Tailored to You

Free Project Assessment & Audit, Tailored to You

E.ON: Building the Virtual Power Station

The Context

The Challenge

What We Did

The Result

What Made the Difference

Services Utilised

Free Project Assessment & Audit, Tailored to You

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

The Three Hidden Costs Most Leaders Underestimate

Why Project Teams Burn Out Faster

Four Things That Actually Reduce Burnout

The Real Maths of Burnout

Free Project Assessment & Audit, Tailored to You

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

Why Most Recovery Efforts Start Too Late

Seven Warning Signs Your Project Is Failing

How to Recover a Failing Project: The First 30 Days

When to Recover, and When to Stop

What Changes When the Right Help Arrives

Free Project Assessment & Audit, Tailored to You

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

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

Reason 2: It Was Staffed Too Junior

Reason 3: It Has No Real Authority

Reason 4: It Measured the Wrong Things

Reason 5: It Couldn’t Adapt

Free Project Assessment & Audit, Tailored to You

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

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

Three Reasons the Middle Layer Gets Left Behind

How to Land Digital Transformation in the Middle

The Pattern We See Most Often

Free Project Assessment & Audit, Tailored to You