Stakeholder Perceptions Become Your Project Reality

Introduction

As project managers, we have often heard stories about our fellow project managers being set up to fail by sponsors, stakeholders, and senior management because of expectations that were out of line with what a project could actually deliver. How and why does this happen? There is no single correct answer, but there is plenty of blame to go around. It takes a thorough examination of the relationships and tendencies of project managers, business analysts, and stakeholders to uncover how perceptions can become misaligned with reality. The bottom line is that it is the job of the project manager to be the honest broker with the project sponsor as to what a project can realistically deliver. It is the job of the project sponsor to communicate those same realities to the senior management and executive audiences.

The Role of the Project Manager in Stakeholder Management

The project manager is the tip of the spear when it comes to stakeholder management. It is the project manager's responsibility to build a thorough, deliberate, and complete stakeholder management strategy. In order for a project manager to build that strategy effectively, he or she must first conduct a thorough stakeholder analysis. Stakeholder analysis is all about understanding the different personalities, agendas, and priorities of the stakeholder community. As a rule of thumb, there are three steps to stakeholder analysis:

  1. Identify stakeholders
  2. Stakeholder assessment and classification
  3. Identify stakeholder communication needs

For the project manager, identifying all of the potential individuals and groups that have a stake in the project is an important first step in setting the conditions for successful stakeholder management. This effort should not be limited to a once-over of the clear project players, but should be an attempt to identify all those who could be affected by a project's outcome (real or perceived), those inside the organization who could help or hinder your project, and even those outside the organization whose actions could help or hinder your project. Because of the complexities of identifying the full array of stakeholders in a single round, stakeholder identification should not be limited to a one-time event—identification should be ongoing throughout the entire life of the project.

Once the project manager, with help from the project sponsor and project team, identifies the stakeholders of the project, it is then time for the project manager to assess and classify all the stakeholders. The truth is that not all stakeholders are created equal, and equal time and effort cannot be devoted to each stakeholder. The purpose of assessing and classifying the stakeholders is to discover, through multiple rounds of analysis, which stakeholders constitute the key stakeholders. All stakeholders will be managed, but the key stakeholders will be those who must be satisfied in order for a project to be deemed a success. There are many different ways to analyze stakeholder importance, but one of the most popular ways is using an Impact x Influence grid. A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Fifth Edition, Project Management Institute, Inc., 2013 defines impact as the ability to effect changes to the project plan or execution, and influence as a stakeholder's active involvement in the project. Organizations must determine an acceptable standard for assigning numerical values to subjective ranking criteria. There is not a defined standard, if using a ranking system for impact and influence of 1-5 for example, as to what makes a stakeholder a score of 1 (the lowest) vs. what makes a stakeholder a 5 (the highest). But, by these two definitions, it can be inferred that those stakeholders who must be actively involved in the project in order for it to be successful (high influence), and those who have the ability to change organizational priorities for resources (high impact) should be considered key stakeholders who must be closely managed.

Another key piece of information that needs to be uncovered and understood about each stakeholder, especially the key stakeholders, is: what is the stakeholders' key success criteria? Again, there are many different ways to do this, and there is no single correct answer, but a great starting point is to ask stakeholders, point blank, what is most important to them among the triple constraints. If you know this, then your work performance reports can be tailored to their needs. A simple question to these key stakeholders could be, "What is most important to you: schedule, budget, or scope?" Many stakeholders will have a natural temptation to tell the project manager that they are all important, and they are, but one has to be the most important. There cannot be any ties in this situation. The priorities cannot come out as 1A, 1B, 1C, etc. If the project manager can nail this down, and determine that a stakeholder values budget over schedule and scope, then the project manager can relay costbased information more regularly to that stakeholder (likewise if the stakeholder is more concerned with schedule or scope). Having this information can also help the project manager craft an execution strategy that is in line with stakeholder success priorities.

