We’re often told that, when embarking on a major project, we need to consult with the stakeholders. All very sensible, but who are the stakeholders? This article originally appeared on the Bee Digital website.

You’ve consulted with senior leaders, teachers, students – just about everyone you can think of, in fact. You launch the product and then WHAM! People complain that it doesn’t work, or it’s impractical, or too difficult, or too – something.

What on earth went wrong?

It usually comes down to not asking all the right people, aka the stakeholders. Sometimes these people are (or should be) obvious, at other times less so, and in those cases, you’ll have to think laterally to discover who they are. I’ll give you an example of each of these kinds of situation.

Useless software

In one of my previous incarnations, I led a team of school technicians. They were based in the local authority offices and went into schools to sort out technical issues. They recorded their visits, and what they did during them, in a software application purchased sometime in the past.

The main reason for recording such incidents is to be able to detect patterns. For example, if the network in school X always “goes down” whenever it rains that suggests it’s more than “one of those things”. Similarly, if a printer in a particular room always jams up in period 3 on Wednesday, perhaps the teacher in that class needs extra support or training.

In order to get a “big picture” view of the technical state of things in the local authority’s schools, I set out to gather some data, by asking the lead technician to email me a summary report of recent visits. That’s when I discovered that the technical support software had a unique feature. Although it was easy to enter data into it, such as the name of the school visited, when, how long was spent there, what work was carried out, and so on, it was impossible to generate any reports from it.

I asked the lead technician why the software had been bought in the first place. He had no idea because apparently none of the team had had any say in the matter. They, as a group, were a vital stakeholder, and from what they said, they hadn’t been consulted. The result was that the software was, in effect, useless.

The pink slip

The scenario just described could be seen as an example of what an ICT advisor I knew used to call the “pink slip problem”. This is where a team of consultants come into a school or company and devise a marvellous new streamlined mode of operation. It fails on its first “outing” when Miss Jones in the office says “What about the pink slip?”. “What pink slip?”, you ask. “This is the stage where we have to fill in the pink slip and get it signed by the Deputy Head. But this program doesn’t have a pink slip option.”

Lateral thinking

The pink slip problem could, I suggest, be avoided quite easily. However, the issue can be more abstruse than that.

I was once in charge of the educational technology side of a new build in a secondary school. There was going to be lots of drilling in the school grounds and also the road, for underground fibre optic cables to be put in. We consulted everyone – or so we thought. Teachers, local residents, the local authority, local companies: anyone we could think of who might be affected by the disruption.

As soon as the works started, we had a protestation – from the local vicar. Because of the road works near the church, people attending Sunday services could not get to the church car park. How could we have known?

In retrospect, we should have asked all the people we consulted: “Can you think of anyone else we should be speaking to?”. Hindsight is such a great thing!

Concluding remarks

In summary, before trying to develop new products and services, you have to identify and then consult with the people who are going to be using it and affected by it. Stated like that, it’s pretty obvious. But the people you need to consult with may not be immediately obvious, and getting the go-ahead from the senior leadership team may not, ultimately, be enough.