Background

Rich Pictures is a technique developed by Peter Checkland and others when they wrote the soft systems methodology. It was deliberately designed to help with requirements which are not easy to understand. They realised that there are some circumstances where the problems are ill structured and messy and there is no clear view of what constitutes the problem itself. If we talk to different stakeholders, we get different answers as to what they believe the issue actually is. Consequently, there may be no clear action that should be taken, no obvious solution to the problem.

There could be many reasons why stakeholders cannot articulate their requirements. There could be many reasons why they cannot define the problem that they are dealing with. They only see the symptoms and cannot identify the cause of the problem. In these circumstances we need techniques which will allow them to express themselves freely and informally about their problems. This is when Rich Pictures comes in.

It is designed to help stakeholders avoid making poorly thought out decisions in reaction to circumstances they do not fully understand.

Rich Pictures can be written with any software tool or by hand, depending upon the assignment and the preferences of the business analyst.

When do we use Rich Pictures?

Rich Pictures is used for messy problems as we said. It is used when the objectives of stakeholders diverge. They might diverge because of hidden agendas, but that is a different story. I am talking about when user perspectives diverge due to the different ways in which they view the problem. When culture, social background or the organisational background of stakeholders cause them to see the problem from different perspectives, they might not all have a complete view of the problem. Each stakeholder may see only their side of the problem. They are being honest and truthful about how they perceive the problem. But cannot see the full picture.

To get around this problem there needs to be negotiation and compromise from all parties. People need to be able to communicate about the problem in a way that circumvents differences in professional and even cultural perspectives. This is where Rich Pictures comes in.

What is a Rich Picture?

A Rich picture is a highly contextual, possibly even a cartoonlike representation, of a problem that cannot easily be defined. It helps to define the issues, problems, processes, actors, relationships (internal and external), conflicts and other interesting features.

The Rich Pictures are drawn by the users, stakeholders to illustrate their perspective on the problem in a way that is free from professional, social, or cultural differences. It is deliberately designed to be free of jargon or any baggage that people bring with them into a meeting. It allows people to interact free of these things. In some ways they are free to communicate like children who express themselves in simple art.

The Rich Pictures can be labelled with text that describes aspects of the problem or requirements, but only in the form of very short notes. In this way, the issues are described graphically, but also with personal statements from the stakeholder who is drawing the picture.

The Amateur Dramatic Society Problem

The only way to fully understand Rich Pictures is by example, so let us now take some examples of Rich Pictures and see how they work.

The Amateur Dramatic Society has a problem. Let’s read what the problem is all about:

The local Amateur Dramatic Society is concerned. Membership has been declining slightly. There is little money available to fund activities, and none of its members seem willing to undertake administrative duties, which are especially important when it gives performances. As it is a performing society, and number of administrative tasks must be managed. What might they do about this situation?

If we talk to different members of the society to solve this problem, they will each give different definitions of the problem. They all see it from their own perspective. After talking to each of them we can draw our own Rich Picture to express what we know. In this instance we will have just one picture that expresses the problem, in practice there could be many, one for each member.

The Amateur Dramatic Society Rich Picture

Here we can see the illustration that expresses the problem to everyone’s satisfaction. The ellipse on the bottom right shows the Society. The members in red and orange are happy when they are performing. They are not so happy when they have to do administrative tasks such as looking after the money or selling tickets to their performances. On the left we see that the amount of money available for performances is declining.

At the bottom left we see the local community who are deciding whether to join the Dramatic Society, or invest their time in other clubs or activities that are on offer.

On the top right we see the source of funds in the form of council grants available to societies that offer activities in the community. The Amateur Dramatic Society must be attractive to new members so that they will receive a healthy grant from the council.

Here we can see that what is a complex situation for the members of the Society can be illustrated graphically, even in a fun way, so that all agree on what the fundamentals of the problem are, without referring to language or personal issues that cloud their judgement as to the true nature of the problem. Now we hope that the Dramatic Society can begin to discuss their problems together from a common viewpoint.

Customer Booking at Travel Agent

Here we can see another example of a Rich Picture that describes a complex problem. It looks at the activities of the travel agent during the day and the problems they encounter attracting new customers and satisfying all customers.

In the centre we have a pin person which represents the travel agent. We have two-way arrows which indicate the interaction they have with other parties. On the top right we have new customers. New customers ask where should I go, when should I go, how much will it cost. The travel agent must provide much more fundamental answers to questions from new customers and be much more of a mentor to them.

For experienced customers in the top left, the travel agent has less to do. The experienced customers know what they want, where they want to go and how they want to get there. The travel agent must be aware of the tastes and preferences of their returning customers.

