There is a particular kind of silence that settles over project meetings when everyone in the room knows something is catastrophically wrong, but and no one says it.

The budget is unrealistic.

The deadline is impossible.

The vendor is failing.

The sponsor is disengaged.

The risks have been logged, reviewed, and politely set aside.

The biggest elephant in the room of IT project management: not ignorance of risk, but the collective, tacit agreement to ignore it.

Projects do not fail because project managers lack technical knowledge. They fail because social, cultural, and psychological forces create invisible walls around inconvenient truths. These failures repeat, not occasionally, but with the inevitability of a herd of charging elephants rampaging down a steep hill – something is going to get trampled. And so it is, project after project, organisation after organisation.

“The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw (*)

WHIPSNADE – A LESSON FROM REAL ELEPHANTS

Many years ago, my PM friend Paul was at Whipsnade Zoo when he happened upon some actual elephants.

They weren’t in an enclosure; they were being guided through the park on what they called an “elephant walk”. They weren’t tethered or leashed; they were walking side by side with their keepers, each elephant holding onto the tail of the one in front with their trunk.

Paul asked a keeper how his colleagues were herding the elephants like that.

The keeper’s response is mentioned by Paul whenever we discuss “the elephant in the room” in IT Projects:

“You don’t herd elephants, you lead them,” said the keeper. What a brilliant mantra for IT project teams!

First, let’s address some of the elephants that are hiding in plain sight in our IT project portfolios and then work out how we can lead them.

“The most dangerous knowledge in a project is the kind that everyone holds privately but no one voices collectively.” – David Cotgreave, 2026

THE SIX ELEPHANTS NOBODY WANTS TO NAME

These are not wild, rare and exotic edge cases. They are structural features of how organisations deliver technology and they appear, with remarkable consistency, across industries and geographies.

1. Ignored Risks

Teams see the warning signs. They log them in risk registers. Then, driven by fear of the messenger being shot, they stay silent in steering committees.

2. The Lessons Learned Paradox

Post-mortems are written. Recommendations are filed. The next project kicks off and makes the identical mistakes. Institutional memory is ceremonial, not operational.

3. Software Failure Blindness

Leaders who would never promise a bridge will be completed with 60% of the steel still routinely sign off on software projects with fundamental unknowns unresolved.

4. Human Factor & Miscommunication

Technology projects are fundamentally human endeavours. Poor communication and eroded trust between teams quietly collapse delivery capability long before a deadline appears.

5. Agile Misapplication

Agile ceremonies can become theatre, with sprints and stand-ups that signal activity while masking an absence of coherent value delivery or genuine iterative thinking.

6. Opacity

In large public-sector programmes, lack of transparency goes unaddressed because the incentives to name it are outweighed by the risks of doing so.

WHY DO ELEPHANTS PERSIST?

“The tar pit of software engineering will continue to be sticky for a long time to come.” — Fred Brooks, The Mythical Man-Month (1975)

None of this is new.

These elephants have been trampling on our project outcomes for years. So, why do they show up time and again?

There are several reasons:

• Fear: Breaking bad news to senior stakeholders carries career risk. Silence is rational self-preservation.
• Cognitive bias: Optimism bias and sunk cost fallacy distort how teams read their own evidence.
• Cultural resistance: Organisations that reward confidence suppress the very signals that would save them.
• Broken processes: RAG statuses, risk logs, and governance frameworks become rituals detached from reality.

TAMING THE ELEPHANT: FOUR COMMITMENTS

Each elephant cannot be wished away.

But, like Whipsnade’s Ming Jung, Donna (also known as Geetha), Lucha, Kaylee, and Nang Phaya – they can be named! Naming your elephant, and, more importantly, creating the conditions where naming it is safe, is the foundational act of genuine project governance.

So, let’s make four commitments to each other and our projects:

1. Create psychological safety: Risk-bearing information must flow upward without penalty. Leaders who shoot the messenger will eventually run out of messengers, and the elephant will grow unchallenged.
2. Shift from risk identification to risk action: A risk that is identified and then managed identically to one that is not identified is just bureaucracy. Risk management must be proactive and consequential.
3. Institutionalise radical transparency: Project health reporting should reflect reality, not aspirations. Stakeholders who receive accurate information, even uncomfortable information, can make better decisions.
4. Acknowledge and act, in that order: Acknowledging an elephant that you then ignore is worse than not acknowledging it at all. Naming the problem commits the team to resolving it.

HOW PMaaS ADDRESSES WHAT INTERNAL TEAMS CANNOT

The structural reason elephants persist is that the people best positioned to name them, experienced project professionals, are often the ones most embedded in the political dynamics that keep them invisible.

PMaaS introduces something rare: credible, experienced, genuinely independent oversight. Like those Whipsnade elephants, ours need leadership too. Here’s how PMaaS can help:

• Independent voice: External PMs have no internal political stake. They can name what internal teams cannot, without career consequences.
• Cross-portfolio pattern recognition: PMaaS providers see the same failure modes across dozens of clients. They recognise the elephant’s footprint before it becomes visible to those inside the project.
• Operationalised lessons learned: Rather than post-mortem documents, PMaaS embeds institutional knowledge from prior failures into live project governance, making lessons actually learned.
• Structured risk cadence: Regular, structured risk reviews led by experienced practitioners ensure risks are actively managed, not merely recorded and archived.
• Communication architecture: PMaaS designs the communication frameworks that prevent human-factor failures, with clear escalation paths, stakeholder mapping, and conflict resolution protocols.
• Transparency by design: Governance dashboards, honest RAG reporting, and executive briefings that reflect project reality, not what stakeholders hoped to hear.

CONCLUSION

The elephant in the room of IT project management is, ultimately, not a technical problem.

It is a problem of courage, culture, and trust, the kind that no methodology or framework can solve by itself, but that can be enabled by the right structure, the right people, and the right incentives.

PMaaS is not a silver bullet, but bringing in experienced, independent project professionals who have seen the same elephant in a hundred different rooms, and who have nothing to lose by naming it, is one of the most effective structural interventions available to organisations that are tired of repeating the same failures.

The elephant is in the room. The question is no longer whether to acknowledge it. The question is who is brave enough to speak first, and whether the organisation has built the conditions that make speaking up safe.

More about Project Management as a Service from Stoneseed

(*) Quote attributed to GBS but often debated!

SOURCES:

WATCH A WHIPSNADE ELEPHANT WALK

FIND OUT MORE ABOUT PMaaS

The post IT Project Management Risk & Governance – The Herd Of Elephants in the Room appeared first on Project Accelerator News.

The Secret Diary of Gary Clencher, I.T. Project Director, Aged 51 and ¾ is a fictional diary series following one very real type of person through one very recognisable type of project. Inspired by Sue Townsend. Written entirely for fun.


If you’ve ever sat through a steering group that should have been an email…

If you’ve ever nodded along to “human-centred AI orchestration”…

If at least one person in your organisation is pretending this isn’t happening…

This one’s for you.


A Note Before We Begin

This is entirely Helen’s fault.

It started, as many questionable ideas do, on a Tuesday evening somewhere around the second glass of Primitivo, when your Marketing Manager found herself wondering what it would actually feel like to be a middle-aged IT Project Director trying to deliver an AI transformation programme while the organisation slowly rearranges itself around him.

The answer, it turns out, is Gary Clencher.

The Secret Diary of Gary Clencher, I.T. Project Director, Aged 51 and ¾ is a work of pure fiction – a comedic love letter to everyone who has ever sat through a steering group that should have been an email, received a change request with forty-seven tracked amendments, or nodded along in a meeting about “human-centred AI orchestration” without the faintest idea what was being orchestrated or for whose benefit.

Gary, Sandra, Barry, Karen, Priya, Trevor, Darren and the rest are entirely made up. Any resemblance to actual project directors, PMO analysts, or middleware is coincidental and, frankly, says more about your organisation than it does about ours.

The whole thing was inspired by the incomparable Sue Townsend, whose Adrian Mole taught a generation that the gap between how we see ourselves and how the world sees us is the funniest place there is. Gary Clencher operates firmly in that tradition – except instead of spots and unrequited love, he has scope creep and a middleware issue that Darren refuses to acknowledge.

Read it as it was written: with a glass of something, and absolutely no expectation of professional development.

Helen Marketing Manager, Glass Half Full

The Secret Diary of Gary Clencher, I.T. Project Director – Aged 51 and ¾

Navigating enterprise systems, impossible deadlines, and the terrifying spectre of artificial intelligence. A completely confidential document.

Do not share with Patricia from Finance.

Week One

In which Gary discovers AI, offends Karen, and emails the wrong budget to Patricia.