Another important role that the project manager fulfills in stakeholder management is crafting the appropriate stakeholder communication strategy. Many projects have an expansive list of stakeholders; so again, the project manager must focus his or her efforts on the key stakeholders, without neglecting the others. Once the project manager has classified the stakeholders, an effective communication strategy that satisfies their information needs can be built. Communication with the key stakeholder community is a linchpin of project success. Communications must be focused not only on satisfying the need for information, but also toward constantly managing stakeholder expectations and perceptions of project performance. At the beginning of the planning phase of a project, much uncertainty exists. Through iterative planning uncertainty is reduced, but even when plans are baselined, some uncertainty remains. It is important to communicate to our stakeholders at the outset of execution the risks that the project faces, what our contingency plans are, and that estimates are only estimates and not facts.

The Role of the Business Analyst in Stakeholder Management

The business analyst also plays an important role in setting and managing the expectations and perceptions of stakeholders. The beginning of a project is normally born out of a contract being signed, a statement of work (SOW) being generated, or a feasibility study being conducted. From these documents, a project charter is created (ideally), which outlines the project's high-level requirements, expectations, assumptions, risks, and project background. The project charter should outline the high-level requirements and success criteria that the project must achieve, and also the constraints within which the project must be completed (initial schedule, budget constraints, etc.).

There is a lot that the business analyst can start to do at the point where there is an approved project charter to begin the process of setting stakeholders expectations. Among the stakeholders that the business analyst needs to consider are:

  • Executive-level stakeholders: Executives many times understand the project in ways that other stakeholders may not, including what the strategic, long-term value of the project is and how the organization will tie that value to the overall direction of the enterprise. Understanding the larger vision of the project can help to define the correct solution. A solution crafted without the strategic vision of the organization in mind is likely to lead to stakeholder dissatisfaction.
  • Management-level stakeholders: Managers understand how the solution needs to be deployed most effectively at the operational level. They are intimately familiar with the challenges their business unit faces, how the proposed solutions will affect their business unit, and the business rules within which the solution must operate. A solution that negatively affects a certain business unit, doesn't address the underlying problems, fails to exploit the potential opportunity, or isn't compatible with the organizations business rules can lead to stakeholder dissatisfaction.
  • End-user stakeholders: Failure of end users to adopt and fully integrate new technology is a key component of project failure. A project team can plan, design, test, build, and deploy what they believe is an excellent solution, but if the end users cannot or will not use it, then the project will be considered a failure. Executives and managers may believe that the delivered solution will address the need as well, but they will change their minds if users fail to exploit the solution. Consultation with end users during solution development can be an outstanding source of key nonfunctional requirements: how they need the solution to look and feel in order for it to be effective. Many times, end-user stakeholders can better frame the problem with the current application than a manager who doesn't work as regularly on an application.
  • Technical stakeholders: Technical stakeholders can often serve as the "reality check" on a proposed solution. Does the current infrastructure support the proposed solution, and if not, what is needed to get to that level? Does the current IT team have the expertise to maintain the solution, or will your organization need to sign into a managed services agreement with the vendor? Can we design the solution ourselves, or is there a commercial-off-the-shelf (COTS) solution that can be deployed? If the organization deploys a solution that the IT team cannot maintain, stakeholder dissatisfaction is sure to follow.

By engaging the widest possible community of stakeholders during requirements development, the business analyst can ensure that the needs of all communities are addressed. This leads to a solution that everyone in the organization can not only live with but fully support and integrate into operations.

Management beyond the Triple Constraints

Project managers often fall into the trap of believing that their project will be considered a success if they meet the schedule and budget targets. The bottom line is that it is naïve to consider these our only success criteria. Balanced with the time and cost constraint is whether or not we delivered the full scope of the product. I like to think of it as a three-legged stool; you can't lengthen or shorten one leg without equal adjustments to the others. If you do, your stool will be out of balance. So it is with time, cost, and scope—the triple constraints. Crafting a balanced execution strategy is important. It is absolutely necessary that we, as project managers and business analysts, are completely honest about what scope we can deliver within the schedule and budget allocated. However, don't fail to consider the other constraints: risk, resources and quality.

