A common problem I run into as an IT consultant is a reluctance of project sponsors to include all of the stakeholders in project discussions. Sponsors often cite the following concerns:
- Getting too many people involved will complicate and delay the project. Besides, the concerns of these other stakeholders are out of the scope of this project. We’ll deal with them in some future version.
- I already know the requirements so we do not need to speak with those people.
- Those key stakeholders are too busy and not available.
Indeed, there is much truth to these concerns. Speaking with stakeholders adds time to a project, their expectations might well increase scope, and it is tricky to untangle contradictory expectations. If you are going to get something done within budget, a line must be drawn somewhere. The project manager with the agreement of the sponsor must strike a balance based on costs and benefits. But in my experience, projects fail to achieve their potential more often because of the exclusion of stakeholders rather than because of the inclusion of too many stakeholders.
The definition of a stakeholder is one who has a stake in the project or its outcome. Stakeholders have expectations that must be met or in some way addressed. The more stakeholders, the more expectations. From this perspective, stakeholders are a burden. Admittedly, stakeholder management is one of the most challenging aspects of the project manager role.
But stakeholders are also valuable resources. They bring distinct perspectives, knowledge, and problem solving skills. They bring a fuller, more nuanced understanding of the problem. They help you understand what might actually work. They tell you where a project can truly add value. They help you appreciate the risks and how to mitigate them. They can find and free up resources that you need to get a project accomplished. You want them involved.
Even if you can speed up a project by excluding stakeholders, the problem is the end result. Now as I mentioned, I’m an IT consultant and a software developer by expertise. But what I deliver is not really software. I deliver a better way of doing things, new or improved business processes. And processes, at least important ones, usually cross department lines and involve stakeholders across the organization. These people are not just adapting to a new software application but a new way of doing their jobs. So what happens when the project finishes and the software is put out there. Will those people who had no input into the project actually use it and change the way they get their work done?
No, they won’t. They will tell you why the new approach will not work. In frustration, the project team will grumble that these are just irrational excuses. These luddites just do not recognize our brilliance and hard work. Unfortunately, these stakeholders, now opponents, usually have a point. By excluding these folk, you missed something and this is a really bad time to find that out. You delivered on time and on budget and met sponsor expectations but delivered a solution that does not work.
Now I’m all for the agile methodology of delivering software early and often. Yes, you should crawl before you walk and walk before you run. It is important to control scope and break big projects into pieces wherever that makes sense. None of this eliminates the need for upfront and continuous efforts at stakeholder analysis. Stakeholders must be involved in defining and prioritizing features. If the first release fails to deliver value and gain user adoption, it might not be the beginning of a spiral but rather the end of the line.
Let me point out that I’ve been grappling with this problem for over ten years with varying degrees of success. And, no, I’ve not found a silver bullet that guarantees success. But stakeholder analysis, if done well, is a very useful tool to mitigate the risk of getting the scope wrong by omitting the right people.
Here are a few approaches for discovering stakeholders:
- Review the organization chart.
- Brainstorm with known stakeholders.
- Review the scope with known stakeholders line item by line item asking who would be affected.
- Ask about the customers, internal and external, of each affected department and how they could be affected.
- Look over the stakeholder analysis charts from past projects.
- Network continuously within the organization to learn the informal power relations and meet as many potential stakeholders as possible.
- Focus early on in the business analysis on process flows and identify who performs each task, who provides the inputs, and who receives each output.
The process is iterative. Each discovery leads to more questions and more discoveries. This goes on throughout the project and it’s important to continuously update the stakeholder analysis document. Although it’s obviously preferable to know all of the stakeholders up front, late is better than too late.
Identifying the stakeholders is not enough if the sponsor is inclined to exclude them. Through the stakeholder analysis, it is necessary to build a business case for the inclusion of each stakeholder, which means documenting the potential costs and benefits of including the stakeholder and the risks of exclusion. In cases where this must be accomplished without actually speaking with the stakeholder, you will need to rely on the experience of the project team and the stakeholder analysis performed on previous projects of similar scope.
This business case for stakeholder inclusion is also useful for explaining to a reluctant stakeholder why their participation is valuable.
In the end, the sponsor may still decide to exclude certain stakeholders but by going through the exercise of stakeholder analysis you will at least be able to document the risks of doing so and have added those risks to the risk register. And you have created a document that will be of value for future projects.
Articles:
http://www.stsc.hill.af.mil/CrossTalk/2000/12/smith.html
http://www.mindtools.com/pages/article/newPPM_07.htm
http://www.softwareprojects.org/stakeholders.pdf
Templates:
Stakeholder Map: http://www.gantthead.com/deliverables/Stakeholder-Map.html
Stakeholder Interest/Influence Matrix: http://www.brighthub.com/office/project-management/media/p/3712/download.aspx
Stakeholder Analysis: http://www.gantthead.com/deliverables/Stakeholder-Analysis.html
Jim Downey 
Leave a Reply