Stakeholder management

Stakeholders are people that have a stake in the system that is designed, built,  implemented, managed and used. Stakeholders have concerns about the system and these concerns must be addressed. To manage the communication with  stakeholders a stakeholder analysis should be performed at the start of the project. This analyis comprises:

  • a stakeholder landscape
  • a ranking
  • a  stakeholder map
  • a communication plan

Stakeholder landscape
A list of stakeholders must be compiled to effectively manage stakeholders. A good way to do this is to create a visual map. Put the main system in the centre and the main components of the system around it. For each main component define the roles, like the business owner, the user, external parties, and the system  manager. Then define the actual persons working in these roles.

Ranking the stakeholders
When the stakeholder landscape is clear, a list of the stakeholders can created. All stakeholders are categorized based on their interest to the project and  the  influence they have on the success of the project. Most project leads to changes in both the IT landscape and (often) the business processes and therefore to concerns of the stakeholders. For every stakeholder their concerns are weighted and given a number  between between one and three. This number is called interest. One is low interest for this stakeholder. An interest of three shows a the project brings many, or complex  changes to the stakeholder.

Some stakeholders have more influence on the project than others. This influence is also ranked between one and three. One means the stakeholder is  considered to have very little influence on the project or the solution being built. An influence of three means the stakeholder has much power to resist or  support the project or solution.
Based on the ranking for all concerns, an average is calculated per stakeholder.

Stakeholder map
In this stage noth the interest and the influence are ranked either high or low per stakeholder.Communication planWhen the stakeholders are ranked, they are caracterised using the following stakeholder map.

2015-10/stakeholder-map.jpg


The stakeholder map classifies all stakeholders in four groups:

Weight Communication strategy
Explaination
Low interest, low influence Occasionally Contact These are relatively unimportant  stakeholders, but keeping in touch with them  is a good idea,  just in case their status  changes.
High interest, low influence Keep Informed These stakeholders are easy to ignore as  they apparently cannot derail the project,  although if sufficiently upset they may gain  influence by low-level blocking and other  techniques of resistance to the project. Do  remember that minorities can be very  powerful, particularly if they work together  or if they get powerful allies.
Low interest, high influence Keep Satisfied Stakeholders with a low interest in the  project will not be particularly worried it, so  are not too much of a problem in the actual  project. A problem can appear when they are  persuaded to act for those who oppose the  project. It is thus important to keep them satiesfied, for example with regular meetings that explain what is happening.
High interest, high influence Actively Engage These stakeholders are both  significantly  affected by the project and most able to do  something about it, either by  supporting or by opposing the project. It is particularly  important to engage these  stakeholders in the project, ensuring that they  understand what is going on and  also  to create buy-in as they feel a sense of  ownership of what is being done.


Based on the classification of the stakeholders a communication plan must be created.  In the communications plan the stakeholders and the frequency and  type of contact per  stakeholder are listed. This way it is ensured that the stakeholders get the attention they  need and deserve.

Communication plan
At the beginning of the project individual interviews should be held by the architect and the relevant project members with  the high interest, high influence  stakeholders. This opens up communication channels between the architects and the most important stakeholders, enabling smooth communications in the  future. In the interviews the interests of the stakeholders are discussed and arrangements are  made about the frequency and form of future  communications. It is always a good idea to have the follow-up stakeholder discussions with multiple stakeholders  in one room. This not only saves time for the project team, but also  opens up  communications between the stakeholders about the project. It is not unusual that the stakeholders never exchangeds ideas and concerns amongst each other. In such a setting conflicting concerns can often be cleared up easy and early.

It is important for the architect to address all stakeholders’ concerns, even if it means  that concerns might not be mitigated. Addressing the concerns of all  stakeholders must  be done during the full project life cycle, as during the project new concerns will arise. This  is perfectly normal as all stakeholders get  more insight in the results of the project and  as business continues to move forward during the project's life span. These new concerns must be  handled in the same way as  the original concerns.

Typically, only when the stakeholders feel their concerns are taken care of and get serious attention, they are willing to support the project.


This entry was posted on Friday 06 November 2015

Earlier articles

Infrastructure as code

My Book

DevOps for infrastructure

Infrastructure as a Service (IaaS)

(Hyper) Converged Infrastructure

Object storage

Software Defined Networking (SDN) and Network Function Virtualization (NFV)

Software Defined Storage (SDS)

What's the point of using Docker containers?

Identity and Access Management

Using user profiles to determine infrastructure load

Public wireless networks

Supercomputer architecture

Desktop virtualization

Stakeholder management

x86 platform architecture

Midrange systems architecture

Mainframe Architecture

Software Defined Data Center - SDDC

The Virtualization Model

What are concurrent users?

Performance and availability monitoring in levels

UX/UI has no business rules

Technical debt: a time related issue

Solution shaping workshops

Architecture life cycle

Project managers and architects

Using ArchiMate for describing infrastructures

Kruchten’s 4+1 views for solution architecture

The SEI stack of solution architecture frameworks

TOGAF and infrastructure architecture

The Zachman framework

An introduction to architecture frameworks

How to handle a Distributed Denial of Service (DDoS) attack

Architecture Principles

Views and viewpoints explained

Stakeholders and their concerns

Skills of a solution architect architect

Solution architects versus enterprise architects

Definition of IT Architecture

What is Big Data?

How to make your IT "Greener"

What is Cloud computing and IaaS?

Purchasing of IT infrastructure technologies and services

IDS/IPS systems

IP Protocol (IPv4) classes and subnets

Infrastructure Architecture - Course materials

Introduction to Bring Your Own Device (BYOD)

IT Infrastructure Architecture model

Fire prevention in the datacenter

Where to build your datacenter

Availability - Fall-back, hot site, warm site

Reliabilty of infrastructure components

Human factors in availability of systems

Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)

Performance - Design for use

Performance concepts - Load balancing

Performance concepts - Scaling

Performance concept - Caching

Perceived performance

Ethical hacking

The first computers

Open group ITAC /Open CA Certification

Sjaak Laan


Recommended links

Ruth Malan
Gaudi site
Byelex
XR Magazine
Esther Barthel's site on virtualization


Feeds

 
XML: RSS Feed 
XML: Atom Feed 


Disclaimer

The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.

 

Copyright Sjaak Laan