Where we help/05

We've built things, and they don't get used.

Projects deliver on time and on budget, technically speaking. Then the organisation doesn't adopt what was built. Systems sit unused. Workarounds persist. The investment does not translate into changed behaviour — and changed behaviour is the only thing that creates business value. This is not a technology problem. It is a people, process, and design problem that was never treated as part of the project.

Four people clustered at a brown-paper canvas pinned to a wood-panelled wall, working coloured sticky notes into groups together; one person facilitating the discussion.
In the room · Working the option space with the people who'll have to live with the decision

What leaders actually say

The consultants delivered. The team went back to the spreadsheet.

People say they like it in workshops. In practice, nothing changed.

We need training. We never budgeted for training.

What's actually going on

  • No user involvement in design — system built for the spec, not the workflow.
  • Training and documentation treated as afterthoughts, not deliverables.
  • No feedback loop between users and product post-launch.
  • Project declared done when software was done — not when adoption was achieved.
  • Change management absent or delegated to a single line in the project plan.
03Where we've seen this

Evidenced by

How we engage on this

Adoption isn't a phase tacked on at the end — it's built into how the work is designed. Engagements on this situation often start with a Depth Check to read where adoption is breaking down, then move into Implementation with adoption planning from sprint one, often closed out with a Sustain window covering the 60–90 days after launch. Where the problem is programme-shaped rather than product-shaped, Programme Oversight(Sune-led) is the right cover.

Start here

“The 60 days after launch decide whether the investment paid for itself. Plan for that window from the beginning.”

Start a conversation