How to Define Stakeholders for Your Software Development Project

A good discovery process is critical to software development. The requirements generated here set the stage for the entire project, laying the groundwork for success or failure. Involving all stakeholders from the beginning is the single most impactful step developers can take- but identifying those stakeholders isn’t always easy. Companies who rush through this phase might overlook a group whose support they need down the road. That’s why defining the stakeholders should be a deliberate process during the early stages of discovery.

What Do Stakeholders Do?

The term “stakeholder’ refers to the people or groups affected by a software development project. Stakeholders exist both within the organization and outside of it. They may be end users, or they might simply be affected by the process. Either way they have a vested interest in the final product. Input from stakeholders tells the company what kind of software is needed, suggesting ideas for features or problems it needs to solve. They construct use-case diagrams and map workflows which guide the new software’s UI design. As a group they evaluate the merits of each others’ ideas, assigning an initial priority to the prospective feature list. Stakeholders are in the best position to offer specific input on needs at their level. They know what will or won’t work within their workflows. Plus, as representatives of their category’s interests they have a handle on any unique needs that may conflict with other stakeholders. Having that knowledge early helps developers find a compromise before serious problems arise. Collaboration doesn’t stop after discovery, either. A more limited group of stakeholders is active during development to review prototypes and provide recurring feedback throughout the development process.

Why Are They Important?

Neglecting stakeholders is a risky proposition. First and foremost, without their input developers are working from an incomplete list of requirements. Surprise needs are bound to pop up during development. These sudden additions cause scope creep, where the project grows past its original boundaries. The initial time and budget requirements are forced to stretch to cover the new requirements. That isn’t always possible. It’s much more likely that some features have to be cut to meet deadlines. Even when deadlines and budgets are satisfied, missing contributions have consequences. Lack of adoption is a serious risk. Sometimes software turns out exactly as leadership wants but isn’t used by employees. They might already have more effective tools or find the new software doesn’t have features they wanted, or they’re just not sold on the software’s value. Whatever the reason, their lack of enthusiasm translates into a wasted investment. This is especially true for smaller and niche groups whose needs tend to be overlooked. There is room within development to add new requirements. However, those should come in response to ongoing feedback instead of being a band-aid for a weak discovery process.

Who Is Considered a Stakeholder?

While every development project is unique, there are some universal categories that can be used to guide stakeholder identification.

End users and beneficiaries

These are the people who will be most directly affected by the software. Their buy-in is essential. No matter how flashy or efficient software is, if end users don’t like it they won’t use it. End users fall into three main groups:

Direct users

Those who will use the software directly are usually most concerned with how it will fit into their current workflows. They want to know that it solves a significant problem or otherwise makes their job easier.

Secondary users

Direct users interact with the software itself. Secondary users rely on the products of the software. New software needs to produce results in a format that fits into secondary users’ workflows. Forgetting about this group can cause one problem while solving another, like suddenly generating reports in a format secondary users can’t integrate into their analytics.

Beneficiaries

These are all the people affected by the software’s products. The term encompasses a huge base of customers and vendors who focus more on results than process. Their input should revolve around the services or information the software will provide.

Project build team 

Good software development is a balancing act between dreams and reality. End users sometimes create an unrealistic list of features and requirements. The build team serves as the voice of reason that keeps the project within a manageable scope. Their job is to find a way to fulfill as much of the “wish-list” as possible while meeting business goals and hitting time and budget targets. Each member of the build team has a different focus:

• Managers and company liaisons make final decisions about timeline, budget, and scope. They’re the ones authorized to add time or cut features.
• Project managers shape the development process. They keep track of all the moving parts to maximize efficiency and serve as the point of contact for other stakeholders. Their primary interest is creating a solid product and leaving clients happy.
• Developers build the software based on feedback from other stakeholders, but they’re also stakeholders in their own right. They have the technological expertise necessary to advise executives on which features are feasible and how long each would take to build.
• Partners refers here to outside groups involved in the actual development process. They may be owners of third-party tools or a client’s business partners who need to ensure compatibility with their systems.

Authorities

