Skip to main content
Exploring what’s next in tech – Insights, information, and ideas for today’s IT leaders

How to identify the right IT project stakeholders

You need to develop software requirements before you get started. But are you getting input from the right people? Here’s how to know.

Embarking on any new IT project is always exciting, and especially so when it means using genuinely innovative technology. Perhaps your business is ready to begin a shiny new IoT deployment, an artificial intelligence pilot that could change the company’s direction, or a migration to cloud services.

Every "digital transformation" guidebook suggests that during the design phase, the transformers—that would be youshould meet with stakeholders. In the requirements-gathering process, the goal is to identify what stakeholders need so that everyone’s heartfelt desires are met. Even when your new project is relatively mundane, you want the resulting system to make everybody happy.

However, the first step of meeting with stakeholders is finding those stakeholders—and that’s not as simple as it seems. Too often, those meetings are with the wrong people, or too few of the right ones. When the project is delivered, it doesn’t address users’ practical needs, it fails to collect the data necessary for managers to make good strategic decisions, or it has another “obvious” omission.

Or, as software tester Michael Bolton says, “Lack of stakeholder involvement is arguably a factor in every bug that is not due to a coding error—and coding errors are in the minority.”

How do you make sure that you are interviewing the right people to find out what “makes them happy” looks like? And how do you accomplish that without inviting so many suggestions that it’s impossible to deliver everything? I asked experienced experts to help compile practical guidelines.

Note that I do not address the questions to ask in those meetings or how to encourage stakeholder participation; optimizing software requirements gathering is another discussion. I start with the simplest task: Making sure you interview the right people.

Yes, it’s a problem

Ten years ago, I was put in charge of an online community. My company hired developers to customize a community platform. Yet, the developers never talked to me; they only interviewed the boss, two levels above me. She had never used this or any other online community. She was, however, the person who signed the checks. Needless to say, the community software they delivered was horrible, missing basic-to-me features.

And that was for a predictable use case. Online communities have existed since at least the 1970s, and the message board feature list is well understood (though rarely by web developers, as I recognized in 2000). In other words, that path has been trod before.

However, getting accurate stakeholder input is even more urgent when you are doing something truly new. For example, an urban community trying to design a smart city can be brought down by making wrong IoT, infrastructure, or data privacy assumptions.

Missing the mark is painful, embarrassing, and expensive. For example, one developer spent six weeks coding a data overlay based on imagery. But the morning after deployment, he discovered that his algorithm didn’t take into account the input from two scientists in the Southern Hemisphere. “I’d only asked colocated scientists, for whom ‘north is up’ was natural,” he explains.

Alan Zucker, founding principal at Project Management Essentials, learned the hard way to include production operations and technology support. “Once, we decommissioned an old accounting platform and replaced it with a shiny, brand new one” that promised to save lots of money and require less finance and technology support. One difference was that the old application ran the accounting at month end, but the new application closed the books every day. “No one had considered that production support costs were based on the number of processes executed, so the costs of running this application ballooned,” says Zucker.

Start with the project sponsor

Whether you’re company staff or an outside consultant, there’s usually someone who ultimately signs off on the project completion. In most cases, it’s easy to identify that individual. Who's paying for the project? Who has veto power? Whose bonus depends on the software working or on its successful delivery? You probably know the answer.

Some IT professionals stop there. One consultant named Wallace opined that the only stakeholder that really matters is whoever brought you in and OKs your payment. “Everyone else is to be given a light touch. Take their input with a grain of salt…. You can’t please everyone, so don’t try.” (I bet he worked on that online community board project. Yes, I hold grudges.)

Fortunately, most serious IT professionals know that successful projects reflect the needs of more than the person with the checkbook.

The State of Hiring: Learn how 101 IT execs find staff for critical positions.

The types of stakeholders are described in several ways, but a good working model are the three categories used by Matt Koopmans, director of the Aurelian Group consultancy:

  • Product owners or sponsors: the people making the investment to receive the benefits. They provide input to what needs to be achieved, the outcome of the project, and the value that represents.
  • Users and delivery team: the people affected by the delivered product. Users provide insight into how the goals can be achieved and work efficiently.
  • Peripheral stakeholders: people with an interest or stake that isn't significant, such as other employees, vendors, and customers.

The peripheral stakeholders should be kept informed and invited to product demonstrations, Koopmans says. However, he cautions, “Any feedback needs to go via a feedback process to the product owner, not the delivery team.” He informs customers and vendors when the project affects them and (for important vendors or customers) provides a time frame for them to work with the team to make changes.

Users, schmoozers

Users have subcategories as well. Eric, a former business analyst, looks for input for anyone who interacts with the system. He advises that you interview or at least consider the needs of:

  • Anyone who puts information into the system. Beyond the people who directly use the system, consider those who supply them with information. Bank tellers use a dedicated application, but their data comes from customers who never see the software. “The customer's experience will be influenced by what the bank teller is required to do by the system,” says Eric.
  • Anyone who gets information out of the system. Begin with the people who extract data directly, such as those who run reports or interrogate the database. Then consider who receives reports from those people, such as managers who receive a monthly management report.
  • Anyone who works on the system. What do the developers, database managers, or network analysts need?
  • Anyone who supports people who use the system. If the new application replaces a previous system, the IT help desk staff are an important resource. They know the problems users face and the questions they ask.
  • Anyone who holds the purse strings. Of course the people who pay for the system, both now and in the future, must be consulted. Development and maintenance often come from two separate budgets and are managed by two separate areas.