Monday

Have decided to embrace AI. Barry from the Change Management team said it will “transform our ways of working.” Barry once thought a pivot table was a piece of gym equipment. I am nonetheless keeping an open mind.

Spent forty-five minutes trying to log into the AI platform we purchased in Q3. IT helpdesk said my account “exists in principle.” This is not the reassurance I needed.

Am 51 and three-quarters. Have successfully delivered seventeen major IT programmes. Have once fixed a photocopier. I will not be defeated by a chatbot.

Tuesday

Got into the AI platform. Asked it to summarise the project risk register. It produced a seventeen-page document of extraordinary confidence and moderate accuracy. Like a consultant, but faster and without the expense account.

Note to self: “Hallucination” in AI does not mean the system is unwell. Have googled this. Still not entirely reassured.

Showed it to Karen from the PMO. She said it had invented two risks she’d never heard of and omitted the one about the server room flooding. I pointed out this was arguably an improvement on Karen’s own register, which she did not take well.

Project board meeting at 3pm. Have told no one about the AI risk register. Am sitting on a secret like a hen on a digital egg.

Wednesday

Big day. Presented the AI tool to the wider programme team. Described it as a “force multiplier for intelligent delivery.” This phrase came from the AI itself, which I feel is somewhat circular.

Darren from Infrastructure asked if it could fix the legacy middleware issue that has plagued us since 2019. I asked the AI. It said “this is a complex and multifaceted challenge requiring stakeholder alignment.” Darren said that was exactly what I always say and walked out.

Tried to get AI to write the weekly steering committee update. It did so in under eight seconds. The update was grammatically perfect and utterly devoid of the defensive ambiguity I have spent years perfecting. Had to edit heavily. Added three uses of “ongoing,” two of “in flight,” and one “we are where we are.”

Thursday

Have been asked to present our “AI adoption strategy” at next month’s Digital Futures conference. This is extremely ironic as our current AI adoption strategy is me, alone, at my desk, asking a chatbot to explain what “RAG architecture” means and nodding slowly.

RAG stands for Retrieval-Augmented Generation. This does not mean what I hoped it meant. Nobody in the project environment appears to know what it means either, but everyone is saying it with great authority.

Called a team meeting to discuss “AI integration across the programme.” There were twelve people. Ten laptops. And a collective understanding of AI that could be generously described as folkloric.

Have drafted a roadmap. The AI helped. It added a phase called “Value Realisation” which sounds excellent and means nothing. We are in business.

Friday

Quiet day. Used the AI to rephrase seventeen emails. They were all better. This is troubling.

The AI has suggested we automate the monthly status report using a pipeline that “ingests project artefacts and surfaces actionable insights.” I have forwarded this to the Head of Portfolio, describing it as my idea. This is wrong of me. I am not a good person.

Spent the afternoon reading about “prompt engineering.” It is apparently a skill. I have been doing it wrong for months. You must be specific. You must give context. This is, I note, exactly what I tell my team about writing project briefs, and they also ignore it entirely.

End of week one. Have learned the following: AI is very good at writing things. AI is moderately good at numbers, if supervised. AI does not understand Patricia from Finance. In this, AI and I are united.

Week Two

In which AI meets the board, the budget catastrophe unfolds, and Trevor arrives.

Monday

Have been asked to explain machine learning to the board. Have eleven days to prepare. This is both too long and not nearly long enough.

Spent the morning asking the AI to explain machine learning in simple terms. It gave me a very clear explanation involving dogs and cats. Asked it to make it more professional. It removed the dogs and cats and added “pattern recognition” seventeen times. Felt like a loss.

Machine learning is, as far as I can tell, the process of showing a computer thousands of examples until it stops being wrong. This is also how I trained Dave on the helpdesk. The analogy is uncomfortably apt.

My wife Sandra asked how work was going. I said I was “leading the organisation’s AI transformation agenda.” She asked if I’d remembered to put the bins out. I had not. Even AI cannot help me with this.

Tuesday — The Budget Incident

A grave day. Will record events faithfully for posterity and possible use in a tribunal.

Asked the AI to assist with reforecasting the programme budget. Gave it the spreadsheet. Gave it the context. Gave it what I thought were clear instructions. The AI reforecast the budget with tremendous efficiency and quiet confidence. It moved £340,000 from the contingency reserve into “Innovation and Experimentation.” I did not notice this. I sent it to the Finance Director.

The Finance Director’s name is Patricia. Patricia has worked in finance for twenty-six years. Patricia does not experiment.

Patricia’s email response contained four questions, two of which were rhetorical, and one sentence that ended with the words “…if this is indeed a serious document.” Have read this eleven times. It does not improve.

Replied to Patricia saying the reforecast was “a working draft intended to provoke strategic dialogue.” This is not true. It was meant to be the final version. I had already put it in the board pack.

Removed it from the board pack at 11:47pm. This is why I cannot sleep. Am 51 and three-quarters. My contingency reserve is now in innovation. This is a metaphor for something.

Wednesday

Recovery day. Told the team the budget “remains under active review.” Nobody asked further. This is either trust or indifference. After seventeen years in IT delivery, I cannot tell the difference.

Returned to the board presentation. The AI has now produced a twelve-slide deck explaining machine learning. Slide four contains a diagram that is technically accurate and completely incomprehensible. It looks like a plumbing schematic for a building that hasn’t been built yet.

Showed it to Nigel, who is our Enterprise Architect and therefore professionally obliged to find it interesting. Nigel said it was “a reasonable representation of a neural network.” I asked if the board would understand it. Nigel said “probably not, but it’ll make them feel like they should.” Kept the slide.

Have added a note at the bottom of slide four reading “simplified for clarity.” This is a lie. Nothing has been simplified. I have merely made the arrows slightly thicker.

Thursday — The Board Presentation

It is done. I am alive. This is the best that can be said.

Presented “Harnessing Artificial Intelligence Across the Programme Landscape” to the full board. Fourteen people. Twelve laptops. One man called Trevor who I have never seen before and who was introduced only as “from the centre.” Trevor wrote nothing down. This frightened me.

The dogs-and-cats explanation went well. Sir Michael laughed and then looked embarrassed about laughing, which I took as a good sign. The neural network diagram caused a silence of approximately eight seconds, which in a boardroom is geological.

The Deputy Chief Executive asked if AI would “replace the project team.” I said, “AI augments human capability rather than substituting professional judgement.” The AI wrote this line for me. There is a poetry to this that I choose not to examine.

Trevor from the centre asked one question at the end: “What’s your data governance framework for AI-generated outputs?” I said we were “actively developing a robust and iterative framework.” Trevor wrote this down. This was the only thing Trevor wrote down. I will be thinking about Trevor for some time.

Went home. Had a biscuit. Had three biscuits. Stared at the wall. Am 51 and three-quarters. Have survived.

Friday

Received two emails saying the presentation was “really thought-provoking.” In my experience “thought-provoking” means they don’t know what they think yet. This is fine. Neither do I.

Barry from Change Management has announced he is now our “AI Champion.” He has changed his email signature. It includes a small robot emoji. I said nothing. One must choose one’s battles.

Karen from the PMO has started using the AI tool. She asked it to rewrite the project initiation document. The AI produced something clear, well-structured, and free of passive voice. Karen said it “didn’t sound like us.” She is correct. This is the problem and also possibly the solution.

End of week two. The board presentation is complete. Trevor has been encountered. The budget incident is unresolved. Barry has one robot emoji. The organisation’s relationship with AI can be described as “ongoing.” Am 51 and three-quarters.

A Final Word (For Now)

I’m writing this from the departure lounge, metaphorically speaking — hand luggage packed, out-of-office on, and a novel set in Space already open on my Kindle.

Gary, however, is not going on holiday. Gary never goes on holiday. There will be something in his inbox when he gets back from his, and it will almost certainly be from Karen, and it will have tracked changes.

Whether Gary’s story continues beyond Week 2 depends entirely on you. If you’ve enjoyed his particular brand of suffering — the bilateral meetings with Trevor, Barry’s domain name, Darren’s middleware developing what we can only describe as a personality — then do let me know. Forward it to someone. Share it with whoever in your organisation would recognise every single character without needing a cast list.

If it lands well, I’ll pour another glass and find out what happens next.

The post The Secret Diary of Gary Clencher, I.T. Project Director – Aged 51 and ¾ appeared first on Project Accelerator News.

My friend Gareth is a radio presenter. He has just banned AI from the show prep process after it suggested he broadcast this “fact”: “George Ezra named himself after folk legend Woody Guthrie’s full name for his stage name.”

