Stakeholder Analysis - Notes - Identifying Stakeholders 3

---

Stakeholder Identification – An Example.

A few years ago I worked on a proposal to work with a major UK retailer  to provide Business Analysis training and consultancy for their systems development teams. At the time I was working for a large UK consultancy firm.

They have  over 600 high street stores across the UK and over 600 stores at airports, train stations, hospitals and motorway services. They are one of the UK's leading retail groups, a well-respected household name with a history going back to the late eighteenth century.

They are sometimes regarded as a bookseller and newsagent and this is a big part of their core business. But one thing that distinguishes them from other similar companies is the range of things that they offer in their stores.

Their product range includes:
• Books.
• Newspapers and Magazines.
• Stationery.
• Greetings Cards and Gifts.
• Toys and Games.
• Entertainment – Music and Film.

I did some research this to better understand their business and requirements.
In particular I wanted to learn more about 2 key groups of stakeholders – their staff and customers.
I took a look at printed and online sources – background research.
I also visited a couple of their stores as a customer - observation.

So when we got to meet with them for the first time we were better placed to connect with them, talk about their business and how we could help with business analysis.

One interesting thing – that I discovered as part of this. The range of product offerings mentioned above might be seen as a major strength,  by both staff and customers.

But in my view, it could also be seen  as a potential weakness. Some specialist retailers – who focussed just on books (none of the other products) might have an edge. One category of customers, could be called “book lovers”, some of whom might prefer these competitors because of their wider range of books for sale and their focussed expertise of their staff. This was an interesting insight.

Stakeholder identification could help them to identify more detail. So maybe not just Customers – but Customers (Book Lovers), Customers (General), Customers (Newspapers) …… and so on. Each with possibly different requirements. Staff could be broken down as well – including maybe General Staff and Specialist Booksellers.

Identifying stakeholders at the right level of details means a better understanding of requirements –

and therefore better systems and better solutions to business problems.

In this case - one (of many) possible business improvements might be to attract more book buying customers. For example, by providing specialist training to staff in book-selling. Or by enhancing IT systems to provide better information about available books.

The mind map diagram below shows some of the possible stakeholders for the 

UK retailer. 

It is not a complete model - 

but would serve as a useful start point for further investigation and analysis.

---

Mind Map - Stakeholders (Partial Model) – Retailer

---

Here are my other blog posts on this topic -  covering some of the fact finding techniques that you might use to analyse Stakeholders and how to apply them:

Stakeholder Analysis - Notes - Identifying Stakeholders - Part 1

Stakeholder Analysis - Notes - Identifying Stakeholders - Part 2

If you would like to learn more about this subject - look at my online course - on Udemy - Stakeholder Analysis.

This highly practical course covers the key concepts and techniques for Stakeholder Analysis.

It also includes a detailed practical case study that you can work through as you progress through the course. This will enable to to see how the techniques described apply in practice - and to apply them yourself to real business project situations.

For more information - use the link below:

Practical Business Analysis - Stakeholder Analysis

---

Image credit - Wikimedia Commons.
Licensed under the Creative Commons Attribution-Share Alike 2.0 Generic license.

Stakeholder Analysis - Notes - Identifying Stakeholders 2

---

Stakeholder Identification – Fact Finding Techniques.

There are many fact finding techniques that can be used in Business Analysis – some of these might be particularly useful for identifying stakeholders in the early stages of a project:

• Background research.
• Observation
• Interviewing
• Facilitated workshops.

Background research.

• Mission statement.
• Organisation chart.
• Job descriptions.
• Social media.

The organisation’s Mission Statement will give some idea of the overall context. It may give a start on identifying stakeholders – particularly External Stakeholders. For example it might mention the importance of customers, delivering value to shareholders, a responsibility to the wider world.

Organisation charts and job descriptions will be particularly useful for identifying Business Stakeholders – managers and employees.

Social media, such as Facebook business pages, will give further insights, in particular a more up to date “snapshot” of current stakeholders and their concerns.

It is worth noting that documents and information found online may be out of date or misleading, so following up with some “face to face” fact finding is important.

Observation.

Observation of the business and its people in action might be done formally or informally. This will give the analyst more of an “as is” view – what is actually happening, and who is involved.

