Stakeholder Management

Any project has many implications to many people - hence there are many stakeholders, who can influence the project in either way. Stakeholder management is an important discipline for a successful architect. That is important to ensure the project has the required support and backing through its life.

The technique should be used during Phase A to identify the key players in the engagement. It should be referred and updated throughout each phase of the ADM cycle. The output of this process forms the start of the Communications Plan.

Identifying Stakeholders

Identifying the stakeholders is the most important part of stakeholder management. TOGAF standard guides us with this task. It provides a list of most likely stakeholders for any architecture project.

Corporate Functions

  • CxO
  • Enterprise Security
  • Program Management Office
  • QA/Standards Group
  • Procurement
  • HR

End User Organization

  • Executives
  • Line Management
  • Business Domain Experts
  • Data Owners

Project Organization

  • Executives
  • Line Management
  • Business Process / Functional Experts
  • Product Specialists
  • Technical Specialists

System Operations

  • IT Service Management
  • Service Desk
  • Application Management
  • Infrastructure Management
  • Data/Voice Communication


  • Suppliers
  • Regulatory Bodies

Stakeholder Analysis

There are too many stakeholders for any project. We cannot and should not try to appease each of them. Stakeholder analysis helps us identify the ones that are important and worth our time and attention. Further, it helps us classify them to identify different ways of dealing with each.

Stakeholder analysis requires evaluating the stakeholders on different parameters:

  • Ability to Disrupt
  • Current Understanding
  • Required Understanding
  • Current Commitment
  • Required Commitment
  • Required Support

Along with this, we need to identify the stakeholders based on the grid of Interest and Power. Based on this, we can identify the approach for working with any given stakeholder

  • High Power, High Interest => Core group. Focus on them
  • High Interest, Low Power => Keep Informed
  • High Power, Low Interest => Keep Satisfied
  • Low Power, Low Interest => Ignore(?)

The architect should identify individual artifacts that need to be produced and validated with each stakeholder group. This helps communicating the architecture to all the stakeholders; and ensure it is understood by all the stakeholders. It helps them verify that the Enterprise Architecture initiative will address their concerns.