PMP Primer Masterclass Online Training
Shares

Identify Stakeholders

Shares

 

Stakeholders in PMBOK – the Identify Stakeholders process

This is the second and final process within the initiating process group, and follows on from the develop project charter process. The key word here of course is stakeholders which define anyone with an interest in the project whether that interests be positive or negative.
It would be easy to assume that this process is just about making a list of stakeholders, but its value is far higher because of stakeholders are not properly identified, and worse, the project does not fully understand their needs, then the chance of the project meeting their expectations is very slim indeed. It is almost certain that if these stakeholder needs are not understood, then the project will fail in some way.

It is important to understand that the PMBOK processes may be performed once per project, however if the project is split into phases, which is normally the case, then most of the activities will be performed multiple times. In all cases it needs to be performed after the process of develop project charter.

There are four pre-requisites or inputs needed in order to carry out the identify stakeholders process:
The project charter.

This is a high-level document that triggers the project. It is the project charter that defines an official and recognized project requirement. It is in effect a ‘contract’ of understanding. The project charter may describe some of the stakeholders along with their interests either in the project itself or the end-product/deliverable.

Procurements documents.

This input is required if there is a contract involved with the project, in which case such procurement documents should lay out who the main stakeholders are and their needs.

Enterprise environmental factors.

This too, must be considered as a common inputs for many processes, but to be careful not to gloss over this particular phrase as it is vital for you to understand the exam material. You may have heard of the acronym ‘PESTLE’ which stands for political, economic, social, technical, legislative, and environmental. This is a good starting point when considering environmental factors.

However, examples of the environment within which a project will take place are; values and work ethic, laws and regulations, industry norms, the structure and culture within your organisation, the characteristics or mindset of your projects stakeholders, the industry or market place within which your project fits, along with its appetite for risk.

Put simply, enterprise environmental factors can be just about anything external to your project that will have an effect upon it.

Organisational process assets.

This is also a common inputs to many processes. The key word here is asset, and refers to anything that will assist your project, either in the planning or the implementation. An important aspect here is that such assets may include information that allows you to scope your project more precisely. Very often such assets include documentation or information from previous similar projects – lessons learned are an example here.

Other examples of organisational process assets are:

  • Historical information
  • Documentation templates
  • Policies procedures and guidelines on any aspect of a project
  • Tools and databases
  • Estimates from previous projects on time, cost, quality or resources
  • Staff skills, knowledge, experience or competences

An important aspect of such organisational process assets, is that your current project will contribute and answers to these, thus becoming an asset for future projects.

There are two main tools that are used to help identify stakeholders.

The first is that stakeholder analysis which can be a fairly deep subject there are many approaches here. However the objectives are fairly straightforward; to identify which stakeholders should receive project communications, what communications they should receive, how all they should receive his communications, and how often they should receive them. This is a fairly common model of communication strategy.

An important aspect here is that not all stakeholders need the same treatment, because some are more important than others, while others have greater influence, and yet again others have different interests in the project outcome.

One technique that is worth mentioning is via a stakeholder map which plots each stakeholder’s interest against their impact and influence.
The second tool is again a common one which is used for many other activities, and that is expert judgement.

The key to understand this is that expert judgement is used whenever the project team or the project manager does not have sufficient expertise to carry out a process or activity.

This particular tool crops up often on planning processes, and such expertise may come from any source whatever be it internal to your organization or external. Expert judgment may come as free advice, or it may need to be solicited from paid consultants.

There are two main outputs from the identify stakeholders process namely; the stakeholder register and the stakeholder management strategy.

The first output is the stakeholder register which often contain sensitive information and therefore may only be used by the project manager. This register lists all of the project stakeholders, and goes on to describe and classify them. Such description and classification may describe for example, an individual’s perception, their prejudices, what sources of power, authority and influence they may have.

Very often such information is based on perception and is hence sensitive in nature. However its use is legitimate in that it helps the project communicate and influence with all those involved and hence enhance the probability of the project being successful in meeting its goals and objectives.

The second output is the stakeholder management strategy. This builds upon the stakeholder register, by identifying the positive or negative intentions that each may have for the project. The aim of this strategy is simple; to describe how to maximize those stakeholders able to make a positive contribution to the project are maximised, on the other side of the coin those stakeholders with either negative abilities or intention are minimised or mitigated.

To make the point again this document because of its sensitive nature is normally not published and used in a confidential manner by the project manager.

If you need help to get the PMP Exam results you deserve, then CLICK HERE

David spent 25 years as a senior project manager for US multinationals and now develops a wide range of project-related downloadable video training products under the Primer brand. In addition, David runs training seminars across the world, and is a prolific writer on the many topics of project management. He currently lives in Spain with his wife Jude.