top of page
Search

The Human Factor - Why Many PA Tools Die Quiet Deaths

  • Jun 4
  • 7 min read

THE STRATEGIC EDGE  |  Blog Series by Stefan Borst


A few days ago I sat with the global head of Public Affairs of a large chemicals company. We talked about AI and how it affects PA functions. His problem was not what you might expect. He wasn't short of the right tools. He had tools. Good ones, by his own assessment. Monitoring platforms, stakeholder systems, AI assistants, the whole lot. His problem was that his teams around the world wouldn't use them consistently.


They did not refuse them, exactly. They did attend the demo. They logged in enthusiastically during the first two weeks. Then the next consultation deadline hit, the next position paper was due, time pressure increased and everyone quietly went back to the way they had always worked. The subscription is still running. Nobody really uses it. It will eventually die a slow death: renewed once out of optimism, then cancelled with mild embarrassment.


I have heard variations of this story from PA leaders in pharma, energy, automotive and finance. The tools change. The story doesn't.


This is not just a PA problem. It's everywhere.


The numbers on this are almost comically bad. Zylo, which manages software spend for large enterprises, reported in its 2025 index that just over half of all purchased SaaS (Software as a Service) licenses sat completely idle, costing the average large organization around $21 million a year. Their 2026 edition shows modest improvement but still roughly a third of licenses unused. The reasearch firm Gartner has reported that only 16% of Microsoft Copilot pilots convert to production.


AI makes the pattern sharper, not better. S&P Global found that the share of companies abandoning most of their AI initiatives jumped from 17% to 42% in a single year. Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027. And then there is the famous MIT figure from 2025: 95% of enterprise GenAI pilots showing no measurable P&L impact. That number deserves a caveat, because it came from a preliminary, non-peer-reviewed study with a narrow definition of success and a six-month window. But even heavily discounted, the direction is unambiguous. Organizations are very good at buying capability and very bad at absorbing it.


Here is a detail from that same MIT research that I find genuinely interesting, though. While the official enterprise pilots were failing, workers at 90% of the surveyed companies were using personal AI tools, on their own initiative, often against policy. Other surveys put unsanctioned AI use among knowledge workers at around 70%.


Read those two findings together and the comfortable explanation collapses. People are not resisting AI. People love AI. They use it at home, on their phones, in browser tabs the IT department can't see. What they resist is *your rollout*.


Why nobody changes a system that works


To understand why, you don't need a technology theory. You need a theory of busy people with a dash of psychology.


Roughly 43% of what we do on any given day, we do on autopilot, cued by context rather than decided afresh. That is not a character flaw, it simply is how skilled professionals function under pressure. The research on habit formation suggests it takes about two months of consistent repetition before a new behaviour becomes automatic. Now compare that with the standard tool rollout: a one-hour training webinar, a follow-up email, and the assumption that behaviour has changed. The habit research says that assumption is off by roughly fifty-nine days.


Add status quo bias, documented since Samuelson and Zeckhauser's experiments in 1988: when in doubt, people disproportionately stick with what they have. Add loss aversion: switching tools means trading a comfortable certain, risking your fluency, your speed, your shortcuts, for an uncertain future gain. Behavioral economists have spent forty years showing that humans price that trade at roughly two to one against you.


And then add the condition that defines Public Affairs specifically: there is never a quiet week. In Quorum's 2025 survey of government affairs professionals, more than a third said their team was understaffed, and nearly 30% said there was simply too much legislative and regulatory activity to track. PA work is reactive by design. The consultation closes Friday. The committee votes Tuesday. The amendment appeared overnight.


Repenning and Sterman described what happens to teams in that state in a paper whose title I love – especially in PA – and that perfectly explains half of the failed rollouts I have seen: "Nobody Ever Gets Credit for Fixing Problems That Never Happened." Teams under constant delivery pressure fall into what is called a capability trap. Low capability forces firefighting. Firefighting consumes the time that could be invested in better tools and processes – in other words, incresed capability. Consequently capability stays low, which guarantees more firefighting. The cruel twist is that any serious improvement effort makes things worse before it makes them better. In the first weeks, the new tool inevitably slows you down, because you are competent in the old system and a beginner in the new one. That perception makes teams abandon the change precisely at the bottom of that dip, go back to the old way, and sees the episode as proof that the tool didn't work.


