For years, organisations focused primarily on improving their ability to develop solutions. They invested in agile working, DevOps, product teams, portfolio management, digital transformations, AI and innovation labs. We learnt how to build software faster, prioritise better and collaborate more effectively in multidisciplinary teams. And it worked; organisations have never been so good at devising and implementing change. At the same time, something striking is happening.
More and more managers are looking at reports marked in green, whilst the intended results fail to materialise. New systems are being rolled out, but not used. New working methods are being introduced, but fade into the background after a few months. This will inevitably lead to a loss of value, change fatigue, a lower ROI or a lack of execution capability.
We see this particularly in large organisations and multinationals with multiple sites, countries or business units, all supported by a central IT organisation. The challenge for these organisations no longer lies at the front end of change, but at the back end. Not in building solutions, but in ensuring they are successfully implemented.
But didn’t we already have Change Management for that? To some extent, yes: Change Management traditionally focuses on the human side of change, with methodologies for communication, stakeholder management, sponsorship and change approaches. Change Management paves the way. What is still missing, however, is the integrated management of the actual implementation within the organisation: implementation management.
An Implementation Manager or Implementation Team focuses not only on communication and engagement, but also on roll-out plans, dependencies, local adoption, operational readiness, training, support structures, benefits tracking and assurance. Implementation management therefore lies at the intersection of project and change management, technology and operations. Bringing these disciplines together ensures that a developed solution is not only delivered, but also successfully embedded within the organisation and actually put to use.
The rise of implementation management
In many organisations, we are seeing an ever-widening divide between building a solution and actually implementing it. Whilst the development team is responsible for development, a separate implementation team takes responsibility for rolling out the change and ensuring it takes root within the organisation. The development team’s responsibility effectively ends at the “ready for deployment” stage. The implementation team ensures that the solution is actually used and delivers value.
This is not a subtle distinction, and it is fundamental. A developed solution represents potential value. It is only when employees use this solution, adapt their processes and change their behaviour that actual value is created for the organisation. This creates a distinction that must be properly addressed:
- The development team provides solutions
- The implementation team drives adoption and delivers value
In traditional projects, these responsibilities often fell to the same team, but in large organisations we are seeing these disciplines becoming increasingly separate. And there are good reasons for this.
The first reason is scale: more and more organisations are developing solutions centrally for dozens of countries or business units at the same time. It is impossible for a development team in the Netherlands, India or Poland to keep track of all the local regulations, cultural differences, processes and interests.
Furthermore, the skills required are simply different: good software developers are not automatically good trainers. Product Owners are not, by definition, experts in behavioural change, and development teams are generally structured to deliver functionality, not to facilitate organisational change.
At the same time, the pace of development is accelerating: new solutions are emerging in rapid succession. Whereas in the past one project would be completed before the next began, development teams now deliver new solutions continuously. As a result, the challenge has shifted from development to implementation; it is not the building of the solution that constitutes the bottleneck, but the organisation’s capacity to absorb it.
The risks of a split model
Unfortunately, this development does not bring only benefits, as new risks are emerging at the interface between development and implementation.
The first risk is the well-known “over the fence” effect. Once the solution is available, the real challenge is only just beginning, as users will need to start working with it. Due to differing views between the development team and the implementation team on what constitutes ‘completion’, there is a risk that shortcomings or missing ‘features’ in the delivered solution will only become apparent during the implementation phase, resulting in delays and lower adoption rates.
A second risk is unclear ownership: who is ultimately responsible for the success? Is it the Product Owner who commissioned the solution, or the Implementation Manager who is overseeing the roll-out? Or is it actually the business that has to use the solution?
A third risk is the build-up of ‘adoption debt’. Just as technical debt arises when development teams build faster than they can maintain, adoption debt arises when new solutions are rolled out faster than users can adopt them. Users are faced with an ever-increasing number of changes, training sessions and new working methods, causing adoption rates to fall, whilst the backlog of implementations continues to grow.
New skills for an old discipline
If implementation is indeed a separate discipline, this also calls for a different profile to that of the traditional project manager. Naturally, project-based skills remain important: planning, risk management and monitoring progress are here to stay. However, we are also seeing a number of other competencies gaining in importance.
First and foremost, organisational sensitivity; implementation teams operate across countries, departments, management levels and cultures. The ability to bridge these worlds is becoming crucial. The ability to translate is also becoming more important – not from one language to another, but from solution to practice. The question is not what the system can do, but what it will mean tomorrow for a planner, a nurse, a service engineer or a finance officer. In addition, the importance of change management expertise is growing. Success is increasingly less determined by the quality of the solution and increasingly more by the extent to which people actually apply it. Finally, benefit management is becoming increasingly important. It is not just about implementation, but also about demonstrating that the intended benefits are actually being realised.
Not a final chapter, but a subject in its own right
Perhaps it is time to stop viewing implementation as the final phase of a project. In many organisations, implementation management is evolving into an independent field with its own processes, competencies and governance. Implementation management is a discipline situated at the intersection of technology, change and operations – a discipline that begins before go-live and continues until the change is firmly embedded within the organisation.
After all, a solution that is not adopted ultimately remains nothing more than a technical possibility. The real value arises when the organisation actually starts using it. This is not the final stage of a project, but a discipline in its own right.
