Identify stakeholders and dynamics

Identifying the stakeholder team dynamics and organizational politics makes it easier to navigate delivery. In an ideal world, there is a single decision maker, but when working with large enterprises . . . the world is less than ideal.

For example, one of our banking clients structures their company with business and technology sections. Business owns the domain and is closest to the customer, so they identify the most valuable opportunities. Technology, on the other hand, owns funding and delivery. Pause for a moment and think about what that means for discussions about scope and spending. Because business is not accountable for spend, they push our teams to maximize the scope—gold plating, stuffing the backlog, and so on. Technology owns the budget but has no decision-making power over the business scope. This guarantees conflict and challenges with product delivery.

When working with large enterprises, group stakeholders into the following categories:

  • Sponsor: the single individual who signs the contract (typically the CIO or COO). Identifying the sponsor helps navigate not only the early phases of the onboarding but also instances where escalation is unavoidable. This is the champion, the one who needs the project to succeed most. Note: The sponsor is too high up in the organization to be involved in the project daily.
  • Primary stakeholders: the individuals who own the project and who determine scope throughout delivery. They may not control over the budget. However, they definitely need to be managed from a scope perspective. Ideally, this is a single person with the ability (and authority) to make decisions.
  • Subject matter experts: the people who have deep domain knowledge of the organization and the dependencies (business, technical, regulatory, etc.).
  • Users/customers: the heads of business lines that benefit from the product but don’t necessarily have a major say in the day-to-day delivery. They could be external users/customers who (a) have a strong opinion and (b) don’t necessarily know what they need.

Be sure to have a clear understanding of who needs the product most, what the approval and conflict resolution chains look like, what the constraints are, and any potential political landmines.

Next article
Set priorities
The Secret Source by Aurimas Adomavicius

About the author

Aurimas Adomavicius is the president and co-founder of Devbridge. When not in the trenches working with clients, Aurimas is an active speaker and writer on product design and engineering best practices.

Get in touch