Managing stakeholders to achieve true implementation success

Introduction

Developing and implementing projects can be a complex and difficult process. When the stakeholders are insufficiently engaged, the problem of getting them to support the project and use its outputs is even more difficult, and the likelihood of project success diminishes quickly. Many project managers have had their efforts fail in spite of their confidence that what they were doing made complete sense. The primary reason is this: focusing on and implementing only the technical aspects of a project doesn't address the interests and concerns of the people who need to support the project and who may be affected by it. Stakeholders may have skills and knowledge to contribute to make the deliverables better, and the project needs them to support both the development effort and eventual use of those deliverables for the project to be truly successful.

Dealing with stakeholder issues is critical to the success of the development and implementation effort. People issues directly affect the achievement of the business case of the project and its anticipated impact on the bottom line of the organization. Effective implementers have learned to engage the people who need to use and support the project outcomes.

A core body of knowledge parallel to the PMBOK^® Guide exists in the realm of stakeholder and organizational change management. This paper will provide an introduction and approach to the Stakeholder Management process and describe its flow through the project lifecycle.

Who are the project stakeholders - and what do they want?

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) Glossary defines a stakeholder as “person or organization (e.g., customer, sponsor, performing organization, or the public) that is actively involved in the project, or whose interests may be positively or negatively affected by execution and completion of the project. A stakeholder may also exert influence over the project and its deliverables.” (PMI, 2004)p. 376)

“Interests” doesn't fully capture the different degrees of possible ‘interest’ in a project. Interests could range from curiosity or news fodder (for a publication), to tangential effect (for an area of a company or community not directly affected, but which will see some ripples from the project), to financial impact (gain or loss of investment), to job loss/ job security (people whose personal lives may be thrown into disarray – or greatly enhanced – as a result of the project).

Stakeholders are often defined or thought of as only the senior members of the organization – those who are providing resources (money, people, etc.), or who expect to see a business benefit in their area of responsibility. The approach we're discussing here highlights the importance of relating to a larger constituency, so we will broaden and clarify that definition to include those who:

• are putting money or resources into the project;
• are affected by results – positively or negatively, directly or tangentially;
• have information needed by the project for the project to succeed (“know things”), or information that, if withheld, can precipitate failure or diminished capability;
• are conduits of information to other interested parties (including: media, support staff, website administrators, message transporters, etc);
• want the project to succeed (for example, gain a tangible benefit or it supports their values or needs) or fail (enemies are also stakeholders!) – and/or influence others who want success/ failure.

Section 2.2 of the PMBOK^® Guide explains, in general terms, what types of people or groups may be stakeholders (including most of those identified above), and how they may interact with the project. That section also describes why they are stakeholders, and how the needs of different stakeholders may come into conflict. The PMBOK^® Guide also mentions that stakeholders need to be engaged, but without much detail. (PMI, 2004, pp. 24-27). The remainder of this paper will focus on the how to engage them and when, to increase the probability of project success.

What is Stakeholder Management and when does it operate?

The management of stakeholders in the PMBOK^® Guide is specifically covered under “Project Communications Management,” in section “10.4 Manage Stakeholders.” It is defined as:

“Stakeholder management refers to managing communications to satisfy the needs of, and resolve issues with, project stakeholders. Actively managing stakeholders increases the likelihood that the project will not veer off track due to unresolved stakeholder issues, enhances the ability of persons to operate synergistically, and limits disruptions during the project. The Project Manager is responsible for stakeholder management.” (p. 235-236)

Stakeholder Management is a proactive process. It is the active seeking out, communicating with and working with stakeholders. There are three major reasons for making Stakeholder Management a central planned activity (with abundant sub-activities) in a project:

(1) Active involvement of stakeholders is critical to defining, designing and producing the deliverables of the project. Without stakeholder involvement the deliverables simply will not meet their needs. This is not just bringing stakeholders in for product acceptance (too late, from a quality management perspective), but having them involved in project definition, requirements, design and construction.