Gareth replied: “That George Ezra fact doesn’t make sense”

AI fessed: “You’re right, sorry about that! I completely made that up — it’s nonsense! Woody Guthrie’s full name was Woodrow Wilson Guthrie, which has nothing to do with George Ezra at all. Let me fix it”

At this point Gareth decided he was more than capable of making himself sound like an idiot without AI’s help.

Most organisations are talking about AI. Some are experimenting with it. Few are set up to use it well.

A PROMPT FREEBIE

Often, it’s all about the quality of the prompt.

If you fall into this category, Stoneseed has created some AI prompts that might help your project delivery team get the most out of AI. Check them out and share your feedback – we’re all on this journey together. Find the AI Prompt Guides in Stoneseed’s library 

BUT sometimes it runs deeper. It is more strategic, operationally nuanced and aligned to the robustness of your governance.

We all know GIGO (Garbage In, Garbage Out), the fundamental computing and mathematics concept that states that, regardless of how accurate a programme or model is, poor-quality input (“garbage”) inevitably produces unreliable, inaccurate output.

This element of GIGO is the quality of the prompt or the question that you ask of AI.

GIGO also emphasises that data quality, governance, and correct input are essential for valid results. What many fail to grasp is, this is especially true with AI.

SPAGHETTI NEST

As a Project Management as a Service (PMaaS) provider, we’ve spent over 15 years coming to the rescue of troubled projects, providing governance, resources, and structure.

These have always been key to project delivery, and now they are vital when embedding AI into your workflow.

The AI age has brought a new set of challenges for Stoneseed to help with.

Increasingly, we are starting PMaaS engagements by helping to unravel a spaghetti nest of AI confusion and unchecked missteps. The Project Management equivalent of thinking that George Ezra was somehow named after Woody Guthrie is rife, only in our world it compounds. It can be a real problem for teams, leading to miscommunication or teams being blown completely off course by AI’s occasional total lack of intelligence, artificial or otherwise.

My colleague points out, “The difference is not tools. It is structure, and consistency when using the tools. It is having a clear, joined-up approach that works across PMOs, project managers and business analysts. Because without that, AI does not scale. It fragments.”

THE REALITY OF AI ADOPTION

In an ideal world, organisations would already have:

• A clear AI strategy aligned to delivery outcomes
• Agreed tools and platforms
• Defined standards for prompts and usage
• Consistent ways of working across teams

Something designed properly. Rolled out properly. Used consistently. Most businesses are not there yet.

Instead, what we see is:

• Individuals experimenting in isolation
• Inconsistent use of tools
• Different standards across teams
• Outputs that vary in quality and reliability

Some of it works well.

Some of it (a lot of it) does not.

And most of it is disconnected.

Let’s be clear, though, and have some compassion. This is not failure. It is simply where many organisations are on their AI journey.

WHY STRATEGY AND GOVERNANCE MATTER

AI in project delivery is not just about saving time. I think it is about creating consistency at scale.

Without governance, AI introduces risk. We’ve seen:

• Inconsistent reporting to senior stakeholders
• Misaligned outputs across projects
• Lack of auditability in decision-making
• Over-reliance on individuals rather than repeatable processes

With the right structure, AI becomes something very different:

• A standard way to produce consistent outputs
• A support layer for governance and reporting
• A way to improve clarity across the portfolio
• A tool that enhances, rather than fragments, delivery

This is where most organisations need to focus first.

Instead of asking,  “Which AI tool?”

Try:

• How should AI fit into our delivery model?
• Where does it support governance?
• How do we ensure consistency across teams?
• What role do PMOs, PMs and BAs play in making it work?

>>> Ready to put structured AI prompts to work in your project delivery? Download Stoneseed’s free AI Prompt Libraries for PMs, BAs and PMOs → <<<

WHERE THIS SHOWS UP IN PRACTICE

The gap between theory and reality is most obvious in day-to-day delivery.

Portfolio and Governance

Senior stakeholders expect clear, consistent reporting.

But when each project communicates differently, AI can amplify the problem rather than solve it.

With the right governance in place, AI can:

• Standardise reporting outputs
• Improve clarity across portfolios
• Support better decision-making

Without it, you simply get faster inconsistency.

Communication and Stakeholder Management

AI can help structure communication but tone, judgement and context still matter.

A well-governed approach ensures:

• Consistent messaging
• Appropriate levels of detail
• Alignment with stakeholder expectations

This is where PMs and BAs remain critical.

From Messy Inputs to Structured Outputs

Much of delivery is still about turning unstructured information into something usable.

AI can accelerate that.

But only if there is a clear definition of what “good” looks like.

That definition comes from governance and BA-led thinking, not from the tool itself.

A Joined-Up Delivery Model

At Stoneseed, this is how we approach project delivery.

Not as separate roles or disconnected capabilities.

But as a joined-up model where PMOs, PMs and BAs work together to create structure, clarity and control.

Our Project Management as a Service model is built around providing the right capability at the right time.

• PMOs to define governance and reporting standards
• Project managers to drive delivery and accountability
• Business analysts to create clarity from complexity

That combination is what makes AI usable at scale, because tools on their own do not create consistency. People, structure and standards do.

WHY THIS MATTERS NOW

AI is already being used across delivery teams. The question is no longer whether it will be adopted – it will – it is! The questions to focus on now are whether it will be:

• Structured or fragmented
• Governed or ad hoc
• Scalable or inconsistent

Organisations that focus on strategy and governance now will get significantly more value from AI over time.

Those that do not risk creating more noise, not more clarity.

A PRACTICAL STARTING POINT

Of course, not everything needs to be solved at once.

While wider strategies and governance models are evolving, there is still value in helping delivery teams in the moment.

That is why we have also created a set of practical, copy-and-paste AI prompts for PMOs, project managers and business analysts.

They are not a strategy.

They are not a solution to governance.

They are simply useful tools.

A way to:

• Save time
• Improve clarity
• Handle day-to-day delivery challenges more efficiently

Think of them as a short-term support. A way to reduce friction while the bigger picture is being put in place.

WHEN YOU NEED MORE THAN THAT…

Prompts can help individuals work faster, but they do not create consistency across a portfolio.

They do not define governance and they do not align teams.

If your organisation is looking to move beyond experimentation and towards structured AI adoption, we can help.

Through our PMaaS model, we support organisations in putting the right governance, delivery structure and BA capability in place to make AI work properly.

No hard sell. Let’s just a practical conversation about what you need.

>>> Find out more about our BA services and access the IT Project support you need now! Download the BAaaS brochure — free → <<<

A FINAL THOUGHT

AI is not the hard part. Using it consistently, effectively and at scale is.

So …

Start with strategy.

Build the governance.

And then use the tools.

More about Project Management as a Service from Stoneseed

Notes:

Woodrow Wilson Guthrie (July 14, 1912 – October 3, 1967) was an American singer, songwriter, and composer widely considered one of the most significant figures in American folk music.

George Ezra Barnett (born 7 June 1993) is an English musician, singer-songwriter, and podcaster.

The post AI in IT Project Delivery – Why it’s deeper than “your input determines your output” appeared first on Project Accelerator News.

Project Management inspiration can come from truly anywhere, can’t it?

I just visited recently retired Project Guru Frank. Frank has been a mentor to many over the years. Without realising, he still is.

As we walked around his garden, in the sunshine, something Frank kept doing intrigued me. Every few steps, Frank crouched down, plucked a seemingly healthy shoot from the soil and either tossed it in his wheelbarrow to compost or replanted it elsewhere.

In gardening, I learned, this practice is called thinning.

I thought Frank was having “a moment”.

In spring, when new shoots are pushing through, and everything looks full of promise, the experienced gardener walks the beds and removes plants, not just the failing ones, not just the diseased ones, but healthy ones too, ones that are growing exactly as they should. The logic is counterintuitive until you understand it: left unchecked, too many healthy plants competing for the same soil, light and water means none of them can reach their potential.

>>> A PMO gives you the structure to make these thinning decisions with confidence, not guesswork. Explore Stoneseed’s PMO Services → <<<

Why am I sharing this in a Project Management blog?

Am I having “a moment” too?

No, as Frank and I walked and talked, it increasingly struck me as a great metaphor for portfolio management. Like the soil, light and water, our project resources have limits, spread them too thinly and good projects, projects that are progressing well, can soon start to wither.

How often are the hardest problems in a project portfolio not the ones that are visibly failing?

THE PORTFOLIO THAT LOOKS FINE

Imagine a portfolio review where every status is green or amber.

Delivery is progressing. Teams are engaged. Sponsors are satisfied.

On paper, everything looks healthy.

And yet something feels off. Been there? Me too.