The routine jobs of the travel agent are to book seats, book hire cars, organise visas, provide travel insurance and currency conversion to their customers. These provide extra income to the travel agent, the more value-added services they provide to all of their customers.

Call Centre Operations

Let’s have a look at a more complex Rich Picture in a business context that may be more typical of the types of Rich Picture business analysts have to deal with.

Here we have an illustration of some of the activities of a call centre belonging to a retail organisation.

There are two types of activity illustrated. The first one is illustrated by the pin people in red within the box that represents the call centre boundary. Front-line support answers calls from customers using IVR to provide technical support to their customers. Their customers can be individual customers, or business customers.

If there is a problem that they cannot solve, they will refer difficult problems to level 2 support. If level 2 support cannot provide a solution, the problem will be escalated to the vendor that developed the product the customer uses.

The green pin person in the call centre provides sales support to the customers and new prospects. Their job is to provide a good deal.

Other messages that can be sent to customers and the public in general, are information in the form of newsletters or advertising. These are shown by the blue arrows at the top and bottom.

Also illustrated are the graphs that monitor these activities. The green graph at the top shows sales over time. The red graph at the bottom shows the number of calls answered over time. These are normal performance measures we would expect to be used within a call centre.

How to use Rich Pictures

To use Rich Pictures to maximum effect, they should be introduced at a workshop. This could be a brainstorming session, in which case it is used in the first meeting when ideas are created. In other workshops it is used in the early stages when we are trying to identify the nature of the problem and are establish a collective understanding of what the problem is.

Every stakeholder is asked to draw their own Rich Picture of their perspective of the requirements or problem in the workshop. People are free to discuss these pictures among themselves, exchange and share them.

The business analyst reviews the Rich Pictures, looking for common elements and new requirements, risks, constraints, anything.

The Rich Pictures are reviewed by the users and business analysts, often at a second workshop. The artist of each Rich Picture is the best and only one who can explain it fully.

It is useful if each stakeholder explains their own Rich Picture to other members of the workshop. This enables a greater understanding of each person’s perspective of the problem, which is the prime objective of using Rich Pictures.

From this common understanding a single definition of the problem can be agreed upon. There may be a need for negotiation and compromise among stakeholders, but at least a common understanding of the problem will be achieved.

Final Thoughts

Rich Pictures can be used in many circumstances. For example, they may be used as an idea generation technique in a brainstorming workshop. When it is used in a creative scenario like this, the activity must be fun and light, it must be stress free. Remember that stress kills creativity, so the activity must be fun. Things must be kept informal.

Mind Mapping is a similar technique that can be used. Rich Pictures and Mind Mapping are both informal and even fun.

Rich Pictures can be used with any other creative techniques you wish.

The analysis of Rich Pictures from all stakeholders enables common ground to be identified. They also help to identify essential requirements that may otherwise be lost because of the assumptions of the stakeholders. This is a common mistake in requirements gathering. The stakeholders assume that we know something that they want because they would never dream of an application being developed or a problem being solved without a certain process, or piece of data being included. A layperson such as a business analyst would not easily make that assumption. This is a common source of missed requirements that business analysts must look out for. Always make sure that assumptions are articulated in as much detail as possible in the requirements documents.

This is all we’ve got to say about Rich Pictures today. If you want to see any more Rich Pictures, there are plenty available on the Internet. Simply Google “Rich Pictures Examples” to see more. Look at them using the Google images folder rather than the websites themselves.

Questions

Alright, that’s basically it. Are there any questions? Feel free to enter them in and we’ll have a look at them after we finish the webinar.

If you want to know more, please feel free to submit a question. If a question occurs to you later and you want to us to answer it, please feel free to email at the normal information email address at IRM which is training@irm.com.au and we will try to answer it as soon as possible.

Thank you for attending and listening to our first webinar. We hope you have enjoyed it and will join us for the next one. Please send any suggestions you have for ways in which you think we can improve them.

To learn more about diagramming and modelling as a valuable part of analysis attend our 4-day Business Analysis course or check out some of our helpful articles:

• BPMN vs UML vs DFD – Which One is Best
• What Do Business Analysts and Graphic Designers Have in Common
• Process Modelling 101
• How To of Essential Modelling

The post Rich Pictures: Webinar appeared first on IRM Training.

A 2016 survey of Australian business analysts across 30 organisations (government, big business, SMEs) found that while 14% used one or more of the popular languages (DFD, UML, BPMN) regularly, the vast majority 76% did not or only very occasionally.

This shows that a small number of business analysts have found benefit in the use of modelling language but the majority still use plain English to try to describe business processes and systems. This may be because the modelling languages can seem intimidating – or more likely the analyst just hasn’t been shown how beneficial modelling languages can be.

