Why Your Expensive Platform Purchase Won’t Transform Anything
The pattern is familiar. A public institution buys an expensive platform — ERP, CRM, document management, citizen portal. The vendor promises transformation. Leadership announces modernization. The project goes live. Six months later: staff still use spreadsheets. Citizens still call to ask basic questions. The new system sits half-empty while workarounds multiply. When outcomes don’t materialize, the vendor points to “adoption issues” and recommends more training. The platform worked fine. The problem was buying technology before understanding what needed to change.
The shelf-ware pattern This is not an edge case. It is the baseline. The Standish Group found that only 7% of enterprise software features are “always” used. Another 13% are “often” used. That leaves 64% of features either rarely or never used. (https://www.linkedin.com/pulse/why-45-all-software-features-production-never-used-david-rice) A Userlane and PwC study of 255 UK CIOs found that employees use an average of just 40% of available features in applications required for their jobs. Fewer than half of software purchases (45%) meet or exceed expected ROI. The average large organization loses upwards of £6 million annually on failed software investments. (https://www.computerweekly.com/news/365531552/Millions-wasted-as-staff-only-use-40-of-new-software-features) Nextthink analyzed over 6 million customer environments and found that nearly half of all installed software (49.96%) goes unused — resulting in over $537 million wasted annually across the organizations studied. (https://www.walkme.com/blog/unused-software-licences/) In the public sector, the numbers are worse. The Standish Group reports that government technology projects over $6 million succeed only 13% of the time. (https://www.belfercenter.org/publication/government-tech-projects-fail-default-it-doesnt-have-be-way) These aren’t implementation failures in the traditional sense. The software was installed. It runs. The failure is that it doesn’t change anything.
Why it happens Technology vendors sell platforms, not transformation. Their business model rewards closed deals, not changed outcomes. A vendor has no incentive to tell you that your processes need redesign before their software will help — that delays the sale and introduces variables they don’t control. Procurement structures reinforce this. It is easier to write a specification for a platform than for a process change. Budget cycles reward tangible purchases. A €500K line item for software is easier to justify than €150K for assessment, process redesign, and change management spread across two years. Political pressure adds urgency. Leaders want visible action. A signed contract with a recognized vendor signals progress. A six-month assessment phase signals delay — even if it prevents a six-year recovery. The result: institutions buy technology to solve problems they haven’t yet defined, for processes they haven’t yet mapped, with outcomes they haven’t yet measured.
The real problem: technology automates what you already do If your current process is broken, new software gives you an automated broken process. If citizens can’t find information because it’s scattered across PDFs, emails, and outdated pages, a new portal won’t fix that. You’ll have a new portal with scattered, outdated information. If staff use workarounds because the official process is slower than the unofficial one, new software won’t change the behavior. Staff will create new workarounds. If no one owns content updates today, no one will own them in the new system either. Technology does not redesign processes. It does not reassign responsibilities. It does not create ownership where none existed. Those are organizational changes — and they have to happen before implementation, not after. McKinsey’s research confirms this pattern: organizations that invest in cultural change see 5.3 times higher success rates than those focused only on technology. Transformations emphasizing people and change management are 2.6 times more likely to succeed than those focused predominantly on technology. (https://blog.meltingspot.io/why-digital-transformation-projects-fail/) The common thread across failed projects is not bad software. It is implementing technology before redesigning the process it is supposed to support.
What works instead The sequence matters. Assessment first. Before selecting technology, map what exists: services, workflows, responsibilities, constraints. Identify where friction actually occurs — for citizens and for staff. Establish a baseline so you can measure whether anything improves. Process redesign second. Decide what needs to change and in what order. Define who owns each change. Eliminate unnecessary steps before automating the ones that remain. As Capgemini’s ESOAR methodology puts it: Eliminate, Standardize, Optimize — then Automate. (https://www.heflo.com/blog/business-process-redesign-examples) Technology selection third. With a clear picture of current state, defined process changes, and named ownership, you can now write requirements that reflect what you actually need — not what a vendor wants to sell. This isn’t slower. It’s more predictable. And it dramatically reduces the risk of buying expensive shelf-ware.
How to tell if you’re ready Before signing a platform contract, answer these questions:
Can you describe your current process — who does what, in what order, with what tools — without guessing? Do you have a documented baseline of current performance: time to resolution, repeat inquiries, error rates, staff burden? Have you identified which steps in the process create the most friction — and confirmed that technology is the bottleneck? Is there a named owner responsible for outcomes after go-live — not just for implementation? Have you defined what success looks like in terms that don’t depend on the vendor’s metrics?
If the answer to any of these is “no,” you are not ready to buy a platform. You are ready for an assessment.
Technology is the last step, not the first The institutions that succeed don’t start with software. They start by understanding what they have, defining what needs to change, and assigning clear ownership for outcomes. Technology becomes a line item in the roadmap — selected to support defined requirements, implemented in phases, measured against a baseline that existed before the vendor arrived. The €500K platform might still be the right choice. But only after you know what problem it’s solving, for whom, and how you’ll know it worked.
DIGIPART helps public institutions avoid the shelf-ware trap. We start with assessment: mapping current state, identifying friction, and establishing a baseline. Then we build a phased roadmap with named ownership and measurable outcomes — before any technology decision is made. If you’re planning a platform purchase, or recovering from one that didn’t deliver, we can help you find a path that puts process before technology.
Sources:
Standish Group / LinkedIn: https://www.linkedin.com/pulse/why-45-all-software-features-production-never-used-david-rice Userlane & PwC / Computer Weekly: https://www.computerweekly.com/news/365531552/Millions-wasted-as-staff-only-use-40-of-new-software-features Nextthink / WalkMe: https://www.walkme.com/blog/unused-software-licences/ Standish Group / Belfer Center: https://www.belfercenter.org/publication/government-tech-projects-fail-default-it-doesnt-have-be-way McKinsey / MeltingSpot: https://blog.meltingspot.io/why-digital-transformation-projects-fail/ Capgemini ESOAR / Heflo: https://www.heflo.com/blog/business-process-redesign-examples
