6th Edition PMBOK® Guide–Process 13.2 Plan Stakeholder Engagement: Outputs

This is probably one of the simplest posts I’ve done in a long while.   I’m covering the outputs for the process 13.2 Plan Stakeholder Engagement, and there’s only one, which shouldn’t be surprising given the title of the process.   Notice, however, that most knowledge areas have a process called Plan X Management, where “X” is the name of the knowledge area.   In the case of stakeholders, however, PMI feels best to refer to this process as stakeholder engagement rather than stakeholder management.   This is perhaps because some of your stakeholders will be upper management and it would be presumptuous of you as a project manager to try to “manage” them.   Engaging, them, however, is okay.

13.2.3  Plan Stakeholder Engagement:  Outputs Stakeholder Engagement Plan

This identifies the strategies and actions required to promote productive involvement of stakeholders in the decision making process and the execution of the project plan.   The stakeholder engagement plan may include specific strategies or approaches for engaging with individual stakeholders or groups of stakeholders.   The stakeholder register is the main focus of this plan.

The next process is the executing process group, “Manage Stakeholder Engagement.”  (Here it is the engagement you are managing, not the stakeholders themselves.)     I will start with the inputs to that process.


6th Edition PMBOK® Guide–Process 13.2 Plan Stakeholder Management: Tools and Techniques

As with other planning processes, there are “generic” tools and techniques that are used in practically all knowledge areas, such as expert judgment, decision making, and meetings.   You talk to the people who know about your knowledge area, you get together with your project team in meetings, and you make decisions about what goes in the management plan.

Now there are some techniques which are specific to this particular knowledge area, the most important of which is the stakeholder engagement assessment matrix, which together with the stakeholder register will be the workhorse of not just this process, but all other processes in this area.

13.2.2  Plan Stakeholder Management:  Tools and Techniques  Expert Judgment

You should consider expertise from individuals with specialized knowledge about:

  • Politics and power structures in the organization and outside the organization
  • Analytical and assessment techniques to be used for stakeholder engagement processes (especially the stakeholder engagement assessment matrix)
  • Communications means and strategies
  • Knowledge from previous projects regarding individual stakeholders and stakeholder groups that were involved in previous similar projects.  Data Gathering

Benchmarking is a data gathering technique which compares the results of stakeholder analysis in the other tools and techniques for this process and compares them with information from other organizations.  Data Analysis

Data analysis techniques used for this process include:

  • Assumption and constraint analysis–analysis of current assumptions and constraints may be conducted in order to tailor appropriate engagement strategies.
  • Root-cause analysis–identifies underlying reasons for the current level of support of project stakeholders in order to select the appropriate strategy to improve their level of engagement.  Decision Making

Prioritization and ranking of stakeholder requirements is important, as is the ranking of the stakeholder themselves.   Those stakeholders with the most interest (those impacted by the project) and the highest influence (those who can impact the project) are often prioritized at the top of the list.  Data Representation

These are used to aid in data analysis and decision making (see the previous two paragraphs).

  • Mind mapping–visually organizes information about stakeholders, their relationship to the project, to each other, and to the organization doing the project.
  • Stakeholder engagement assessment matrix.   This supports comparison between the current engagement levels of stakeholders and the desired engagement levels required for successful project delivery.   Here is one way of classifying stakeholders:
    • Unaware–unaware of the project and potential impacts:  obviously you want to make these stakeholders aware, which means then they will turn into one of the following four classifications
    • Resistant–aware of the project, and resistant to any changes that may occur as a result of the work or outcomes of the project.  These stakeholders will be un-supportive of the work or outcomes of the project.   They might turn neutral or even supportive if you are able to address their concerns, which may involve changes to the project that mitigate the impact it will have on them and their department.
    • Neutral–aware of the project, but neither supportive nor nonsupportive, usually because it doesn’t affect them.  With these stakeholders, it is important to monitor if their position in the organization changes, because that may change their position with regards to your project.
    • Supportive–aware of the project, and supportive of the work and its outcomes.
    • Leading–aware of the project, and actively engaged in ensuring that the project is a success.   This last group is a separate one from “supportive” because the leading stakeholders can help you evangelizing to the rest of the organization.   In addition, if they are members of senior management, they will be the ones to do the heavy lifting in terms of communication with other members of senior management who are resistant to the project, mainly because they influence over those members where you as a project manager do not.   It should go without saying that you should always have at least one leading stakeholder on every project, namely, the project sponsor.

