Selecting the right project stakeholders for a software project comes down to four questions: who is paying, who decides, who will use the system every day, and who can stop it going live. For each you need a named person with the knowledge, the authority and the time to take part. The usual mistake is to choose by seniority, filling the room with managers who know how the work is supposed to be done and leaving out the people who know how it is really done.
A stakeholder is anyone who is affected by the system or can affect it. That is a long list on any project, so the task is selection: deciding whose input shapes the system, whose approval is needed and who only needs to be kept informed.
The stakeholders every project has
The sponsor. The person who controls the budget and wants the result. The sponsor does not attend every meeting but settles disputes that the project cannot settle itself, and protects the time of the people taking part.
The decision-maker. One person who decides what the system should do and in what order, and who accepts the finished work. In Scrum this is the Product Owner, and the Scrum Guide is blunt about it: “The Product Owner is one person, not a committee.” On a small project the sponsor and the decision-maker may be the same person. Our article on the product manager and product owner roles explains the titles.
The users. The people who will have the system open all day, and those who use it once a month. They know the exceptions, the workarounds and the steps that are not in any procedure document. If customers or suppliers will log in, they are users as well.
The people on either side. Staff who supply the information that goes into the system or depend on what comes out of it, such as finance receiving invoices or the warehouse receiving orders. Their work changes even if they never log in.
The gatekeepers. People who do not use the system but can prevent it going live: whoever runs IT and security, whoever is responsible for data protection, finance and audit where money is involved, and in some sectors a regulator. If the system will hold personal data, involve the person responsible for data protection at the start, and take advice on what your obligations are.
The people who will look after it. The internal team or supplier who will support the system after launch. They have views on how it should be built, hosted and documented that nobody else will raise.
Deciding how much to involve each one
Not every stakeholder needs a seat in every meeting. A common way to sort them is by how much influence they have over the project and how much it affects them.
| Influence over the project | Affected by the result | How to involve them |
|---|---|---|
| High | High | Work with them closely. They help decide scope and see every demonstration. |
| High | Low | Consult early, then keep them satisfied. Ask for their constraints at the start so there are no surprises at the end. |
| Low | High | Consult and keep informed. These are usually the daily users, and their knowledge is needed even though they do not approve the budget. |
| Low | Low | Keep informed with occasional updates. |
The row most often mishandled is the third. Daily users have little formal influence, so they are told about the system when it is nearly finished. They then find the gaps that could have been found in week two.
Choosing the individuals
Naming a department is not enough. “Finance” cannot come to a meeting or make a decision. For each group, choose a person, and check four things.
- They do the work. A supervisor’s account of a process is tidier than the real one. Include at least one person who carries out the task every day.
- They can speak for the group. A representative who has to go back and ask after every meeting slows everything down. Agree with their manager what they are allowed to decide.
- They have the time. Reviewing early versions, answering questions and testing takes hours each week during a build. If their normal workload is not reduced, the project gets what is left over.
- They will say what they think. Include a sceptic. Someone who doubts the project will find its weaknesses earlier and more cheaply than a go-live will.
Look for the awkward cases as well: the branch that does things differently, the night shift, the one customer with special terms. Systems designed only around the main office tend to fail at the edges.
Keep the core group small. One decision-maker, two or three user representatives and the supplier’s lead can make progress. Twelve people in a room cannot, and wider groups can be brought in for demonstrations.
What to ask of each stakeholder
Stakeholders stay involved when they know what is expected of them. Put it in writing at the start.
- Sponsor: approve budget and scope, resolve conflicts between departments, attend the main reviews.
- Decision-maker: set priorities, answer questions within an agreed time, and approve finished work against its acceptance criteria.
- User representatives: explain how the work is done today, try each early version and report what does not fit, and help colleagues when the system goes live.
- Gatekeepers: state their requirements before design starts, and confirm before launch that they have been met.
- Support team: review how the system will be run, backed up and handed over.
Involvement is not a single event. People are poor at describing what they want in the abstract and good at reacting to something in front of them, so the most valuable contribution from users comes when they are shown working software at regular intervals. Agile methods build this in. In Scrum, the Sprint Review exists so that the team and its key stakeholders can inspect what was built and decide what to do next.
Mistakes that cost the most
Finding a gatekeeper at the end. A security review or a finance control that appears a week before launch can undo months of work. Ask at the start who has to approve the system before it goes live.
A committee in place of a decision-maker. When three directors must agree every priority, decisions wait for the next meeting and the supplier builds on guesses in the meantime.
Proxies with no authority. A junior member of staff sent to meetings because nobody senior has the time can report back but cannot decide.
Ignoring the people who lose out. A new system often removes a task that someone is good at, or exposes figures that were previously private. Their objections do not go away by being left out. Our article on gathering internal support covers this.
The supplier never meets a real user. If every requirement passes through one manager, the supplier builds that manager’s understanding of the job. Insist that the people building the system watch it being used.
Forgetting who knows the old system. When an existing system is being replaced or taken over, the person who has maintained it, or used it longest, is a stakeholder. Much of what it does is written down nowhere else, which is the problem our page on software with no documentation describes.
A check before the project starts
Write a name, not a job title, against each of these:
- The one person who decides priorities and accepts the work.
- The sponsor who settles disputes.
- Two people who do the job the system supports, with time agreed by their manager.
- Everyone who must approve the system before it goes live.
- Whoever will support it afterwards.
If any line is blank, or the first has more than one name, fix that before work begins. The project planning worksheet has a section for listing each group of users and what they need to do, and our guide to kicking off a software project covers the first meeting.