Formal observation could include asking if you can observe or “shadow” people within the business.

Informal observation could include simply watching and observing what is going on. If the business has a presence “on the ground”, such as shops, hotels, bars, you could visit some of these and gain some useful insights.

Interviewing.

This simply means talking to people face to face – often  in a structured way rather than just an informal chat (though this may still be useful).

Structured means having a plan and a list of questions, meeting, listening, recording and then reacting to what people say with more questions if needed.

For example - the analyst could start with a few interviews with key stakeholders, seek their views on further stakeholders who should be involved, then delve into more detail from there.


Facilitated Workshops.

This means a “structured brainstorming session”. Gathering a group of people together to work on a problem together in a creative and open way.

A particularly useful technique where some creativity and wide ranging thinking is needed.

Facilitated – the session has some structure and is managed by a facilitator – so that it delivers focussed results. For example – you could bring together a group of sales and marketing people for a stakeholder workshop to analyse customers in more detail.

Stakeholder Identification - The “Hidden Agenda” – Building Relationships.

There is potentially one huge additional benefit here – the opportunity for the business analyst to build relationships with stakeholders. 

This is an important skill for the analyst and will deliver benefits throughout the life of the project. 

Making stakeholders feel involved and valued will help in a number of ways – for example, making it easier to gather and prioritise requirements. 

This can be classed as a “soft skill” and so is not easy to quantify, although it probably falls under the heading Communication Skills in the analyst skillset. 

Exactly how to do this is subtle and requires judgement, a feel for the organisation and the people involved. But some things that will help are:

• Communicate – about the project.
• Listen - to what people say.
• Respond – give people answers.
• Empathy – show concern for people.
• Involve – people at all levels.

Here are my other blog posts on this topic -  covering some of the fact finding techniques that you might use to analyse Stakeholders and how to apply them:

Stakeholder Analysis - Notes - Identifying Stakeholders - Part 1

Stakeholder Analysis - Notes - Identifying Stakeholders - Part 3

---

If you would like to learn more about this subject - look at my online course - on Udemy - Stakeholder Analysis.

This highly practical course covers the key concepts and techniques for Stakeholder Analysis.

It also includes a detailed practical case study that you can work through as you progress through the course. This will enable to to see how the techniques described apply in practice - and to apply them yourself to real business project situations.

For more information - use the link below:

Practical Business Analysis - Stakeholder Analysis

Stakeholder Analysis - Notes - Identifying Stakeholders 1

---

Stakeholder Analysis is an important skill for Business Analysts.

Identifying them, understanding their requirements and engaging them in a project is essential.

Who they are and how they might be involved will vary according to the nature of the project that you are working on.

So its worth starting with a definition.

A Stakeholder is:

• Someone who has an interest in the system or business change under consideration.
• A potential source of business requirements and priorities.
• Anybody who may influence the project – in a positive or a negative way.

So, basically, anybody who might be affected by the proposed new system.

But because this means that there may be a large number, it is important to prioritise, as well as to identify all of them.

The role of the Business Analyst in Stakeholder Analysis is to:

• Identify who they are and prioritise.
• Understand their viewpoints and requirements.
• Engage them in the project.
• Keep them engaged throughout.

Here are some of the key principles that apply:

• Missing stakeholders may lead to missing requirements later.
• Get stakeholders involved early and make them feel a valued part of the project.
• Think widely – try to identify all stakeholders (within reason).
• Further analysis will allow you to prioritise and identify the most important.
• A minor stakeholder now may become more important later.
• But - beware “paralysis by analysis”.
• It is probably more common to identify too few stakeholders than too many.

One possible start point is to consider three broad categories that will apply to just about any project:

• Project Stakeholders.
• Business Stakeholders.
• External Stakeholders.

How to do this is covered in three earlier blog posts - use the links below to take a look:

Stakeholder Analysis - Notes - Part 1 - Project Stakeholders

Stakeholder Analysis - Notes - Part 2 - Business Stakeholders

Stakeholder Analysis - Notes - Part 3 - External Stakeholders

You can then analyse your initial list in more detail

Here are my other blog posts on this topic -  covering some of the fact finding techniques that you might use to analyse Stakeholders and how to apply them:

