Practical Stakeholder Engagement

Practical Stakeholder
Engagement
John Sherwood
COSAC 2014
© The SABSA Institute 1995 - 2014

1
Objectives for this Session
l  Use this session as a workshop
l  Present some ideas
l  Discuss the ideas
l  Capture new ideas
l  Recruit a team to take the work forward
l  Develop a white paper by iterating and critiquing drafts
l  Publish the White Paper under The SABSA Institute with
joint authorship
Creating a New White Paper
© The SABSA Institute 1995 - 2014

Action
l Appoint a scribe to capture the ideas
l Can be more than one scribe
© The SABSA Institute 1995 - 2014 2

Agenda
l  Stakeholder context – theoretical models
l  Step-by-step stakeholder engagement process
l  Stakeholder identification: viewpoints and views
l  Stakeholder intake – getting them on board
l  Stakeholder consultation – psychological factors
l  Stakeholder analysis
l  RACI mapping
l  Concerns, prioritisation
l  Input validation
l  On-going stakeholder engagement
l  Internal publication
l  Open discussion – how best to engage with stakeholders

STAKEHOLDER CONTEXT
Theoretical Foundations for Systems, Services and Stakeholders

System of Interest Concept
System Environment
System of Interest
Opportunities
& Threats
Strengths &
Vulnerabilities
Logical System Boundary
(not physical)
External Stakeholders with an Interest in the System
Internal Stakeholders
that are part of the System
System means
a combination
of people,
processes &
technology
Stakeholders
can be both of
these
Stakeholders can
be both of these

ISO/IEC/IEEE 42010: Meta Framework
l  Standardisation of Terminology and Language for Architecture Work
l  Conceptual Foundations for Architecture Work
l  Conceptual Model – Architecture Description
l  Conceptual Model – Architecture View
l  Conceptual Model – Architecture Viewpoint
l  Conceptual Model – Stakeholders and Concerns
l  Conformance to ISO/IEC/IEEE 42010
l  Architecture Description
l  Architecture Viewpoint
l  Architecture Framework
l  Architecture Description Language
Systems & S/W Engineering: Architecture Description

System of
Interest
Architecture
exhibits
⏏
identifies
⏏
Stakeholder
Concern
1 1
1
n
has interests in⏏
has
⏏
n
n
Architecture
Viewpoint
Model Type
Architecture
Description
Architecture
View
Architecture
Model
identifies
⏏
expresses⏏
1
1
1
1
1
1
n
n
frames⏏
represents⏏
n
n
n
n
n
n
nn
n
n
n1
governs
⏏
governs
⏏
conforms to
⏏
conforms to
⏏
represents⏏
populates⏏
1
n
42010
Conceptual
Model

System of
Interest
Architecture
exhibits
⏏
identifies
⏏
Stakeholder
Concern
1 1
1
n
has interests in⏏
has
⏏
n
n
Architecture
Viewpoint
Model Type
Architecture
Description
Architecture
View
Architecture
Model
identifies
⏏
expresses⏏
1
1
1
1
1
1
n
n
frames⏏
represents⏏
n
n
n
n
n
n
nn
n
n
n1
governs
⏏
governs
⏏conforms to
⏏
conforms to
⏏
represents⏏
populates⏏
1
n
Our focus
today
E.g.:
Business
Attributes
Profile
Requirements
People,
processes,
technology and
environment
From which the
stakeholder
views the world
E.g.: Detailed
Attributes
Ideas and
concepts
(knowledge)
Documented
concepts
(information)
What the
stakeholder
sees

System of
Interest
Architecture
exhibits
⏏
identifies
⏏
Stakeholder
Concern
1 1
1
n
has interests in⏏
has
⏏
n
n
Architecture
Viewpoint
Model Type
Architecture
Description
Architecture
View
Architecture
Model
identifies
⏏
expresses⏏
1
1
1
1
1
1
n
n
frames⏏
represents⏏
n
n
n
n
n
n
nn
n
n
n1
governs
⏏
governs
⏏conforms to
⏏
conforms to
⏏
represents⏏
populates⏏
1
n
WHAT
WHO
&
WHY
HOW,
WHERE
&
WHEN
Assets
BAP as
Proxy-Assets

SABSA Asset Ownership, Custody & Use
l  Although in one sense assets are owned by the
enterprise, each asset must have a specific
person assigned as the ‘owner’
l  An owner is empowered to make decisions
about the asset:
l  How much is it worth?
l  How should it be used and by whom?
l  What risks does it face and how should these risks be
treated?
l  Sometimes (often) an owner delegates the
looking after and management of an asset to a
‘custodian’
l  Usually an owner allows (authorises) other
people to use the asset. These people are
called ‘users’
Owner
Custodian
User
Delegates
Authorises
Manages use
according to
authorisations