The BABOK Guide® specifies that:

“One of the key objectives of business analysis is to ensure that requirements are visible to and understood by all stakeholders.”

While all business analysts want to deliver their projects to the best of their ability, many projects are still over-time and over-budget. Most often this is a result of poorly communicated or mis-interpreted business needs. How often have two people read the same piece of text and come to different conclusions? If you’re not making the requirements as visible as possible to stakeholders then you’re not doing your job.

Using a modelling language is nearly always the clearest way to communicate your understanding of an as-is system and demonstrate your recommendations for the to-be one. The language will also allow you to use layers – high level views to summarise the overall system and detailed views to clearly describe functionality.

Pictures in the form of modelling languages help get all stakeholders on the same page easily – and demonstrate concepts clearly without room for misinterpretation.

If you’re in an organisation that’s already using modelling languages we’d love to know which one you favour – leave us a comment below. If not, come along to our 4-day Business Analysis training and learn how to start making use of this powerful business analysis technique. You’ll also learn that each modelling language has different strengths and the skilled analyst knows what to use and when.

Already down with modelling? We have 6 other business analyst courses.

The post BPMN vs UML vs DFD – which one is best? appeared first on IRM Training.

If you like spending time in the kitchen, test your skills by translating something you’re familiar with into a process model. You’ll need to be objective and not rely on inside knowledge – just follow the instructions even if you can see better ways of doing things. That comes later.

If you don’t cook then completing the exercise will  demonstrate that even without being a subject matter expert you can use a methodology to accurately document a process. Again, your first job is to accurately interpret the process description.

You’ll be using data flow diagrams (DFDs),  the simplest of all diagramming languages. If you’re unfamiliar with DFDs, check out How To Draw Data Flow Diagrams. For those of you already comfortable with this modelling notation, parts B and C of the exercise test your skills in showing/hiding complexity through levelling. We’ve included example answers for all 3 parts if you get stuck. Bon appetit!

Click here to go to the exercise.

If you enjoyed this articles you might also like the following:

How To of Essential Modelling

Modelling and Your Next Interview

How To Draw Data Flow Diagrams

The post Process Modelling 101 appeared first on IRM Training.

Data Flow Diagram – a process modelling tool

• Data flow diagrams (DFD) show how the functions, or processes, of a system relate to each other via the data that flows between them. They are most valuable in showing ‘what’, (the logical view) but can also be used to show the ‘how’ (the physical view).
• Data flow diagrams can be used to model the processes in a current system and, separately, a proposed new system. In addition they can show either physical or logical views.
• Data flow diagrams are not concerned with control or sequence. As a tool they are of limited use to designers, but are of greater use to analysts in communicating to the client and to the designers.
• DFDs are levelled so as to reduce the complexity at any one level.

Rules for Drawing a Data Flow Diagram

The four elements used in data flow diagrams are:

Data Flow

• Show the movement of data between processes, into and out of data stores and to and from terminators
• An arrow head indicates the direction of the data flow
• The data must have a meaningful name
• They do not show control

Process

• Indicates a function, this should be a transformation of data
• A functional primitive is the lowest process level

Data Store

• Shows data at rest
• May be manual or automatic accumulation of data

Terminator

• Shows the originator and/or receiver of the overall system data
• Represents people, organisations and systems just beyond the scope of the system under study
• Marks the boundary of the model
• Only appear in the highest level DFD – usually the context diagram

Download the PDF version of this guide to DFDs: How To Draw Data Flow Diagrams

If you enjoyed this article, you may also like:

There’s More to Modelling than Runways and Catwalks

Event-Based Analysis & Modelling

Process Modelling 101

The post How to a Draw Data Flow Diagram appeared first on IRM Training.

In the fashion industry, models are used to communicate (to bring to life) a designer’s ideas and creations. But they also go one step further – helping us the consumer to imagine how the clothes might look like if we were wearing them.

Models in business analysis perform a similar role, they stimulate our imagination so that we can analyse problems, explore solutions. The case for modelling is neatly summed up in this quote from the book Business Analysis Techniques: 72 Essential Tools for Success:

Models reveal the inconsistencies, loops, delays and bottlenecks involved in a process. A systematic analysis of “as is” process models provides a business analyst with the opportunity to think analytically and creatively about what the organisation really needs to do to achieve a better “to be” solution.

Modelling is one of those timeless techniques that transcends business analysis and is used in virtually every discipline from Accounting to Zoology – in between there’s engineering, design, construction, research, etc. Incidentally, accountants use modelling techniques to analyse financial data, zoologists use modelling techniques to analyse, amongst other things, animal behaviour.

