fbpx

Identify Stakeholders for Requirements Gathering

Lined up business people sitting in an office building waiting room, waiting for a job interview

Engaging and aligning the right stakeholders for your requirements gathering process for enterprise software selection projects,  drives digital transformation, and results in high user adoption after implementation. Here we break down what stakeholders to include, and why identifying the right ones is important for finding best-fit enterprise tech.

How to Identify the Right Stakeholders for Requirements Gathering?

Digital transformation success relies on gathering the right requirements. However, this isn’t a possibility without talking to the right stakeholders and understanding their needs. Collaborating with the right stakeholders reduces the risk of choosing the wrong solution. The only people that are able to help you avoid failure, are the eventual end users!

Take your time to figure out who needs to be heard. Valuing the right voices creates a compounding benefit throughout the software buying process. With the right input and validation, you guarantee a seamless implementation and high user adoption.

But who are the right stakeholders to elicit requirements from? Should everyone get a say? Who are you forgetting or overlooking?

Following our process of stakeholder identification reduces the risk of a failed implementation.

What Defines a Stakeholder for Requirements Gathering?

A stakeholder is anyone responsible for selecting the solution, either as a user or beneficiary. They can be internal or external to the organization and are, undoubtedly, the best people to ask for input when gathering the requirements.‍

Why is Eliciting Requirements from the Right Stakeholders Important?

Stakeholders inform the CIO, digital transformation leader or IT department of what type of software is needed and how it should perform. They help discover what the business needs are when evaluating solutions. Finding and working with the right stakeholders is key for digital transformation, and can help you with:

  • Highlighting the right business problems to solve
  • Identifying crucial features of software
  • Avoiding requirement oversights
  • Avoiding band-aid solutions
  • Evaluating requirements suggested by others
  • Ranking priority requirements
  • Raising compatibility issues
  • Championing the software implementation
  • Constructing the best workflow process using the software

What Stakeholders Should you Gather Requirements from?

Let’s go into a bit more detail on who these stakeholders are;

End Users 

Direct Users

Direct users are the people who will interact with the software most frequently. Whose job it will be to use this software, whose problems you are trying to solve or the department that will be impacted the most. .

In some cases there will be many direct users who will have varying degrees of importance.  While going through the end users, make sure to give the right amount of weight to the most important stakeholder. You are usually able to tell the key stakeholders by how significant an impact the new software would have on their role.

Indirect Stakeholders

Indirect stakeholders are the secondary users that are impacted as a result of using the software. These stakeholders traditionally are consumers of the output generated by the direct users or the creators of the input needed by the software.

For example, finance would be an indirect stakeholder for a procurement system because they rely on the invoices generated by the procurement software & team. The customers could also be considered as indirect stakeholder because they receive the invoice

Indirect stakeholders can be both internal or external so make sure you assess who is impacted.

By taking into account the indirect users, you are ensuring that the new software makes life easier for direct users and benefits the indirect user. Companies who overlook secondary stakeholders often end up benefiting one department while causing problems and barriers for the others.

Beneficiaries

Beneficiaries are the group who enjoy the fruits of the direct and secondary user labours. The beneficiaries can be the customers, customer support staff, leadership team or anyone that derives a benefit from an improvement in the overall service mechanism.

Relevant Authorities and Decision Makers

You might not like it but you are not always the only one with a say in the matter. Just as you need city building permits  for a new building or a licence for certain services, you may have a regulatory authority involved in your decision.

Figure out if you will need to satisfy any software certification, shareholder approval or other regulatory requirements. Consider who might have the authority to veto your software purchase? Or do you need to discuss your plans with any governmental authority? For example, the American State Bar does not permit the use or construction of certain technologies without prior approval.

The last thing you want is to pull the trigger on buying an expensive software just to find that you don’t have the permission required to use it.

The Project Team

The project team are key stakeholders and collaborators who are responsible for finding the right software to meet the needs of your users. They must be able to gather, assimilate and organize the requirements from the necessary stakeholders. Once requirements are gathered, the team will decipher between what are utterly essential requirements and what are nice to have. Finally, they must be capable of assessing the stakeholders and understanding which opinions to prioritize.

The team is the guiding voice responsible for matching the wishlist items of the stakeholders with the best interests, intentions and business functions of their company. Their success depends on finding an accepted software for a smooth implementation within the budgetary parameters.

Stakeholders and collaborators can be made up of project coordinators, key department figureheads, customer representatives and external partners. Again, anyone who is a key stakeholder should be represented on the committee.

Questions to Ask When Identifying Stakeholders

Accidentally omitting the opinions of key stakeholders is a very real possibility when carrying out your requirements gathering. Rather than trying to avoid this by inviting anyone and everyone to avoid this, consider qualifying them.

Considerations for qualifying stakeholders

  • What departments will this software affect?
  • Who will be impacted by the output of the software?
  • Who is impacted upstream and downstream
  • If we switched off the legacy software, who will be affected?
  • What job description changes are required if we install new software?
  • Are there legal ramifications for any departments?
  • Do customers need to be included?
  • Do we have any subject matter experts in the area?
  • Who will be the champions of change to influence users?
  • Who has authority in the decision making?
  • Who should be informed about the change even if it doesn’t impact their day to day?

What are the Risks of Asking the Wrong Stakeholders?

You end up paying more for features you don’t need

If you are unsure of who to ask, don’t just ask everyone. This is a knee jerk reaction befalls many, but it comes with considerable risks. If you ask stakeholders who don’t have a vested interest, you could end up with a host of costly features that don’t add any value for the intended users.

You dilute the opinion of key stakeholders

Furthermore, when it comes to ranking what is and is not a priority, you need to avoid diluting the opinion of key stakeholders. If you turn to everyone, you undermine the process of finding the right solution.

Engaging the Right Stakeholders for Your Technology Evaluations, Drives Digital Transformation

Identifying the right stakeholders for your software requirement gathering saves you time, mistakes and money. The only people that are able to help you avoid failure, are the eventual end users.

Take your time to figure out who needs to be heard. Valuing the right voices creates a compounding benefit throughout the software buying process. With the right input and validation, you guarantee a seamless implementation and high user adoption.

Once you know who they are, Olive can help you and your stakeholders collaborate and work seamlessly together to find the right solutions that drive digital transformation. Olive provides clients with libraries of requirements to choose from so you don’t risk omission or misinterpretation from vendors. Our library speaks the language of the stakeholders and vendors so there is no margin for error or disconnect. Once your team has had the chance to collaborate, select and grade the requirements together, Olive puts your opportunity out to the right vendors, through surveys, without revealing your company’s identity.  Get in touch with us to learn more.

Requirements Gathering for Software Selection

Share

Stay Updated with the Latest in Software and Technology Sourcing

Join Our Community of IT Leaders and Consultants!

Get insights, tips, offers and the latest trends in software sourcing delivered straight to your inbox. Subscribe to our blog and never miss an update.

Read Related Posts