Section 6.3. Identifying Stakeholders

6.3. Identifying Stakeholders

Stakeholders are any individuals (sometimes companies or groups, but we'll keep it simple here) who have an interest or stake in the outcome of the project. Typical stakeholders are users, corporate executives, project team members, and the project sponsor. Different stakeholders have different needs, requirements, and expectations, so it's important to identify your various stakeholders early in the project's life. As you move through the definition and organization phases of this IT project management process, you may identify additional stakeholders. Keep in mind that stakeholders usually define (or refine) the project's requirements. Users are those who use or rely upon the project's deliverables, so clearly they have a stake in the project. The company is footing the bill for the project, so clearly corporate executives have a stake in the project's outcome. The project sponsor will be judged upon the success of the project, so clearly the project sponsor is a stakeholder. There are others who can be stakeholders in different circumstances and each company and project is different.

6.3.1. Identifying Your IT Project's Stakeholders

When trying to determine who the stakeholders are, you can ask a series of questions to help you identify stakeholders and to help ensure you don't inadvertently overlook an important stakeholder.

Who needs to know about this project?
Who will use this project?
Who is impacted by the results of this project?
Who is impacted by the operations of this project (the actual project itself )?
Who is paying for this project?
Who is approving this project?
Who is delivering this project?
Who needs to be trained?
Who else should we talk to about this project (what else do we need to know)?

We'll discuss each of these questions very briefly to help clarify exactly how these questions help you identify all potential stakeholders. Remember, though, that there are stakeholders and then there are stakeholdersmeaning there are many different people or groups you'll identify as stakeholders, but they can then be prioritized into primary, secondary, and tertiary stakeholders. This is important to understand because later in this chapter, we'll discuss how to work with stakeholders to define, refine, and negotiate project requirements.

6.3.1.1. Who Needs to Know About this Project?

Answering this question helps you identify stakeholders in the company that will be impacted by this project. This could include groups you might not always think about such as Human Resources, Marketing, Sales, and Training to name a few. There may be groups or departments in the company that will be called upon to lend resources to the project. There may be individuals or groups whose activities will be impacted by the project. Another approach to this is to take a look at all the departments in your company (assuming your company isn't too large) and ask if that department will be impacted by your project or if anyone in any of those departments needs to know about your project.

Remember that people will have different information needs. Some individuals or groups will have to be (or should be) brought into the project planning and decision-making loop while others may just need to be notified of the existence of the project. Once you've identified your stakeholders, you can prioritize them, as we'll discuss in just a bit.

6.3.1.2. Who Will Use this Project?

The results or deliverables for your project are intended for use by someone or some group. You may already know who the users will be (current or existing) or the users may be a target market for a new product that doesn't yet exist. In either case, you will need to identify who will be using the output of this project. Getting user input and developing user acceptance criteria are crucial to the success of the project, so we'll discuss this later in this chapter. The users of the project's output are usually among the most important stakeholders, but they're not the only stakeholders you'll need to address.

6.3.1.3. Who is Impacted by the Results of this Project?

Understanding who is impacted by the results of the project is also vitally important. For instance, if you're implementing a new payroll system, the users may be the people in Finance and/or Human Resources that will actually use the system, but everyone at your company who gets a paycheck is potentially impacted by the results of this project. Understanding the answer to this question can help you understand how this project will impact your company or your client's company and to plan accordingly.

6.3.1.4. Who is Impacted by the Operations of this Project (the Actual Project Itself )?

This question may seem to overlap earlier questions in terms of identifying stakeholders and if it does, that's fine. It's better to overlap slightly than to leave large gaps, so you may start finding duplicates on your stakeholder list as you go through these questions. It's a safe bet that if someone (or some group) shows up more than once or twice on the list, the stakeholder group is very important to your project and you should treat it as such.

Understanding who is impacted by the operations of the project can include other departments that may have to lend staff, expertise, time, or other resources to your project. It can also include people whose jobs or processes may be interrupted or impacted when the project is underway. It might include who will be impacted by your project team taking over an office or conference room. Using the payroll example again, the payroll processing clerks will be impacted by this project and they are also part of the user stakeholder group. However, while you're working on the project, you may also need the assistance of accounts payable and accounts receivable clerks in entering test payroll data, verifying payroll test results, etc. While many of these activities may fall under the Quality Assurance department's line of responsibility, they may require the assistance (or resources) of others in the organization that might not normally be involved in the project.

6.3.1.5. Who is Paying for this Project?

The person paying for the project is clearly a stakeholder. The project might be funded by a client, by a potential client, by a government grant, or by the company (internally, through a departmental or project budget). Regardless of how the project is being funded, someone is going to have to approve the budget and/or project expenditures and that person or group has a vested interest in the outcome of the project. Sometimes project managers forget to take into account the person writing the check unless that person is the project sponsor or part of the user group. This is why we discussed aligning IT projects with corporate objectives earlier in the book. If the IT project is aligned, this stakeholder's needs are likely to be addressed. If the IT project is not aligned, you're probably going to have to spend time addressing this stakeholder's needs in terms of making the business case for the IT project and explaining why the project should be funded and what value it adds.

6.3.1.6. Who is Approving this Project?

Usually the person(s) paying for the project also approves the project, but not always. Make sure you know who will be approving not only the overall project plan and who will be giving the project the green light, but also know who will be approving the project's deliverables. The project plan may be approved by the project sponsor and the deliverables may be approved by the user, but there may be others such as corporate executives, steering committees, and governmental agencies that may be involved with various project approval points.

6.3.1.7. Who is Delivering or Implementing this Project?

The delivery or implementation may be part of your project or it might not be. You should be clear about who is delivering or implementing the project. An example of this might be that the software group develops the software, but the client services division actually installs and supports the software installation on the client side. If that's the case, you'd want to make sure your client service's key personnel are in the loop on this project so you can ensure that their installation and support needs are also met by this project. Delivering a software project that no one can install, implement, or use would be pointless.

6.3.1.8. Who Needs to be Trained?

IT staff rarely deliver training themselves (unless training is part of the IT function in your company) and as such, user training often is neglected. Asking who needs to be trained will help you identify training needs and make plans to address those needs. Sometimes you need to train project staff in a new technology, technique, or process. Sometimes users need to be trained. Even if it is outside the scope of the project, if someone needs to be trained, you've identified another stakeholder (the training department) and you can incorporate this information into your project plan accordingly. Often this is a simple step of adding a task to the project to contact the training department at a certain point to allow them to become familiar with the product or process and develop training materials, etc..

6.3.1.9. Who Else Should We Talk to About this Project (What Else Do We Need to Know)?

Asking "What else do we need to know?" can also lead you to additional stakeholders. If you're tasked with updating the payroll system, you may decide you want to map out or understand the current payroll process and to understand the current limitations. While some or all of this may have been discovered or discussed during your initial project discussions (Chapter 5), it's also possible you'll need additional information. Perhaps you've talked with the payroll staff, but you haven't talked with Human Resources staff who interact with payroll and with corporate employees. Perhaps you need to get input from an outside expert such as an attorney, CPA, or consultant before you have all the needed data. There may be legal, financial, or security requirements that necessitate consulting an expert (Sarbanes-Oxley financial data requirements, HIPAA (health care data) or other data security requirements. These are examples of situations that may require notification or inclusion of people you might not normally think of.

You might be thinking that if you ask and answer all these questions, you're going to have about 15,000 stakeholders on your list. Yes and no. Yes, you may generate a long list; but no, you don't have to accept input from every single stakeholder to the same degree. The point of this exercise is to find out as much as you can about who may be a stakeholder and then develop a strategy for managing stakeholders of various kinds.

6.3.2. Prioritizing or Categorizing Stakeholders

It would be impossible for us to specifically define the stakeholders for your projects, but we have defined three of the high-level stakeholders. Some stakeholders should help make key decisions, others may be needed from time to time or may need to be kept in the loop, and still others may just need to know about the project. We're purposely using the term stakeholder loosely here to ensure you notify and involve the right people in the project early on. How you deal with this list you've generated depends largely on the types of stakeholders you've identified and on the nature of your project. We can divide stakeholders into three categories. If you identify a fourth or fifth category specific to your company, project, or situation, that's fine. The key is to categorize your stakeholders so you can better manage expectations and requirements. The three categories we'll discuss are influential, involved, and informed.

6.3.2.1. Influential

Influential stakeholders are those that are key or critical to the project and they influence the content, deliverables, and acceptance of the project. These stakeholders typically include users of the project's deliverables as well as the project sponsor and the person or group funding the project. These are people whose input and approval is critical to the success of the project and these are the folks you're going to work closely with to ensure your project meets or exceeds expectations. In fact, these are the folks with whom you'll be setting (negotiating) expectations and who will help you develop acceptance criteria for the final project deliverables.

6.3.2.2. Involved

The stakeholders in this category need to be involved to one degree or another. This might include staff from Training, Human Resources, Sales, Marketing, or other departments that may need to be involved with the project from time to time or who may need to gear up to do work related to the project's deliverables once the project is complete. For instance, if a new product is going to market, the Marketing department should be brought into the loop to allow them adequate time to prepare marketing materials to get the new product to market. Of course, in some cases, the Marketing department might be part of the influential group if they are providing input on what users need and therefore will influence the actual project deliverables. The Training group may need to be brought into the picture 60 days before the product is released in order to give them time to develop training content and schedules. They don't influence the actual project, but they need to be involved at some point.

6.3.2.3. Informed

The last category of stakeholder includes those who need to be informed from time to time about the project. If your company is going to implement a new network infrastructure that will be relatively transparent to users, but that will cause downtime at certain points, you'd want to keep users informed of that. If the Sales department has a huge client presentation they're preparing and the network servers are down, that's a major problem. Typically, the informed group needs to be informed of top-level information such as key dates, milestones, or activities. If the network servers will be down from Friday 6:00 P.M. through Sunday at midnight, letting users know this a few weeks before can help avoid all those last minute, frantic help desk calls asking for assistance in preparing for the network outage, for example. Stakeholders in this group might also be corporate executives for whom you must prepare periodic progress reports. They want to know the project is succeeding, but they don't need (or want) to know the project details. Typically, people in this category are included via various communications plans, which we'll discuss in more detail later.

Applying Your Knowledge

Users or customers are those who utilize or employ the deliverables of the project, while stakeholders are those who directly or indirectly impact or are impacted by the project (users are also stakeholders, but not all stakeholders are users). You may wish to develop a different set of criteria for categorizing your stakeholders, but it's important to organize them in a clear and accurate manner. This will make planning and managing the project much easier because large segments of work such as communications plans can be targeted to specific groups of stakeholders. This will help reduce the amount of work (or redundant work) you have to do and will also help you avoid omitting or overlooking a key contingent.

6.3.3. Managing Stakeholder Expectations

Once you've identified and categorized your stakeholders, you will also have to create plans for managing stakeholder expectations. This may sound bigger or more cumbersome than it really is. Stakeholders in the influential category are those you're going to have to work closely with on many aspects of your project. It's fair to say that these are the most important stakeholders for you to manage because it is within this group that your project's definitions of specifications, requirements and success will come (hint: these stakeholders may provide all this, but it's your job as IT project manager to negotiate final specifications). Scope, time, budget, and quality are all impacted by the expectations, demands, requirements, and needs of this group.

The stakeholders in the involved and informed groups typically will be much easier to manage because they are not as key to the project's success. Those in the involved group will need to be managed to a lesser degree than those in the influential group, but it will still be important to develop strong lines of communication and to develop a common understanding of processes and procedures. For example, the Training department needs to be involved at some point, so you'll need to provide them with a method of gaining needed information and expertise so they can develop training materials. This might mean you have to get one of your software developers to commit to spending four hours with one of their trainers to transfer that knowledge at some point during the later stages of the project. Managing the Training department's expectations about what they can expect from your project and when they can expect it will keep everyone calm, cool, and collected as things heat up in the midst of the project.

The stakeholders in the informed group usually just need to be kept in the loop about events that may impact them or top-level accomplishments. It's usually easiest to create communications plans for each stakeholder group within this category. For instance, corporate staff probably don't need a monthly report on project progress (unless you're doing some major in-house PR to gain support for the change that the project will create), but they will need to know about events that will impact them, such as network outages, new logon procedures, etc.. On the other hand, corporate executives need to know about events that will impact them as well as project progress, so you'll need to create a communication strategy unique to this group. We'll talk more about all of this later in the book.

You can see that identifying stakeholders is a bit more involved than you might at first have thought, but it's not a difficult task. When you take time to identify and categorize your stakeholders, your project plan can incorporate plans (or tasks) that provide for the needs of the various stakeholders. It's much easier and faster to take a few minutes to map out your stakeholders now than to overlook at key group and find out later on.

Enterprise 128 …
Avoid the Doh! Factor

The Matt Groening character, Homer Simpson, is famous for exclaiming "Doh!" whenever he discovers an error (well, he uses it for a lot of things, that being one of them). One of the things most IT project managers absolutely hate is that moment when they discover an error or omission that could have (and should have) avoided, causing them that awful Doh! moment. Avoid overlooking any important individuals or groups by taking a few minutes to ask and answer the questions in the previous section. It will help you identify all potential stakeholders. Then take another few minutes to categorize stakeholders to assist you in creating plans for interacting effectively with the various stakeholders. Here's a tip: when you're talking with the stakeholders you've identified, take a moment to ask them who else needs to know. You might be surprised by their answers and relieved that they helped you avoid overlooking an individual or group that is important to the project's success. Asking, "Who else should I be talking to?" helps you avoid the Doh! factor later on.