Stakeholders

Satisfied Stakeholders

A stakeholder is someone (person, entity) that has an interest in the outcome of something. An investor in a business is a stakeholder, as are its CEO and its suppliers and its staff members. A sponsor in a project is a stakeholder, as are the people who will use the resulting system and maintain it. Stakeholders have different perspectives, motivations and expectations. Often, we will rely upon stakeholders for things that we want: investment, information, participation, approval, support, resources… So, it is really important to identify stakeholders, keep them engaged and to meet their expectations (within reason and without compromising our own goals).

Another reason to really keep an eye on stakeholders is this: If we are a business, we prosper to the extent that we continue to deliver value to our stakeholders; delivering that value requires capabilities, which in turn rely upon people, processes, systems, data, technology etc. So this guides where we put our focus and what we need to optimise in our business and enterprise architecture.

From a project perspective, our stakeholders are providing inputs (money, information, resources etc.) with the expectation of some desirable change or result (e.g. a new process, product, system etc. ). To produce the outputs that they require, we will need to carry out various tasks, apply skills, resources and effort to produce various artefacts. If we pay attention to what stakeholders need, we can translate that to product models (configurations of deliverables if you like), the tasks required to produce them, and the people, skills, resources and tools needed to perform the tasks. So, stakeholders can lead us directly into good project plans.

A technique we have evolved to rapidly analyse stakeholder interaction is the Stakeholder Net Value Exchange. This puts an enterprise or project in a central “black box”, surrounded by Stakeholder Types (e.g. Customer) & some important independent Stakeholders (e.g. Industry Regulator). We connect the stakeholders to the entity via edges in the direction of Value flow. You can think of these relationships as Stakeholder provides Value to Entity (inbound) or Stakeholder expects Value from Entity (outbound). For a compact diagram, the value can be recorded as text on the arrow. For a richer diagram (where we can start to see commonality etc. and define values more deeply) we put a Value symbol on the flow.

It is really illuminating to see an Enterprise or a Project from this perspective. It is also possible to model more than one collaborating entity this way, e.g. ourselves and a strategic business partner.
More detailed analysis easily ensues: We need to include all the Stakeholder types as concepts in our Domain Model; We can contemplate what Business Events occur with each Stakeholder, what Business Communication results and which Processes support them.

#Stakeholder #projectmanagement #enterprisearchitecture #businessarchitecture

Customer Service?

Today I was searching for images for a new website. I wanted something to represent delivery of desirable outcomes for customers. I searched images libraries on the term "customer service". Interesting: about 60-70% of the images were related to a smiling call centre operator or something similar. That jarred for me. I don't know of a single person (aka "customer") who actually likes dealing through or with a call centre! Call centres are mostly a way to push customers away from real person interaction and save the delivery organisation money. How can that be a symbol for customer service?

Many "customer centricity" drives in organisations equally miss the point. One consulting client, when we asked about their stand on customer centricity replied: "We take it very seriously, we have 3 ongoing projects and 7 CRM systems" - Oh boy, what are the chances of any client of theirs receiving seamless service...

Better that we start from the outside in. We like to use a model called a Stakeholder Net Value Exchange. This puts the service organisation at the centre, as a single box, with no detail of its internals (deliberate: we don't want to see the org structure, or the processes, or the systems.. These are mechanisms to achieve delivery chosen at some time in the past). We do want to see the interaction of the organisation with the outside world and what value it adds. We show all external stakeholders (customers, suppliers, government, community etc. ) on the outside of the organisation; what they provide to the organisation and what they expect from it in net terms. E.g. for a bank, a customer might provide us with deposits and expect interest and capital growth. Here is an example:

After we discover who we are dealing with and what they expect, then we can begin to drill down to how that interaction should occur, from the external party's perspective. Then we can design a customer experience to match. Finally, we can create the internal (or outsourced) mechanisms to deliver that.