Omega Guide 1

Stakeholder Identification and Balancing Conflicting Requirements

ω 1

View PDF

Issue 1.0
January 2012


Stakeholder Identification and Balancing Conflicting Requirements


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:

  • Having some form of “ownership” over a system-of-interest or its future development; or
  • Requiring something from a system; or
  • Being impacted upon by a system; or
  • Some combination of all three.

There are usually many different stakeholders for any given problem space or system-of-interest.This includes:

  • People who interact directly with a system such as operators, maintainers, administrators or casual untrained users (e.g. for systems used by the general public);
  • People who benefit from the outcomes enabled and outputs provided by the system, but do not necessarily interact with it directly (e.g. those who direct the actions of the direct users);
  • Organisations/entities which place restrictions upon the system (e.g. legislative bodies);
  • Organisations/entities which stand to gain from some aspect of the solution (e.g. manufacturers);
  • Organisations which are customers for the solution.

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.

solution space

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).

system life

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.

system life cycle

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 interest in.

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.

  • Customer – the beneficiary (or victim)
  • Actor – the person/organisation doing the work
  • Transformation – that which is to be done
  • World-view – the cultural context
  • Owner – a person/organisation who can say go/no-go
  • Environment – the relevant constraints

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 solution space.

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”

  • We assume we know who the customer is, and what they want.
  • We think we know who all the stakeholders are, and what they want.
  • We ‘consult’ after we have made the decision, and bias the ‘consultation’.
  • We filter everything we hear through our own mental models.

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?

Stakeholder Management

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.

steak holder management

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:

Members can download copies of this leaflet and other Systems Engineering resources online at:

For more information about the worldwide Systems Engineering professional community, go to:

Series editor: Hazel Woodcock
Lead author: Ian Gibson
© 2012 INCOSE UK Ltd