Failing to consider the cost of risk management or failing to include contingency reserves into your cost baseline can cause stakeholders considerable consternation. Whether you perform a quantitative analysis to determine your contingency reserve levels or use a percentage of project cost method, making contingency reserves part of your cost baseline is critical. Asking management to release additional funds to you is uncomfortable, especially if you failed to do a good risk analysis or consider contingency reserves in your estimates, or missed something that you should have anticipated. Remember, contingency reserves are allocated to the project manager (in theory) to deal with identified risks. Management should reserve an amount equal to the contingency reserve as the management reserve in order to deal with risks that could not have been anticipated. Whatever your organizational approach to risk is, be sure to clearly communicate to your stakeholders what risks your project faces, and what your contingency and fallback plans for addressing them are. Also, be the honest broker and let management know that there may be risk events that no one could have anticipated, and for that reason, they should allocate a management reserve.

Projects are also constrained by the resources that are allocated to the project team, whether that is equipment, facilities, or human resources. If the people that make up your project team do not have the level of expertise to accomplish the schedule or to achieve the scope, then be honest about it up front. If your team needs training, again, tell management up front. Two months into a six-month project isn't the time to start raising the red flag that your team lacks the skills to succeed. The same can be said for not having the proper equipment or facilities—you have to have the proper human resources and tools to be successful. If you don't, then don't pretend that you do and end up disappointing your stakeholders when you fail to meet objectives. If you set the expectation up front, and communicate consistently about the skill gap of your team or other resource constraints, these issues won't come as a surprise later on in the project.

Quality is another key constraint that has to be considered and communicated to stakeholders. Quality has to be considered in every time and cost estimate for every work package and every activity. In your initial interactions with stakeholders, ensure that you have a clear understanding of the level of quality that they expect. Have the conversation with your stakeholders and management about the difference between quality and grade as well. Quality is conforming to the stated requirements or fitness for use. Grade is the features or functions of an item.

For example, if someone goes out and buys an economy car with cloth seats, manual transmission, and only an AM/FM radio, he has bought something low grade. If it starts every day, gets him where he wants to go, and does what he expects, it is high quality. If his wife buys a luxury car with heated leather seats, a navigation system, satellite radio, and various other accouterments, she has something high grade. Assuming that it still does what it is supposed to do, like start and not break down, then it is also high quality. The difference between high grade and low grade is the features that each car provides. No matter what grade of product your project is producing, you cannot produce low quality—meaning that the product doesn't do what it is supposed to do. It has to. Your project team has to produce a product, service, or result that meets the basic functionality required. If the product doesn't, or can't produce the functionality required due to the other constraints, then your project could be viewed by your stakeholders as having failed. The message to your stakeholders has to be, essentially, you cannot give me Hyundai money and expect me to deliver a Ferrari. If you don't communicate that to them up front, then what is stopping them from having that expectation? Nothing.

How and Why Do Stakeholder Perceptions and Expectations Go Askew?

The stakeholder identification and classification process is where we identify our key stakeholders. So what happens if we miss a key stakeholder or stakeholder group in our assessment? The eventual requirements issues aside, what is likely to happen is that we will not fully assess what a stakeholder's communication needs are, or what their expectations are, if we fail to consider them in the first place.

Identification of stakeholders, in many cases, may seem like a no-brainer. However, it is critical that the proper care and attention be given to the process. Failing to properly identify and classify your project's stakeholder community can lead to problems in many different areas. First and foremost, your stakeholders are the source for many of your project's requirements, and therefore, a foundational resource in defining the scope of the project's product, service, or result. Failing to account for a stakeholder can mean missing key functional or nonfunctional requirements.