(2) The stakeholders – especially the “customers/users” – will be expected to work with the deliverables that have been produced and in that use they will generate the true business value of those deliverables. The deliverables only have value in use, not in their mere creation.

(3) Engagement in the development process by relevant stakeholders builds support and enthusiasm during the project that translates to support and use once the project is implemented.

These reasons work together: engaging stakeholders on the planning and development side also helps ensure the final acceptance, use and positive support of the deliverables those stakeholders were involved in creating.

Stakeholder Management is a process of planned, supported and monitored interactions that run parallel to and are fully integrated with the development of the “technical” deliverables (the physical outputs from the project). It runs the length of the project, from project definition and initiation through implementation, and is carried forward to post-implementation – into the operational and maintenance phases of the product life cycle. It is integral to creation of the “correct” technical products (definition, execution, acceptance), then the implementation and use of those products – to gain full business benefits.

Stakeholder Management begins as the project is first defined. Often senior level people want a project to meet an organizational need, but they themselves will not necessarily use, work with or “touch” the final deliverables. Those who will use them may have understanding from the outset as to whether or not the problem has been properly defined, or whether the proposed solution is the best approach to solving a problem. (Gerald Nadler and William Chandon, in their book “Smart Questions – Learn to Ask the Right Questions for Powerful Results,” are an excellent resource for problem analysis/ identification, as well as identification and engagement of project stakeholders.)

Stakeholder Management is a critical aspect of Change Management: defining, supporting and implementing the organizational changes that are needed for the project's deliverables to be used effectively (proactive), and/or dealing with the organizational changes that will be precipitated through the project's implementation process (reactive). Stakeholder (and Change) Management are not “nice” adjuncts to a project (to be included “if we have the time”), but are critical, central components to successful implementation.

The major (i.e., high visibility or powerful) stakeholders get their share of attention through the course of the project (with one-on-one meetings, presentations, regular reports and the like). In contrast, the less visible (and very likely less powerful) frontline workers – those who will be working with the project outputs to deliver the project's benefits – are usually left to end-of-project training sessions, or to managers who will tell them to “get on board,” or “like it or lump it.” Working with those under-represented stakeholders (often left out of the communications process or included only minimally) is a major objective of effective Stakeholder Management. They, too, need to be involved from project inception.

It is difficult to involve/engage all of the stakeholders in a project – there are usually too many to participate, and, at a certain point, including additional stakeholders simply duplicates the input, knowledge and involvement of other stakeholders. Here Stakeholder Management has to be examined and evaluated like any other significant project risk, asking: ‘what is the likelihood of the project achieving success in its business case if the identified stakeholders are or are not suitably engaged.’ The primary issue here is which stakeholders and the degree to which they will be involved. Those decisions are another one of the balancing acts that a Project Manager handles every day. Too little involvement of relevant stakeholders and the project will not be defined properly or achieve its goals; too much involvement and the project gets bogged down in “process” and “communication,” with little work being completed.

Good Stakeholder Management requires time and resources. It is part of the project's commitment to Quality Management, and equally emphasizes that achievement of benefits must be addressed from the beginning of the project. Stakeholder Management cannot be resolved by making announcements during the project, and cannot be patched-on towards the end by sending the end-users to training sessions or issuing self-congratulatory press releases.

The Overall Flow of Stakeholder Management

When assessing and applying this approach, remember to keep the scale of your effort appropriate to the size, complexity and overall risk of the project. A small project affecting only a few people can apply this approach in an informal manner, probably with little or no written documentation. An organization-wide initiative requires far more detailed thought, probably with an individual committed full-time to formally managing the process with a project team that interacts with and advises allthe project teams.

Here is a summary of the flow of this approach. The following sections will explain each step in more detail.

Step 1 – Planning the Stakeholder Management Process (during Project Initiation).

