Business Processes and Scenarios - Think Like A BA

---

Like many Business Analysis Trainers / Consultants - I've spent a lot of time in hotels over the years.

One thing that I enjoy as a BA is observing how businesses work, even if I'm simply a customer rather than on an assignment. I find the process of doing business and how different organisations work quite fascinating.

Observation is one fact finding technique that you can apply anywhere at any time.

This can lead to some interesting insights into the way that a business works and how things might be improved. One of the things that Business Analysts do!

To give an example - I was once staying in a large chain hotel, in Belfast as it happens (one of my favourite cities to visit and work in).

Once I'd checked in and unloaded my bags into my room I headed for the restaurant. Like many travellers I was hungry after a long journey.

One question a BA might ask - why do most larger hotels have an on-site restaurant? Particularly those in city centre locations where there are dozens of places to eat within a short walk.

Restaurants incur cost overheads - staffing, heating, lighting and use of space that could be used for something else.

One reason is that it is a useful facility for their guests, easy and convenient - the Customer viewpoint. Another is that it should generate cashflow and profits - the Business viewpoint.

What follows on from this is that one way (there are others) to achieve this business objective is to provide good food and good service.

Returning to my own story - I was shown to a table by a very friendly and polite waitress, handed a menu, asked if I wanted to order a drink, given my beer and asked if I was ready to order food.

I placed my order, enjoyed my beer, waited a short while and my meal was delivered by the waitress.

I started to eat and the food was not good, overcooked and dry, probably pre-prepared and left under a heat lamp in the kitchen for too long.

After about 5 minutes the waitress returned and politely asked if everything was ok with my meal. I replied, equally politely, that it was not. She smiled and without saying anything moved on to her next customer.

Once I'd finished I walked over to the restaurant bar where the same waitress produced my bill and asked me to sign for the meal, so that it could be added to my final hotel bill. I thought about complaining, but was too tired to argue so simply signed the chit.

Then - she asked me again, with a smile, if everything was ok with my meal. I again replied, equally politely, that it was not. She handed me my receipt and I headed out.

Why am I explaining all this? After all if I wanted to moan about the hotel I could post on TripAdvisor or Facebook!

Well it got me thinking, why did such an obviously polite and pleasant member of staff behave like this and completely ignore my complaint? Other than that the service in the restaurant had been excellent.

I'll never know for certain, but based on my experience of business processes and Business Analysis it probably came down to failure by the hotel , not her, to do two things properly:

• Business Process Modelling.
• Process Implementation and Staff Training.

I reckon that when the waitress did her initial training in the hotel she was taken through the basic processes of dealing with a restaurant customer:

• Show to table and give menu.
• Take drinks order.
• Deliver drinks.
• Take food order.
• Deliver food order.
• Check all ok.
• Produce bill.
• Check (again) all ok.
• Take payment.

What the hotel had failed to do was consider various scenarios for the process.

The waitress had clearly been well trained in "Scenario A":
Check all ok - answer = Yes.
Check (again) all ok - answer = Yes.

What the hotel had failed to consider was "Scenario B":
Check all ok - answer = No.
Check (again) all ok - answer = No.

Or indeed variants - "Scenarios B-1 and B-2"
Check all ok - answer = No.
Check (again) all ok - answer = Yes.
Check all ok - answer = Yes.
Check (again) all ok - answer = No.

This resulted in two potential weaknesses - and therefore potential areas for improvement.

First - a training plan that not only covered the "Happy Day" Scenario but other situations as well.

Second - a business process that included additional actions to be taken in the case of various "Unhappy Day" Scenarios.