Stakeholder Analysis - Notes - Identifying Stakeholders - Part 2

Stakeholder Analysis - Notes - Identifying Stakeholders - Part 3

---

If you would like to learn more about this subject - look at my online course - on Udemy - Stakeholder Analysis.

This highly practical course covers the key concepts and techniques for Stakeholder Analysis.

It also includes a detailed practical case study that you can work through as you progress through the course. This will enable to to see how the techniques described apply in practice - and to apply them yourself to real business project situations.

For more information - use the link below:

Practical Business Analysis - Stakeholder Analysis

Business Analysis Techniques - Process Modelling - Context Diagrams - Part Two

Business Analysis Techniques - Context Diagram

---

There are many techniques that can be used in Business Analysis.

One part of this toolset is modelling techniques - diagrams with supporting text, often used to model business processes and business data.

Process modelling helps us to understand how a business system works now (as is) and possible areas for improvement.

This helps to identify requirements for a new system, analyse those requirements and produce models showing how a new improved system might work.

There are many process modelling techniques that might be used to achieve this.
This post focuses one of the simplest - Context Diagrams.

This is the second post on this topic and follows on from a previous post - take a look at that here:
Process Modelling - Context Diagrams - Part One

Context Diagrams Part One covers the "What", "When" and "Why" - this post will focus on the "How".

First - Notation - the symbols that can be used on the diagram to convey a particular meaning.
The idea is to use a standard notation so that everybody can understand what a particular diagram is showing in business terms. There are various standards out there. It doesn't matter, in principle, which standard you use as long as everybody involved in the project understands it. Here I''ll be using a notation widely used in the UK.

To illustrate this, here I'll show the steps involved in building a Context Diagram for a Hotel Booking and Administration System.

The System under analysis is represented as a single box.
The box represents the system boundary.
Inside the box is a name representing the system as a whole.
So here we can start the diagram with a simple rectangular box labelled "Hotel".

Things outside the system boundary that interact with it are called External Entities.

These are represented with an ellipse labelled with a name. For example - one of the External Entities for a Hotel might be a Customer – somebody who stays or visits and spends money on services.

Interactions between External Entities and the system are shown as Data Flows.

Represented by lines with an arrowhead showing the direction of the flow and text briefly describing what it is. For example one of the interactions between a Customer and the Hotel might be a booking.

Things outside the system boundary that interact with it are called External Entities.

For the purposes of the Context Diagram – we are only interested in how these interact with the system.

In this case - for example a customer makes a booking.

We are not interested, at this stage, in when they make a booking or how they decide to make a booking. This can be analysed later as needed.

We are simply modelling the data flow into the system – Booking – and the flow back to them – Booking Confirmation.

One advantage of Context Diagrams is that they are relatively straightforward and easy to understand.
This makes validation with business users and other stakeholders easier.

They can then form a basis for more detailed analysis as needed, using other techniques such as Use Case Diagrams or Data Flow Diagrams.

 Context Diagram - Summary.

A High Level Diagram.

Shows:

• System Boundary.
• External Entities.
• Data Flows – into system.
• Data Flows – out of system.

A useful starting point for further analysis.

---

You might also find these blog posts useful:
Process Modelling - Context Diagrams - Part One

Stakeholder Analysis

You could also take a look at my online courses that cover various Business Analysis techniques in more detail:

Getting Started In Business Analysis

Business Analysis Techniques - Stakeholder Analysis

Business Analysis Techniques - Process Modelling - Context Diagrams - Part One

Business Analysis Techniques - Process Modelling

---

There are many techniques that can be used in Business Analysis.

One part of this toolset is modelling techniques - diagrams with supporting text, often used to model business processes and business data.

Process modelling helps us to understand how a business system works now (as is) and possible areas for improvement.

This helps to identify requirements for a new system, analyse those requirements and produce models showing how a new improved system might work.

There are many process modelling techniques that might be used to achieve this.
This post focuses one of the simplest - Context Diagrams.

Context Diagram – What it is:

• A diagram showing flows of information into and out of a business system.
• Defines a boundary between the system and its environment, showing the entities that interact with it and how they interact.
• Provides a top level view of things and so is a useful starting point for further process analysis.

Here is an example - a Context Diagram for a Hotel Booking and Administration System.