Step 1a – Defining and Building Support for Stakeholder Management.

Step 1b – Identifying Stakeholders.

Step 1c – Defining and Selecting the Stakeholder Planning Team.

Step 2 – Developing the Stakeholder Management Plan (in concert with creation of Project Plan).

Step 2a – Identifying Critical Contact Points.

Step 2b – Identifying Resources.

Step 2c – Identifying Modes of Contact/ Communication.

Step 2d – Reviewing Stakeholder Management Risks.

Step 2e – Educating the Project Team on Stakeholder Management.

Step 3 – Executing Stakeholder Interactions.

Step 4 – Monitoring and Controlling Planned Interactions.

Step 5 – Assessing at End-of-Phase and End-of-Project.

The Detailed Flow

Step 1 – Planning the Stakeholder Management Process

Step 1a – Defining and Building Support for Stakeholder Management

Here we are establishing support for our Stakeholder Management efforts by identifying their benefits (in the greater likelihood of achieving the business case), and gaining sponsorship from the senior managers who are key stakeholders and the controller of the purse strings. We tie these efforts directly to the business case for the project, and emphasize that Stakeholder Management is one dimension of risk management – increasing the likelihood that the time and effort invested in creating major organizational deliverables will produce the desired results in implementation and use. One issue to be dealt with is the scope of stakeholder involvement. Some senior managers don't see the value of staff stakeholders being involved in definition, design and construction, but project managers (especially those who have lived on the “working edge” of the business) know that involvement of those stakeholders is crucial to success.

We will make clear the costs and time of Stakeholder Management to those sponsors and senior managers. It is no different from quality management: you can't patch it on at the end when things are not going so well. The critical period for stakeholder buy-in is the first 10-20% of the project, so these issues need to be addressed and managed from the outset.

Another activity here is the identification of the individual who will have the role of “Stakeholder Manager.” This work is often done by the project manager, but on large, complex and risky projects the role will need to be given to a separate team manager, to ensure that proper attention is paid to all aspects of the effort. Successful large-scale projects often have a defined Stakeholder (or Change) Manager overseeing a Stakeholder Management workstream to support this effort.

We also need to clarify – and obtain commitment to – the responsibilities of those senior managers who themselves are stakeholders: what will be expected of them and of the resources over which they have authority.

Step 1b – Identifying Stakeholders

At this point we are creating a high-level work list of likely project stakeholders. Some discussion will be needed to clarify why they are considered stakeholders, and what their likely roles will be in the project. We will be using this list to select individuals and representatives in the next Step (1c) who will work together to develop the Stakeholder Management Plan (Step 2). We will prioritize stakeholders (those whose involvement is critical to the success of the project, in declining level of importance) since, in the course of the project, we will need to allocate limited project resources for Stakeholder Management activities.

Step 1c – Defining and Selecting the Stakeholder Planning Team

We are selecting the specific team that will develop the Stakeholder Management Plan (Step 2). In addition to identifying these people, we will need to give them an orientation to the project, the project's methodology, why and how we will be doing Stakeholder Management, the project's expected business benefits, etc. If this orientation doesn't occur here, the Stakeholder Manager will need to prepare this information for delivery before the plan development begins.

Step 2 – Developing the Stakeholder Management Plan

This is the heart of Stakeholder Management. As in preparing the project plan, we consider what actions and activities need to be undertaken to achieve defined goals and the business case of the project. This plan is developed by the Stakeholder Planning Team (Step 1c), in concert with and parallel to the project plan. The planning team will pursue the following steps in stakeholder planning using a draft project plan as their primary reference point. The actions and activities generated in this Stakeholder Management Plan are very likely to trigger recommendations to modify and update the draft project plan.

Step 2a – Identifying Critical Contact Points (What, Why, When, How)