The economists call this the productivity J-curve, and it shows up at every scale, from national statistics down to one policy analyst deciding at 18:40 on a Thursday whether to tackle the new monitoring platform or just do it the old way and go home. She does it the old way. Every individual decision is rational. The sum of those rational decisions is a dead subscription.


The leadership failure is structural, not moral


This is the point in the argument where leadership usually gets blamed for "lack of commitment," which is about as true as it is useless. The more precise failure is that leadership treats adoption as a procurement moment followed by an announcement, when everything we know says the actual purchase is the cheapest and least important part.


You may have heard that 70% of change initiatives fail. Treat that number with suspicion; the academic Mark Hughes traced it through the literature in 2011 and found it was never based on actual evidence, just consultants quoting each other since 1993. But the studies that do have methodology behind them point at the same culprit from a different angle. Boston Consulting Group came up with a rule of thumb for AI programmes which is 10/20/70: ten percent of the effort is the algorithms, twenty percent the technology and data, seventy percent the people, processes and workflows. Most organizations spend their money and attention in exactly the the other way round.


The leader buys the tool, announces the tool, perhaps opens the kickoff call, and then returns to their own firefighting. Usage is never measured. Old workflows are never switched off, so the new tool competes against the old habit with the deck stacked. Nobody is given time to climb the J-curve. Six months later the conclusion is that the team "wasn't ready," and the cycle restarts with the next vendor.


What working adoption actually looks like


There is a way to avoid this. It is just unglamorous. From the evidence and from what we see in PA teams that have made tools stick, the pattern is consistent:


  1. Ensure your organization is ready. Especially AI tools will amplify what they find - strucure or chaos. So before adopting any new tool, make sure the foundation is solid. If it is not, work on that first.

  2. Buy less, adopt more. One tool fully embedded beats four tools at 20% usage. The honest question before any purchase is not "is this tool good?" but "which existing workflow will this replace, and who will switch the old one off?" If there is no answer, don't buy - revert to 1.

  3. Redesign the workflow, not just the toolbar. A tool dropped on top of an unchanged process is an invitation to revert. So if the monitoring platform is meant to replace the Monday morning manual press review, then the manual press review has to actually end, visibly, on a date.

  4. Give someone the mandate and the hours. The evidence on champions is clear: they accelerate adoption when they have a defined role, real time carved out, and training, not when "super user" is an honorary title added to a full workload.

  5. The leader goes first, for sixty days. Not sponsorship as a kickoff speech, but the team lead running the weekly meeting from the new dashboard, asking for the brief out of the new system, week after week, past the point where the novelty has worn off. Reinforcement is the most neglected phase of every change, and it is where tool rollouts die, because this is exactly what a firefighting team never takes the time for.

  6. Expect the dip and budget for it. Productivity goes down before it goes up. If that is not said out loud at the start, the dip reads as failure. If it is, the dip reads as the plan working.

  7. Measure use, then decide. Usage data, not renewal dates, should trigger the review. Keep what is being used, fix what is struggling, and cancel what is dead, without sentimentality.


The system that works for them


The chemicals executive said something else that stayed with me. His team's old way of working, he admitted, actually works. Positions get filed. Deadlines get met. Stakeholders get managed. That is what makes this problem so stubborn: you are not asking people to abandon a broken system. You are asking them to abandon a functioning one, on the promise of a better one, during the busiest legislative period in years.


That ask is reasonable only if you treat it as what it is: a structural change to how the team works, with an owner, a timeline, protected hours and visible leadership, not a license purchase with a hopeful email attached. This is, in the end, the same conviction that sits underneath everything we do at Advocacy Strategy: structured Public Affairs is successful Public Affairs. Tools don't transform PA teams. Structures do, and the tools follow. The teams that get this right won't be the ones with the biggest tech budget next year. They will be the ones that chose one change, made it stick, and then chose the next one.

 
 
 

Comments


bottom of page