Whether I am working on a single process or an operating model, I have found that stakeholder analysis is a good place to start. It is simple to do and often gives insights that are valuable both to the design work and to the transformation work.
Take a page of paper or a flip chart, describe the thing you are designing (process or function or whole organisation) in a circle in the middle, and array the stakeholders on spokes leading away from this central circle. A stakeholder is an individual or group of individuals or organisations who are likely to be affected by the work you are doing or whose requirements will affect the work you are doing.
Let’s take a recent project working on the processes connected with outpatients in a hospital. We wrote “outpatient processes” in the central circle. Then, at the end of the first spoke, we wrote “patients”. Then we thought it would be helpful to distinguish between different types of patient need – “day surgery”, “follow up on previous treatment”, “physiotherapy”, etc. On the next spoke we wrote “General Manager Outpatients”. Additional spokes had “Doctors”, “Nurses”, “Administrators”, “IT staff”, etc. Then we added “Suppliers” and distinguished between different types of suppliers one of which was the organisation that runs the car parking franchise. We also added “Hospital board” and “Community panel”. Broadly we were considering six categories of stakeholder: customers, employees, suppliers, bosses or owners, rule setters (such as regulators), others (such as other hospital processes that might be affected). I like to place customers on the right, suppliers on the left and owners at the top so there is a kind of flow from left to right.
Sometimes a stakeholder analysis exposes a confusion about which stakeholder group is the “customer”. In one charity, there was a confusion about whether the charity was working for “animals” or for “donors”. Should the charity decide which animals to help and then raise money to fund their work or should the charity approach donors and do whatever “animal conservation” donors were prepared to pay for. It was vital to clarify this confusion before working on an operating model.
In the outpatient’s case, we then asked “what is our offer for each of these stakeholders”. In other words, what is the stakeholder getting from “outpatient processes” that makes them care about how these processes are designed? Patients want good treatment. But, we were also ambitious to reduce waiting times and appointment cancelations, and improve administrative simplicity. For doctors, it was “support that enables the doctor to give good care”. For IT staff, it was “clear briefs and collaborative engagement”.
When we are doing design work, we are encouraged to focus on the customer and to “lean” processes, eliminating all “waste” that is not delivering value to customers. However, partly as a result of my work on operating models, I have learnt to expand my thinking beyond customers to stakeholders. Of course, it is helpful to have a primary focus, and “customer” still provides this focus. However, “outpatient processes” also need to deliver benefits to other stakeholders. Losing sight of these other stakeholders can lead to less good outcomes as well as resistance when implementing changes.
A follow up question, I often ask is which of these “stakeholder offers” is difficult to deliver and why. One reason it can be difficult to deliver “what the stakeholder needs to be engaged” is because of competition. The performance of competitors may have set such a high bar that it is really challenging to outperform or even to meet their standards. In the current environment many organisations are improving their offer to employees, making it harder for others to compete for talent. Another reason it can be difficult to deliver to a stakeholder is because one stakeholder may influence the satisfaction of another stakeholder, but have little motivation to promote engagement. This was the case with the parking franchise owner whose performance affected patients. It was also the case with IT staff whose performance affected patients and admin staff. In both of these examples, the “difficulty” was the way the relationship had been set up and the performance measures these stakeholders used to measure themselves. Part of the project involved renegotiating these relationships.
Another benefit of stakeholder analysis is that it helps define the scope of the project: what is in scope and what is not in scope. The processes used by stakeholders, such as those used by the IT team, were not in scope. Only the processes of the central circle “outpatient processes” were in scope. The stakeholder analysis helped clarify these boundaries. Hence, the project could not redesign IT process, but it could seek to influence and to renegotiate the relationship between Outpatients and IT.
A final benefit of stakeholder analysis is to alert the team to stakeholders whose involvement will be important during the implementation of changes. At the start of a project, you do not know what changes you want to make, and hence which stakeholders will need to be most closely involved. But, a stakeholder analysis helps you anticipate; and, when likely changes become clearer, it helps remind you to engage the stakeholders who will be affected.
I have rarely found that an analysis of stakeholders fails to give insights. It can take only an hour or two to do. But can have a significant impact on the quality of your work.
