I spy with my little eye: stakeholder

by | 09.09.2019

Remember the amusement from childhood: “I spy with my little eye …? The game was often used to teach children concepts: “I spy with my litte eye a flower.” Or: “I spy with my litte eye something and that’s a cat.” In the course of time the challenges rose and colours came into play: “…. and that’s the color blue.” From that point on, in search of the concrete object, it was necessary to name all the elements in the field of vision that were blue: sky, water, lacing needle (the end of a lacing) or mum’s earring.

Shall we play the game? “I spy with my litte eye something and that’s a stakeholder.”

What is a stakeholder and why is he important?

A stakeholder is a person who has a direct or indirect interest in the course or outcome of a process, project, development, product or company. Of course, groups of people or entire organisations are also considered stakeholders. Put simply, a stakeholder “holds a stake” and who therefore has an interest in the outcome of a project.Âą

And why are stakeholders so important?

  • Stakeholders deliver requirements. If stakeholders are overlooked, their requirements are missing. With a little luck, you will recognise this failure in the course of development, and the requirements will subsequently flow into your development – e.g. as elaborate and expensive change requests.
  • What happens if you want to test a new business idea and you ask the wrong people? You are probably making a bad decision.
  • What happens if you only know the goals of a few stakeholders? Goals are not achieved accidentally. And unlike some change requests, requirements or user stories, goals cannot be implemented retrospectively. Your project is therefore very likely to produce a result that does not achieve all goals.

In other words, stakeholders are important. And now what?

The Stakeholder Management

“Stakeholder management” is the central term for the orientation of an organisation towards its stakeholders. Stakeholder management is a continuous task that can extend beyond the period of an explicit development. It is continuous as new stakeholders emerge or existing stakeholders change their opinions during the course of a development. And it can extend beyond the period of a development, because stakeholders can also ” hold a stake ” in several parallel projects or have a fundamental interest in your company.

Expressed in a simple formula: stakeholder management = stakeholder identification + stakeholder analysis + stakeholder communication. Together, these three areas make up stakeholder management. In theory, this sounds much simpler than is often the case in practice.

Do you have someone in your organisation who is explicitly responsible for stakeholder management for a product or development? Hopefully. This could be, for example, a product manager, or a product owner, or perhaps a business analyst or requirements engineer. Maybe it is also a team of colleagues, e.g. a Project Management Office. And how regularly does the responsible person / team try to identify new stakeholders, to understand and question the wishes, goals and motives of the stakeholders, and how, when and in what form does the communication with them take place?

In addition, stakeholder management is not just a continuous task, but a task with a high level of responsibility. It doesn’t just work in passing, it sets high standards. It demands empathy, trust, analytical skills and very good communication skills. In fact, stakeholder management is an intensive full-time job. Those who make elementary mistakes here will find it difficult to develop successful products.

The Stakeholder Identification

Stakeholder identification is the first step in stakeholder management. It aims to identify all persons, groups of persons or organisations who are directly or indirectly affected by or have a concrete interest in the activities of a company. Four questions are helpful in stakeholder identification:

  • Who is affected by the project?
  • Which processes are affected by your project?
  • Which external groupings are affected by your project?
  • What are the framework conditions for your project?

The answers can be found by looking at internal and external company structures: Which internal divisions, departments or locations are affected? Who is interested in the output of the project that may be active in neighboring areas or projects? And which employees are engaged by customers, partners or suppliers? The last question aims at normative, regulatory or legal requirements.

The result of the identification is a stakeholder list. Ideally, it contains concrete names and not just “abstract” role designations such as “customer” or “owner”. Of course, this depends on the context; for example, if your company has two owners, both may have different motives, requirements or goals, so it makes sense to record them separately. If your company supplies products to thousands of consumers, this may be difficult and not make much sense.

The Stakeholder Analysis

The identification is followed by the analysis. The stakeholder analysis has two objectives: to identify the most important stakeholders for a project and to analyse their attitudes, motives and wishes. It is also responsible for identifying conflicts between stakeholders and/or between their goals. Ideally, opponents, obstacles and resistances as well as supporters and promoters can be identified.

Within the analysis there are two approaches that have to be reconciled: on the one hand the survey should be methodical and structured, on the other hand creative techniques – e.g. brainstorming, braindumping, apprenticing, etc. – have to be applied. Implicitly there is always the danger of generalisation. In order to reduce this danger, the analyses are often carried out by teams. This increases the effort, but should be cheaper than making decisions based on wrong, overinterpreted or missing information.

