How will you identify stakeholders? How will you keep your stakeholders engaged and informed?

** At first, stakeholder identification seems pretty straightforward – name the people who will affect the project or be affected. All too frequently, some very important stakeholders are forgotten.

How will you identify stakeholders? How will you keep your stakeholders engaged and informed?

There are many ways to identify the stakeholder. One can use organization charts or directories to look for stakeholders, as Measey (2015) points out. When gathering stakeholders, it can be best to create a stakeholder list of people who should be involved in product delivery. If previous projects exist around the same product, one may be able to leverage the stakeholders participating in past projects. Another way to identify stakeholders is to hold a brainstorming session to capture every name, organization, or type of stakeholder needed for the project. This kind of workshop can be a great way to identify stakeholders, as Measey (2015) points out.

Once a stakeholder has been identified, the next step is to conduct a stakeholder analysis. There are different methodologies to handle the analysis, some of which are complex and some that are easy. The end goal is to prioritize stakeholders in the order of importance as described by Maesey (2015). One way to achieve this is to create a four-quadrant square, each representing a different power or interest. The four quadrants would be broken into high power/high interest, high power/low interest, high interest/low power, and low interest/low power, as Maesey (2015) points out. The high power/high interests are governance or decision-making key players. High power/low interest are used for interest areas. High-interest/low-power stakeholders within this quadrant can be engaged by involving them in the low-risk areas and keeping them informed. The low-interest/low-power groups should be aware of what is happening in general communications such as mailing lists, newsletters, or websites.

Stakeholders are all the people and organizations with an actual or perceived stake in a project outcome. Stakeholders can be defined as party(s) with an interest in the execution or outcome of a project. These party(s) would include business streams affected by or dependent on the outcome, as Measey (2015) described. The stakeholder could also be described as any person or group that can help or hinder the project, as Measey (2015) points out.

One important part of delivering success to a project is to engage stakeholders and effectively manage the stakeholders because they can help champion a project and make it a success but also can be effective in sabotaging the project if they do not buy into or feel engaged in the project as Measey (2015) points out. Many projects do not include the right stakeholders during the project planning. The results of leaving these people out of the planning process would be a rework of requirements and features but, in the worst case, could lead to a monetary fine or even a lawsuit. It just depends on who it is and what type of project is involved. In Agile delivery, the role of the stakeholder is to be sure that the interests of the group they come from are represented during the project.

The mapping product that our team at the office is managing has some different stakeholders. The external customers provide feedback through customer advocates. The software was written to support three clients (commercial, federal, and military), so each one has particular features they want to incorporate into the product. There are also internal stakeholders. Internal stakeholders include the CIO, the DevOps team, and the customer service team. The CIO has a feature to harden the security around the application. The DevOps team requires certain changes to support the application, and the customer service team needs changes done to the application to help the users log into the system. So, there are stakeholders for the one application at many levels. Before the application is deployed, an operational readiness review (ORR) is conducted to be sure that all the stakeholders understand what will be released and agree that the release is good. A go or no go decision to deploy the release to production. The ORR is one method of keeping stakeholders engaged in the product and deploying new releases.

References

Measey, P. (2015). Agile foundations : principles, practices and frameworks. Retrieved from (https://books.google.com/books?id=AUwcDQEACAAJ)