An example of the matrix is given on p. 522 of the PMBOK Guide.   Basically there is one line for every stakeholder, and the currently level of engagement (unaware, resistant, neutral, supportive, and leading) is listed as well as the desired level.

NOTE:   The stakeholder engagement assessment matrix is confidential to be used by the project team.   You can share information with the stakeholders, but not the matrix!  Meetings

As mentioned above, this is a generic tool and technique of ALL planning processes, because it is definitely an activity that the whole project team needs to be involved with because of its important for the success of the project.

With those tools and techniques, you can now produce the output of this process, namely the stakeholder management plan.  This is the subject of the next post.

6th Edition PMBOK® Guide–Process 13.2 Plan Stakeholder Management: Inputs

The Plan Stakeholder Management process has its aim the production of the Stakeholder Management Plan.   Like the management plans for other knowledge areas, it contains the guidelines for how to do all of the other processes in the area, such as Manage Stakeholder Engagement and Monitor Stakeholder Engagement.

Here are the inputs:

13.2.1  Plan Stakeholder Engagement:  Inputs  Project Charter

The project purpose, objectives, and success criteria can be used in planning how to engage stakeholders.  Project Management Plan

Here are the components of the overall project management plan that can be used for this process.

  • Resource management plan–may contain information regarding roles and responsibilities of the team and other stakeholders listed in the stakeholder register.
  • Communications management plan–the communication strategies for stakeholder management and their implementation plans are input to this process
  • Risk management plan–may contain risk thresholds or risk attitudes that can assist in the selection of the optimal stakeholder engagement strategy.

13.2.3 Project Documents

  • Assumption log–contains information about assumptions and constraints that may be linked to specific stakeholders.  ]
  • Change log–changes to the original scope of the project are usually linked to specific stakeholders who are requesting those changes, or who are involved in the decision about change requests.
  • Issue log–resolving issues contained in the issue log will require additional communications with the stakeholders affected.
  • Project schedule–contains activities that may be linked to specific stakeholder as owners or executors
  • Risk register–contains identified risks of the project and links them to specific stakeholders either as risk owners or as subject to impact from that risk.
  • Stakeholder register–the output of process 13.1 Identify Stakeholders.   The preliminary list of project stakeholders, including additional data about their classification.  Agreements

When planning for the engagement of contractors and suppliers (who are one subset of stakeholders), coordination usually involves working with the procurement/contracting group in the organization to ensure contractors and suppliers are effectively managed.  Enterprise Environmental Factors

  • Organizational culture, political climate, governance framework
  • Personnel administration policies
  • Stakeholder risk appetites
  • Established communication channels
  • Global, regional or local trends
  • Geographical distribution of facilities and resources. Organizational Process Assets

Among the OPAs listed on p. 520 of the PMBOK Guide, here are the ones that I feel are the most relevant to this process.

  • Corporate policies and procedures for social media.
  • Corporate policies and procedures for issue, risk, change, and data management.
  • Lessons learned repository with information about the preferences, actions, and involvement of stakeholders

The next post covers the tools and techniques of this process.

6th Edition PMBOK® Guide–Process 13.1 Identify Stakeholders: Outputs

In the same way that the initial Risk Management planning process creates the risk register, which is then modified throughout the remaining processes in that knowledge area, the initial Stakeholder Management process creates the stakeholder register, which is then modified throughout the remaining processes in the Stakeholder Management knowledge area.

The other outputs are updates to the project management plan and project documents.

13.1.3  Identify Stakeholders:  Outputs\  Stakeholder Register

This document contains the following information about identified stakeholders:

  • Identification information–name, organization position, location and contact details, and role on the project.
  • Assessment information–major requirements, expectations, potential for influencing project outcomes, and the phase of the project life cycle where the stakeholder has the most influence or impact.
  • Stakeholder classification–Internal/external, impact/influence (or power/interest), upward/downward/outward/sideward influence, or any other classification model chosen by the project manager.  Change Requests

The initial iteration of identifying stakeholders will not generate change requests.  However, as stakeholder identification continues throughout the project, new stakeholders or new information about the stakeholders may result in a change request.  Project Management Plan Updates