Everything as a Service (EaaS)
l  Supply & demand model
l  Stakeholder Types
l  Stakeholders are service owners
(service providers)
l  Stakeholders are service
custodians (service providers)
l  Stakeholders are service users
(service consumers)
Infrastructure+as+a+Service+(IaaS)+
Pla3orm+as+a+Service+(PaaS)+
So6ware+as+a+Service+(SaaS)+
Business+Services+
Business+Processes+
Business+Value+Chains+
People,+Skills+and+Competencies+
Support+Processes+and++Services+

STAKEHOLDER ENGAGEMENT
PROCESS
Step-by-Step Process

Stakeholder+engagement+process+
Stakeholder+iden3ﬁca3on+
Stakeholder+intake+
Stakeholder+consulta3on+
Stakeholder+analysis+
Stakeholder+input+valida3on+
Regular+stakeholder+consulta3ons+
along+the+project+3meline+
Internal+publica3on+
of+the+business+analysis++
Project+board+
Architecture+board+
GOVERNANCE
ENGAGEMENT

Governance: Project Board
l  To provide representation of the stakeholder community
l  To provide project steering
l  To monitor the progress of the project against the aims and
objectives set through the stakeholder engagement and
business analysis process
l  To ensure compliance with stakeholder requirements
l  To provide feedback on evolving business requirements
l  To ensure that the stakeholder community is kept informed of
any major issues that might affect the success or outcome of
the project

Governance: Architecture Board
l  The purpose of the architecture board is to ensure that architectural standards are
set and that all projects comply with these standards. Specific objectives include:
l  Creation and publication of architecture standards
l  Architecture development processes
l  Reference architectures
l  Maintaining and publishing the architectural artifacts repository
l  Maintaining and publishing the service catalogue for project use
l  Creation and publication of architecture governance processes
l  Project submission process
l  Project approval process
l  Stakeholder engagement process
l  Ultimate control and approval of project budget release
l  Conditional on architectural standards compliance
l  Conditional on compliance with stakeholder requirements

STAKEHOLDER IDENTIFICATION
Finding the Stakeholder Viewpoints and Views, Roles & Responsibilities

Stakeholder Viewpoints
l  Lifecycle viewpoints
l  Strategic, programme, project, operational
l  Functional viewpoints
l  Business Management, Compliance, Information Management,
Systems Design, Financial Management, Health & Safety; Human
Resources Management, etc…
l  Industry Viewpoints
l  Nuclear Industry, Civil Aviation, Pharmaceuticals, Banking and
Finance, Energy Distribution, Retail, etc…
l  Legislative and Regulatory Viewpoints
l  Food Safety, Transport Safety, Health and Safety at Work, Crime
Prevention, Controlled Drug Use, Building Regulation, etc…

Stakeholder Types
l  Internal stakeholders:
l  Business owners
l  Internal Auditors
l  Quality Managers
l  Risk Managers
l  Delivery Managers
l  Application Managers
l  Infrastructure Managers
l  Security Managers
l  Data Managers
l  Architects
l  Development Managers
l  Others as dictated by the
specific context
l  External stakeholders:
l  Customers
l  Service Suppliers
l  Equipment vendors
l  External auditors
l  Others as dictated by the
specific context.

STAKEHOLDER INTAKE
Bringing the Stakeholder Community On-board

Intake Requirements
l  Making contact with each stakeholder
l  Selling the project and obtaining their buy-in and support
l  Creating stakeholder commitment
l  Arranging the logistics of how they will participate

Creating Stakeholder Commitment
l  An initial meeting / workshop is used to kick-start the commitment of
project participants. This will need to be refreshed from time to time.
l  Regular informal dialogues and a regular progress meetings on a
periodic basis are used to attain the commitment of key stakeholders.
l  Commitment of key stakeholders should be maintained by keeping
them informed of all current matters.
l  The governance framework, comprising the Stakeholder Engagement
Process, the Architecture Board and the Project Boards is also a key
mechanism for maintaining and strengthening stakeholder
commitment.

Getting the Right Stakeholders
l  Making the approach to stakeholders
l  Selling them the ideas
l  Gaining their commitment, sponsorship and enthusiasm
l  Setting up the steering group (Project Board)
l  Arranging meetings and workshops
l  Dealing with political sensitivities
l  Seniority versus expert knowledge
Let’s discuss: How should we do this?

STAKEHOLDER CONSULTATION
The Real Engagement: Psychological Factors

The Importance of Language
l  Negative Terminology
l  Threat
l  Vulnerability
l  Prevent
l  Loss
l  Impact
l  Mistrust
l  Uncertainty
l  Positive Terminology
l  Opportunity
l  Strength
l  Enable
l  Gain
l  Benefit
l  Trust
l  Assurance
Neuroscience tells us to think positive: it will make you feel better
Get your stakeholders to think positive: they will feel better too
Neuroscience: Nominalisation – How the Human Brain Works
We are hard-wired to ‘feel’ before we ‘think’. Emotions precede thought by about 8 milliseconds

