A common problem I see in many change projects, particularly technology based change, is the grouping of all the key stakeholders into one audience for engagement and communication. This is particularly rife with assuming Subject Matter Experts (SMEs) will be Super Users and also trainers or change champions. I find it more helpful to consider these audiences separately in order to really get the best out of them!
Let’s just do a quick review of the key audiences in technology change projects and how you might engage, manage or communicate with them. All of these audiences need to be identified, engaged, inducted and provided an indication of their roles and responsibilities. Where there is heavy usage it’s helpful to get a formal commitment from their line managers on release from their Business As Usual activity (BAU).
Charmingly pronounced SMEEZ (rhymes with cheese) are employees identified as having functional expertise. We need to ensure there is adequate time release from their “day job” and their efforts are recognised. They need to get a clear indication of the time requirements throughout the lifecycle of the project. Because of their early exposure on projects they can be a source of negativity about the change if they are not provided with context and rationale of the change. Similarly, they may also be a great source of enthusiasm as they get advanced opportunity to work through the benefits earlier than others. They may or may not be super users.
Visions of capes and undies on the outside pervade – but these are really just employees identified as having high usage of the impacted processes and systems. This group needs to be provided with additional training and education in the new system and processes in order to provide support to the rest of the employees the project goes live. There may be some overlap with change champions, but this is not automatic. They need strong support at the time of go live and for some time after as they will get the brunt of the employees queries on the changes. One of the risks with super users is that they do not necessarily have the communication and influencing skills to manage the queries they receive at the introduction of a new system. It’s often prudent to buddy them up with a change champion. They often need a Lois Lane.
I must say the term “change champion” is getting increasingly out of favour. It’s often viewed as the kiss of death, or associated with previous initiatives where they were not used so well. These employees are identified as having strong influencing and communication skills and a passion for new ways of doing things. This community will be identified, recruited, inducted and provided early education and opportunity to “play” with the technology (eg sandpit). They will be equipped with three domains of knowledge – project timing and activity, technical knowledge of the system, and change management knowledge to encourage user adoption. In some cases the change champions may be used to conduct local briefings and training. Ideally you want geographically located champions – although with more companies becoming comfortable with Enterprise Social Networks we are starting to see more e-change champions.
These are line managers and senior managers who are prepared to actively and vocally sponsor, support and role model the changes associated with the system you are introducing. Ideally, they should work alongside the change champion to ensure that the change champion is supported. In many companies, change leaders end up having the key success criteria of the change project built into their performance review. They are also integral in determining consequence management of the change – eg what happens when people work around the change.
This is an often forgotten community – and it includes teams from communications, HR, and IT functions who inevitably are needed in some capacity to make your change happen. These core functions need to be engaged early in the piece so they can plan for how they can support you. It’s no point going to them at the 11th hour and demanding they proof your communications, schedule an intranet article, or address their induction packs. If not treated with respect, they can be change blockers. The good thing about these groups is they are boundary spanners. By that, I mean they span the other projects and activities going on in the organisation and so can help you with identifying overlaps, dependencies and schedule based road blocks (eg employee engagement survey periods, financial moratoriums).
So these are the ones who come to mind – who have I missed? Who else do you like to manage as a specific community?