Just as accountants and engineers have specific modelling techniques which are used across their respective professions, so too business analysis. But this article is not about which technique should you use – there’s plenty to choose from – it’s more about what are you trying to achieve.

So what are we trying to achieve? It boils down to two things. First what’s the problem – what’s wrong with the “as is” system? To get to the bottom of this we need some dialogue with the stakeholder. If the problem is well documented and understood then great – but often as not the stakeholder will only see the problem from a particular perspective. It’s up to the analyst to dig below the surface and find out the real cause.

Here you’ve got two choices, write a step by step description of the process under investigation – or draw a process model. Which do you think is easier and more likely to draw out the inconsistencies, loops, delays and bottlenecks in the current process? And a (very important) by product of doing the latter is you get to work collaboratively with the stakeholder rather than them dictating and you taking notes. And you don’t have to be the artist – take every opportunity to hand the whiteboard marker to the stakeholder and say “can you draw that for me?”

The second of our objectives is to decide what the “to be” system will look like. Modelling again offers a rich choice of options. It might be as easy as modifying an existing “as is” diagram or as liberating as asking draw me a picture of what you’d really like to see happening. Very few people would say they can’t understand the following diagram:

A final world on models – they can also clarify the often confusing steps in the business analysis process. Whether your project is agile, iterative, waterfall or a mixture of all of these, they all have the same objective…

…to reach an end point and produce a deliverable.

If you liked this article, you may also enjoy these:

Event-Based Analysis & Modelling

Stakeholder Communications – Pictures not Words

Data Modelling & Object Oriented Development

The post There’s More to Modelling than Runways and Catwalks appeared first on IRM Training.

To produce a data model (a logical view of the data) the technique of choice has been, and still remains, the entity relationship diagram (ERD). However in Object Oriented Development (OOD), classes are used to group together things (including data) that have similar properties. Class diagrams in themselves do not provide a straightforward path to database design because they do not represent a logical view of the data. To get this logical view we need to modify how class diagrams are used so that we can have a single view of the data in our application.

Read the full paper here: Data Modelling and Object Oriented Development

If you liked this paper, you may also enjoy:

Event-Based Analysis & Modelling

How to of Essential Modelling

The post Data Modelling & Object Oriented Development appeared first on IRM Training.

An event can be any activity, action or business process where the system under investigation needs to respond. In this approach to business analysis, once the scope of the system has been identified, the first deliverable is a table (a list) of events.

Event-based analysis aligns very well with UML and object-oriented development as both are based on how a system responds to an event. For example, use case diagrams model system responses when an actor initiates an interaction with a system.

Events can be of different types (external, time dependant, internal to a system) and requirements analysis begins with the identification and documentation of these events.

As mentioned, each event describes a condition – a piece of functionality. The system under development must have the capability to successfully process the event.

Each event can be thought of as a functional or non-functional requirement and a typical Business Requirements Document could contain dozens or even hundreds of individual events. Once we’ve defined an event we can further analyse and model the process itself using any one of a number of modelling techniques.

Try our course Modelling Requirements with Use Case & UML.

If you liked this article, you may also enjoy:

Data Modelling & Object Oriented Development

Use Case Fragments

Most Popular BA Techniques

The post Event-Based Analysis & Modelling appeared first on IRM Training.

This switch in thinking is not always easy as we have to ignore the very practical matters of procedures, methods, people, technology etc. The more involved we are in the system that we’re looking at, the more difficult it may be to look at things conceptually. We have to look at what business objective we are trying to achieve. The business analyst who can do this – and explain it to clients and management – becomes a most valuable asset to the business.

Read full paper here: How To of Essential Modelling

If you like this paper, you may also enjoy:

The BA’s Journey – From a Current to a Future State

Event-Based Analysis & Modelling

There’s More to Modelling than Runways & Catwalks

The post How To of Essential Modelling appeared first on IRM Training.

Read full paper: UML Business Context

If you liked this paper, you may also enjoy:

Use Case Fragments

How to use Use Cases

How to of Essential Modelling

The post UML – Business Context appeared first on IRM Training.

Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words.

Remember the phrase “A picture is worth a thousand words”. The question is – which type of diagram best suits our needs? In this article we’ll look at stakeholder communications whilst future articles will cover communications with solution providers.

Read full paper: Stakeholder Communications

If you liked this paper, you might enjoy:

There’s More to Modelling than Runways & Catwalks

Is Business Analysis Low Tech?

Most Popular BA Techniques

The post Stakeholder Communications – Pictures not Words appeared first on IRM Training.