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.

Business Analysis Jobs - Interview Questions - Part One

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.

Applying a Business Analysis approach would give you these steps:

• Fact finding - your resume.
• Fact finding – the organisation.
• Fact finding – the job.
• Analysis – of requirements.
• Identification – of potential questions.

Your resume - it may seem odd to say "fact finding" here, after all you should know what's in it. But - it is worth reviewing your resume and considering what interview questions might arise.

The organisation - find out more about the company that you want to join. A common question is "Why do you want to join us". You need some convincing answers.

The job - review the job description and any associated documents such as an "ideal candidate" specification. Consider how well you match these, any strong points, any weak areas.

I'll be covering each of these steps, in turn, in more detail in future posts.

For now - to sum up - if you are looking for a Business Analysis job - why not apply your skills as a Business Analyst to help you to prepare and increase your chances of success!

---

You can learn more about BA Interviews in this video on my Business Analysis YouTube channel:
Business Analysis Jobs - The Interview - Part 1 - Introduction

My online course on Udemy covers the fundamentals of Business Analysis - including a session on Business Analysis Jobs. Learn more here -
Course - Getting Started In Business Analysis

Getting Started in Business Analysis

Getting Started in Business Analysis

---

I have just launched my new course on Udemy - Getting Started in Business Analysis.

Udemy is a brilliant online training platform - where course are highly interactive - informative - and fun! One great feature is that you can do a course in stages - at a time to suit you.

My course includes video lectures, slideshows, quizzes to test your knowledge and case study exercises so you can practice your BA skills.

The course is aimed at those new to BA - so will NOT suit more experienced analysts.

Anybody seeking to move into Business Analysis from an IT / technical role or a business role.
Recent graduates seeking a job in Business Analysis.
Or maybe you just want to learn more about the BA role.

So if you are just starting out and looking at a BA career - take a look.

There is a detailed course description - so you can see if it suits you..
Also some sessions that you can try out for free.

If you enrol I will provide you with help and support as needed right through the course.

If you have any queries or need more info - contact me.

I'm offering discounted places to blog readers -
 £12.99 (UK Pounds) - half the standard price.

Take a look - use the link below ......
Getting Started in Business Analysis