Strategic initiatives are moving slowly. Key people are stretched.

There’s a lot of activity but not much momentum.

Leadership keeps asking why the big things aren’t landing.

The answer is rarely one bad project. It’s usually three or four good ones quietly consuming the capacity that the critical work actually needs. Like an overcrowded flower bed, everything is technically alive, but nothing has room to fully grow.

GOOD VS. GOOD IS THE HARDEST DECISION IN PORTFOLIO MANAGEMENT

Prioritisation frameworks tend to assume a relatively clear hierarchy, high strategic value beats low, high ROI beats low, but the genuinely difficult portfolio decisions aren’t between strong and weak. Instead, they’re between two things that are both legitimate, both progressing, both backed by your stakeholders.

The gardener faces the same problem.

The shoots being removed aren’t failures, they’re just occupying space that something else needs more. That distinction matters, because it means the decision can’t be made on quality alone. It has to be made on fit, on timing, on what the soil can actually support right now.

That’s where most internal PMOs stall. There’s no clean objective basis for the call, the politics are complicated, and the people closest to the work have too much invested to recommend pausing something that isn’t visibly broken.

HOW PORTFOLIOS GET SATURATED

It usually happens in a moment of organisational optimism.

After a period of constraint (budget freeze, restructuring, strategic pause), energy returns, and the instinct is to move fast. Initiatives that were parked get restarted. New opportunities get approved. Every yes is genuine; every sponsor has a legitimate case. Green lights everywhere.

The portfolio fills up quickly and, for a while, it feels like progress.

The problem surfaces later, and quietly.

Delivery teams are spread across too many priorities. The two or three initiatives that actually need to land this year are competing for attention with everything else. Progress is happening everywhere and completing nowhere. The garden looks full, but nothing is fruiting properly.

For example, imagine an organisation running three separate digital transformation initiatives at the same time: a CRM replacement, a customer portal redesign and a finance system upgrade. All three are worthwhile. All have strong sponsors. All are showing green status in the monthly review.

The problem is that each project depends on the same enterprise architect and the same senior Business Analyst.

Neither person is formally overallocated on paper, but in reality they are splitting their time across workshops, design reviews, decisions and stakeholder conversations for all three. As a result, each project keeps moving, but more slowly than planned. Decisions are delayed. Dependencies stack up. Teams lose momentum while they wait.

Individually, none of the projects looks unhealthy. Portfolio-wide, however, the organisation has created exactly the kind of overcrowding that stops the most important work from thriving.

If the CRM replacement is the initiative that matters most this year, the better decision may be to “thin” the portfolio: pause the portal redesign for three months, sequence the finance upgrade later, and allow the critical people to focus properly on the CRM. Suddenly, one project has the space to move decisively, rather than three competing to make limited progress.

By the time it’s visible, months have been lost.

Another gardener I know has always said she’d rather her trees grew a handful of apples that taste delicious than a barrow full of sour ones – I get it now. It’s a lesson our portfolios could benefit from.

WHAT A PORTFOLIO THINNING ACTUALLY INVOLVES

The answer isn’t always to cut.

Sometimes it’s sequencing, moving something genuinely valuable to a later phase when the capacity to do it properly exists.

Sometimes it’s descoping.

Sometimes it really is pausing something that, judged on its own merits, would be worth running.

What it requires is an honest assessment at the portfolio level rather than the project level:

• Where is your real delivery capacity – not headcount on paper, but actual senior bandwidth?
• Which projects are competing for the same scarce people, and which of those is most critical to your strategy this year?
• Which initiatives are progressing adequately but occupying space that higher-priority work actually needs?
• What would the portfolio look like if you focused deeply on the few initiatives that matter most, rather than spreading effort across everything?

These questions are straightforward.

Getting honest answers from inside the organisation is the hard part.

THE VIEW YOU CAN’T GET FROM INSIDE THE GARDEN

This is where proximity becomes the real problem. When you’re inside the organisation, you see each project individually: the team behind it, the effort that went into getting it approved, and the genuine progress it’s making.

What you often can’t see from that position is what it’s costing everything else.

An experienced external perspective can change that dynamic.

Not because outside eyes are smarter, but because they’re not carrying the history of every decision that shaped the portfolio. They can look at what the organisation is genuinely trying to achieve, map that against where delivery capacity is actually going, and make recommendations that an internal team might struggle to make about itself.

Telling a senior stakeholder that their project, the healthy one, the one delivering, the one they’ve championed, needs to step back to protect something more strategically critical is a genuinely difficult conversation. It requires portfolio-level visibility, clear strategic rationale, and enough distance from the internal dynamics to say it plainly. Ironically, this was the kind of thing Frank was brilliant at – and now I know why!

That’s also a significant part of what good PMaaS delivers.

As well as flexible, cost-effective access to experienced Project Managers, Business Analysts and PMO specialists (without the overhead of permanent hires), it’s the capacity to look at the whole garden, not just the individual plants, and make the call that creates room for what matters most to flourish.

Of course, sometimes all the flowers in your project garden aren’t blooming because your team is overstretched. At Stoneseed, we have a tried and tested fix for that too!

More about Project Management as a Service from Stoneseed

>>> More straight-talking insight on smarter IT project management — Download the free Straight Talk on Project Management eBook → <<<

The post A Project Management Lesson From The Garden: The Strategic Value of Thinning appeared first on Project Accelerator News.

Poor project management affects your people as much as your projects.

We get called in at all sorts of moments, across all sectors, sizes and industries.

Sometimes a project is already off the rails, sometimes a business is scaling fast, and the cracks are starting to show, and sometimes, a leadership team just quietly knows that things could, and should, work better.

BUT across all of those engagements, in all those different sectors and team sizes and working cultures, we keep noticing the same thing:

When project management is poor, people aren’t just less productive.

They’re more anxious, more burnt out, and far more likely to leave.

A recent piece by Johannes Heinlein, Chief Growth Officer at the Project Management Institute, put it plainly: strong project management is a powerful, yet often overlooked, way to build psychological safety and improve mental well-being at work.

Having seen this play out repeatedly across our client work, we couldn’t agree more.

A POORLY RUN PROJECT’S HIDDEN COSTS

Let’s be honest about what a chaotic project actually feels like from the inside.

Unclear roles.

Shifting goalposts.

Deadlines that materialise out of nowhere.

An inbox that never empties.

Blame without accountability.

The word “urgent” applied to absolutely everything.

I need a chamomile tea and a shoulder massage just writing that!

These aren’t minor inconveniences. The World Health Organisation has highlighted low job control and job insecurity as direct contributors to poor mental health at work.

A badly run project delivers both in abundance: it strips people of the sense of agency and predictability they need to feel settled and effective.

“Work should not, and does not have to, be a major source of mental distress.” Writes Johannes.

What’s striking, from our vantage point, is how this plays out differently across sectors:

In a high-growth tech company, the chaos tends to be fast and frenetic: everyone’s running at pace, but nobody quite knows what the destination is.

In a traditional professional services firm, it’s often more structural: inherited processes that no longer serve the business, and teams too polite, or too ground down, to challenge them.

In the public sector, it can be the sheer complexity of stakeholder landscapes that creates the fog.

Different contexts, but the same human cost.

STRUCTURE AS SELF-CARE

Here’s something we’ve seen change teams almost overnight: when someone finally defines what “done” looks like, who owns what, and what the realistic milestones are, people visibly relax.

That might sound simple.

But it’s rarer than it should be.

Clear roles, realistic timelines, and well-structured goals do something important: they give people back a sense of control.

As Harvard Business School professor Amy Edmondson’s research on psychological safety shows, teams that feel safe, where people can raise concerns, admit mistakes and ask for help, are more innovative, make better decisions, and perform at a higher level.

According to Johannes, a study at Yale School of Medicine found:

24% – increase in productivity from structured workplace wellbeing

25% – fewer missed work days in well-managed team environments

1 in 2 European workers lack a psychologically healthy workplace

Good project management creates the conditions for that safety to exist, removing the ambiguity that makes people second-guess themselves. It provides the regular check-ins and small wins that remind teams that progress is being made. It turns potential crises into foreseeable problems with plans attached.

WHAT THE AI ERA IS MAKING WORSE, AND WHAT FIXES IT

We’d be remiss not to acknowledge the current reality.

The rise of AI, combined with the lingering effects of the shift to distributed working, has added a new layer of anxiety to many workplaces. Questions about job security, skill relevance, and what work will look like in two years are not abstract; they’re live, daily concerns for many people in our client’s teams.

