Stakeholder Identification and Balancing Conflicting Requirements
Issue 1.0January 2012
Identifying stakeholders is all about applying systems thinking to the problem in question, the wider
environment that contains the problem, and the potential solution space, in order to identify the
people and organisations that will play a role in the development of the solution to the problem.
Definition of a stakeholder
“A party having a right, share or claim in a system or in its possession of
characteristics that meet that party’s needs and expectations” [ISO-15288]
Stakeholders can be characterised as:
There are usually many different stakeholders for any given problem space or system-of-interest.This includes:
Each stakeholder will have a different viewpoint on the problem space and the solution space.Some may even be so focussed inside the solution space that they don’t recognise the existence of the problem space that the solution sits inside. Some may sit outside of the problem space, typically in a legislative role, or as “capability” customers who are concerned that the problem can be solved, but less interested in the particular solutions available.
A system is through-life, not just for delivery
It is important to consider the full set of stakeholders throughout the full lifecycle of any
proposed systems which are created as a solution to the perceived problem.
Some stakeholders will be fairly constant, others will only have a view on certain
elements of the system lifecycle, and only on systems of direct relevance to themselves
(e.g. safety authorities).
A “Stakeholder Dartboard” can be a useful tool to help you to think about how
stakeholders play their parts across the lifecycles of the any proposed systems to
solve the problem. This takes the solution-space, problem-space, and wider-context
boundaries, and superimposes a system lifecycle over it to create a set of segments to
think about when identifying stakeholders and understanding where they fit.
If you work in the Defence industry then it will also be useful to think about the
Stakeholders in terms of which DLODs (Defence Lines Of Development) they have an
Relationships between stakeholders
Soft System Methodology (SSM) is traditionally used in the context of organisational
change management, but can be usefully applied at the front end of a “traditional”
engineering project to help explore and articulate what the real problems are, before
the project team starts dashing off trying to develop solutions to “show progress”.
Soft Systems Methodology uses the concept of root definitions to analyse stakeholder
relationships with respect to transformations within a system or organisational context.
The “root definition” is a set of CATWOE terms for a particular transformation required.
There can be many root definitions which are appropriate to a given problem and
In terms of stakeholders, it can be useful to frame the set of needs or goals for a
particular problem-space as Transformations, to be done by A, to impact upon C, under
the control of O, for the reasons put forward in W, constrained by E.
This will identify a series of C-A-O relationships, typically with multiple stakeholders
for each T-W-E set.
For a fuller explanation of SSM, please refer to the INCOSE UK Z-Guide Z4.
The “Expert Trap”
To misquote George Orwell, “All stakeholders are equal, but some stakeholders are
treated more equally than others.” To an extent this has to be the case in order to
recognise issues of ownership and responsibility, but there is no excuse for riding
roughshod over the views of actual stakeholders because you think you know better.
Obtaining the Real Stakeholder Needs and Views
Various group working techniques exist to facilitate such information, including:
Open Space – allowing stakeholders to define their own themes and then cluster into self-forming groups to discuss the pertinent issues.
“Post-it” facilitation – inviting stakeholder to post observations and comments against predefined themes. This can be a very democratic process suited to getting the views of the less vocal.
Graphical facilitation – using expert facilitators to encourage stakeholders to develop “rich pictures” that capture the key aims, issues and conflicts in the situation under discussion.
The Secret to Resolving Conflict
Clarification – what are the real underlying issues?
Omission – what is not being said? Is there missing information that could inform a decision?
Challenge – are the issues really show stoppers – can they be resolved or dissolved?
When dealing with stakeholders in a more traditional and bureaucratic environment, it can be useful
to categorise stakeholder organisations according to the level and type of interaction needed with
them, and clustering them into related domains of interest. The RACI diagram can be a useful tool
in these circumstances.
This leaflet is intended as a working guide to stakeholder identification, and is adapted from
material presented by Ian Gibson and Emma Langman at the INCOSE UK one day event
“Simple Systems Techniques That Work”, held on the 3rd March 2010.
This series of working guides is produced by members of the UK Chapter of INCOSE.
For further information, advice and links to helpful websites go to: www.incoseonline.org.uk
Members can download copies of this leaflet and other Systems Engineering
resources online at: www.incoseonline.org.uk
For more information about the worldwide Systems Engineering
professional community, go to: www.incose.org
Series editor: Hazel Woodcock Lead author: Ian Gibson © 2012 INCOSE UK Ltd