In general, try to involve a good cross-section of those users during your design phase. In a smaller business, talk to those using the system the most. However, one corporate consultant I’ll call Kelly advises, “If it's something narrow in scope, like a new server cluster or something that only a few people will directly touch, a senior representative from that team and maybe his or her deputy will be sufficient.”

Think about expertise, as well. Categorize users as novice, intermediate, and power users, says Bret Carmichael, founder of Leapworks, which provides agile software development coaching. The novice and power users are most valuable for project planning, he says—particularly the former. Novice users have questions about basic capabilities and terminology and may report working functionality as bugs due to their lack of experience. (That can help you determine UI baselines, at least.) “Conversely, power users will employ workarounds to extend a product’s capabilities beyond its current scope,” Carmichael adds.

Then consider corporate oversight. “Do you have security and compliance objectives?” asks Carmichael. Reach out to those teams, he advises. “Don’t wait for them to come to you. The result of excluding them will be rework and expense,” he adds.

However, don’t get bogged down with the oversight roles. Only include individuals who have influence and authority throughout the project’s entire lifecycle. “While other individuals and teams have critical input and may serve as an approval gate for a particular portion of the project (networking, security, etc.), they are only responsible for their functional areas and should not be included in the key stakeholders,” says Marcus Bearden, executive director for cloud enablement at 2nd Watch.

Which individuals? Ask.

Nearly everyone suggests that the best way to find the “right people” is to ask the sponsor. And then ask each person you interview, “Who else?”

“You never know when you have everyone you should,” says Eric, the business analyst. “There's always someone you find out about halfway through the project.” To minimize the issue, he suggests, ask everyone you interview, “Who else uses the system?” For example, "Who do you give this report to after you run it?"

Don’t be afraid to ask. If a consultant asked you questions you couldn’t answer, you wouldn’t hesitate to respond, “I need to loop in Kendra; she's the expert on that." If you're the point person and you’re asked, "Should we involve anybody else from your team?" you probably know if the answer is yes or no. “I've asked and been asked that question countless times and never had an issue with it,” adds Kelly, the corporate IT consultant.

In some circumstances, you’re still not done. Finding functional influencers can be “as simple as asking the project sponsor, as direct as asking multiple team members who the innovators are in their group, or as complex as watching and listening for whom the team defers to for technical guidance,” says Bearden.

If that seems like a lot of people to invite to a meeting, it is. To streamline the process, remain mindful of everyone’s time and avoid decisions by committee. Consultant Sarah Cummings has learned to use a small group to get the basics right. “Bring together your core project team—usually the product owner, project manager, business analyst, and any already-identified key subject matter experts,” she says.

In that meeting, clearly define the problem you are solving and outline your working hypothesis of the solution and any stages. Then, says Cummings, create a list of the stakeholders and the role they play at each stage, using a RACI model.

At that point, Cummings is ready to invite others to participate. She does so with a 20-minute town hall meeting for the direct managers who are expected to have input. The project team walks through the information gathered, confirms its assumptions, and asks managers to nominate a contact person for the project. Then the real work can get underway.

“By keeping the meeting short, you are more likely to get everyone to turn up (particularly helpful if senior management back this process) and still have enough time to articulate the purpose of the project and benefits to the business,” Cumming says. “The second, happy unintended side effect is that everyone across the business has more buy-in to the project even if they aren’t directly involved, as they feel included.”

Draw the line somewhere

Certainly, you want to get input from everyone who can help—and avoid the rest. “The net of project stakeholders should be cast as wide as possible,” says Zucker. “Include everyone and all groups that you can think of. You can sort and prioritize requirements later.”

To a point.

“I do not invite people just because they have a fancy title or because they shout loudly,” says Eric. “The only people who get to have their say are the people who use the system (either upstream or downstream) or work with it or pay for it. If there's no connection between someone and the system... why am I wasting my time talking to them?”

Bearden has been on projects with upwards of 10 stakeholders. “When it came time to make decisions, everyone looked at the rest of the room. And once someone did attempt to make a decision, it was nearly impossible to reach consensus.” To narrow down the list of stakeholders, he learned to ask:

  • Can the project be successful without the explicit approval of someone not included in this group? If not, talk to the existing organizational leader to determine the best path forward.
  • Do organizational dynamics require the inclusion of someone outside of the identified group of stakeholders? While not ideal, sometimes this cannot be avoided. So rather than fight it, embrace it and work to make that person a project evangelist.

Or just go for the “Who really helps?” approach. IT project manager Max Ddos works regularly with the same people at his company. “As I know my colleagues, I always avoid asking those persons with the ‘my glass is always half empty’ attitude,” he says.

When bad stakeholders happen to good project managers

Things don’t always go well. Sometimes, despite your best efforts, you don’t get access to the right people, and the system you build reflects the lack of knowledge. That’s especially so when you are an outsider with little control or influence.

The best option is to build the lack of information into your design process. For example, one freelance programmer, working mostly as a third-tier subcontractor doing UIs for AV systems, has learned to put a design narrative requirement in contract assumptions “so we don’t have to totally redo our work when the client finally sees it.”

Another developer, working on a custom project for a niche industry, encountered a client who was adamant about the project requirements—except the developer, with far more experience, knew the stakeholder was wrong. As a fourth-tier subcontractor, contacting the client directly is verboten; it’s often necessary to rely on backdoor communication with the design consultant. “So the best we can do is write our contract such that when the client inevitably asks for changes, we can at least get paid for it.”

Ultimately, keep your eye on the prize. “A major reason for project failure is that smart technical people have the wrong concepts of their job. They believe that they are designing a system and features to do something,” says Greg Githens, author of “How to Think Strategically.” “The better approach is that they are designing a tool to help a user get a job done, and they need to understand what that job is.”

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.