What we’ve found is that structured project management is genuinely one of the best antidotes to that disorientation. Clear communication rhythms, well-run check-ins, and defined contributions to larger goals give people a meaningful sense of belonging and purpose that transcends both physical location and the fog of technological uncertainty.

They know where they stand. They know what they’re building toward.

That matters enormously right now.

PERSPECTIVE: PROJECT AFTER PROJECT

One of the less-discussed advantages of working as a PMaaS provider, rather than embedded in a single organisation, is the breadth of perspective it gives us.

We’re not viewing project health through the lens of one culture, one leadership team, or one way of working. We bring patterns from across industries, team sizes, and stages of organisational maturity.

That means we recognise dysfunction early, because we’ve seen it before. We know which interventions land, because we’ve tried them in contexts that look a lot like yours.

We know that the businesses where people thrive, where retention is strong, energy is high, and projects actually deliver, aren’t always the ones with the most sophisticated tools or the biggest budgets. They’re the ones where the basics are genuinely embedded: clarity, accountability, realistic planning, and leadership that treats people as whole human beings.

The most effective projects rest on the well-being of the people who deliver them.

Everything else follows from that.

THINKING ABOUT HOW YOUR PROJECTS COULD RUN BETTER?

If any of this feels familiar, it may be time to look at whether your projects are supporting your people as well as your delivery goals. We’d love to talk.

No pitch, no pressure.

Just a conversation about where you are and what good might look like – for your projects and your people.

More about Project Management as a Service from Stoneseed

Sources:

https://www.management-issues.com/opinion/7783/the-hidden-mental-health-value-of-good-project-management

The post The Silent Superpower of Good Project Management: What It Does for Your Team’s Mental Health appeared first on Project Accelerator News.

The role of the Project Management Office is evolving.

The PMO was once viewed primarily as a governance function, focused on oversight, reporting, and control.

Your PMO is now expected to play a far more dynamic, business-critical role.

Organisations need their PMO not only to provide structure, but to actively enable delivery, and adapt when priorities shift.

In practice, that usually means operating in two distinct modes: providing strategic advice when clarity is needed, and embedding within teams to support delivery when capacity is stretched.

In our experience, as a provider of PMO services, both modes are increasingly valuable (from the perspective of ROI) and strategically essential. Most PMOs have strengths with one or the other – but rarely both.

WHEN DELIVERY NEEDS SUPPORT: EMBEDDED PMO CAPABILITY

For many organisations, the immediate challenge is not strategy, it’s capacity.

Projects are underway, reporting cycles need to be maintained, and governance requirements don’t pause when teams are under pressure. Hiring permanent resource can be slow and uncertain, and traditional contractor models don’t always deliver the level of integration organisations expected. I’m not knocking traditional contractor models, to be fair, they weren’t set up to address needs in this way. That said, neither where traditional PMO outsourcing services, but the beauty of an “aaS” model (as a Service) is that having recognised the business need, we were able to flex and evolve to meet it.

Indeed, this is where an embedded PMO support model provides a more effective alternative.

Rather than simply filling a gap, the focus is on integrating experienced PMO professionals into existing teams in a way that feels natural and adds value quickly. That starts with careful alignment, ensuring that capability, experience, and working style are all considered before a resource is introduced.

Structured onboarding plays a key role too.

By investing time upfront to understand your organisation’s culture, priorities, and ways of working, embedded PMO support can begin contributing immediately, without the friction that often comes with an external resource.

The result is not an external add-on, but a seamless extension of the team.

INTEGRATION OVER SUBSTITUTION

One of the common concerns when bringing in external support is how it will be received internally.

In some organisations, previous experiences with contractors  or vendor supplied project staff have created a perception that external resource operates at a distance. They’re focused on task completion rather than team contribution, or lacking alignment with the organisation’s broader objectives.

Whether that’s fair or not, it’s a perception that can create friction.

An embedded PMO model addresses this directly by prioritising integration over substitution. The objective is not to replace existing capability or to operate independently, but to support and strengthen what is already in place.

A client recently told me that one of the first questions our talent asked was: “Where’s the kettle?” They then proceeded to make a round of brews for the whole internal team. That sounds irrelevant, but on reflection, it’s a great illustration of the culture embedded in our PMO resources – all teams, however they are formed, work better when they work together.

Beyond the brew, that means:

• Working alongside internal teams, not around them
• Contributing to delivery, not just observing it
• Enhancing existing processes where appropriate, rather than imposing new ones unnecessarily

Over time, this approach builds trust, and more importantly, it leaves the organisation in a stronger position than it was before.

MORE THAN CAPACITY: ACCESS TO WIDER EXPERTISE

While embedded support is often initially driven by capacity needs, its value extends much further.

Each individual is backed by a broader network of PMO experience, meaning organisations benefit not just from an additional resource, but from access to wider expertise and proven approaches.

This can lead to incremental, but meaningful improvements: more consistent reporting, clearer governance, and better alignment across delivery. Crucially, these improvements are introduced in a way that is proportionate and sustainable, rather than disruptive.

WHEN CLARITY IS NEEDED: ADVISORY SUPPORT

There are also points where capacity alone isn’t the issue.

Organisations may be dealing with inconsistent processes, unclear governance, or limited visibility across their portfolio. In these situations, adding more resource won’t resolve the underlying challenge.

What’s needed is clarity.

Advisory support provides an opportunity to step back, assess the current state, and define a more effective way forward. This is typically delivered through a structured, time-bound engagement designed to create focus and momentum.

The emphasis is not on theory, but on practical outcomes:

• A clear understanding of current challenges
• Identification of opportunities for improvement
• A realistic, prioritised roadmap for change

Importantly, this approach is designed to be proportionate. The goal is not to over-engineer the PMO, but to ensure it is aligned to your organisation’s needs and capable of supporting delivery effectively.

FROM INSIGHT TO EXECUTION

Where our PMO aaS model becomes particularly effective is in the ability to move from advisory to delivery.

Many organisations have experienced the gap between strategy and execution: recommendations are made, but momentum is lost before meaningful change is implemented.

Bridging that gap requires continuity.

By combining advisory expertise with embedded delivery capability, organisations can move directly from defining a roadmap to putting it into practice. The same understanding that shapes the recommendations can then be applied in delivery, reducing friction and accelerating progress, creating a more joined-up approach – where insight leads directly to action.

A MORE FLEXIBLE PMO MODEL

No two organisations operate in the same way, and PMOs should reflect that.

Some require short-term support to maintain delivery during periods of change. Others need a clearer structure or stronger governance. Many need a combination of both at different times.

A flexible PMO model allows organisations to respond to these changing needs, accessing the right type of support at the right time, without being locked into a single approach.

It also ensures that support remains aligned to your organisation’s objectives, rather than introducing unnecessary complexity.

STRENGTHENING DELIVERY FROM WITHIN

Ultimately, whether the focus is on advisory or embedded support, the objective is the same: to improve how the organisation delivers.

That means strengthening existing teams, refining processes where needed, and ensuring governance supports rather than constrains progress. It also means working in a way that aligns with your organisation’s culture, because even the best-designed PMO will struggle if it doesn’t fit how the business operates.

The most effective PMOs are not defined by the complexity of their frameworks, but by their ability to enable consistent, confident delivery.

THE TAKEAWAY

The demands on today’s PMO are broader than ever.

Organisations need clarity when direction is uncertain, and capacity when delivery is under pressure. Treating these as separate challenges can lead to fragmented solutions.

A more effective approach brings both together. By combining advisory insight with embedded delivery support, you can create a PMO that is both structured and responsive.

Ultimately, the value of a PMO lies not just in its design, but in how well it enables your organisation to deliver.

NEXT STEPS

Stoneseed offers a complete range of PMO services from provision of single resources to a team of PMO experts; or a full PMO service package. We also offer PMO Consultancy and Technical Design Authority, if you have a PMO you wish to refine and improve. Download our PMO Services brochure here or visit our PMO Services page to learn more.

Find out more about Stoneseed’s PMO Services

The post Beyond Traditional PMO: Combining Embedded Delivery And Advisory appeared first on Project Accelerator News.

I’m sorry to break a third of that promise! In my defence, a new Association for Project Management (APM) report made me do it.

My friend Andy, a public sector IT Project Manager, half-jokes that multi-agency government programmes now run on two clocks: the delivery plan and electoral cycle – and party politics almost always wins.

THE IMPACT OF POLITICS ON PROJECT SUCCESS

A new APM study, ‘The Impact of Politics on Project Success in Multi-Agent Projects’, written by Professor Amos Haniff, Professor Laura Galloway and Isabel Gillert, backs up Andy’s quip and lays bare how manifesto promises, ministerial churn and cross-party conflict routinely distort priorities and timelines in complex multi-stakeholder government projects — and it makes fascinating reading.”