Establish what the critical contact points are, when they occur, why we have identified them as critical, and how will we use these contact points to maximize positive impact and minimize the potential negative aspects. These contact points are activities or milestones in the project at which engagement or greater commitment can be obtained, established or enhanced. Conversely, they can also be points where commitment can be lost, damaged or undermined. They are points when:

• we want to engage a stakeholder to set the groundwork for a later, more active contact point;
• a particular stakeholder can have the greatest positive impact on the project;
• we want to reduce negative reactions or obstruction;
• we need information from a stakeholder, e.g.,
  • ▪      to plan upcoming work;
  • ▪      to do something specific;
  • ▪      about what they need or what they know, or what others may need;
• work has to get done and these stakeholders are the ones that do it –
  • ▪      some of their work is analyzing, designing and building things (the technical products);
  • ▪      some of their work is helping to shift attitudes/ beliefs/ behavior, etc, in anticipation of the changes that will be precipitated by the projects deliverables (the change management work).

Some of the contact points will be after the formal completion of the project, during the operational and maintenance phases of the product's life cycle. Members of the planning team need to be reminded that the business case plays out after product delivery, and that Stakeholder Management continues to operate in that time frame as well. The most common element in the operational life of the product is end-user training, but continual feedback, product improvement, detection of and response to unintended consequences, etc, are also needed.

Secondly, determine what kinds of interactions need to take place with the identified stakeholders at the critical contact points, asking: ‘what do we want to accomplish with this interaction?’ We also have to think about what we need to do before this contact point to make whatever action we take at this point to be most effective (often we will need to set the groundwork for an interaction, much as an envoy visit precedes the visit of a head-of-state). Along with pre-contact preparation, we have to consider what we might need to do after this contact point to reinforce what we did here (again, as diplomats follow up on a head-of-state visit).

We also want to determine our criteria for success: “what result/ impact do we anticipate from working with the stakeholder at this point, and how will we measure whether or not we have accomplished that result?” This sets the ground for useful monitoring and controlling as we execute the Stakeholder Management Plan.

Step 2b – Identifying Resources (Who, Why)

This step extends the analysis performed in Step 2a, establishes which specific stakeholders we will engage at each contact point previously identified, and clarifies why we have we chosen them. These decisions will depend on:

• how critical that contact point is (priorities will need to be considered);
• what information we need, why, and who is the best resource to provide it;
• which stakeholder provides the most value out of the contact (e.g., someone who has information, is an influencer of others, can effectively convey project goals, is a conduit to other important stakeholders, etc.) – the more value from any particular stakeholder, the better the use of scarce project resources.

Step 2c – Identifying Modes of Contact/ Communication (How, Where)

This is an extended, more detailed approach to the Communications Plan (from 10.1 Communications Planning). The PMBOK^® Guide focuses on distribution of information, but here we are defining more types of interactions. We are asking: “Now that we've established the importance of a particular interaction with an important stakeholder, what is the most effective way to work with that stakeholder to be most beneficial to the project and the individual?” We are looking at the modes of engagement. (PMI, 2004, pp 225-228)

This question is broken down into “how do we communicate in the most effective manner”, “where should that communication take place” and “who should represent the project side in that communication.” We want the right message received by the right people at the right time in the right form from the right person. On the “how” side, standard modes of providing information (most suggesting delivery of information, and passive reception) include:

To this list we add the more active and engaging modes of:

Interviews,

Focus groups,

Inclusion as active member of a project team (e.g. requirements team, design team, etc),

External resource to the project team (e.g., advisor),

Quality checkers,

Reviewers,

Member of Stakeholder Management Planning team,

Et cetera.

Each of these latter modes engages the stakeholder, makes the person a part of the project, and confers degrees of project ownership. If the contributions and participation of those stakeholders are not included, ignored or minimized, then the potential benefits are squandered. In Step 2e we will educate all members of the project team to support and reinforce these stakeholder engagements. (Eddie Obeng, cited in the References, has excellent discussions on where and how to have good interactions.)

Step 2d – Reviewing Stakeholder Management Risks

