Stakeholder Management

By stakeholder management I mean managing the expectations of all the project stakeholders. Many project managers remark, after a discussion about stakeholders, that they now understand why their project was not completely successful: They had failed to identify the stakeholders. And, if they had identified them, they failed to meet their expectations or to keep them properly informed about the project.

Stakeholder management involves a number of interconnected activities. These activities must be accomplished and managed while the work of the project progresses. Exhibit 5-2 is a model of the stakeholder management process and how it fits into the project management environment. These steps or activities are discussed in some detail below. However, before we get into how to manage stakeholders, it is important to define exactly what a stakeholder is.

Exhibit 5-2: The stakeholder management process.

start example

click to expand

end example

What Is a Stakeholder?

A stakeholder is an individual or organization that is either actively involved in the project or who might be affected by the project's execution or completion. It is important to note that the stakeholders may be either positively or negatively affected by the project, so it is crucial to identify all of them—not just those who are positively affected. To expand on the definition above, I think it is important for the project manager to be aware that there are those who think they are stakeholders but who may not be in the strict sense of the word. Actually, those people can do the most damage to the project. If you ignore someone who thinks he is a stakeholder and he happens to wield a tremendous amount of influence in the organization, he can kill the project before you even know what happened. So here is my simple definition of a stakeholder: A stakeholder is anyone who thinks he has a vested interest in the project.

Stakeholders need to be identified as soon as possible. Usually, most of the stakeholders can be identified during the requirements definition stage. While the project manager has the initial team together, she should properly identify stakeholders, using the experiences of the team members.

Identifying Stakeholders

Many stakeholders are obvious. Stakeholders include:

  • Project team members

  • The customer

  • Functional managers

  • Suppliers

  • System users

There are also stakeholders who are not so obvious, including:

  • Stockholders

  • Local and federal regulating agencies

  • Creditors

  • Environmental groups

Then there are those who also think they are stakeholders. A good rule of thumb to use when identifying stakeholders is that it is far better to overdo it than to ignore someone. Once the project is under way and the project manager has an opportunity to interface with each stakeholder, he can begin to assess who is a true stakeholder and who has the power to impact the project. In that regard, it is helpful to have a stakeholder analysis process in place.

Stakeholder Analysis

Stakeholder analysis involves answering four basic questions:

  1. Who is the stakeholder (or potential stakeholder)?

  2. What is the stakeholder's position, relative to supporting the project?

  3. What is the reason for the stakeholder's position?

  4. What is the strategy for changing the stakeholder's position if it is less than positive?

Exhibit 5-3 is a simple form that can be used to help determine how to manage your stakeholders.

Exhibit 5-3: Stakeholder analysis form.

start example

click to expand

end example

The most important aspect of the stakeholder analysis, after identifying the stakeholder, is determining her position or agenda. What the project manager needs to know early in the project's life is whether the stakeholder is for, against, or neutral about the project, and whether the stakeholder will actively support or resist the project. Then, of course, it is important to determine why the stakeholder has taken that position.

A stakeholder will support or resist a project for a variety of reasons. The most basic reason for supporting a project is because it appears to be one that supports the organization's strategic goals. The stakeholder may dislike a project because it does not appear to support the goals. In any case, the reasons for support or resistance have to be known, otherwise the project manager has no chance to meet or change stakeholder expectations.

Once you know why the stakeholder takes the position he has chosen, you need to determine the stakeholder's strengths and weaknesses. Some strength and weakness considerations are:

  • Political alliances

  • Availability and effective use of resources

  • Quality of decisions and managerial strategies

  • Organizational support

  • Dedication of support

Determining the stakeholder strengths and weaknesses helps the project manager assess just how important a particular stakeholder is to the project, both in terms of being a friend who can help obtain resources, for example, and as an adversary who can make obtaining resources very difficult. It is also important to know whether the stakeholder has enough organizational clout to actually impact the project.

Finally, it is crucial to develop a strategy to change a stakeholder's position if it is neutral or negative. A neutral position can be tolerated, although it is certainly better if all stakeholders support the project unconditionally. The chances are that a neutral stakeholder really doesn't have a stake so strong that she will sabotage the project. But a stakeholder with a negative bias is another thing altogether. At the very minimum, that stakeholder will not support your efforts to complete the project and at the worst case, he will actively lobby to kill the project.

Stakeholder Management Strategies

The most effective stakeholder management strategies are those that satisfy the stakeholder's requirements and answer their concerns. There are a variety of strategies that achieve these ends.

Two underused strategies that I have seen hook stakeholders immediately in the early stages of the project are the project charter and the project kick-off meeting.

