A Key Stakeholder: The Employees of Tomorrow
9th August 2021
It’s no secret that stakeholder analysis is a crucial part of any successful change initiative. Ensuring that different types of stakeholders are identified and represented ensures that their voices are heard and their perspectives are taken into consideration. It can be very inconvenient when a stakeholder group emerges late in the business change lifecycle—often the stakeholders themselves will feel disengaged and will find it hard to ‘buy in’ to the change. This is completely understandable, we probably all hate the feeling of having change “done” to us with insufficient consultation and engagement.
Yet one aspect that is rarely considered is time. The changes that are implemented today may well continue to exist in some shape or form for years—or even decades—to come. It might be hard to envisage that a process, journey or IT system that you are implementing today will be in existence in 20 years time. However, think back to the oldest system you’ve worked on… I’d suspect many of us have specified changes to so-called ‘legacy’ systems that were originally implemented in the 80s and 90s.
The very term ‘legacy’ is often used pejoratively, and seems to have become a codeword which broadly means ‘rigid and hard to change’. The rigidity might be down to the code-base and technical infrastructure, or it might be down to a lack of understanding around how the current solution actually works. Perhaps the people that specified it have long since left the organisation, and what is left is an IT system that perfectly meets the needs articulated by a set of stakeholders 25 years ago. Meanwhile, the stakeholders of today are trying to work out why on earth certain design decisions were made, and whether there are knock-on impacts of changing them.
The Temporal Nature of Stakeholders
Someone is a stakeholder because they have a ‘stake’, an interest, in something. People’s vested interests change over time, and stakeholders come and go. If you live on a particular street, you might be interested in whether or not a new supermarket is being built directly opposite you. In ten years time, if you’ve moved, you’re unlikely to care (but the new residents will be very interested). Exactly the same is true of organisations—the processes, journeys and IT systems that we’re designing today will probably outlive the tenure of those who specify them.
This implies that there is another very important type of stakeholder, and one that is often forgotten: employees of the future. In ten years time, when the project team is long gone and that ‘project repository’ which we think will be useful has long since been relegated to the corporate dustbin, how will those employees know what was built and why? Of equal importance, how will they know what has been changed in the intervening ten years? How will they know what design compromises were made, and what the impact of those compromises were?
Leaving A Trail Of Clues
You might expect me to now talk about extensive documentation. Well, if you were hoping this blog would end with an argument for creating huge, monolithic and wordy ‘project documents’, you might be disappointed. Documentation can be useful, and there are contexts where it will be the answer, but we need to remember that we are ultimately talking about asynchronous communication here. Documentation is one way of communication across time, but there are many others, and even the best documentation is useless unless it is maintained and can be found by those that need it. How we all smile at the document which is technically available but is actually hidden 23 links deep on an intranet that nobody ever looks at…
Perhaps we could think of this differently, and think about leaving a trail of clues for stakeholders. The stakeholders of the future will be busy (just as we are today!) so they’ll need just enough information, with the ability to delve deeper if needed. This leads to a discussion over what information should be captured and in what format. Of course, what is appropriate will depend on the context, but here is a partial list:
- A short statement of why the change was initiated in the first place
- Context diagram showing the work scope and adjacent systems
- Short videos explaining particular processes/the rationale why decisions were made
- Process diagrams, and accompanying task descriptions
- Artefacts outlining the business rules
- Decision logs
- E-learning packages outlining how particular processes work
- Test cases showing what the system ought to do
Of course, these are just some examples, and notably they are from a business perspective (our technical colleagues may have additional needs). These are also artefacts that don’t have to be lengthy: A process model can be high level, giving just enough information to be useful. The level of detail can be varied depending on the context.
Many of these artefacts would be created anyway, however the art of curating them and ensuring they will be maintainable and useful for future stakeholders does take some additional effort. However, the stakeholders of the future will thank you for it… and it might just mean that a future change initiative runs more smoothly!
by Adrian Reed, Business Analysis Expert