And, I think, it raises a question for CIOs: not how to keep politics out of programmes, but how to design delivery that survives it.

I think it also hints at the need, not just in public sector IT, but across all complex delivery environments, for a neutral and consistent delivery backbone.

WHEN PARTY POLITICS COLLIDES WITH IT PROGRAMMES

While the report focuses squarely on national-level public projects involving ministers, parliament and senior civil servants, I question whether any IT project portfolio is immune from changes in political will.

The report describes public sector programmes that change shape after each election, dependencies that are rearranged after every reshuffle, and delivery teams left to reconcile incompatible promises made at the dispatch box.

PM Andy tells me that the patterns are painfully familiar:

Manifestos commit to ambitious outcomes and dates before delivery teams have even sized the work.
New ministers inherit programmes mid-flight and seek visible resets to signal political difference.
Cross-party point-scoring turns programme milestones into opportunities for blame rather than collaboration.
Under these conditions, traditional project disciplines struggle:

Roadmaps become political artefacts as much as technical ones.
Risks are suppressed if they cut against the prevailing narrative.
Governance forums are overloaded with stakeholders whose primary accountability is to their party or department, not to the programme as a whole.
The APM research is clear: these programmes are not failing because project managers cannot use Gantt charts. They struggle because the delivery system itself is not designed for political volatility.

WHAT THE RESEARCH ACTUALLY RECOMMENDS

Crucially, the report does not indulge in wishful thinking about apolitical government. It assumes politics will continue to shape priorities, funding and public commitments.

Instead, it surfaces several themes that should catch a CIO’s eye:

Depoliticise day-to-day delivery while accepting politics at the top.
Strengthen governance and accountability so decisions and trade-offs are transparent.
Invest in professional project capability that can operate across departments and electoral cycles.
In other words: get clear about where politics legitimately belongs, in choices about outcomes, scope and public value, and where it is actively harmful, such as task-level planning, risk assessment and vendor management.

WHAT THIS MEANS FOR CIOS

Reading the report, and hearing Andy’s stories, got me thinking about the poor CIOs and project teams who actually have to navigate all this.

They sit at the intersection of policy ambition, organisational complexity and delivery reality. They cannot remove politics from programmes, but they are still expected to deliver outcomes that often span multiple departments, suppliers and parliamentary cycles.

That raises a practical question: if political volatility is inevitable, how do you design a delivery model that remains stable even when the political environment is not?

The uncomfortable reality is that many government programmes still treat delivery capability as a temporary staffing question rather than a permanent part of the delivery architecture.

Teams assemble around a programme, disperse after a reshuffle, and rebuild again when the next initiative appears. Yet the political environment surrounding these programmes is anything but temporary.

If politics is a structural feature of public programmes, perhaps delivery capability should be designed with the same permanence in mind.

DESIGNING A NEUTRAL DELIVERY BACKBONE

One response is to stop thinking of delivery purely as staffing and instead treat it as infrastructure, a managed service with its own mandate and safeguards.

Instead of each department building its own project team, you establish, or bring in, a neutral delivery backbone that supports the entire multi-agency programme.

In practice, that means a service-based project and PMO capability providing planning, reporting, RAID management, benefits tracking and integration of supplier plans across the programme.

If that sounds familiar, it is: Project Management as a Service (PMaaS)!

Crucially, in the context of the APM report, this backbone would operate with three characteristics:

Politically neutral

Accountable to agreed outcomes and service measures, not to any single party or department.

Cross-cutting

Spanning all participating agencies and major suppliers rather than sitting inside one organisational silo.

Method-led

Using common standards, artefacts and cadences across the entire programme.

Senior politicians still debate what should be done, in what order, and with what money. However, once those decisions are made, the neutral backbone is responsible for turning them into credible delivery plans and surfacing the consequences when political aspiration and operational reality diverge.

So, you are not removing politics from the system, you are simply stopping it from editing the RAID log every week.

SURVIVING RESHUFFLES AND MANIFESTO WHIPLASH

For CIOs, one of the most corrosive features of political systems is churn.

Ministers move, priorities get re-branded, and programmes are re-announced under new banners. Every change risks resetting expectations and losing institutional memory.

A service-based delivery capability provides an important counterweight:

Continuity of capability – core project leadership and PMO functions remain stable over the life of the programme.
Structured impact assessment – policy changes can be modelled quickly against scope, cost and timeline.
Evidence-based conversations – incoming ministers see the trade-offs grounded in data, not just narratives optimised for political comfort.
Political decisions will still be made, but they are made with clearer visibility of the consequences.

MANAGING MULTI-PARTY POWER, NOT JUST PROCESS

The APM research emphasises that in multi-agent public projects, power is fragmented. Departments hold different budgets, committees hold different vetoes, and suppliers hold critical knowledge.

Formal governance often masks a complex web of informal influence and political pressure.

A neutral delivery service cannot redraw those lines of power, but it can make them easier to manage:

Clear decision rights that define who can approve what.

A single version of the truth for schedules, risks and performance.

Structured escalation paths when conflicts arise between agencies or suppliers.

For CIOs, this changes the character of governance. Instead of arguing over whose spreadsheet is correct, political debate can focus on what to do about known constraints and risks.

Over time, this kind of shared delivery infrastructure can also foster a cross-department community around major programmes. Because the capability sits outside any single policy silo, it can convene agencies and suppliers around shared delivery outcomes rather than organisational boundaries.

THE CIO’S REALITY

The APM report is a useful reminder that politics is not background noise for government CIOs. It is a structural feature of the operating environment.

Party agendas, parliamentary cycles and ministerial careers all shape the conditions under which programmes must be delivered.

You cannot solve that with better templates alone.

But you can design delivery models that are resilient to political change – separating political choice from operational control, maintaining continuity of capability across reshuffles, and creating a trusted source of delivery truth across departments.

CIOs who make that shift are not opting out of politics.

They are designing programmes that can survive it.

In a world of manifesto whiplash and permanent campaign mode, that may be the most practical response of all.

More about Project Management as a Service from Stoneseed

Source

https://www.apm.org.uk/media/ivcbketn/the-impact-of-polictics-on-project-success-in-multi-agent-projects.pdf

The post PMaaS: Protecting Delivery When Politics and Projects Clash appeared first on Project Accelerator News.

Run with me on this, at the weekend I had the dubious pleasure of unclogging the bathroom sink. It’s a job I do maybe once a year—usually just removing and cleaning the U-bend. This time, I did that and, having reattached the pipes, ran the cold tap – the sink filled and did not drain.

I removed and cleaned more of the pipes, right to where the plumbing disappears into the floor, but it still didn’t drain.

At this point, I did what any self-respecting fella would do: I told the family the bathroom was out of order and put the kettle on for a ponder and a Google.

Eventually, and shamefully, a few days later (Ed – !!!!), I bought an extendable “unclogger”, like a coiled wire formed into a snake that you push into the pipe, twisting and turning as you go. It’s 7.6 m long and every centimetre entered that pipework until there was a glorious gurgling sound that signalled the job was done.

Why had I left the job incomplete, for days, after I’d reached my level of experience?

Honestly?

Fear, probably.

But the satisfaction of properly starting and completing the job was huge. I felt like a god!

I celebrated with a brew, naturally, and pondered how many IT projects we see that are either staring bewilderedly down a clogged pipeline or, worse, too fearful or out of their comfort zone to even start.

Straight up: at what point does planning become procrastination?

And what can state-of-the-art resourcing models like Project Management as a Service (PMaaS) do to help teams finally shift from preparation to progress?

THE COMFORTABLE TRAP OF “PLANNING MODE”

Planning is safe. Spreadsheets, frameworks, and RACI charts create a sense of control in an unpredictable environment. For project professionals, thoughtful planning demonstrates discipline and rigour. The problem is that sometimes, planning becomes a substitute for action.

Like I did Googling that blocked pipe, organisations can get trapped in a cycle of analysis:

• Stakeholders want more data before committing.
• Dependencies need just one more review.
• Risk logs keep expanding, not shrinking.

What starts as diligence slowly morphs into delay. Teams over-analyse, over-prepare, and lose momentum. Days spent debating scope or redrafting slide decks don’t move value closer to market; they just look productive.

WHY WE HIDE BEHIND RESEARCH

In a risk-averse culture, over-planning feels safer than delivering. Leaders want certainty, which planning seems to offer.

BUT this is a rapidly changing world, that illusion of certainty is expensive.

The causes of “planning paralysis” often boil down to four things:

• Fear of failure: Teams believe they must anticipate every risk before acting.
• Leadership pressure: Long planning phases look like good governance.
• Skill gaps: Without enough delivery experience, teams hesitate.
• Over-complexity: Cross-functional dependencies can feel overwhelming.

Ironically, by trying to avoid uncertainty, organisations simply trade one risk for another: wasted time, cost overruns, disengaged sponsors, and missed market windows. The longer a plan stays theoretical, the harder it becomes to activate.

The Moment Plans Need to Move

So, where’s the tipping point? How do you know when “strategic preparation” has crossed into delay?

The tipping point is easy to spot:

• You’ve run more steering meetings than delivery stand-ups.
• Stakeholders ask for new information more often than they make decisions.
• Your best people spend more time on documentation than execution.
• When this pattern appears, it’s not a planning issue.
• It’s a delivery capability issue.

Increasingly, organisations are solving that gap not by hiring slower, but by accessing delivery capability on demand. You don’t need more plans; you need the capacity, confidence, and clarity to execute the ones you already have.

This is where Project Management as a Service (PMaaS) can help.

PMAAS: TURNING PLANS INTO PROGRESS

PMaaS closes the gap between planning and progress by injecting delivery capability exactly when it’s needed – instead of pausing to recruit, train, or restructure internally!

That means:

• Immediate execution capacity through ready-to-go frameworks and governance.
• Objective momentum, since external PMs aren’t tied up in internal politics.
• Scalable resources that flex with budgets and portfolio peaks.
• Proven delivery methods refined across multiple sectors.

In short, PMaaS helps your organisation stop planning to deliver and start delivering the plan.

PMaaS AS A STRATEGIC LEVER

Many leaders first see PMaaS as a resourcing fix, but the real value lies in the mindset shift. It turns “what should we do next?” into “what’s stopping us from starting now?”

PMaaS partners bring more than hands-on project management. They instil structure, accountability, and focus that reset delivery tempo. A good provider acts as a catalyst, not a replacement, helping in-house teams recapture lost momentum and deliver measurable outcomes faster.

FROM THEORY TO TANGIBLE OUTCOMES

Take this simple example.

A public-sector department spent nine months building a detailed transformation roadmap. Nine months of detailed planning: dependencies mapped, risks scored.

Nothing delivered

By bringing in PMaaS specialists for six months, they moved from plan to progress: vendor contracts signed, pilot projects launched, and live dashboards tracking adoption across three departments.

The difference wasn’t strategy; it was a drive to deliver.

“Momentum feeds motivation feeds momentum,” my PM friend Malc says. Once teams see progress, confidence grows and governance meetings shift from “what if” to “what’s next.”

BALANCING PLANNING AND DOING

Smart planning isn’t the enemy, it’s essential, but balance is an art.

Think of delivery like launching a rocket. Too little preparation and it fails to break orbit. Too much, and bureaucracy burns up your fuel before lift-off. PMaaS gives you the right launch engineers at the right time to turn potential energy into progress.

A few ways to prevent planning turning into procrastination:

• Set clear go/no-go milestones; forcing decisions instead of deferrals.
• Assign accountability for activation, not just documentation.
• Embed delivery-focused PM roles early, even in planning phases.
• Use PMaaS resources strategically to fill skill gaps or accelerate readiness.

WHY 2026 IS THE YEAR TO RETHINK DELIVERY MODELS

As economic uncertainty and digital demands collide, organisations can’t afford slow starts. Projects must move from idea to execution – faster and smarter.

The rise of flexible service models across IT, operations, and HR shows that the “as-a-Service” mindset is now the default. PMaaS fits perfectly with this shift toward agile scalability and outcome-based engagement, helping leaders de-risk projects while maintaining momentum.

Adopting early gains gives you two key advantages:

Delivery agility: Respond to change without rewriting resource plans.

Speed to value: Start realising benefits while others are still revising slides.

A LAST THOUGHT: TIME TO CROSS THE BRIDGE

If your project plan’s gathering dust or momentum has been lost to workshops and review loops, maybe it’s time to move. Planning matters, but progress is priceless.

And Project Management as a Service could be the bridge that helps you cross that line, from preparation to performance, from strategy to results, from a stagnant sink to a flowing pipeline.

More about Project Management as a Service from Stoneseed

The post IT Project Delivery: When Project Planning Becomes Procrastination (and How PMaaS Gets You Moving) appeared first on Project Accelerator News.

There’s a paradox at the heart of UK enterprise IT: C-suite relationships are strengthening, yet CFO satisfaction with technology outcomes remains stubbornly low.

According to a UK C-suite survey, 83% of UK CFOs and CIOs say their relationship has strengthened over the past year. And yet, when those same CFOs are asked whether they’re happy with the impact that technology is having on their business, only 17% say yes.
The missing piece isn’t a better tool or a bigger budget. It’s governance.

THE PARADOX NOBODY’S TALKING ABOUT

More collaboration, stronger bonds, more budget, and a satisfaction rate that most businesses would find unacceptable on a customer survey, let alone an internal one.
This isn’t just stats in a research document; we see it played out in real time, in real life.

So, what’s going wrong?

The answer, when you dig into the data from Rimini Street’s UK C-suite survey, isn’t about the technology. It isn’t really about the people either. It’s about what happens, or more accurately, what doesn’t happen, in the space between a CFO’s expectation and a CIO’s delivery.

I call it the translation gap.

And it’s costing UK enterprises more than they realise.

TWO LEADERS, TWO LANGUAGES

The research paints a picture that will feel familiar to anyone who’s sat in a leadership team meeting. CFOs and CIOs are talking to each other more than ever. They’re collaborating on decisions faster. They’ve recognised — correctly — that technology and finance are no longer separate conversations.

But here’s the friction: 79% of CFOs think CIOs need to be more business-savvy to improve communication. Meanwhile, 82% of CIOs believe CFOs need to become more tech-savvy. Both sides think the other is the problem.

The reality is that both are right, and neither is the root cause. The issue isn’t a knowledge gap on either side. It’s a structural one. There is no shared language built into the project delivery process itself, no consistent mechanism for translating a CFO’s business outcome into a CIO’s delivery roadmap and then tracking that translation all the way to completion.

When that mechanism is missing:
Projects drift.
Milestones get measured in technical outputs rather than business results.
Finance leaders disengage.
Expectations and reality quietly diverge, until someone notices the 17% figure and asks what went wrong.

WHAT THE TRANSLATION GAP ACTUALLY COSTS

The survey shows that UK CFOs have a clear set of priorities they want CIOs to focus on: revenue-generating initiatives (25%), security and privacy (24%), and cost-cutting operational projects (22%).

Clear, measurable, commercial.

Now ask yourself: how many IT projects at your organisation are formally tracked against these metrics from day one?
How many project status updates include a line on revenue impact, or a running total of operational cost reduction?
How many board-level reports connect technical delivery progress to the CFO’s priority stack?

In most enterprises, the honest answer is: not many.
Projects get tracked against scope, schedule and budget, the classic triple constraint. The thing is, the CFO doesn’t primarily care about scope, schedule and budget. They care about whether the investment is moving the needle on outcomes that matter to the business.
That mismatch is what drives the 17% satisfaction figure. It’s not that the technology fails. It’s that the project was never properly anchored to the right outcomes to begin with, and nobody was consistently translating between the two worlds throughout delivery.

A GOVERNANCE PROBLEM, NOT A PEOPLE PROBLEM

It’s tempting to conclude that the solution is better communication training, or more cross-functional workshops, or simply asking CIOs and CFOs to spend more time together. The data even seems to suggest that: 43% point to the pressure of making fast, collaborative technology calls as the main driver behind the improved relationship.
However, collaboration frequency isn’t the bottleneck.

The bottleneck is that as IT budgets grow and CFOs take on greater ownership of technology decisions (65% of UK CFOs now say they’re responsible for underlying tech decisions, compared to 63% of CIOs), the same project governance structures that worked when finance and technology were separate conversations are being asked to serve both worlds at once.
They weren’t built for that. And they’re showing the strain.

Of course, neither role was originally designed to own the intersection of financial accountability and technical delivery:
The CFO thinks in business cases, ROI and risk-adjustments.
The CIO thinks in architectures, integrations and delivery sprints.

Both perspectives are valid and necessary, but they need a bridge between them, one that speaks both languages fluently and maintains that translation throughout the entire project lifecycle.
That’s not a personality trait you can necessarily hire for. It’s more a function, and increasingly, it’s a function that organisations are recognising they need.

WHERE IT PMAAS CHANGES THE EQUATION