Secondly, missing stakeholders or stakeholder groups can result in a project manager crafting an execution strategy that is not in line with what the stakeholders' success priorities are. If your focus is on the budget, but the stakeholders are more concerned with quality, then your execution strategy will be focused in the wrong area. The same goes with a strategy that is focused on schedule or scope. Lastly, focusing your attention on satisfying the needs of the wrong stakeholders can lead to an incorrectly crafted plan. In the classification piece of stakeholder analysis, we are identifying our key stakeholders. These are the stakeholders whose expectations must be met in order for the project to be viewed as a success. Just because you identify a stakeholder who holds a senior position in the organization does not necessarily make them a key stakeholder. It is important to remember that impact and influence, with regard to the project, is how we determine which stakeholders are key. Managing to the expectations of a stakeholder who has low impact and low influence on the project will result in a strategy that does not reflect the expectations of those who will determine success or failure.

The requirements development function in project management (defined as the Collect Requirements process by the PMBOK Guide®) is another area where the project manager must work closely with the business analyst in order to satisfy the stakeholder community. Requirements must be elicited from the widest possible pool of sources available. The project manager and business analyst must be on the lookout for stakeholder requirements that cannot coexist in the solution. When there are conflicts in requirements, more weight must be given to the requirements that are needed by the stakeholder that is deemed more important (which was determined during stakeholder analysis.) Failing to account for stakeholders during the collect requirements process can lead to the design of a solution that does not fulfill the business need. As requirements are elicited, developed, and analyzed, traceability must be done early and often. All requirements must be traced back to a business need, and also traced forward to an element of work on the work breakdown structure (WBS) to ensure that the work required to fulfill the requirement is represented in the WBS. Failure to trace requirements can lead to missed requirements or requirements in the solution that do not add business value. Either of these problems can lead to stakeholder dissatisfaction.

Setting Expectations and Shaping Stakeholder Perceptions

During the initiating stage of a project (where the project charter is developed and stakeholders are identified) the project manager has the first crack at setting stakeholder expectations. There are times that a project manager has no input during development of a project charter, but in an ideal situation, the project manager will get a draft charter and finalize the charter after stakeholder analysis is done. The project charter should define several important pieces of information, including what the key success criteria are, what is in scope, what is specifically out of scope, major constraints and assumptions, and high-level risks that the project faces. Clearly defining the aforementioned up front will be critical in setting initial project expectations. The project's sponsor should be the signature authority for the project charter, and once signed, the charter will set the limits within which the project must align.

Once signed, the project charter can be used as a guide for stakeholders during requirements development. If, during elicitation, stakeholders are asking for features or functionality that the project is not intended to deliver, they can be referred to the project charter for clarification. It can also be used at the beginning of the project as a tool to communicate to stakeholders what the project is expected to deliver or not deliver. Stakeholders can quickly reference what schedule and budget constraints the project faces, which can help to bring expectations in line with what is achievable.

Key stakeholders should be given multiple opportunities to contribute input during the planning phase of the project. Since project planning is an iterative process and project teams learn more about the project as planning progresses, stakeholders should be updated regularly as the plan evolves. As risks are identified, assumptions are validated or invalidated, and as quality metrics are defined, stakeholders should be presented information that will help to guide their decision making process. The frequency of project planning reviews will often determine the level of understanding that stakeholders have about the project.

There are several major events that should trigger stakeholder interaction, among them are:

  • After the collect requirements process to gain sign off of the requirements
  • Upon completion of the scope statement, WBS, and WBS dictionary to validate that the scope is correct
  • Upon completion of the proposed project schedule
  • Upon determination of the proposed budget
  • Upon completion of the risk analysis to ensure that the project is within the organization's risk tolerance
  • Upon completion of the other subsidiary management plans that comprise the project management plan

