This is the third in a series of posts that began with “How to Capture Software Requirements Using Story Roadmaps”. The focus of this post is stakeholders.
The importance of stakeholders in any enterprise software project cannot be overstated. Let me say that again … The importance of stakeholders in any enterprise software project cannot be overstated.
What is a stakeholder? In the context of software projects, we are interested in business people who have an interest in the project. Stakeholders care about project outcomes. They want the project to succeed. If your project has no stakeholders, why are you bothering? No one cares!
Another group that I’ll include as stakeholders is end users — the people who use the software. For internal IT projects, stakeholders and end users often overlap. For customer-facing software, they are different groups though someone in the stakeholder group needs to be the voice of the customer. Ideally, customers will be directly involved in the project as there is no substitute for customer feedback.
Of course, stakeholders and customers don’t always agree amongst themselves. They may not agree on what the software must do or what platforms it must support. That’s okay. It’s the Product Owner’s responsibility to sort out the differences and determine what really matters.
One additional and critically important stakeholder is the executive sponsor. This person is a fairly senior executive in the company, usually a vice president. She can obtain funding for the project, marshal resources, and clear roadblocks. Major initiatives require executive sponsorship. Don’t start an enterprise project without one.
Can you identify the stakeholders for your project?
A key metric for stakeholders is their level of engagement. It’s not enough to say “Oh, sure. I’ll participate.” Stakeholders need to contribute. They need to be involved in the project early and stay involved throughout. They need to display genuine enthusiasm for the team’s efforts.
Stakeholders will relate to the project goals. Don’t be bashful about wording goals in such a way that they target specific stakeholder types. It’s all part of building support for the project. The stakeholders will often self-select themselves by virtue of expressing an interest in the project outcomes.
The user story roadmap is beginning to take shape. We have Goals and Stakeholders. In the next post, I’ll discuss Needs.
photo credit: francistoms via photo pin cc
[The next post in this series is available here.]