There are now tools that focus on improving every aspect of communications and productivity. Many agree that an integrated digital workplace, especially an intranet, is the most powerful of these tools and can greatly benefit a company’s communications practice. Intranets function as “best of all worlds” solutions, combining social, communication, HR, and other tools all rolled into one.

One of the key questions that companies who deploy intranets ask is who the stakeholders in their intranet project are.

This question is, of course, not limited to intranets and is a staple among project managers. Stakeholder identification and engagement is extremely important; it helps you identify who will be concerned with the project’s final results and how those people may affect the project or larger business outcomes. If you can’t answer those questions, there is no guarantee your project will be successful.

There are abundant resources online explaining how to identify stakeholders, many written by and for project managers. For companies that employ project managers, this makes sense because it’s in their job description to carry out the planning and execution of all significant initiatives.

Intranet projects, however, are unique in many ways. Firstly, project managers aren’t always the responsible party. Instead, that duty often falls on internal communications or IT. For this reason, stakeholder identification is different for intranet projects.

So how can those charged with leading an intranet project identify stakeholders? Let’s start by defining our terms.

What is a stakeholder?

“An individual, group, or organization who may affect, be affected by or perceive itself to be affected by a decision, activity, or outcome of a project.”

Companies unfortunately often have very narrow views of what a stakeholder is. For instance, stakeholders will sometimes be limited to senior management, executives, or other decision makers for a project.

However, it’s easy to see how employees and entire teams would be affected by or perceive themselves to be affected by a decision, activity, or outcome of a project. This places them firmly within the definition of what a stakeholder is. The other side of that coin is that senior management, and even third parties, can’t be forgotten about if they too are accounted for in the PMBOK’s definition.

This casts a wide net for those who may be considered stakeholders. However, this definition comes with a few caveats. Number one is that there is no guarantee that employees, management, and third parties will all be stakeholders – rather, the definition seeks to not cut off the possibility of any of these.

The second caveat is that not all stakeholders are created equal. If a CEO and a front line employee are both stakeholders for a project, there’s a large chance that they aren’t stakeholders in the same way. While they may both affect and be affected by the outcome of the project, those effects will be wildly different for the two of them.

Once identified, stakeholders must be treated according to their reason for being a stakeholder. What to do with the knowledge of who your stakeholders are could be the subject of a whole other article, but noting that they won’t hold that role in the same way is just as important in identifying them as it is in actioning that knowledge.

A different identification

Articles written on identifying project stakeholders, such as the myriad pieces geared toward project management professionals, often make use of very formal tools for doing so.

The PM Study Circle blog (which also published information on the definition of a stakeholder as per the PMBOK) explores several of those tools, explaining how they can be used to identify stakeholders. The places they suggest searching for possible stakeholders include the project charter, the contract documents, the organizational process assets and enterprise environmental factors, interviewing experts (highly influential stakeholders), and conducting brainstorming sessions.

The first three of those tools are concrete documents to review and pull names from, and only conducting brainstorming sessions is completely independent of those documents. Since interviewing experts involves already knowing who highly influential stakeholders are, it cannot be considered independent.

The reason why intranet projects differ greatly from other types of projects in stakeholder identification is because some of the most important stakeholders for an intranet project cannot be discovered through contracts and charters.

The purpose of an intranet is always employee-centric. It may be to boost engagement or to share knowledge more efficiently. Maybe a company needs help in connecting field workers or employees in disparate locations. That makes all of these employees extremely important stakeholders, yet their names will not appear in any key documents, such as a contract.

The brainstorming portion of identifying stakeholders for an intranet project can then be understood as having disproportionate weight as compared with the rest of the tools suggested by the PM Study Circle. But what do we need to consider while brainstorming? How can the brainstorm help to identify stakeholders?

Asking the right questions

Asking questions is the key to identifying intranet stakeholders.

Knowing which questions to ask can be tricky, as there is no fixed set of questions and they may differ from organization to organization. However, there are some which offer an excellent starting point and are likely to be common to the majority of companies.

Your organization likely has multiple goals for its intranet rather than only one. Laying out and understanding these goals is important to identify stakeholders. Once you know, for example, that you’re looking to connect employees who work in field locations with one another, you know that the key stakeholders include all those employees who work in the field and are not already connected.

Another important question is who is involved with the project and exactly how they’re involved.

End users will be an obvious answer to this question. Once the project goals are defined, the end users who are most directly involved in the project will be clear, as will their exact involvement. As we mentioned earlier, internal communications and IT are two of the most likely departments to be leading and managing an intranet project. They and other decision makers must be included as well in this calculation.

The other questions that the PM Study Circle blog proposes are:

Who is directly involved with the project?

Who is indirectly involved with the project?

Who may be affected by the project?

Who may be affected by the project’s outcome?

Who gains or loses from the project’s success?

Who wants to complete the project successfully and who doesn’t?

Who are the suppliers?

Who is the user of the end result of the project?

Who are the competitors?

Who are the shareholders?

Is any local community impacted by the project or its outcome?

Who has the authority to influence the project or its outcome?

Who has the authority to make the project succeed?

Who can make your project fail?

These are all very important questions and are all relevant to intranets. Identifying intranet stakeholders is a necessary part of creating a successful intranet project. Done right, the benefits to your organization can be astounding.