Of course, the main component that will be updated is

  • Stakeholder management plan–agreed-upon communication strategies for identified stakeholders are recorded in the stakeholder engagement plan.

Additional components of the overall project management plan that may be updated may include the following:

  • Requirements management plan–newly identified stakeholders can impact how requirement activities will be planned, tracked, and reported.
  • Communications management plan–stakeholder communication requirements and agreed-upon communications strategies are recorded in the communications management plan.
  • Risk management plan–if stakeholder communication requirements and agreed-upon communications strategies affect the approach to managing risk on the project, this is reflected in the risk management plan. Project Documents Updates

  • Assumption log–much of the information about the relative power, interest, and engagement level of stakeholders is based on assumptions, which are entered into the assumption log.   Any constraints associated with interacting with specific stakeholders are entered as well.
  • Issue log–new issues raised as a result of identifying stakeholders are recorded in the issue log.
  • Risk register–New risks identified during this process of identifying stakeholders are recorded in the risk register and managed during the risk management process.

This process is actually in the initiating process group, which consists of only two processes:  this one and 4.1 Develop Project Charter.   The fact that identifying stakeholders happens even BEFORE proper planning on the project begins tells you how vital PMI thinks the process is for the success of the project.

Now let’s move to the planning process group, which will create as a result the Stakeholder Management Plan, namely, process 13.2 Plan Stakeholder Engagement.  The inputs to that process are contained in the next post.

6th Edition PMBOK® Guide–Process 13.1 Identify Stakeholders: Tools and Techniques

There are certain processes that go in at the beginning of the project which require a brainstorming approach.   Of course, defining and then refining the requirements of the product, service or result is the core of the project planning.

However, if you want to take your project management career to the next level of success, you need to get a handle on two areas:   Risk Management and Stakeholder Management.   They may not seem on the surface to be related, but they are linked at a deeper level in the following way:   a risk is defined as an event or situation that may affect the project, and a stakeholder is a person who may influence the project (or who may be influenced by the project).   In either case, they are not under your control, and yet may effect the outcome of your project.   Trying to manage these factors that are partially out of your control is key to success so that you don’t get sidetracked on your goal of a successful project outcome.

However, the methods of dealing with these factors differs.  In risk management, you try to mitigate those factors either in terms of probability and/or impact.   You can’t control the weather, for example, but you can buy an umbrella and keep it handy so that if it does rain, you mitigate its impact on you and your clothes.   With stakeholders, we’re talking about people, so rather than try to mitigate their impact, you can actually engage with them and attempt to assuage them if they are initially opposing your project.

But in order to engage them, you have to first identify who the stakeholders are.   That is the goal of this process.  In this post, we will discuss the tools and techniques involved.

13.1.2  Identify Stakeholders:  Tools and Techniques  Expert Judgment

“Expert judgment” and “meetings” (tool and technique–see paragraph below) are what I call “generic” tools and techniques in that they are used with many, if not, most of the project management processes.

In this case, expertise should be considered from people who have specialized knowledge in:

  • Understanding the politics and power structures in the organization
  • Knowledge of the industry or type of project deliverable
  • Knowledge of the wider environment and culture including customers
  • Knowledge of individual team members contributions and expertise  Data Gathering

Here are the techniques for gathering data that can be used for this process.

  • Questionnaires and surveys–these can include one-one-on interviews or focus group sessions (see “Meetings” paragraph below)
  • Brainstorming–this elicits input from groups such as team members of subject matter experts (see “Expert Judgment” paragraph above).   Brain writing is a variant on brainstorming that allows individual participants time to consider the question(s) before the group creativity session is held.  Data Analysis

Once you’re gathered the data in the techniques listed above, how do you analyze them?

  • Stakeholder analysis–stakeholders are listed together with their
    • positions in the organization
    • relationship to the project (are they on the project, are they affected by the outcome of the project, can they affect the outcome of the project)
    • stake in the project (do they have relevant knowledge, resources, ownership or rights to an asset or property, or interest in the project’s outcome)
  • Document analysis–the repository of lessons learned from previous projects may contain information that may help identify stakeholders for the current project  Data Representation

