Until the latter part of the last century, “stakeholder” referred exclusively to a person who held the stakes in a wager. It has come to mean anyone who has an interest in or is affected by the actions of a business, professional association, political group, or non-profit. For an organizational change initiative, a stakeholder is any person whose participation, support, or decisions can influence the outcome of the initiative. This typically means customers and employees, but can include suppliers and even the community.
Like a wager, the outcome of a change initiative is not known at the onset. Identifying and managing the stakeholders’ expectations is central to ensuring its success. Yet, the inescapable fact that the requirements of any initiative can evolve, and employees with different roles can have different “stakes” in the change initiative makes managing expectations difficult. Consider a straightforward example of a software firm rewriting a substantial subset of their code to take advantage of new methodologies. The software designers’ expectations are that the rewrite will result in better code that is easier to maintain. However, during the rewrite, customers may request additional features or bug fixes. The sales force may push to have these added, to make the product a stronger competitor. If the rewrite is complex and expensive, those responsible for cost control could possibly see new features as a way to justify costs, or conversely they might push for less rewriting to reduce costs.
Aligning these diverse expectations demands consistent communication. Much ink—electronic and physical— has been used to describe the process of communicating with stakeholders. The process is typically some variant on the following:
Identify Stakeholders–>Devise Communication Plans–>Disseminate Information
All of these steps are necessary, but not sufficient. There are two clear ways that feedback can improve this process. First, it helps ensure that the implementers understand the information and expectations that is disseminated. Second, every decision is made according to a set of criteria, but the decision maker cannot always foresee the downstream effects. Feedback from downstream implementers can provide critical information needed to keep expectations aligned or make adjustments to the initiative. For instance, in the above example, suppose a decision was made to trim down the scope of the re-write to reduce cost. An unforeseen outcome might be increasing the difficulty of interfacing the un-rewritten parts of the code with the newly rewritten parts—ultimately increasing costs. Seeking feedback from implementers can uncover such a problem more quickly. Anytime modifications are made to the initiative, the stakeholders’ expectations must be re-aligned or the change cannot accomplish its goals.
I would suggest the initial step is to Understand the Stakes, that is, to articulatewhat is at stake. What is the company wagering with this change initiative and what does it mean to succeed? Then go on to Identify Stakeholders; once they have been identified, it is an opportunity to revisit the stakes. Has identifying the stakeholders uncovered some additional stakes, or are others less important than initially thought? With more confidence that the stakes are clear, Devise Communication Plans. Compare the communication plans with what is at stake with the initiative. Is everything covered? Are there new issues? Then go on to Disseminate Information, and immediately Seek Feedback to sure everything is understood. Look for disconnects between what stakeholders see as their expectations and what they should be. Compare all expectations with what is at stake, and adjust as needed. Every step in the plan to communicate expectations is an opportunity to revisit the stakes and make sure that everyone understands what is at stake with the change initiative, and what is required for success.