Common Project Manager Mistakes: #1 Limiting Stakeholders

December 18, 2014 | Author: PM Hut | Filed under: Project Stakeholder Management

Common Project Manager Mistakes: #1 Limiting Stakeholders
By Samuel T. Brown, III, PMP, Global Knowledge Course Director and Instructor

According to A Guide to the Project Management Body of Knowledge, (PMBOK® Guide)-Fifth Edition, Project Management Institute, Inc., 2013, stakeholders are “individuals, groups, or organizations who may affect, or be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.” This is a simple definition from the PMBOK® Guide and yet we often focused our attention on only those who requested the project or who are actively involved in project execution and decision-making.

Obviously our project’s initiator, sponsor and team are stakeholders. Equally obvious is the fact that the customer is a stakeholder, but here’s the rub: Who is the customer of the project? Is it the group that will use the results of the project? Is it the group that asked for the project to be done? Is it the group that is paying for the project? The answer is “all of the above” and there may even more stakeholders. Additionally, the PMBOK® Guide slips in a new, inconvenient little phrase that states “or perceives itself to be affected by,” which means that even those we believe shouldn’t be stakeholders may need to be addressed as stakeholders if they think they’re stakeholders.

Why is it so important to take a holistic approach to identifying project stakeholders? It’s important because failure to do so will increase project risk, communication issues, and complexity. A short list of the potential problems resulting from inadequate stakeholder identification and analysis include:

  • Increased project risk in the form of unknown unknowns that unpredictably manifest as surprises throughout the project life cycle.

  • Increased demands from senior management stakeholders for frequent and detailed project progress and status information.

  • Delivering a “successful failure.” By this I mean, delivering on the known and agreed requirements without recognition that those requirements did not include input from important (unknown) stakeholder constituencies.

  • Reduced ability to effectively anticipate and manage stakeholder expectations.

  • Increased scope instability and frequent change control challenges.

The truth about project management is that we don’t need to communicate with anyone who isn’t a stakeholder. The challenge here is that people who believe they need information but are not getting it have a tendency to make assumptions and then act on those assumptions as if they were actually true. Stakeholders who are acting on unfounded assumptions due to lack of information are very likely to create challenges for the project, usually in the form of unexpected impacts. We know from risk management that there will always be surprises because we cannot anticipate every uncertainty.

Frequent impact from unknown unknowns not only raises the level of risk in the project, but also undermines key stakeholder confidence in our ability to manage the project effectively. Neglected stakeholders will not suffer silently; they will voice their complaints to senior management. So when we combine these doubts with the “squeaky wheel” phenomenon you reinforce the perception that your project is out of control.

Among the big risks from unidentified stakeholders is the likelihood that we will develop our project plan on the basis of incorrect or incomplete requirements. We assume, expect even, that those key stakeholders who are driving the need for the project know what the requirements are, or at least know which of their constituents we should be talking to in order to thoroughly define requirements. Unfortunately this is often a bad assumption since senior managers may define requirements based on their perception of what their constituents need. Additionally, those who are resistant or outright opposed to the project are not necessarily wrong. We need to remember to always include our detractors among our stakeholders and give their issues an objective hearing. Failure to explore and validate requirements across the full range of stakeholders can easily result in a project that meets the defined requirements but fails to satisfy the stakeholder’s needs.

Poorly defined requirements, complaining, and excessive oversight from senior management, are all contributors to scope instability and excessive changes. All projects will experience change. The purpose of change control is not to prevent changes, but rather, to ensure that changes are captured, evaluated and approved with they are “good” for the project. Even with a robust, effective change control process it is difficult to maintain scope stability when change requests are constant and often from unexpected (unrecognized) sources.

The remedy for these and other stakeholder problems should be focused at the stakeholder identification process, both during initiating, and throughout the life of the project. First, we need to expand our perspective and the questions we ask as we try to identify our stakeholders. There are always a few stakeholders who are obvious and easy to recognize; we need to engage them as helpers in identifying other, less obvious stakeholders. We should be asking questions like: Who are your customers? What constituents do you represent or speak for? Who, from your perspective, will be affected by project success/failure? Such questions will broaden our view and help us to better understand the stakeholders’ point of view.

Once we have identified a broader range of stakeholders, then we need to analyze them to understand their involvement, interests, and influence, as the PMBOK® Guide has suggested for many years. But we also need to consider the relationships among our stakeholders. Which stakeholders want the result of the project? Which stakeholders don’t want the project results? Which stakeholders have authority over which other stakeholders? Which stakeholders influence the perceptions, attitudes, and thinking of others? Who are the “thought leaders” among our stakeholders? What are the reporting and communications channels among the stakeholders? These and other questions will help ensure that we not only recognize more of our stakeholders but that we more clearly understand their relationship to the project. Such an understanding goes a long way toward reducing surprises, anticipating requirements gaps, changes and other risks.

Finally, the more stakeholders we recognized the better. Many stakeholders makes managing the project and especially project communication more complex, but not nearly as complex as trying to mange constant change. If there is a good, routine assumption that we should make as project managers, it is that there are probably always more stakeholders in our project than we have identified. Be vigilant.

About the Author

Samuel Brown, PMP, is a course developer and instructor for Global Knowledge with 25 years experience teaching. In addition, he has provided project management consulting services for a variety of clients including GE, Glaxo Smith-Klein, Bristol-Myers Squibb, Michelin Tire, and IBM.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge delivers comprehensive hands-on project management, business process, and professional skills training. Visit our online Knowledge Center at www.globalknowledge.com/business for free white papers, webinars, and more.

© Copyright 2014, Global Knowledge. All rights reserved.

PM Hut - The Project Management Hut: Project Management Article Separator

Project Management Categories