In addition to the above there might be a whole range of other Scenarios to consider - including, as in my case:
Check all ok - answer = Yes (but Customer's real feeling = No).
Check (again) all ok - answer = Yes (but Customer's real feeling = No).
...... and many more.

So how could a Business Analyst have helped the hotel to do things better?

Well - there are a number of BA techniques that you could apply - including:

• Stakeholder Analysis.
• Scenario Analysis.
• Process Modelling - Business Activity Models.
• Process Modelling - Use Case Diagrams.

Stakeholder Analysis would help to identify the various participants "actors" in the business process (Serve Restaurant Meal) - and hence their roles and viewpoints.

Scenario Analysis would help to identify the various possible routes through the process - as described above.

Process Modelling would help to identify and design the business processes and actions needed to deal with the various Stakeholders and Scenarios.

Plus of course, in addition to the various diagrams and documents that could be produced using the techniques above - just simple observation and common sense by a good BA.

I'll describe how you might do this in future posts - and I also cover these techniques in my various BA training courses (shameless plug - see links above top right).

If you have anything to add to this - please comment!

---

You might also enjoy:

Adrian Reed Blog:
Make It Easy For Stakeholders: Think Like a Restaurateur!

Business Analysis Blog:
Stakeholder Analysis - Identifying Stakeholders

---

Photo Credits:
Restaurant Photo 1
Restaurant Photo 2
Restaurant Photo 3
Restaurant Photo 4

Business Analysis Techniques - Rich Pictures

Business Analysis Techniques - Rich Pictures

---

A Rich Picture is a diagram used to capture and organise information visually, using images to explore ideas creatively.

In business analysis they have many uses – for example:

• Recording the results of interviews, workshops or other fact finding.
• Capturing and analysing requirements.
• Understanding business processes.
• Analysing stakeholders.
• Exploring solutions creatively.

The example above shows how a Rich Picture might be used to analyse the stakeholders for a Hotel Booking System.

The technique is similar to Mind Maps - but makes more use of visual imagery, which can make them easier for business users and other stakeholders to relate to.
You can learn more about Mind Maps in my earlier blog post:
Business Analysis Techniques - Mind Maps

A Rich Picture can be initially be drawn by hand - as "rough notes" during a meeting or workshop.
It can then be enhanced and expanded if needed - the build up a fuller picture of a business scenario.

For example - taking the example used at the top of this blog post - a Hotel Booking System - Stakeholder Analysis.

Imagine that initial analysis has revealed that there are three main groups of stakeholders for the project - Customers, Staff, Suppliers.

You could start with the diagram shown above - that simply shows the system under investigation in the centre - "Hotel" - with a little sketch of a hotel building to illustrate this. This also shows the three groups of stakeholders link to the central image.

You could then add detail to the diagram step by step. For example - imagine that analysis has showed that Hotel Staff fall into three main groups - Back Office (administration), Reception and Restaurant. This could be shown as above.

Then - as also shown on the diagram - these groups could be broken down further. In the diagram above - for example - staff in the Restaurant have been broken down into Front of House (FoH), Bar and Kitchen.

The same could be done with Customers and Suppliers - as shown above.

The picture could then be reviewed with business users and others to ensure that it is accurate and complete. If not it could be amended accordingly until it does proved an accurate and complete picture of the stakeholders for the project.

So - in conclusion - benefits of Rich Pictures:

• Relatively fast to do.
• Easily understood.
• A good communication tool - stakeholders such as end users can relate to them.
• Visual documents are usually easier to talk through and review than the equivalent text.

---

You can learn more about Business Analysis techniques from the videos on my channel:
Business Analysis - YouTube

My online course on Udemy covers the fundamentals of Business Analysis - including a session on Rich Pictures with a detailed case study example. Learn more here -
Course - Stakeholder Analysis

Business Analysis Techniques - Mind Maps

Business Analysis Techniques - Mind Maps

---

A Mind Map is a diagram used to capture and organise information visually.
A relatively informal high level diagram that can be done quickly.

In business analysis they have many uses – for example:

• Documenting the results of interviews, workshops or other fact finding.
• Capturing requirements.
• Understanding business processes and data.
• Analysing stakeholders.

They can then be used as a basis for more detailed analysis techniques such as data flow diagrams or use case diagrams. So – a good start point for analysis.

A Mind Map can be initially be drawn by hand - as "rough notes" during a meeting or workshop.
It can then be enhanced and expanded if needed - with more text and better images.

The example above shows how you might sketch out a mind map on paper.

This example shows how the technique can be used for Stakeholder Analysis - in this case for a hotel booking system. It shows three main groups of stakeholders - Staff, Customers and Suppliers. Two of these three groups are then broken down further.

You could review this with other members of the project team and with some of business users. This is likely to result in additions, corrections and more detail being added.

Business Analysis is generally iterative – which means that documents are completed in steps.

Having completed the diagram using “pen and paper” you could use a computer based tool to produce a digital version - as in the illustration at the top of this post. This may be easier to share with the project team and other stakeholders.

The Mind Map could then form a basis for further analysis using other techniques.

So - in conclusion - benefits of Mind Maps:

• Relatively fast to do.
• Easily understood – a good communication tool.
• Visual documents are usually easier to talk through and review than the equivalent text.

---

Mind Maps Course on Udemy
My highly practical and interactive course - where I will teach you to draw these diagrams  and how to use them in practice. It includes a real life case study that you can work through step by step to learn and practice your new skills. Also an interesting and fun project that you can try for yourself. You can try out the first couple of sessions for free a d then enroll if you choose:
Mind Maps Course on Udemy

Business Analysis Jobs - Interview Questions - Part Three - The Organisation

Business Analysis Jobs - Interview Questions

---

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

For any job interview, preparation is one 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.

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