The German IPMA partner organisation (GPM) published a study in 2015 in which stakeholders were categorised according to their importance.² In first place were customers, followed by management and employees. After that shareholders, the public, specialist departments, politics, partners, suppliers, users, works councils, steering committees, consultants, departments not involved in the project and the competition followed. Such a categorisation can be an indicator for you, but in the end it is necessary to identify the stakeholders for each project, depending on the context, who

  • have a great influence,
  • have a great interest,
  • and can promote, obstruct or block the project.

The stakeholder matrix is a popular means of visualising the results.

The Stakeholder Communication

Communication is the Alpha and Omega in many situations. Communication is also a very important factor in stakeholder management. It ensures that proponents of a project remain proponents. It helps to appease opponents. It identifies, mediates and questions, explains and integrates.

Since stakeholders are individual, stakeholder communication should also be individual. It has to be clarified,

  • how,
  • when
  • and with which frequency

the exchange of information takes place. The findings could flow into a communication plan that facilitates systematic work. It is important to consider the importance of the stakeholder for the concrete project and the context. For example, it may make sense to exchange views daily with the most important stakeholders at a Jour fixe, to give a weekly summary to a second group and to exchange the latest findings once a month with a third group.

Challenges in practice

In practice, dealing with stakeholders involves mastering numerous, very different challenges. In every area of stakeholder management, pitfalls and dangers lurk. Here you will find a small list of possible challenges with suggestions for action:

  • Stakeholder identification was once carried out several years ago and has since been taken over again and again – without checking for correctness or completeness. Using existing stakeholder lists does not have to be wrong, but the list should always be critically questioned and updated.
  • The identification is not carried out at all, because the owner of the company believes to know the market. Surely it would be right in such a situation to ask the owner where he gets his knowledge from and how valid it actually is. However, this requires courage, resilience and, if necessary, a certain standing in the organisation.
  • Both product owners and product managers are of course stakeholders, but above all they represent other stakeholders. Knowing what the product owner wants or believes is not really enough.
  • Stakeholder analysis is taken lightly, because “after all, we know what the customer wants”. Unfortunately, this attitude is widespread in many organisations and can lead to products that “nobody” wants, that provide features that “nobody” understands and that “nobody” uses.
  • The analysis often overlooks relationships between individuals or groups of individuals. If, for example, a project is supported by one person, this could lead to the rejection of the project by the other person if the relationship between the person and another person is bad. Analytical skills, moderation and often a sure instinct are required.
  • Stakeholder communication takes place without a plan. Based on the identification and analysis, the stakeholders important for a development or a project should be identified with their goals, motives and wishes. The frequency of communication should, for example, be geared to the specific significance of the stakeholder and, of course, to his ideas in terms of time and form.
  • Communication is too sporadic. And what happens if a stakeholder gets the feeling that he is no longer important or that he no longer receives any information? He changes his attitude to a project; a friend may become a skeptic, a skeptic an opponent. It is therefore advisable to agree an individual communication strategy with each stakeholder (or category of stakeholders).
  • Stakeholder management is understood neither as a holistic task nor as a process. Learnings are ignored and not used for subsequent project phases or future developments. Findings are not documented. If such challenges arise, it could also be a question of corporate culture – and that would perhaps be worth another post here in the blog …

Of course, the list can easily be extended, because life poses the greatest challenges. It is important that you identify your challenges, analyse them and communicate about them. Then I am sure that the next successful project is already waiting for you. “I spy with my little eye something and that’s stakeholder management.”

 

Notes:

[1] For reasons of better readability alone, I have refrained from using male and female language forms at the same time. All personal names are valid for all sexes.
[2] In German only: GPM-Studie zu Art und Umfang der Umsetzung des Stakeholdermanagements in deutschen Unternehmen und Projektgruppen

Here you can download a stakeholder whitepaper for free.

Here you will find a template for the documentation of stakeholders or the creation of a stakeholder list.

Michael Schenkel has published further articles in the t2informatik Blog, including

t2informatik Blog: The best process in requirements management

The best process in requirements management

t2informatik Blog: Eliminate requirements

Eliminating requirements

t2informatik Blog: Requirement analysis, but remote

Requirement analysis, but remote

Michael Schenkel
Michael Schenkel

Head of Marketing, t2informatik GmbH

Michael Schenkel has a heart for marketing - so it is fitting that he is responsible for marketing at t2informatik. He likes to blog, likes a change of perspective and tries to offer useful information - e.g. here in the blog - at a time when there is a lot of talk about people's decreasing attention span. If you feel like it, arrange to meet him for a coffee and a piece of cake; he will certainly look forward to it!​