DELIVERING a project is not the same as ADOPTING a project.

Success is not measured by what you build, but by what actually works.

It is very common to see projects being developed, but then nobody uses them. This is especially common in digital projects, ways of working, or cultural changes. It is now seen with AI.

The problem is easy to identify: deliverables (such as software, a Kanban board, or a list of values) are generated, but the new behaviours in which those deliverables are used are not generated.

Has this ever happened to you?

The illusion of a successful project

For years, I believed that a good project manager was measured by delivering projects on time and within budget.

Even many courses and methods are designed this way: perfect timelines, controlled risks, stakeholders signing off on closure documents. And somewhere in the background, it is mentioned that beyond outputs, there are outcomes, value delivery and an impact on the business. Change management is mentioned as if it were something trivial (along with power skills… which is a topic for another article).

But delivering a project does not mean that it works.

You can have the best system in the world, the most agile development, the most comprehensive training… and still fail if people do not embrace change. Projects are the vehicles of change: and if projects are not generating those desirable changes, then… what were they done for?

Sometimes I am suspicious of managers who have targets based on the ‘budget spent on projects and initiatives’, a hunger to ‘get things done’ or simply a lack of understanding of the connection that should exist between a project and the change it seeks to bring about. Or it may be the convenience of measuring only what is easy.

What is the real difference?

DELIVERING means sticking to the plan. It is measurable and predictable.

ADOPTING means changing human behaviour. It is emotional, complex, unpredictable. We can know how long it takes us to develop a new tool, but we cannot know how long it will take people to learn how to use it and truly integrate it into their business as usual.

DELIVERING questions: ‘Did we finish what we promised?’

ADOPTING asks: ‘Have people really changed the way they work?’ Adopting requires us to set aside our biases and put our egos aside in order to truly listen and observe the impact. A more difficult emotional exercise than assessing whether or not the delivery was successful.

DELIVERING measures outputs: functionalities developed, users trained, systems in production…

ADOPTING measures outcomes: more efficient processes, faster decisions, more satisfied customers. It focuses more on efficiency and problem solving.

The difference is not subtle. It’s abysmal.

Why do we fail so badly at adoption?

We believe that resistance to change is the problem. But it is not.

The problem is that we treat people as if they were part of the technical system. ‘If I explain the benefits to them, they will adopt it.’ ‘If I train them well, they will use the tool.’ ‘If I give them incentives, they will change.’

But people don’t work that way.

People embrace change when:

• We understand the personal purpose, not just the corporate one.
• We feel that the change really improves on the previous version.
• We experience improvements from day one.
• We feel like we are part of the solution, not victims of change.
• We trust in leadership

And none of this appears in traditional project plans.

Delivering without adopting is costly

The figures are staggering:

• 70% of digital transformations fail
• 60% of implemented systems have less than 50% actual adoption.

However, the emotional cost is even worse:

• Sceptical employees who no longer believe in ‘upcoming projects’
• Leaders who lose credibility
• Organisations that become allergic to change
• Huge opportunity costs, as the resources could have been allocated elsewhere.

Prioritise adoption

In my experience, projects that truly transform organisations do these things differently:

Adoption is not a ‘nice to have’ that you add at the end of the project. It is the project! And do you know which discipline provides you with structure and guidance for this? Change Management!

Before your next project, ask yourself this question: am I designing to deliver or to adopt?

Claudia Salas Bozich