Have you ever been to a meeting that involved a dozen or more people, that constantly went too far into the weeds, that couldn’t come to a consensus, and that left you feeling like nothing was accomplished? It was horrible, right? You probably never want to have that experience again.
This kind of frustrating situation can quickly become the theme of a software project when too many stakeholders are involved and nobody has clear decision-making power. If multiple people within an organization have to be consulted for every decision, projects quickly grind to a halt.
While stakeholder gridlock is frustrating for everyone, it’s also very costly when it involves custom software. In fact, it’s one of the risks we consider in our pre-project consulting process.
Software development teams are expensive. If you want to make your deadline and stay on budget, your team can’t afford to wait around while everyone in your organization weighs in on the software’s functionality.
In the absence of clear direction, a team might have to make assumptions and move forward with the best information they have. Then if more feedback comes in later, rework can pile up, increasing costs and extending timelines. In short, nobody will be happy.
What the Ideal Stakeholder Team Looks Like
I’ve worked with a lot of clients, and the most effective stakeholder teams share a few key characteristics. Each team had five or fewer stakeholders who all worked well together. They showed up diligently to meetings and set aside time in their schedule to dedicate to the project. And each person on the team had clearly-delineated responsibilities and was an empowered decision-maker within their organization.
On a team like this, there is one person who is ultimately in charge. Sometimes we call them the “key stakeholder.” If a decision can’t be reached, or if a team member isn’t holding up to his or her commitments, this person will make the tough calls and hold the rest of the team members accountable.
How to Pare Down the Team
You might say, “But my project is huge! There’s no way a team of five stakeholders could make it happen.”
In complex organizations and projects that span multiple departments or areas of concern, it can be challenging to narrow down the stakeholder team. However, I’ve found that focusing the team to the essentials will increase, not decrease, the project’s chances of success.
It’s time to stop inviting everyone to every meeting. Instead, nominate several people representing key areas of the business, and ask them to serve as the stakeholder team for your software project. They can work together to make decisions for the project, seek input from specific colleagues when it’s necessary and relevant, and report back to the larger group on a regular basis.
They also have the responsibility and authority to decide how to move forward, so the development team can stay unblocked. They are kind, but firm, to colleagues whose ideas may need to be de-prioritized in order to ensure the success of the entire project.
Put an End to Gridlock
If your organization is encountering the pain points I’ve described above, maybe it’s time to take a step back and re-assess how you are engaging with your software team.
Then decide and communicate to everyone involved who will be the key stakeholder–the tiebreaker when a decision can’t be made. As you move forward, it may take time for people to become used to their new roles and way of working. But if you stick with it, you’ll start to see project success.
And really, who doesn’t mind having fewer meetings to attend?