-p-500.webp)
Involving all stakeholders from the beginning is the single most impactful step developers can take - but identifying those stakeholders isn’t always easy.
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.
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 categories 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.
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.
While every development project is unique, there are some universal categories that can be used to guide stakeholder identification.
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:
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.
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.
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.
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:
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.
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:
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.
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:
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.
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:
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.
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.
If you're grappling with compiling a comprehensive key stakeholder list, there's no need to go it alone. Leverage Concepta's decade-long experience in application development to pinpoint the essential players for your project. From stakeholder mapping to sophisticated development methodologies, we offer a 360-degree approach that not only helps in identifying stakeholders but also in keeping them engaged throughout the project lifecycle.
Reserve your free consultation today to chart the most efficient course for your next web and mobile development project.