Once you’ve analyzed the data in the techniques listed above, how to you represent them in order to prepare the stakeholder register (the outcome of the process)?

  • Impact/influence grid–this is one example of the way information gathered and analyzed in the techniques listed above can be represented in a way that pulls it all together.   One axis of the grid represents the power or influence a stakeholder has in the organization, and therefore has over the project the organization is undertaking.   One axis of the grid represents the impact that the product, service or result created by the project will have on that stakeholder.   Those who have are not impacted by the project, and who have little interest in the project, will be treated like risks that have little probability or impact on the project–i.e., they will be “monitored” in case their attitude towards the project changes., and simply informed about the results.   On the other hand, those who are greatly impacted by the project, and who have great interest in the project, will be positively engaged by the project manager.   Those in between may be informed about the process and engaged to a lesser extent by the project to increase their interest and support for the project.

The “influence” part of the impact/influence grid listed above can be given further analysis through analysis of the “directions of influence” a person has, such as:

  • Upward (senior management)
  • Downward (subject matter experts who contribute their knowledge or skills)
  • Outward (stakeholder groups and their representatives outside the organization)
  • Sideward (other project managers or middle managers who are in competition for scarce project resources)

There are other data representation techniques, like a “stakeholder cube”, which basically takes the impact/influence grid mentioned above and adds a third dimension to the analysis.   The salience model which assesses the stakeholder’s power, urgency and legitimacy (i.e., their involvement in the project is appropriate), is an example of this type of three-dimensional model.   Look at p. 512 and 513 of the 6th Edition of the PMBOK® Guide for further details.

These techniques help with prioritization of your stakeholder engagement efforts.   Those stakeholders with high levels of impact and/or influence will obviously receive more of your efforts to try to engage them.    The types of engagement you will resort to will be spelled out in the next process 13.2 Plan Stakeholder Management.  Meetings

Meetings are used to develop an understanding of significant project stakeholders through brainstorming techniques that gather and analyze data.   They can take the form of

  • Facilitation workshops
  • Small group guided discussions
  • Virtual groups (using electronics or social media technologies)

The output of these meetings will be to create forms of data representation (mentioned the previous paragraph) to help prioritize the engagement of stakeholders in the next process.

The outputs of this process will be discussed in the next post.

6th Edition PMBOK® Guide–Process 13.1 Identify Stakeholders: Inputs

The 5th Edition PMBOK® Guide introduced a new knowledge area called Stakeholder Management.   Before then, stakeholder management was done as part of communications management.   But PMI felt that it is not only important to communicate with stakeholders, but also to actively engage them during the course of the project.

This concept is continued in the 6th Edition.   Stakeholder management not only has processes in the planning, executing, and monitoring and controlling process group, but it also has a process in the initiating process group, namely this process 13.1 Identify Stakeholders.   This post will discuss the inputs to this process.

13.1.1  Identify Stakeholders:  Inputs  Project Charter

The project charter contains the statement of what the project is about, and gives authorization to the project manager to run the project.   Besides these key functions, however, the project charter contains vital information relevant to specific knowledge areas, including stakeholder management.   It should contain a list of the key stakeholders, which is the starting point for this process, as well as information about their responsibilities within the organization.  Business Documents

Project managers need to look at the documents created by business analysts, whose outputs are the business documents listed below.   These documents may contain key information about stakeholders that will be useful in doing this process.

  • Business case–identifies the project objectives and identifies an initial list of stakeholders affected by the project.
  • Benefits management plan–benefits management does not have to do with human resources; in the language of PMI, it refers to realizing the benefits claimed in the business case.   Stakeholders are identified that will benefit from the delivery of the outcomes of the project.  Project Management Plan

The two components of the overall project management plan that are used in the course of this process are the communications management plan and the procurement management plan.   These knowledge areas are linked; as mentioned above, stakeholder management developed as an outgrowth of communications management.

  • Communications management plan–contains information about how to communicate with the various types of stakeholders
  • Stakeholder engagement plan–identifies management strategies and actions required to effectively engage stakeholders in general  Project Documents

Although project documents are not available for the initial stakeholder identification, they will be useful for stakeholder identification that occurs throughout the project.

  • Change log–may be updated to introduce a new stakeholder or change the nature of an existing stakeholder’s relationship to the project (this can happen if the person’s job description within the organization changes)
  • Issue log–may be updated if new issues introduce a new stakeholder or change the type of participation of existing stakeholders
  • Requirements documentation–may provide information on potential stakeholders that are relevant to specific requirements of the project  Agreements