Some people aren’t directly involved in the project but do have authority over it in some way. This includes legal and regulatory bodies, shareholders, and company owners. Although they don’t have daily interaction with the software, they govern its usage. Be sure to get their input during discovery to avoid being shut down later. Each of these categories can be further divided into internal versus external stakeholders. Internal stakeholders are part of the client company: executives, employees, board members, and shareholders. Their goal is to solve pressing business problems through optimized processes, increased sales, better insights, or some other measurable benefit. External stakeholders lie outside the client company, such as customers, regulatory bodies, legal officials, and surrounding communities. They want to gain the most benefit from the project with the least risk to their own interests. Both groups have what seem like conflicting motives, but in practice there’s a middle ground where everyone can find value. Collaboration by a diverse group of stakeholders is key to finding this middle ground. [caption id="attachment_1055" align="aligncenter" width="837"] Source: Concepta, Inc.[/caption]

Defining Stakeholders

Including every individual stakeholder in discovery would be insanely costly, both in time and resources. Fortunately, that’s not necessary. Choosing representatives from every relevant group provides a good working picture of a project’s needs. Look at all stages of the project from conception to actual usage to identify stakeholders. Consider these questions when building the stakeholder list:

• Who will use or be affected by the final product?
• Who uses the current tool or software that the new software will replace?
• Which departments use the products of both the current and proposed software?
• How will workflows change? Will positions be modified or created?
• What legal restrictions and regulations apply? Who knows enough about them to advise the development team?
• Who has authority to make changes to the development plan once it’s finalized?
• Are there any people whose support is absolutely vital to the project’s success? Whose buy-in is needed?

Stand-ins are often used for external stakeholders. Legal counsel can cover regulatory bodies and local government, for example, and focus groups serve as barometers of public opinion. It’s also useful to consider who wants the project to succeed and who isn’t on board yet. Bringing someone who’s reluctant to adopt new technology onto the stakeholder team can be a way to give them a sense of ownership that might change their mind. Similarly, enthusiastic supporters can lend energy to a project others aren’t sure about.

Key Players for Ongoing Support

Interim progress meetings don’t need to include every stakeholder whose input is used during discovery. Developers can gather requirements and suggestions from a larger group in the beginning, then identify key players to provide running feedback during development. What sets key stakeholders apart? Look for those with two or more of these characteristics:

• Will have direct contact with the final product (project managers and end users)
• Are the senior representative of a group of important stakeholders (department heads)
• Have unique knowledge or insight to offer which can shape development process (Subject matter experts)
• Are so vital to success that the project can’t easily succeed without their support (executives, business partners, end users)

Think about whose input or approval is needed on an ongoing basis as opposed to those who simply want to approve the concept. Also, keep in mind that stakeholders don’t have to show up in person to be included. For instance, agile development practices like continuous delivery open the door for gathering regular feedback from end users in the form of feature requests and reviews.

Sample Stakeholder Selection

What does stakeholder selection look like in practice? Imagine a mid-level retailer - call them ExampleCorp - who’s working through digital transformation. ECorp wants to make their sales, marketing, and inventory data accessible by leaders throughout the company. They decide to build a unified reporting dashboard that collects incoming analytics streams and displays them in an intuitive, easily understood format. Who are their stakeholders in this project? ECorps starts by compiling a list of everyone whose input should be considered during discovery. For this analytics project, they should consult:

• Executives
• Company liaison
• Marketing team
• Social media manager
• Sales staff
• Customer service department
• Legal department (for advice about data protection regulations)
• Administrative staff who currently pull reports
• IT department who will maintain and train on the dashboard (including the database manager)
• Company shareholders
• Project managers
• Development Team

Their key stakeholders, who come to progress meetings during development, are a smaller group. The project manager, IT team, and company liaison still attend themselves. The sales, marketing, and customer service departments simply send representatives to report on how the most recent updates are being received by end users. If a particular feature leans heavily towards a certain department more employees might want to come, but otherwise the representatives can carry concerns to the meetings instead of the entire team missing work to attend.

Final Thoughts

Effort spent during discovery translates into money saved during development. Take the time to gather input from all stakeholders and reap the benefits of a smoother, more focused development process.

Struggling with putting together your key stakeholder list? Take advantage of Concepta’s decade of experience to highlight the essential players for your next software development project. Your free consultation is waiting!