IT Project Management as a Service does something deceptively simple: it places structured, experienced project governance at the intersection of the CFO’s world and the CIO’s world.
And keeps it there, consistently, for the duration of every engagement.

That means projects are framed in commercial outcomes from the very first conversation, not retro-fitted with financial metrics after the project goes live. It means stakeholder reporting is calibrated to what finance leaders actually need to see, not just RAG statuses and technical milestones, but progress against revenue targets, improvements to security and data protection, and measurable cost savings to date.

It means that when market conditions shift, and the survey is clear that 33% of UK enterprises currently lack contingency plans for exactly that scenario, there’s a governance layer with the flexibility and expertise to adapt quickly, without the organisation having to scramble for permanent resource it may not need long-term.Critically, it also means the CIO gets to lead delivery with greater business clarity, and the CFO gets the visibility and accountability they’re currently not getting from the 83% of partnerships that are, by all accounts, supposed to be working well.
And because PMaaS scales up or down with demand, it suits the pragmatic, incremental approach most UK enterprises are actually taking right now.

THE QUESTION WORTH ASKING

If your CFO and CIO are collaborating more than ever, but satisfaction with tech outcomes is still sitting at 17%, what would it actually take to close that gap?
The answer probably isn’t another strategy session or a new communication framework. It’s a structural change to how projects are governed from day one: anchored to commercial outcomes, translated consistently across both worlds, and accountable to the metrics that matter to the business.

That’s what we do.
That’s the structural change that closes the gap.

To explore how IT PMaaS can align delivery to business outcomes in your organisation, understand what IT PMaaS looks like in practice, and how it eases the specific pressures your CFO and CIO are navigating right now – get in touch.

More about Project Management as a Service from Stoneseed

SOURCE

This article draws on findings from Rimini Street’s UK C-suite survey, conducted by Censuswide across 250+ UK CFOs and CIOs. Full report available at: https://www.riministreet.com/resources/research-report/evolving-it-and-enterprise-investments-uk/

The post Lost in Translation: Why Over 8 out of 10 UK C-suites Are Talking More But Achieving Less – And How IT PMaaS Can Help appeared first on Project Accelerator News.

We have an ever-expanding set of digital tools and solutions, hybrid and more distributed teams for our convenience, and an ever-connected, always-plugged-in culture (adopted by many teams). They haven’t always made things better.

There, I’ve said it out loud. That, actually, feels better.

In a world where teams are under increasing and evolving pressures, it is important that we do talk about this. As we hear on every UK train journey:

“See it. Say It. Sorted”

There is usually someone within earshot, on the other end of a phone call or email, who can offer a new perspective, a word or two of wisdom or just help brainstorm a solution.

If you’re leading IT change and quietly wondering why everything feels heavier than it used to, this one’s for you.

In this blog, I’m going to recreate and combine four watercooler interactions and the kernels of insight I have heard in response. These aren’t single conversations but amalgamations of several that illustrate the shared experience of leading IT projects in these changing and fragmented times.

How come everything we do feels harder – and what can we do about it?

Strategy, Focus And Knowing What To Stop

A growing challenge in project work is deciding what you should pass, pause or pivot. And, let’s be honest, what you will politely but deliberately ignore!

With increasingly slick tools and constant input, almost everything now looks simultaneously possible and urgent.

Solution: a weekly “do‑not‑do” list.

Write down the initiatives, requests and ideas you’re consciously leaving alone, circulate it and then hold the line when the noise inevitably creeps back in.

In terms of importance, the “do‑not‑do” list sits alongside the roadmap, rather than beneath it. Strategy decays often faster than it ever has, so you need a solid document to refer to.

Stopping work or killing a project has also become more politically charged and harder than starting it. In our experience, teams are keeping initiatives alive because ending them feels uncomfortable, not because they’re still the right course of action.

Solution: Schedule explicit “stop points” alongside greenlights, where the default is to re‑justify the work, not to rubber‑stamp its continuation.

This is where PMaaS can quietly help, too. An external delivery capability is less emotionally attached to legacy projects and can provide evidence‑based recommendations on what to pause or stop, backed by capacity plans, risk views and commercial impacts rather than internal politics.

Alignment In A Fragmented, Hybrid World

Keeping different teams genuinely aligned has become trickier in hybrid and remote environments. Priorities shift, tools multiply and a slow erosion of shared understanding creates delivery risk long before anyone updates a RAID log.

Solution: A single, “central source of truth” for decisions, trade‑offs and ownership, plus a short weekly narrative explaining why things changed. That combination keeps people in sync and stops small gaps turning into big problems.

In hybrid settings, people often feel informed but still aren’t actually coordinated.

To counter that, enforce early clarity by documenting in your “central source of truth” and revisiting it at key milestones. This reduces rework and protects momentum as context inevitably fades. Managing focus is also harder when attention is scattered across too many tools and channels, so short, protected work blocks become non‑negotiable.

In practice, this is where platforms like Stoneseed’s P3MO can help. By harnessing the Microsoft 365 ecosystem you can turn a sprawl of tools into an integrated project, programme and portfolio environment: Planner or Microsoft Project for scheduling, Teams for collaboration, PowerApps and Automate for workflow, Forms for data capture and Power BI for reporting.

Instead of each team improvising its own way of working, P3MO gives you a consistent governance layer and real‑time business intelligence that keeps everyone aligned on the same story.

For many organisations, it’s not about buying yet another toolset, but unlocking the value of investments they already have. A structured P3MO implementation on Microsoft 365 can provide that stable backbone for alignment.

And PMaaS can act as a stabilising layer: a consistent governance and reporting rhythm, a standard way of documenting decisions across all projects, and practitioners whose job is to maintain alignment even as internal teams rotate or reorganise.

Money, Risk And The Invisible Edges Of Delivery

It’s increasingly difficult to make risk decisions when you never have the full picture. In compliance‑heavy work, waiting for perfect clarity often means acting too late, but moving too early can expose you to audit and security issues.

Solution: Set clear decision bars in advance: what’s enough to move forward, what triggers a pause and what needs escalation.

Rising compliance and cybersecurity requirements multiply complexity fast, so these demands need to be built into the project from day one, with every related step mapped early rather than bolted on at the end.

Modern projects also carry more invisible complexity in their architecture.

In Agile teams, the rush to ship features can hide small architectural shortcuts that turn into expensive technical debt later. So, plan specific “health check” sprints where you stop adding features, inspect core systems and pay down that debt before it starts to threaten delivery dates and budgets.

These are the edges of delivery that don’t show on a basic RAG report, but they are often where time and money quietly disappear.

Here, PMaaS gives you flexibility on both risk and cost. You can bring in specialist capability for spikes in regulatory work or technical‑debt sprints, without hard‑coding permanent headcount. At the same time, outcome‑based PMaaS contracts make financial trade‑offs more explicit, tying spend to risk reduction and value delivery rather than just time and materials.

Delivery Discipline In A Noisy Environment

The daily reality of delivery is now a constant negotiation between speed, complexity and attention.

Dependencies span security, regulation, suppliers, APIs and AI governance, and decisions stall more easily in hybrid and async work where silence can look like agreement but often hides drift.

Solution: Keep things moving by precisely defining what “done” looks like, limiting how long decisions can sit, surfacing risks early and reviewing them every week.

Every decision gets an owner, clearly articulated options with trade‑offs and a deadline; if it doesn’t affect architecture or budget, the owner decides within 48 hours.

Timelines are hardest when everyone asks for “just a few more days.”

One of my schoolteachers used to say, “The calendar doesn’t bend.”

Deadlines are fixed, communicated clearly and treated as immovable, which forces more honest planning from the start.

At the same time, set outcome‑led metrics early, make progress visible and iterate often so you’re measuring real impact, not just activity.

PMaaS can reinforce that delivery discipline by providing a standing playbook: standard definitions of “done”, agreed escalation paths, and experienced PMs who are comfortable saying “no” to date‑slippage and scope‑creep. Instead of each project inventing its own rules, you effectively rent a delivery operating system that keeps teams honest and aligned with the business case and project goals.

Honestly, writing this may have been as much personal therapy as it was anything else. To realise that you’re not alone and that, somewhere, someone is feeling the way you and I feel is good for your mental health.

It’s important to name the IT project delivery hurdles and challenges out loud and remember that you’re not alone, even if you’re working remotely on your own.

Mostly, remember that there’s always a solution.

If any of this sounds familiar, we’re always up for a no-pressure conversation about what’s making delivery harder in your world.

Let’s talk. Call today on 01623 723910 or contact us here.

More about Project Management as a Service from Stoneseed

The post POV Every IT Project Manager: “How come everything we do feels harder?” appeared first on Project Accelerator News.