Input please: How to identify the right IT project stakeholders
I'd like your input for an article I'm writing.
Let’s say you’re starting a new IT project. It could be custom software; perhaps it’s a migration to cloud services; maybe it’s a shiny new IoT project.
The point is that you're here to build something great. You’re in charge of the design (or an important part of it), and making sure that the resulting system makes everybody happy.
How do you make sure that you are interviewing the right people to find out what “make them happy” looks like? What do you do to get input from the people who matter for the project’s success… without inviting so many suggestions that it’s impossible to deliver everything?
Case in point: Ten years ago I was in charge of an online tech community. The company I worked for hired custom developers to build the software platform, but the developers never talked to me. They interviewed the boss, two levels above me (who just so happened to be the person who signed the checks) even though she had never used this online community or any other. Needless to say, the community software they delivered was horrible, missing basic-to-me features.
Formally this process would be called “identifying the project stakeholders” or “master the requirements-gathering process” but that seems too corporate-speak. I’m looking for real-world examples of what works and what doesn’t, so I can write a genuinely useful article with practical guidelines.
Note that this is NOT about the questions to ask those stakeholders; that’s another discussion. Here I am writing merely (merely!) about making sure you are speaking to the people whose input you need.
My questions:
• How do you decide which people to ask for input? In what way do you find those people? How do you know when you have everyone you should?
• How do you decide whom NOT to invite? Where do you draw the line?
• Tell me about the manner in which you learned that lesson. (The hard way. Anecdotes are good.)
• If you want to be quoted (it's good for business!) tell me (via PM) how to refer to you in the article: Name, title, company name, short company description, URL.
As a former Business Analyst, I faced this issue quite a lot. I basically looked for people who interacted with the system:
Anyone who puts information into the system in any way. This will include people who actually use the system directly, but it might also include people who supply information to the direct users. For example, a bank teller will use bank-telling software, but they're inputting data provided to them by customers who never even see the software - and the customer's experience will be influenced by what the bank teller is required to do by the system.
Anyone who gets information out of the system in any way. This will include people who extract data from the system directly, such as people who interrogate the database directly, and people who read a screen of data, and people who run reports - but it also includes anyone who receives reports from those people. If someone is running a monthly management report, they're a direct user of the system, but the manager who receives that report every month is also impacted by the system.
Anyone who will maintain the system after it's implemented. (I've never been clear on IT titles.) The system can't just be useful for users, it also has to be able to be fixed if something goes wrong, and upgraded when users' needs change. If the systems support people can't maintain the shiny new system, it won't stay useful very long.
Anyone who builds the system: developers, etc. (Again: I don't know IT titles.) These people have needs, too.
Anyone who will support people who use the system. I'm thinking primarily of IT Help Desk staff here. Especially if there's a prior system that the current system is replacing, these people will know the type of questions that users ask and problems they face - which helps you define your system's requirements.
The people who are paying for the system: now and in the future (development and maintenance often come from two separate budgets and are managed by two separate areas).
You never know when you have everyone you should. There's always someone you find out about halfway through the project, who noone saw fit to tell you about before. All you can do is minimise this issue by asking everyone you speak to about who else uses the system or interacts with their own use of the system ("Who do you get this information from, before you enter it?" "Who do you give this report to after you run it?").
I do NOT invite people just because they have a fancy title or because they shout loudly. 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?
EDIT to add more information that I thought of later.