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 beneficiariesThese 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 usersThose 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 usersDirect 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.
BeneficiariesThese 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 teamGood 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.
AuthoritiesSome 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.
Defining StakeholdersIncluding 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?
Key Players for Ongoing SupportInterim 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)
Sample Stakeholder SelectionWhat 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:
- 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
Final ThoughtsEffort 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!