Here we are applying standard risk management analysis to Stakeholder Management. As we have gone through the process (from the first step) we should have been identifying any risks associated with our management (or non-management) of the stakeholders, in terms of particular stakeholders (individuals and classes of stakeholders) selected and not selected, the contact points, the how of the interactions, etc. (all of the elements of the Stakeholder Management Plan identified earlier in Step 2). As indicated earlier, the entire Stakeholder Management process is a project risk mitigation activity, with a goal of reducing risk to the project's business case.

In considering which elements of the above approach you have chosen to include or omit, consideration needs to be given to:

• the complexity of the project;
• the scale of the project, and the dimension of people affected (individual, office, department, organization, community, society);
• the history and culture of the organization in dealing effectively with projects of this scale (receptive? hostile? passive or active hostility? do people expect to be involved? etc.)

In its simplest form, the risk management is: “which interested party (or parties), at which contact points, can we afford to ignore or ‘accept’, and still successfully achieve our business case?”

Step 2e – Educating the Project Team on Stakeholder Management

Before the formal work of the project begins, all members of the project team need to understand Stakeholder Management. An explanation and discussion of the following are parts of this education: a summary of the above steps, the reasons provided to management, management's commitment to this process, the value to them as members of the project team, and their role in the process. Everyone on the project who interacts with another person (or fails to do so when appropriate) is part of Stakeholder Management. Remember that the members of the project team are themselves stakeholders, and the project manager's work with them calls for the same level of thoughtfulness given to all other stakeholders in the project.

Step 3 – Executing Stakeholder Interactions

These are the adjunct and parallel activities to “4.4 Direct and Manage Project Execution,” specifically guiding and executing the Stakeholder Management Plan (“working the plan”). (PMI, 2004, pp. 91-94)

The Stakeholder Manager either maintains contact with stakeholders identified in the Stakeholder Management Plan, in the manner agreed upon, or coaches the various team managers or team members who are following their responsibilities outline in the plan.

Step 4 – Monitoring and Controlling Planned Interactions

These are the adjunct and parallel activities to “4.5 Monitor and Control Project Work,” (pp. 94-96) specifically related to activities in the Stakeholder Management Plan. The Stakeholder Manager:

• monitors the execution of the Stakeholder Management Plan by the team managers and all others who interface with stakeholders;
• reviews what was expected to be accomplished at the contact points specified in the Stakeholder Management Plan;
• determines what has been done to execute the plan and the results of those efforts;
• assesses the effectiveness of planned actions/ activities on identified goals, based on the agreed measurement criteria;
• applies or recommends corrective action, as required, to adjust stakeholder interactions to achieve project goals and business case, either for imminent or future activities;
• determines whether new issues or risks have arisen that call for new Stakeholder Management activities in later steps in the project, defines them if needed, and updates/ amends the Stakeholder Management Plan.

Step 5 – Assessing at End-of-Phase and End-of-Project

This review of Stakeholder Management work is part of the review of the entire phase or project to date, covering accomplishments, lessons learned, and recommendations for the next phase, post-project (on these deliverables), and/or future projects.

Extending your skill set to manage stakeholders effectively

Improving one's skills for the detail managing of interactions with stakeholders is a development effort of its own, and beyond the scope of this paper. Those competencies, however, are critical to the successful application of this approach . They include the skills to manage project team members (which should be part of a project manager's standard toolkit), but also extend beyond them to the interpersonal competencies to relate to and deal with many people over whom the project manager needs to exert influence without accompanying authority. Many project managers have advanced to their roles through their technical capabilities and expertise. It is particularly in Stakeholder Management, though, that the need for developing the project manager's interpersonal skills becomes critical. It would be well for project managers who wish to become more effective in Stakeholder Management to develop themselves in this area. (One useful starter book – “Crucial Conversations…” – is listed below in the References. It is a good resource to begin examining this topic.)