Objectives for Stakeholder Engagement
l  ‘Engaging with’ - not ‘Managing’ the stakeholders
l  Relationship development
l  Hearing stories
l  Gathering and documenting information (the role of the scribe)
l  Validating inputs
l  Increasing stakeholder commitment

‘Them & Us’ or ‘We’
l  Social engagement – we’re all people (social animals)
l  Let the meeting settle in
l  Degrees of Intimacy versus Formality
l  Arranging the seating for a meeting
l  Team Building
l  Relationship Building (investment of time)
l  Leadership Styles
l  Power Games and Politics
l  Observer or player?
l  Chance Encounters – the ‘Elevator Pitch’

Presentation Styles
l  Failing to plan is planning to fail
l  Plan for unexpected outcomes
l Previous meeting overruns – giving the ‘short version’
l Overlap with previous presenters – ‘stakeholder boredom’
l  Eye contact and body language
l  Telling the story:
l  Tell them what you’ll tell them,
l  Tell them
l  Tell them what you told them
l  Avoid information overload
l  Aim only at areas of interest to the stakeholder(s)
l  Simple key messages, well structured
l  Most important messages first – to get engagement
l  ‘Talking the Talk’ versus ‘Death by PowerPoint’

Problem Stakeholders
l  Technical geeks who think they understand the business without
consulting the business people
l  Business people who think they understand the technology without
consulting the technologists
l  “I need encryption” or “but it’s encrypted so everything is OK”
l  Stakeholders who feel threatened by change: job security, status, etc.
l  Architects who live in ivory towers
l  Conflicting stakeholder views requiring resolution
l  Inconsistency in project approval processes depending on random
allocation of individuals
l  Self-important bureaucrats who seek power by blocking progress
l  The security geeks who see themselves as policemen
l  Auditors with checklist mind-sets
l  Project managers who think they are subject matter experts

STAKEHOLDER ANALYSIS
Analysing gathered information

Objectives
l  Analysis of stakeholder inputs (stories)
l  Cross-reference between inputs of various stakeholders
l  Creation of business drivers, critical success factors (CSFs) and user
stories
l  Prioritization of business drivers, CSFs and user stories
l  Analysis of project risks such as:
l  Resource shortages
l  Untried new technologies being considered
l  Cultural changes required for project success
l  …etc.

RACI Modelling
l  A RACI Matrix is widely used to describe the roles and responsibilities
of various teams or people in delivering a project or operating a
process.
l  It is especially useful in clarifying roles and responsibilities in cross-
functional/departmental projects and processes.
l  The acronym stands for:
l  Responsible
l  Accountable
l  Consulted
l  Informed
The RACI Matrix is a tool for assigning responsibility types to roles

RACI Matrix Explained
l  Responsible (R)
l  The person or team that perform the tasks to achieve the objectives
l  There may be multiple resources that are responsible for delivery of
these outputs
l  Accountable (A)
l  The person who is ultimately answerable for the correct and thorough
completion of the task. There MUST be EXACTLY ONE A specified for
each task. Accountability implies ‘ownership’.
l  Consulted (C)
l  Those whose [expert] opinions are sought. Two-way communication
l  Informed (I)
l  Those who are kept up-to-date on progress. One-way communication

Accountability / Ownership
l  Dealing with Overlaps
l  If more than one resource is identified as being ‘accountable’, or
‘the owner’ there is a problem of overlap.
l  This may be resolved by making an executive decision – which of
the possible candidates is to be held accountable?
l  This may also be solved by drilling down to the next level of
detailed analysis, where perhaps ‘accountability’ splits up into a
number of sub-accountabilities for individual owners.
l  Dealing with Gaps
l  Where no-one is identified as being the owner and held
accountable, someone must be appointed to that role.
Accountability requires exactly ONE resource – no gaps, no overlaps

SABSA Extended RACI Roles
l  Communicates (Com)
l  Those who are responsible for initiating and managing communications, either
to ‘consult’ or ‘inform’ others
l  Monitors (M)
l  Those who are responsible for monitoring and reporting on progress, on risk
levels, or on other similar changing parameters
l  Reviews (Rev)
l  Those who are responsible for looking at the work output of others and
commenting and creatively criticising it for quality assurance purposes
l  Verifies (V)
l  Those who check that the work product output from others complies with the
specification and acceptance criteria for that work product
l  Signs off (S)
l  The party who formally approves the V decision
l  At the highest level this is also the same party who holds the A role
RACI is just a concept – extend it as you find necessary

