When you decide to implement a new way of doing things, or a new learning management system, say, or any other major change, you will need to consult with other people at some point. But who?
The first thing you need to do is identify who the stakeholders are. I agree that terminology like “stakeholder” is pretty horrible, but if you think about it all it means is someone who has a vested interest – a stake – in the outcome.
This is where a bit of lateral thinking could come in handy. You might think the stakeholders are obvious, but I’ve discovered that that is not always the case. It’s possible to overlook crucial people by mistake. For example, some years ago I was in charge of the educational and education technology aspects of a school rebuild. I identified all the stakeholders, including local residents whose road would be blocked at one end while a company laid down underground networking cables. At least, I thought I'd identified all the stakeholders: we suddenly received a complaint from a local vicar. Say what? Apparently, the blocking of the road meant that the entrance to the church car park was blocked as well. That hadn't occurred to any of us on the team. With the benefit of hindsight, we should have asked the local residents if they could think of anyone else who might be affected – or taken a closer look at the map!
Another important element of identifying all the stakeholders is to acknowledge that you don’t know what you don’t know. In particular, you could miss an important part of a process, an aspect that you didn't even know about. This is sometimes known as 'the pink slip problem', a term that was introduced to me by my ICT and Computing advisor, Martin Kilkie. What happens is that a brilliant new system is put into practice, and as soon as it starts operating someone says, "But what about the pink slip?", referring to the fact that between Stages 4 and Stage 5 (say), someone has to fill in a pink slip and get it signed by their manager before going any further. It’s a good reason to ask everyone who could conceivably be affected by the change.
For example, you might think to yourself that it’s not important to consult with a peripatetic music teacher who works in the school with 6 pupils every Wednesday. However, unbeknown to you, she has to fill in a form to say what was covered by each pupil, and what piece of music they should practise next. If your new whiz-bang reporting system, room-booking system or whatever doesn’t allow for that, then it’s dysfunctional right from the start. It's usually much easier to anticipate problems before they occur than to fix them afterwards.
To identify who the stakeholders are, I suggest starting by making a list of as many as you can think of, and then ask other people to do the same. In fact, you could start a Google Doc or a wiki and invite everyone on the staff to contribute, or create a survey using Google Forms. Or you could go low-tech and ask people to write down their suggestions on a sheet of paper, although that does add a layer of admin to the process. You never know: someone might come up with a stakeholder that would never have occurred to you.
This stakeholder business does unfortunately add time and complexity to implementing change, but is an essential ingredient of success.