A stakeholder is someone who is materially impacted by the outcome of the solution. In this regard, the stakeholder is clearly more than an end-user: A stakeholder could be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, maintenance professionals potentially affected by the development and/or deployment of a software project. To simplify the definition of stakeholders, we’ve adopted Outside In Software Development’s four stakeholder categories:
End users. These are the people who will use your system, often to fulfill the goals of your principals. They typically want systems which are usable and enable them to do their jobs more effectively.
Principals. These are the decision makers who ultimately pay for and then put your system to use. This includes gold owners, senior business management, and purchasers of the commercial systems.
Partners. These people make the system work in production. This includes operations staff, support staff, trainers, legal experts, installers, application hosting companies, and application developers on external systems which integrate with yours.
Insiders. These are members of the development team and people who provide technical and business services to your team. This includes enterprise architects, database administrators, security experts, network experts, toolsmiths, marketing experts, and sales staff.
So why does DAD use the term stakeholder instead of customer? Although customer is a perfectly good term, it’s very popular with agile adherents, we’ve found that many agile teams will inadvertently limit themselves to considering just end users and principals to be their customers and miss the partner stakeholders and sometimes even the insider stakeholders. Granted, you’ll often work with some insider stakeholders as a matter of course throughout the project so it’s hard to miss these people, although both of us have seen core agile teams neglect working with their organization’s enterprise architects in the name of “having the courage to worry about tomorrow’s problem tomorrow.” Our experience is that although the term stakeholder is a bit more formal than the term customer, in practice it seems to lead agile teams to a more mature strategy.
One challenge with the term stakeholder, which customer also suffers from, is that it reinforces the “them vs. us” mentality prevalent in many IT departments. When we use terms such as “the stakeholders” or “the customers” or “the business” they imply that we see ourselves as a group set apart from them. The reality is that it isn’t the business, it’s our business, that we’re all in this together. It’s important to be careful with terminology.
