welcome to part 5 of Stakeholder engagement for testers. This is the final part in this series you’ll all be pleased to hear 🙂
If you have not read the rest you can start back here at part 1.
so off we go…
How to inform them?
Once we know what they want, and why they want it, the final thing is identifying how to keep them informed.
Lets start with how I believe you should not keep your stakeholders informed. Standardised reporting! Sending a standard report to every Tom, Dick and Harry across all your stakeholders is a bad idea.
The reason is this, different stakeholders want different information. Different stakeholders want information presented in different ways, some are numbers driven some are narrative oriented and some like pretty graphs. Different Stakeholders what there information and different frequencies.
Now I understand the motives for standardised reports, and I have done them myself. It’s easier to only have to do one report. It might be efficient, but I don’t think its at all effective. Standardised reports can easily end up being useless to everyone. This is because to please everyone these reports become overloaded with different bits of information, it becomes disjointed and hard to read.
They can also be dangerous, especially where metrics are concerned because unless all your stakeholders have asked for that specific metric, and all have the same understanding of what that metric is (and is not) telling then, they will be read and misinterpreted. This allows for some of your stakeholders to make false assumptions about what your message is.
So what’s the alternative? Well you could create a personalised report for each of your stakeholders, but lets be honest, that is an overhead that is not sustainable. So I tend to suggest the following:
Produce more than 1 but less than 4. Unless you are lucky enough to only have 1 stakeholder then you are going to have slightly different reporting requests. There is however going to be some overlap. Therefore group the requesting into a couple of reports. I tend to find that I end up with 3 reports; one will be a technical report, for those stakeholders that are in this space such as development managers, other test areas if needed, support teams etc. The second report will be for management stakeholders such as PM’s, IT senior managers, etc. and the final one will be for business stakeholders.
The key for each of your reports send them to the relevant people, and keep the information as concise and relevant to its audience as possible, don’t overload it with stuff they don’t care about or might not understand. This is how assumptions and unwanted noise are created.
Reports are not the only way to inform your stakeholders though. In fact some stakeholders will explicitly not want them. So for these you are going to need to use other vehicles of communication. This could be meetings, group or one to one catch-ups. Use your judgement if these meetings should be formal or informal based on who the stakeholders are.
Dashboards either on walls or on things like Wiki pages is another good way to allow your stakeholders to keep themselves informed at their pace.
A demo, if appropriate is a further way to inform and engage your stakeholders. So if possible set up the occasional “show and tell” with those stakeholders that are keen on the product itself such as users of support and sales teams.