3365 Views
0 likes
There are some common change management challenges that seem to recur across technology-related programmes, regardless of whether they involve system implementations, migrations, or digitisation, for example. This may relate to the programme focus (i.e. technology rather than people), or to the potential speed and practicality of system-related change. Here is a brief overview of the common change management challenges I’ve come across most often during my years as a consultant, along with some recommendations that could be considered for anyone in a similar situation.
This is probably the most common change management challenge that I have experienced. Technology programmes are usually planned and driven by Leaders from the Technology space, who naturally have a technology-tinted view and don’t always sufficiently consider the other half of the equation – implementing the changes into the business. Their focus is on understanding requirements for the system, designing and building the technology, ensuring successful integration and testing, and finally – deployment into Production. Timelines are planned based on the speed of delivery, without always considering the change and upskilling that needs to take place amongst change recipients in order to use the technology successfully.
When planning Releases therefore, Leaders often leave very little time between testing, and making the functionality live to users. This means that Change Management interventions (especially Learning and Development) are often squeezed into a short space of time, which is put under further pressure when testing is delayed, and deployment timelines do not move out accordingly. Without a seat at the table where such decisions are made, Change Management is often left scrambling.
There are two suggestions I’d like to raise here. The first is the role of Business Leadership. It is important to drive senior ownership of the change in the impacted business area/s – not only for the usual reasons of maintaining support to continue the initiative; ensuring sustainable change and promoting a credible role model for the business to follow. Business Leadership is also important because in technology-driven programmes where many decision makers have a tech-perspective, senior business stakeholders can provide a useful and credible counterbalance, wearing the hat of change recipients. When Technical Programme Leadership is keen to implement quickly and realise some return on investment, Business Leadership can help dictate the pace of change based on what is feasible for the business. If they understand the need for and value of Change Management, they will have more sway in influencing scope-related decisions than any level of external Change Consultant. This is the way it should be – there should be a pull for Change Management from the business once they understand the value to their staff and clients. This brings me to the second point.
Technical (and sometimes Business) Leads often don’t understand what Change Management involves or the role it plays in a programme’s success. They plan for system deployments or implementations without really considering its requirements – including reasonable quality user stories or specifications and ongoing access to information, as well as sufficient time to prepare and implement change interventions. It is useful to market the importance of Change Management and seize any opportunities to highlight it’s benefits and resulting ‘quick wins. If you can make the value of Change Management visible and get a ‘seat at the Technology table’, it will make your role in enabling change that much easier.
The second challenge is one of speed. Technology-related change can be designed, built, tested and implemented very quickly, often in an iterative way to make ongoing improvements. On the other hand, people take more time to understand the new changes, the reason for the changes and how to work differently going forward. For Change Managers, it is often difficult to bridge the gap between fast technical delivery and the need to enable change as logically and simply as possible for those impacted, allowing them time to adapt. Information and training material delivered one day may become outdated the next. This can be frustrating both for Change Consultants and for staff or clients on the receiving end.
A few recommendations may help. Firstly, try to work with Business Change Managers to co-create a way of facilitating change in the business. They understand the intricacies of their environment, and if you help them understand the programme and the common change management challenges, you can discuss effective change interventions that are also quick to adapt in line with technology changes. The old way of delivering learning, for example, may need to change. It may no longer be feasible to try keep long training manuals up-to-date in line with ongoing changes. We may need to add ‘Release notes’ to share minor changes when new releases are deployed. The bulk of the material may then be updated later. Another option may be to build learning tips and hints into the system itself, to make it user friendly and reduce staff’s reliance on formal learning material.
As Change Managers, we also need to help change recipients understand upfront what to expect during the system change, especially where an Agile approach is being taken. While some businesses are already used to Agile, many are not. We need to help them understand why this way of working is important in today’s context given the pace of technological change. It is also more important than ever to contextualise specific project changes within the broader case for change. If you can entrench the guiding benefits that you’re aiming to achieve through the programme, it will be easier for staff to contextualise minor ongoing changes. This brings us to challenge #3.
Technology projects or programmes are often managed in isolation. The scope usually relates to one tool or system, or to enabling one set of business processes, for example. When facilitating Change Management for that programme, we sometimes tend to forget the simultaneous impact of other change programmes on our impacted stakeholders. This can result in competition for airspace and change fatigue, thereby reducing our effectiveness.
It is useful to have a high-level understanding of the other programmes and changes affecting your audience, as well as their timelines and strategic intent. Again, working with Business Change Managers and securing the support of Business Leadership to prioritise the changes being introduced into their business is key.
It is also useful to integrate with Change Management teams from other programmes where there is a link between their programme and yours. This allows you to align, optimise the timing of your interventions, prevent duplicated efforts, and to present a united view to change recipients where appropriate.
A fellow Change Consultant commented on this recently on my current project. It is obvious and yet so true. Since technology-related change is often practical and centres around how to use new technology, it is so easy to focus mostly on communications and training. From an integrated Change perspective, we often forget to consider and manage the less obvious stakeholder impacts, such as changes to: decision-making as a result of reporting changes; work autonomy and roles, concerns about automation leading to job redundancies, and reduced interaction with people leading to less job satisfaction etc. These may all trigger an emotional response to the change, leading to resistance.
One way to mitigate this is to engage impacted stakeholders in discussing the impact of the changes on their jobs, and how best to handle these impacts. Change Impact Assessments should consider different types of impacts, create an open space for new insights, and explore different Change interventions for addressing them. You can also offer a secure feedback mechanism for any ongoing insights and suggestions around this, once you have positioned the context with identified staff. Don’t let the intangible ‘people’ impacts be a blind-spot in the face of more obvious and tangible system change.
As the pace and amount of technology change increases, and technology programmes start competing for airspace with end users, hopefully the alignment between Business, Change Consultants and Technology stakeholders will improve, mitigating some of these common change management challenges. I’d be interested in hearing your views about the most common change management challenges you have experienced on Technology programmes, and how to resolve them.
