Introduction – Why Software Change is Difficult
This guide is a follow-up to the 2025 article: Why Most Software Fails.
Organisations do not struggle with technology. They struggle with change. Effective software change management is the key to moving from friction to momentum.
Yet despite unprecedented levels of digital investment, failure remains the norm. Research from McKinsey indicates that 70% of digital transformations fail to meet their objectives. This isn’t a rounding error. This is a fundamental trend.
Boston Consulting Group also found similar results. According to their research, only 30% of digital transformations achieve lasting change. The majority stall, underperform, or simply disappear from the enterprise’s radar screen.
But perhaps most interestingly, global research from Prosci found that many digital transformations fail to deliver because organisations underestimate the human dimension of change. The technology gets deployed. The platform gets configured. Yet the behaviours intended to change simply carry on as before.
This is the uncomfortable truth that CEOs and other senior leaders have to confront. Software change management isn’t just an IT project. It’s an organisational redesign project.
When you implement a new system, you aren’t simply updating technology. You are redesigning how the enterprise operates. You are redesigning how performance is measured. You are redesigning how decisions are made. You are redesigning whose expertise matters.
This creates discomfort. This creates friction. This creates stress.
If you see this as resistance to be overcome, you’ll struggle. If you see this as human nature in the face of uncertainty, you can succeed.
This guide is for executives and managers who understand that systems change is fundamentally about people. We’ll look at how to anticipate this resistance, align this behaviour to strategy, and navigate the organisation through software change management to create lasting value.
Understanding the Real Source of Resistance
One of the most common mistakes an executive makes in software change management is, according to Harvard, treating resistance as an obstruction. In most cases, resistance is simply information.
When we introduce a new system, we do not change the interface people use to interact with it. We are changing what that interface represents to them. For some people, it might represent a loss of competence. They have become efficient in how they use the old system. The new system requires them to become efficient in a different way.
For some people, it might represent a loss of status. The new system might increase transparency in how we work. Bottlenecks become more apparent. Influence is reduced as we standardise our processes. In this second set of people, resistance to software change is less about the user interface and more about the loss of control.
There is also the question of trust. If we have been through a series of initiatives that have been cancelled, implemented poorly, or implemented but ignored in practice, we have learned to wait out the latest initiative. In this case, resistance to software change is the silent non-adoption of the new system.
One of the most important things that an executive must understand in software change management is that there is a huge difference between resistance and non-adoption. The former is loud and vocal. The latter is silent and deadly. When we refer to silent non-adoption, we mean a situation in which people comply with the new software solution in how they use it in the office, but revert to the old way of doing things as soon as they get back to their desks.
Critically, diagnosis is more important than enforcement. What we need to understand is what the resistance is protecting. Is it their competence? Is it their status? Is it their workload? Is it their identity or their sense of self?
When we understand that, we can respond appropriately.
Reframing Systems Change as Behavioural Change
Most organisations discuss implementation. Very few discuss behaviour.
And this is where software change management becomes revolutionary or just another process. If the objective is to “deliver a new system”, success will be measured by logins and licenses. If the objective is to “influence behaviour”, the conversation becomes much more interesting.
A system does not simply support behaviour. A system defines behaviour. It defines who is responsible for data input, task approval, access to performance metrics, and ownership of stalled processes. Every system configuration is a leadership call to define the organisation’s future state.
This is why leadership clarity around behaviour is essential. What are we actually changing? Are we speeding up decisions? Increasing collaboration? Defining ownership? Ensuring data accuracy? Until this behaviour clarity exists, the system remains a tool without a reason to exist.
One simple exercise to clarify this discussion of behaviour is to define the current behaviour against the future behaviour. Identify where we have issues today. Identify where we have ambiguity today. Then ask what this new system does to support the future state – not the current state.
When software change management starts from a discussion around behaviour, communication becomes clearer, training becomes relevant, and success becomes meaningful.
The system does not matter. Behaviour does.
Building the Strategic Case for Software Change
Surprisingly, a large number of systems programs are justified on the basis of efficiency alone. Time saved. Costs reduced. Emails minimised. Reports simplified.
Efficiency may be important, but it does not inspire.
If senior leadership defines software change management in terms of efficiency, they are, in effect, diminishing its potential impact. People hear, “Do more with less.” And they will not be convinced.
A more compelling argument will tie the system to the organisation’s intent. How does the system support growth goals? How does the system decrease operational risk? How does the system increase client experience? How does the system allow us to scale without chaos? These are arguments at the highest level of the organisation, not the operational level.
The most effective senior leadership will also articulate the need to act now. Why are we doing this now? What are the implications if we don’t act at all? If there’s no compelling reason to act, the program will be optional for the teams and is likely to be put off.
Just as important, though, will be the willingness to have an honest discussion about the trade-offs required to deliver the system. There will be short-term pain associated with the system implementation. Productivity will likely slow at the start. People will have to learn the system. If senior leadership acknowledges that, they will build credibility.
The key to software change management is to understand that the system must be positioned as an enabler of the organisation’s intent, not one that’s been upgraded for its own sake. When people understand how their day-to-day activities fit with the organisation’s intent, they are more likely to be aligned and to support the system.
Designing Governance
One of the most preventable failures in software change management is the lack of clear governance. The leadership team launches the new system, invests in configuration and training, but never clarifies who owns the system.
Before long, the rules are fuzzy, and trust is undermined.
Before any rollout into production, leadership should clarify who owns the system strategically and operationally. An executive should be assigned to champion the system. An operational owner should be assigned to own the configuration and ongoing improvement. If this isn’t done, the system becomes “everybody’s responsibility,” which means nobody owns it.
Decision rights should be equally well defined. Who owns changes to the workflow? Who owns changes to the overall system structure? Who owns data standards? If this isn’t defined clearly, well-meaning changes to the system undermine its integrity.
Usage expectations should be equally well defined. Is this the single source of truth? Are there other acceptable sources? What does it mean to be “in compliance”? If this isn’t defined clearly, the old processes creep back into the system.
The leadership team should also model the behaviour they expect from others. If the leadership team doesn’t use the system to drive their own decisions – for example, if they use the dashboards to inform discussion at board meetings but request changes behind the scenes – this sends a powerful message: the system isn’t really important.
Governance doesn’t have to be bureaucratic to be effective. Governance should be about creating confidence. When the team understands who owns the system and where to go for guidance, they are much more likely to commit to the system. For software change management, structure breeds trust.
Communicating Change with Credibility
In software change management, change communication is viewed as an announcement. An email. A town hall. A deck of slides discussing features and timelines.
That is not communication. That is broadcasting.
Effective change communication is multi-layered and continuous. It starts with a strong executive message that explains the strategic rationale for the change, rather than the operational rationale.
One of the biggest mistakes made in change communication is over-promising. Managers talk about smooth transitions and rapid benefits. Then the reality happens – disruption, slower speeds. And the benefits do not appear as fast as promised. Trust is broken.
A more credible approach to change communication is to be honest about the disruption. There will be confusion. There will be errors. This is part of the transition.
Managers should be supported, not just informed. They should be given communication points to use, questions to expect, and a clear process to escalate these questions.
Stories are more effective than specifications. Share stories about how the new system reduces confusion, eliminates duplication, or speeds up decision-making. Benefits should be made concrete. Abstract concepts like “transformation” do not work at the team level.
Consistency is key to effective change communication. If the message from the top is that the system is critical to the organisation’s operations, then the actions from the top should reflect this.
In software change management, the tone of change communication is often the key to whether resistance hardens or begins to crumble.
Engaging Middle Managers as Change Multipliers
In most cases, the success or failure of software change management rests in the hands of middle managers in any organisation.
The top leadership defines the organisation’s direction. The frontline teams feel the effects of the changes.
However, it is the middle managers who must translate the direction into action.
They are at the crossroads where strategy meets action. They have to ensure the organisation meets its targets while also promoting the new software.
If the middle managers are not fully committed to the new system, the software change management becomes just another bureaucratic exercise layered on top of existing demands. Managers may be committed to the new system at the top, but secretly allow old systems to continue operating to ensure performance targets are met.
The process of engaging middle managers should begin early. They should be included in workflow designs and configuration discussions. They should be asked to point out what they feel are shortcomings. They are the ones who know where the problems are likely to be and where the operational realities differ from top leadership perceptions.
It is equally important to have a structured system for feedback after the system has gone live. This allows the managers to feel that their views are included in any changes to the system.
This increases ownership.
Measuring Adoption and Embedding Accountability
Many organisations report success in achieving a ‘live launch’.
The reality is that this is when software change management becomes measurable.
Adoption should be defined clearly from the start. What constitutes meaningful usage? Is it a consistent update of tasks, data entry, decision-making within the tool, or elimination of secondary reporting tools? Without explicit definitions, adoption is subjective, and debate replaces clarity.
Visibility is a key element. Leaders need access to transparent dashboards to see how the tool is being used across teams. This is not about spying on people. It is about alignment. If the tool is intended to serve as the operational backbone, then its usage must be visible.
Accountability must be in proportion to adoption. Non-adoption must be addressed through constructive conversations, rather than quiet acceptance. However, leaders must also be able to differentiate between non-adoption and capability. If adoption is low because training was inadequate, then support is required, not pressure.
In effective software change management, what is measured is what becomes ingrained in culture.
Training for Confidence, Not Just Competence
Many organisations take a very technical approach to training in software change management. Users are shown where to click, which fields to update, and where the reports are located.
The assumption here is that if users know all of this, they will use the system.
The problem, of course, is that knowledge does not necessarily translate into confidence.
An employee may know all there is to know about the system and still not use it, due to a lack of confidence in their ability to use it effectively in a visible environment.
The employee may be afraid of making mistakes in front of others, of showing their ignorance in a public setting.
The way to encourage use, therefore, is through proper training, which means making the connection between the system’s functionality and the work itself.
The training needs to be role-specific and based on actual scenarios that the team will encounter in their everyday work.
The other thing that needs to happen, of course, is that the learning curve needs to be normalised.
Managers need to let people know that it takes time to get proficient in a new system and that it is okay to ask questions.
Managers need to let people know that it is okay to make mistakes and that mistakes are a part of the process. If managers punish people for making mistakes, no one will use the system.
Software change management is all about people trusting their ability to use the system, and not just knowing where the buttons are.
Sustaining Momentum After Launch
The most perilous time in software change management is not when the change first begins, but when the system has been launched, and initial training has been delivered.
The assumption here is that, having launched the system, the adoption will continue naturally, but the fact remains that habits are difficult things to break, and people will naturally tend to fall back into their usual ways of working if they are not encouraged otherwise.
The key to sustaining this momentum is to have executive sponsorship beyond the launch phase. Regular review meetings should be held to look at usage and effectiveness. Is this tool truly helping to improve our decision-making process? Are our workflows clearer? Where are the pain points still arising?
The ‘wins’ from this process should be deliberately showcased. When people see improvements, they feel more confident. On the other hand, people who embody these behaviours should be recognised, too.
The key to this process is to realise it’s a living tool. It evolves based on feedback from people in the trenches. When people see this tool change as a result of their feedback, they feel a deeper sense of ownership.
Software change management is not a one-time process; it’s a process that solidifies when these new behaviours feel natural, rather than forced.
Conclusion – Leadership Determines the Outcome
Software change management is not a technical issue; it is a behavioural, cultural, and strategic issue.
The key theme throughout this guide has been consistent. Software change management is not a technical issue; it is a behavioural, cultural, and strategic issue. Software systems embody how things are done, how accountability is managed, and how decisions are made. When leaders view a software change management process as an IT milestone rather than an organisational change moment, they fail to achieve their objectives.
Leaders who succeed in managing change view systems change management with a clarity of purpose. They have a clear understanding of what behaviours they expect to see in their organisation. They have a governance model in place to ensure accountability. They have a high degree of confidence in their ability to communicate change, and they do so honestly.
Leaders who succeed in managing change model what they expect to see in others.
If you are about to embark on a process to implement or enhance a system, ask yourself a very basic but challenging question:
What behaviours need to change in order to create value from this investment?