Stakeholders can bristle if the first time that they hear about weaknesses in the project plan is when the entire plan is complete and presented to them. They are not intimately involved in planning, so the only information that they normally receive comes from the project manager. If the project manager sees that time, cost, or scope are not in balance early on, the red flag needs to be raised. Stakeholders cannot be left to assume that all is going well with planning if it isn't—no news isn't always good news. When the project team has done all it can to craft a balanced execution strategy, it must be presented to the sponsor and other key stakeholders for approval. Once approved, the project plan will be baselined, and execution can begin.

During the execution of project work, data is generated and analyzed. From this analysis, work performance information is produced and that information is compared to the established baselines for time, cost, and scope. When project performance does not match the performance baselines established in planning, some form of change to the plan may be necessary. When change is recommended, stakeholder involvement is critical. The project manager must conduct an impact analysis on the potential change and make a recommendation to the change control authority based on the options that have been evaluated. An assessment of the impact of making no change should also be presented to the stakeholders for their consideration. When the stakeholders make their choice on a change option, it is easy for them to assume that the problem has been fixed. Their perception may be that, for now, all is well. This is why it is critical for the project manager to assess the effectiveness of the change and report to the stakeholders whether or not the change had the intended results. The expectation is that the change recommended by the project manager will fix the problem, and if it did not have the intended effect, the stakeholders need to know as soon as possible.

Crafting a Winning Stakeholder Communication Plan

The project manager is responsible for everything that the project does or fails to do, including how team members communicate. The ground rules for communication must be set immediately at the outset of the project. It is essential for a project manager to foster an environment of open and honest communication. Creating a team where members are not afraid to deliver bad news can be the difference between a project manager who can catch and fix a problem early, and one who finds out about a problem when it is too late to fix it. The project team must also understand what information is needed and when.

Assuming that your team members know what your information needs and expectations are is no different than a key stakeholder assuming that you know what their success criteria are. So, just like a project manager wants it spelled out for them, spell out what communication success looks like for your team. Frequency, formats, and subject of communications need to be a major component of your project communications management plan. Without this plan, the team will be left guessing. This will leave the project manager guessing when it is time to report performance to the stakeholders.

Stakeholder expectations can be misaligned with reality due to estimating errors, as well. It is crucial that, when working in a time-constrained environment, stakeholders understand that the accuracy of your team's estimates are directly proportional to the time allotted for the task. If, however, the key stakeholders believe that the time to complete estimates was sufficient, that will be their perception unless the project manager lets them know otherwise. Members of the project team are charged with giving estimates for the work packages assigned to them, but the project manager is accountable for the accuracy of the estimates.

It is important for the project manager to get estimates for work effort when estimating for time, not the estimated duration of tasks. Team members need to understand that the effort estimates given to the project manager will be subject to loss factoring; that is, when a team member says it will take eight hours to complete an activity, the project manager will not add eight hours to the project schedule. The project manager will adjust for the reality that up to 30 percent of an employee's productivity will be lost daily due to fragmenting of effort, multitasking, and responsibilities for operational work. If loss factoring is not done, then it is easy to underestimate how long work packages, deliverables, and the project will take to complete. Giving estimates to stakeholders that cannot be achieved will set an expectation that cannot be met, and make stakeholder satisfaction very difficult to attain.

The bottom line for project managers in the arena of meeting stakeholder expectations is that you have to know what the expectations are to begin with if you are ever expected to meet them. There is no secret formula to establishing stakeholder expectations—all you need to do is ask. Explaining to your key stakeholders that project success is much more likely if the project manager knows what success criteria he or she must manage can help the stakeholder understand why you are asking something that may be obvious to them. If your stakeholders perceive that your project was initially over-funded and the schedule was padded, provide them the basis of your estimates. This can go a long way in reshaping that perception. Finally, once the expectations have been set, follow up with your stakeholders to ensure that the expectations haven't changed. People change their minds often, so communicate in order to influence their perceptions and expectations. You may be surprised how simple communication and understanding expectations can positively affect your next project.

About the Author

Dan Stober is a PMP-certified project manager with over ten years of experience managing projects. His experience includes managing projects for the United States government in the US, Middle East, and Europe.