Every software development project comes with stakeholders. These players have enormous influence over the project. They require constant communication and management.
Depending on the nature and scope of your project, dealing with your stakeholders could be quick and simple or complex and resource-intensive. But before you can manage those relationships you'll need to determine who your stakeholders actually are.
Management Institute has a great definition:
“Individuals and organizations who are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or successful project completion.”
Basically, stakeholders are groups of people who have something to gain or lose from the project’s outcome. If that sounds a bit nebulous, you’re right. We’re talking about a complex group of people with different - and often competing! - goals.
You might have one stakeholder or many. Startups start acquiring stakeholders as soon as they start accepting venture capital. Enterprise corporations already have enough stakeholders to deserve their own email list.
Further, your stakeholders can change throughout your software project’s development. For instance, you might bring in a new investor or sign a contract with a big customer. Similarly, a stakeholder may step away in the middle of your project as well.
If you’re leading a software development project, it’s your job to keep the stakeholders informed and on-board with the project’s progression. You’ll have to communicate with them frequently, show them demos of the product, and answer their questions.
Interestingly, some organizations take their stakeholder relationships so seriously that they invest in stakeholder happiness programs, sometimes putting a full-time person in charge of managing those relationships.
Types of Stakeholders
There are two main types of stakeholders in software development: internal and external.Image: ActiveCampaign
1. Internal Stakeholders
Internal stakeholders are stakeholders from within your own organization. This group includes executives, managers, and team members. Most don’t have a financial interest in the project, but they want it to succeed for the sake of their careers and reputations.
Some may have a financial interest, however. Executives almost always own some portion of the company. In fact, many organizations vest their employees with some equity in order to give them some financial interest so they’ll do a good job.
2. External Stakeholders
External stakeholders are stakeholders who aren’t a part of your organization. This group includes customers, users, vendors, suppliers, investors, and non-working owners.
These players might also have a financial interest. Investors obviously stand to profit from your work. Customers expect to use your product in the future, so they have a financial interest as well. Vendors and suppliers want you to be successful as well so you’ll keep buying from them.
Some organizations expand stakeholders to include anyone who needs to be informed about the product’s development. Since you’re already keeping a group of “in the know” people informed, it’s often fairly simple to just add a few more names to your email list. That might include the following:
Marketing team / social media manager / email marketer
Sales staff (or just the sales supervisor)
Customer service team
Other development teams
Legal team (especially when you’re working in a regulated market)
As you can see, those two groups have the capacity to complicate your work, Especially when you consider their goals won't always align. For instance, a manager might want you to limit how much you spend with a particular vendor to decrease costs, whereas the vendor wants you to increase usage as much as possible so they make more.
As you can see, the type and number of stakeholders you’re dealing with depend on your organization and your software project. So it’s important to spend a few minutes figuring out who your stakeholders are.
In some cases, this may be as simple as asking your supervisor (or a C-suite executive) to tell you who counts as a stakeholder in regards to your project. In other cases, you may have to do a bit of research. Think of anyone who’s connected to your project that has an interest in its success.
Don’t forget to consider that some stakeholders might not play a role - or even exist - until later in the project’s success. An early customer, for instance, may stand to gain financially if your software succeeds, but they probably won’t be part of the project’s conception.
Here are some questions to ask yourself in order to identify stakeholders:
Who will be affected greatly by the final product?
Who will gain or lose money due to the final product?
Whose work will be drastically changed by the product?
Who will have direct contact with the final product?
Whose career/reputation will be affected by the final product?
Who has authority to make changes to the development plan?
Whose support is vital to the success of the product?
You may understand who counts a stakeholder for your software product, but there’s not much you can do with a simple list. Your stakeholders aren’t all equal, after all. For instance, your direct supervisor and some guy who owns $200 worth of stock are both stakeholders, but the former is obviously a bigger influence on you.
Once you’ve identified all of your stakeholders, your next step is to prioritize them. This step helps you understand what time and other resources you should devote to those relationships.
The simplest prioritization method is to plot them on to a power-interest matrix. This is a simple, quadrant based method of prioritization similar to how you would use the Eisenhower matrix to plot the importance of tasks. (This method is sometimes called the power-influence or impact-influence matrix or grid.)Image: Teamwork
The matrix works by asking yourself two questions about each stakeholder.
What kind of power do they have over you and the project? If they have a lot of power relative to other stakeholders (for instance, perhaps they can force changes to your roadmap), plot them high on the vertical scale. Keep in mind that a stakeholder’s power can be positive or negative. If they can impose their beliefs on the project, even in a destructive way, they have a lot of power.
What kind of interest do they have in the project’s success? If the project is extremely important to the stakeholder, plot them to the right on the vertical scale. Stakeholders who are deeply committed to the project and directly involved in would be considered high interest.
Stakeholders who fall into the “manage closely” quadrant are obviously the most important because they can have the biggest impact on your project. They might require weekly updates, in-person meetings, and access to your project management tools.
Stakeholders in the “keep satisfied” quadrant should be kept happy, but they don’t require as much attention as stakeholders in the “manage closely” quadrant. People in the “keep informed” quadrant should be notified about progress and changes, but you don’t have to engage them one-by-one. And those in the “monitor” require the least amount of time and resources.
If you have a lot of stakeholders in all four prioritization quadrants, it helps to create a central repository with their names, contact information, and classifications. This key piece of documentation will keep you organized as you manage those relationships.
For instance, you can use this repository to document your last communication with each stakeholder to ensure you’re serving their priorities as you drive the project forward. Share the document with anyone who communicates with the stakeholders as well.
By now, you should understand your project’s stakeholders. It’s important to have a clear understanding of this group of people and your responsibilities to them. Manage those relationships well in order to produce a successful product that meets everyone’s needs.