The project charter is an internal document prepared by the senior management in conjunction with the project manager that briefly outlines the project scope, names the project manager, identifies the required resources, and establishes the communication plan for the project. The charter is the primary vehicle for identifying the parameters of the project and can be a powerful communication and negotiation tool. But perhaps its most important use is for obtaining buy-in from all the functional managers because they all have to sign the charter indicating that they support the project. Exhibit 5-4 shows a general project charter outline. Some organizations have much more detailed charters—some may even attach scope statements and, in some cases, the project plan. But the primary purpose of the charter is to name the project manager, explain the boundaries of her authority and responsibility, and detail the functional groups' project support responsibilities.

Exhibit 5-4: Project charter outline.

start example
  1. Purpose

  2. Project Establishment

  3. Project Manager Designation and Authority

  4. Project Manager Responsibility

    1. Support organization's responsibilities

    2. Project organization and structure

    3. Project team composition

  5. Communication Plan

  6. Definitions

  7. Appendixes

end example

The kick-off meeting is another excellent opportunity to engage stakeholders and get their buy-in. There are usually two meetings that come under this heading. The first is generally very informal and simply announces that the project is approved to start—an announcement of the project's existence. The second one is more formal and is designed to discuss the project's scope, as much of the technical approach that is known, any issues expected, schedules, and budget. The amount of information provided at this kick-off meeting is entirely dependent on how far planning has progressed. But the opportunity to include the stakeholders is obvious. For instance, they can be engaged in the discussion about the technical approach and any risks or issues that they might know.

There are several other strategies or opportunities for making stakeholders feel a part of the project. Some of the most common strategies for satisfying stakeholder requirements and answering their concerns are:

  • Actively involving them in the project

  • Providing regular progress reports

  • Including them in formal briefings and project reviews

  • Providing them with individual briefings (particularly if an individual has a particular concern)

  • Soliciting their advice (whether it is actually needed)

  • Including them in major project strategy decisions

  • Providing them with project reports and progress summaries.

Sometimes your strategy will not work or it is simply the wrong strategy for a particular stakeholder. But every strategy plan should include an assessment of the stakeholders' likely reactions and have an alternative strategy ready to implement.

Stakeholder Reactions and Alternative Approaches

Stakeholder reactions generally are predictable, especially if the stakeholder is positive about the project or even neutral. But it is those who are negative about the project who usually require more than one strategic thrust before they are won over. So be prepared for a lukewarm or even cold reception to your first try at answering the concerns of these stakeholders. First of all, your perception of their concerns, even if the stakeholder has expressed them, may not reveal the real concerns. For example, a stakeholder may say he is not convinced the technical approach is viable when his real issue is that he was not included in developing the approach. Hidden agendas proliferate in the stakeholder world. Be prepared to offer a strategy, then observe the reaction and adjust the strategy. That's the essence of stakeholder management.

Implementing the Strategy

When you finally develop your strategy and are ready to implement it, there are several considerations that need to be addressed. Ensure that:

  • Management understands the impact of both supportive and adversarial stakeholders to a project's success.

  • Stakeholder assessment is solicited in review meetings as a part of determining project status.

  • Communication with stakeholders is maintained to improve their perception of the project's progress.

  • An explicit evaluation of probable stakeholder response to major project decisions is accomplished.

  • An ongoing, up-to-date report of stakeholder status is provided to key managers, principally to the project sponsor.

  • Security of sensitive project information is maintained.

One of the unpleasant and politically damaging aspects of stakeholder management for the project manager is the need to keep some senior management informed about the stakeholder status—for or against the project. The project manager needs to have a significant emotional intelligence level to make senior management aware of stakeholder status without seeming to be working behind its back for malevolent reasons. In short, your purpose is not to be a tattletale or a whiner but to maintain strong stakeholder support for the project. This situation is not so difficult if the project has a sponsor who can help with stakeholder management.

Evaluating the Results and Adjusting the Strategy

After the strategy is implemented, you can evaluate the stakeholder response by simply soliciting her comments and reactions to what you have presented. If the strategy involved some change to a project process of the technical approach or utilization of resources, say, then be prepared to discuss in detail the positive impact you expect to the project. To reassure the stakeholder, you should also plan an after-action meeting to report on the strategy's actual impact to the project.

Again, be prepared to discuss and defend your planned strategy for answering particular concerns and issues, but also be prepared to adjust the strategy if it is clear the stakeholder is not happy with your approach. Sometimes a simple compromise is all that is needed to get a consensus between you and the stakeholder. However, you also have to recognize when the stakeholder is pushing the strategy into one that can negatively impact the project. For example, radically changing the product design has implications for the schedule, the budget, and the scope. This type of situation can be smoothly handled with an experienced and well-prepared project manager, but in extreme cases it calls for additional help from the project sponsor or even other senior managers.

Managing Information Technology Projects
Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives
ISBN: 0814408117
EAN: 2147483647
Year: 2003
Pages: 129
Authors: James Taylor

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: