Project Management

Stakeholders over Customers

From the Disciplined Agile Blog
by , , , , , , ,
#ChooseYourWoW | #ContinuousImprovement | #Kaizen | #ProcessImprovement | Adoption | agile | Agile certification | agile transformation | Analogy | Architecture | architecture | book | Business Agility | Certification | Choose your WoW | CMMI | Coaching | Collaboration | Compliancy | Configuration management | Construction phase | Context | Continuous Improvement | COVID-19 | Culture | culture | DAD | DAD discussions | DAD roles | Data Management | database | DevOps | Discipline | disciplined agile delivery | Documentation | DW/BI | Enterprise Agile | Enterprise Architecture | Enterprise Awareness | Essence | estimation | Evolving DA | Experiment | Financial | GDD | Geographic Distribution | global development | Goal-Driven | goal-driven | goals | Governance | Guideline | Improvement | inception | Inception phase | Large Teams | layer | Lean | Lifecycle | lifecycle | Metrics | mindset | News | News and events | Non-Functional Requirements | non-functional requirements | Operations | Outsourcing | People | Philosophies | Planning | PMI | PMI and DA | Portfolio Management | Practices | Principle | Process | process improvement | Product Management | Product Owners | Program Management | Project Management | Promise | quality | Release Management | Requirements | requirements | Reuse Engineering | Risk management | RUP | Scaling | scaling | scaling agile | Scrum | serial | Support | Surveys | Teams | Technical Debt | Terminology | Testing | testing | Toolkit | Transformation | velocity | Workflow | show all posts

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk

Recent Posts

The Four Layers of the Disciplined Agile Tool Kit

The Disciplined Agile Foundation Layer

The Team Lead Role: Different Types of Teams Need Different Types of Leaders

Disciplined Agile is a Hybrid

HONESTY


Categories: People, Stakeholders


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Posted by Scott Ambler on: July 02, 2013 01:09 PM | Permalink

Comments (0)

Please login or join to subscribe to this item


Please Login/Register to leave a comment.

ADVERTISEMENTS

"Too many pieces of music finish too long after the end."

- Igor Stravinsky

ADVERTISEMENT

Sponsors