RACI Methodology
Step 1: Identify all the stakeholders in the project, process or activity
and define their roles
Step 2: Align each stakeholder / role with one or more of the RACI
responsibility types
Step 3: Ensure that all the RACI responsibility types (and SABSA
extensions) are covered
Step 4: Ensure that there is only ONE single A responsibility for
each project, process or activity
Step 5: Give consideration to where there may be a need for
segregation of responsibility types (e.g. R and V should
usually be segregated)
Step 6: Ensure that everyone knows their responsibility types and is
fully trained and competent to carry out that responsibility

Cross-Mapping RACI to Ownership
l  Owner
l  The owner is, in RACI terminology, the one held accountable (A,
plus Com and S)
l  The owner is also possibly responsible to some extent for the
certain work product outputs (can be R, I, C, M, Rev, and V)
l  Custodian
l  The custodian is, in RACI terminology, the one responsible for
producing work on behalf of the owner of the project, process or
activity (can be R, C, I, Com, M, Rev, V and S)
l  User
l  The user is, in RACI terminology, responsible for accepting and
making use of the owner’s and custodian’s work products (can be
R, C, I, M, Rev, V and S)

Accountable
Consulted
Informed
Verifies
Signsoff
Communicates
..etc
Activity 1.3
Activity 1.1
Activity 1.2
Activity 2.2
Activity 2.1
Risk
Management
Process Steps
Stakeholder RACI Roles
Activity 3.1
…etc
…etc
Activity 3.2
Activity 3.3
Monitors
Reviews
Responsible
Activity
Group 1
Activity
Group 2
Activity
Group 3
Stakeholder
Job
R
oles

Stakeholder Prioritisation (Source: OGC M_o_R page 93)
Importance of Stakeholders to Activity
PotentialImpactofActivityonStakeholders
High
High
Medium
Medium
Low
Low
Owners
Custodians
Users

RACI and the Enterprise Models
l  Apply RACI modelling at every stage of the Enterprise Lifecycle
l  SABSA Extended RACI Matrix for every:
l Strategy
l Programme
l Project
l Operational process
l  Apply RACI modelling at every level of every domain hierarchy
l  SABSA Extended RACI Matrix for every:
l Business unit
l Business function
l Business process
Apply RACI at every Identified Viewpoint

Stakeholder Mapping: Structure
l  Documenting the stakeholder details
l  Spread-sheet or database
l A directory of all identified stakeholders
l  Columns for stakeholder descriptors
l  Rows per stakeholder
l  Project team resource for project management (not published –
team confidential)
l  Kept up-to-date by a team member

Stakeholder Mapping: Content
l  Stakeholder Descriptors
l  Names (individuals or groups) and Job Titles, Roles etc.
l  Contact details (Building & Room number, Phone, Mobile, email, etc.)
l  Reporting structure (up and down in the management hierarchy)
l  Importance of stakeholder activity (high, medium, low)
l  Potential impact of project on stakeholder activities (high, medium, low)
l  Overall stakeholder priority rating and level of influence (A, B, C, D)
l  Stakeholder concerns (cross-reference to detailed documentation)
l  Engagement status – Cross reference to detailed documentation –
meeting notes, records of engagements, planned future engagements,
etc.
l  Comments – for additional notes on each stakeholder

Stakeholder Concerns Matrix
l  Matrix mapping between stakeholders and concerns
l  Show clustering of main concerns
l  Populated with extended RACI
Concern A Concern B Concern C Concern Z
Stakeholder 1
Stakeholder n
Stakeholder 1
A, S, Com R, M I
C, Rev

Stakeholder Input Validation
l  Presentation of the business drivers, CSFs and user stories
back to the stakeholders from whom they originated to check
that the business analysis is correct.
l  Presentation of the business analysis at the most senior
stakeholder level to ensure that it is consistent with high level
corporate goals and independent of personal agenda.

On-going Stakeholder Consultation
l  Regular stakeholder consultations along the project timeline
l  To ensure that evolution of business requirements can be
tracked and reworked into the business analysis on an agile
basis
l To flag up any major changes that will impact downstream
project work
l To keep stakeholders up-to-date on progress and maintain
their confidence in the project

Internal Publication
l  Internal publication of the business analysis to stakeholders
and project team members who will use these inputs
l  Providing an intranet publication service for stakeholder and
project team use
l  Ensuring traceability of downstream project work
l  Providing for agile adaptation of requirements as the project
moves forward and requirements evolve over time
l  Providing an up-to-date view of project risks and issues, the plans
for their resolution, progress towards resolution and eventual
closure
Sharing the Process Outputs

Action
l  Open discussion on content
l  Open discussion on developing our white paper
l  Recruitment of group members for the white paper
development

Practical Stakeholder Engagement

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Practical Stakeholder Engagement

Semelhante a Practical Stakeholder Engagement (20)

Último

Último (20)

Practical Stakeholder Engagement