The parties to an agreement are project stakeholders, whether the agreements are with sellers who provide procurements or with other organizations who are sharing the project work. Enterprise Environmental Factors

  • Government or industry standards
  • Global, regional, or local trends  Organizational Process Assets

  • Stakeholder register templates and instructions, and actual stakeholder registers from previous projects
  • Lessons learned repository with information about the involvement of stakeholders.

The next post will cover the tools and techniques associated with process.

6th Edition PMBOK® Guide–Process 12.3 Control Procurements: Outputs

This is the final post on this knowledge area, because it contains the outputs for the final process in that area, namely, 12.3 Control Procurements.

Note that in the 5th Edition of the PMBOK® Guide, closing procurements was a separate process (under the closing process group, of course).   However, in the 6th Edition, PMI has essentially but monitoring and controlling AND closing of a procurement in this single process of Control Procurements.

12.3.3  Control Procurements:  Outputs  Closed Procurements.

The authorized procurement administrator for the buyer provides the seller with formal written notice that the contract has been completed.   This happens after the project management team has approved the deliverables, checking that they have been provided on time and meet technical and quality requirements.  Work Performance Information

Information on how a seller is performing, by comparing the following to what was specified in the SOW and in the agreement:

  • deliverables received
  • technical performance achieved
  • costs incurred and accepted Procurement Documentation Updates

During the Control Procurements process, the following procurement documentation may be updated:

  • the contract
  • all supporting schedules
  • requested but unapproved or unresolved contract changes (see paragraph below on Change Requests)
  • approved change requests
  • seller-developed technical information
  • work performance information (see paragraph
  • seller performance reports and warranties
  • financial documents including invoices and payment records
  • results of contract-related inspections  Change Requests

As a result of monitoring and controlling procurements in the course of this process, change requests may be made to the project management plan.   These change requests are processed for review through process 4.6 Perform Integrated Change Control.

Any requested but resolved contract changes need to uniquely identified and documented by project correspondence, as these may changes may be disputed by one party which may can lead to a claim.  Project Management Plan Updates

Of course, the procurement management plan may need some updates:

  • Procurement management plan–updates may be required depending on the results of the performance of the sellers during execution of the work

The other project management plan component that may need updating is the risk management plan.

  • Risk management plan–if significant unexpected risks occur during the execution of the contract, the risk management plan may require updating.  Specific risks are incorporated into the risk register (see project documents updates paragraph below under “Risk Register”).

The baselines, another important component of the overall project management plan, may also need to be updated:

  • Schedule baseline–if significant schedule changes created by sellers impact the overall project schedule performance, the baseline schedule may need to be updated and approved to reflect the current expectations.   The buyer should be aware of any impacts of schedule delays created by one seller that may impact other sellers.
  • Cost baseline–contractor and materials cost can change, and these changes need to be incorporated into the cost baseline.  Project Documents Updates

  • Requirements traceability matrix–updates are made regarding requirements that have been satisfied
  • Risk register–changes made to the risks related to the approved sellers, or new risks are added to the register, including those related to:
    • The seller’s organization
    • The duration of the contract
    • The external environment
    • The project delivery method
    • Type of contracting vehicle chosen (fixed-cost or cost-reimbursable)
    • Final agreed-upon price
  • Stakeholder register–Any changes in the contractors and suppliers should be reflected in the stakeholder register, especially those stakeholders that are impacted by those changes.  Organizational Process Assets Updates

  • Payment schedules and requests–these are made in accordance with the procurement contract terms and conditions
  • Seller performance evaluation documentation–this is prepared by the buy and documents the seller’s ability to continue to perform work on the current contract, and indicates whether the seller can be allowed to perform work on future projects.
  • Prequalified seller lists updates–according to the outcomes of the Control Procurement process, sellers could be disqualified and removed from the prequalified seller lists based on poor performance.
  • Lessons learned repository–lessons learned during the procurement process should be archived to improve procurements on future projects.
  • Procurement file—a complete set of indexed contract documentation, including the closed contract, is prepared for inclusion with the final project files.

And that is it for this chapter!   The next chapter will discuss the final knowledge area, stakeholder management, which was created in the 5th Edition of the PMBOK® Guide and continues to be an important element of the 6th Edition of the Guide…