Whenever new techniques or processes come along to support project management activities, people tend to embrace it enthusiastically without asking themselves, “What can possibly go wrong?” For a long time, stakeholder management has been a part of project management but only recently has it been introduced as a Knowledge Area in the PMBOK® Guide.

Without a proper understanding of what can go wrong, project managers can unintentionally make mistakes that can be detrimental to the health of the project. Here are a few examples:

1. Choose your words carefully: I would have preferred if the new Knowledge Area was called “Stakeholder Relations Management” or “Stakeholder Interfacing” rather than Stakeholder Management. Most project managers end up managing the relationship with the stakeholders rather than the stakeholders themselves. Many of the stakeholders are in senior positions in their organizations and may be a considerably higher rank than the project manager. If your governance committee for the project is made up of senior managers from your company and the client’s firm, I am at a loss to see how you would manage them in the traditional sense of the word.

2. Make sure everyone understands who is doing the interfacing: Stakeholder interfacing is the responsibility of the project manager and not necessarily the team members. Project managers generally choose their words wisely when interfacing with stakeholders whereas team members may say and do things while interfacing that can create problems for the project manager.  As an example, I was involved in several situations where team members would interface directly with stakeholders (or even counterparts in the stakeholder’s company) and provide them with proprietary information or a promise to do additional work for them – at no cost. By doing this, the workers believed they were impressing the stakeholders; however, by the time the project manager discovered what had happened, the damage was done. Customer interfacing should not be done with the misconception that the customer is always right or to grant all of the stakeholder requests, especially if it results in non-funded work.

3. Giving the stakeholders raw data: Stakeholders often request raw data from testing immediately after the testing has been performed. On the surface, this may seem like the right thing to do, but bad things can happen if the stakeholders formulate their opinion concerning the test results before your personnel analyze the data. The stakeholders may then make decisions, or even cancel the project, without fully understanding the true meaning of the test results. Allowing this to happen is not bad as long as the stakeholders do not formulate their opinion or make any rash decisions until your personnel identify the company position on the data.

4. Using a responsibility assignment matrix (RAM): The intent of the RAM is to make sure that all of the employees fully understand their responsibility on a given project. On the Y-axis of the RAM we identify each of the work packages in the breakdown structure. On the X-axis, we identify the names or the titles of the people assigned to the project. Showing the RAM to the stakeholders using the titles of the team members rather than the names is preferred. When stakeholders see the actual names of the workers, they will find a way to identify the phone numbers for each of the workers. The stakeholders can then contact the workers directly without going through the project manager. The result could be detrimental if the workers and the project manager have a different interpretation about the health of the project or the meaning of certain test results.

5. Do not assume that all stakeholders want the project to succeed: Some stakeholders may have hidden agendas and actually hope that the project fails. This is particularly true if the stakeholder views the result of a successful project reducing their power base, authority, responsibility, image, chances for promotion or the size of their empire.

There are certainly other issues that can lead to detrimental results, but these five are the most common situations that I have experienced.