Context Diagram - Hotel Booking and Administration System

This may be be slightly confusing at first sight - but do not be concerned. This post and subsequent posts on the topic will explain step by step how this diagram is constructed and what it shows

To start - the box in the centre of the diagram represents the system that we are investigating and analysing - in this case - "Hotel".

The ellipse shapes around the outside represent External Entities, sometimes called "Actors" (particularly in UML - Unified Modelling Language). Essentially - anybody or anything that interacts with the system. In this example - one of these is "Customer".

The arrows show interactions between the External Entities and the system, flows of data, with the arrowheads indicating the direction of the flow.

Context Diagram - Hotel Booking and Administration System

For example - here - Customers make Bookings with the Hotel and receive a Booking Confirmation in return.

Hotel - System.
Customer - External Entity (or Actor).
Booking - Data Flow.
Booking Confirmation - Data Flow.

The content of these data flows, what triggers them, how frequent they are, any business rules that apply - and so on - can be analysed in more detail later for on. A Context Diagram just aims to show a top-level view of a system.

So to summarise:

Context Diagram – What it is:

• Defines a boundary between the system and its environment, showing the entities that interact with it. .… those interactions are shown as data flows.

• Provides a top level view of things and so is a useful starting point for further process analysis.…. the box in the centre – representing the system can be broken down further later on.

Context Diagram – When it might be used:

• Could be used at any time.
• Often used early in a project to understand the current system.
• Can be used later as part of a specification for a new system..

Context Diagram – Why it is useful:

• Helps to understand more about a business system and how it works.
• Helps to define the boundary of the system under investigation – scope.
• Can be validated with business users and other stakeholders relatively easily.
• Helps to understand requirements for a new system.

So that covers three of the classic questions - What, When and Why.

The Who and the How will be covered in future posts.

If you have any questions - please comment below or get in touch.

Business Analysis Jobs - Interview Questions - Part Two - Your Resume

Business Analysis Jobs - Interview Questions

---

One of the most common questions I've seen on social media, from aspiring Business Analysts, is - "Can anybody send me a link to a list of BA job interview questions?".

For any job interview, preparation is a key to success.

The problem is that it is difficult to predict exactly what questions you may be asked in a given job interview. This uncertainty is one of the reasons why most people feel somewhat nervous in this situation.

Lists of generic questions are of limited use.
Much depends on the specific job that you are applying for.

So - how to prepare as best you can? This blog aims to help you.

A possible answer is - a Business Analysis approach!

Interviewers, if are doing their job properly, will not ask you questions at random. They will prepare for the interview, set some objectives and formulate some questions to ask. Three of the possible factors that they will consider are:

• Your Resume.
• The Organisation.
• The Job.

MoSCoW Prioritisation - A Useful Guide

DSDM Atern Handbook - MoSCoW Prioritisation

---

The acronym MoSCow was first used a few years back as part of the Agile development framework - Dynamic Systems Development Method (DSDM).

The method is now managed and developed by The Agile Business Consortium.

MoSCow stands for:

• Must Have
• Should Have
• Could Have
• Won't Have

Each requirement identified during the initial phases of requirements analysis should be classified under one of those headings.

This is based a solid Business Analysis principle - that all requirements should be identified - but not all should or will be carried forward into development of a new system.

All projects are subject to constraints of time and cost. These need to be balanced against the business requirements. Do we want to deliver more at higher cost and longer timescales - or deliver less but at lower cost and more quickly?

The answers will vary from project to project - but it is a very good principle to apply. This can be tricky in practice though - as some business users will say that they want everything - but also done quickly and a low cost! Not always possible - so the MoSCoW approach helps to focus the project and separate important requirements from "nice to haves but not absolutely necessary".

The Agile Business Consortium have developed a useful guide to this - which covers what this approach is and how to apply it. You can view on their website - here:
DSDM Atern Handbook - MoSCoW Prioritisation

So in summary - a useful addition to "The Business Analysis Toolkit" and well worth a look.

---

You can also follow me on:

Business Analysis - Facebook

Business Analysis - YouTube

Steve McIntosh - LinkedIn



Steve McIntosh.
Business Analyst.
St Ives, Cornwall, UK.