Techniques

Chapter Study Group

Learning Materials
2015, International Institute of Business Analysis™
(IIBA®).

Permission is granted to IIBA Chapters to use and

modify this content to support chapter activities.

All other rights reserved.

2
Study Session Schedule
Session Date Chapters Topics
1 Jan 25 1&2 Introduction and BA Key Concepts

2 Feb 15 3 Business Analysis Planning and Monitoring

3 Mar 15 4 Elicitation and Collaboration

4 Apr 12 5 Requirements Life Cycle Management

5 May 17 6 Strategy Analysis

6 Jun 14 7 Requirements Analysis and Design Definition

7 Jul 12 8 Solution Evaluation

8 Sep 13 9 Underlying Competencies & Perspectives

9 Oct 18 10 Techniques

10 Nov 1 11 Jeopardy Game and Mock Exam

3
AGENDA

• (6:00 – 6:10) Overview (Holly)

• (6:10 – 7:25) 6 techniques (10-12 minutes each)
• 10.5 Brainstorming (Holly)
• 10.13 Data Flow Diagrams (Tameen)
• 10.16 Decision Analysis (Carolina)
• 10.18 Document Analysis (Pindy)
• 10.20 Financial Analysis (Ron)
• 10.25 Interviews （Ivy)

• (7:25 – 7:35) Break (10 minutes)

Underlying Competencies 4
AGENDA (CON’T)

• (7:35 – 8:45) 6 techniques (10-12 minutes each)

• 10.29 Mind Mapping (Sophie)
• 10.32 Organization Modeling (Cecilia)
• 10.40 Root Cause Analysis (Holly)
• 10.50 Workshops (Paula)
• 10.26 Item Tracking (Holly)
• 10.27 Lessons Learned (Pindy)
• 10.35 Process Modeling (Holly)
• 10.38 Risk Analysis and Management (Cecilia)
• Extra techniques (if time permitting)
• 10.28 Metrics and Key Performance Indicators (KPIs) (Tameen)
• (8:45 – 9:00) Group practice (15 minutes)
Underlying Competencies 5
INTRODUCTION
• Chapter 10 of BABOK v3
• Technique descriptions include:
• Purpose
• Description
• Elements
• Usage Considerations
• Cover the most common and widespread techniques practiced within the
business analysis community.
• As the practice of business analysis evolves, techniques will be added,
changed, or removed from future iterations of the BABOK® Guide.
• In a number of cases, a set of conceptually similar approaches have
been grouped into a single technique.
Techniques 6
10.5 Brainstorming
(Alan)
10.5 BRAINSTORMING

• Purpose
• Generate creative ideas by exploring many possible solutions.
Purpose and Description

• Uses the create power of a group to generate many ideas quickly.

• Description
• Promotes creative thinking by producing a diverse set of options
• Works best by focusing on one issue
• Asks a group to generate many ideas quickly to resolve the issue
• can be use in identifying root causes of business problems, generating
possible solutions or creating product concepts

Techniques 8
10.5 BRAINSTORMING
• Description
• This technique is best applied in a group as it draws on the experience
and creativity of all members of the group.
Purpose and Description

Techniques 9
10.5 BRAINSTORMING
1. Define the area of focus, set expectation, and establish
evaluation criteria

2. Conduct the brainstorming session and encourage others to

build on suggested ideas without critique
Elements

3. Evaluate and condense the list of ideas

Techniques 10
10.5 BRAINSTORMING

• Excel in encouraging creative thinking to generate many ideas in

small amount of time
Usage Considerations

• - Limited by participants' willingness to engage or criticism of

ideas during session

• - Facilitator need to guide the group though the technique to

focus on the issue

• - Ideas generated need additional analysis

Techniques 11
10.5 BRAINSTORMING

• Service desk team tries to figure out why their backlog of tickets is
steadily growing. Through a brainstorming exercise, they may
discover that issue may be caused by delay in resolving existing
tickets, not having enough staff to handle the incoming requests,
or staff not having enough training.
Example

Techniques 12
10.13 Data Flow Diagrams
(Tameen)
10.16 Decision Analysis
(Holly for Carolina)
10.16 DECISION ANALYSIS
• Purpose
• Used to explore possible consequences of different decisions.
Purpose and Description

• Helps to determine the value of alternate outcomes under

conditions of uncertainty or in highly complex situations.

• Description
• A decision is the act of making a choice among multiple viable
alternatives with different values of their outcomes.
• The evaluation of an outcome may take a form of financial value,
scoring, or a relative ranking.
• There are a number of decision analysis tools available to assist in
Decision Analysis.
• The appropriate approach depends on the type of decision, level of
uncertainty, risk, quality of information, and evaluation criteria.

Techniques 15
10.16 DECISION ANALYSIS
• Decision analysis requires an understanding of:
• The values, goals, and objectives related to the decision problem
Purpose and Description

• The nature of the decision that must be made

• The areas of uncertainty that affect the decision
• The consequences of each potential decision

• Decision analysis activities include:

• Define problem statement
• Define alternatives
• Evaluate alternatives
• Choose the alternative to implement
• Implement the chosen alternative

Techniques 16
10.16 DECISION ANALYSIS
• Components of Decision Analysis
• Description of the decision to be made or a Problem Statement.
• Decision Maker: the person or people responsible for making the
final decision.
• Alternative: a possible proposition or course of action.
• Decision criteria used to evaluate the alternatives.
Elements

Techniques 17
10.16 DECISION ANALYSIS
• Examples of decision analysis tools and techniques:
• Pro versus con considerations
• Force field analysis
• Decision tables
• Decision trees
Examples

• Comparison analysis
• Analytical hierarchy process (AHP)
• Totally-partially-not (TPN)
• Multi-criteria decision analysis (MCDA)
• Computer-based simulations and algorithms

Techniques 18
10.16 DECISION ANALYSIS
PROS 33 40 CONS

List Value Value List

Pro vs Con Considerations

Easy Setup 9 7 User Experience

Reports 8 8 Iphone App

Online 6 8 Dashboard
Invoicing
Estimates 5 9 Integration with
Payroll

Expenses 5 8 Cost

Total 33 40
Value Scale: 1-10 (1: lowest, 10: highest)
Techniques 19
10.16 DECISION ANALYSIS

Forces for Change Forces Against Change

4 3 2 1 1 2 3 4
Force Field Analysis

Reduce Payroll Time Resistance

Change
Lower Costs Timing
Time Tracking

Management Project Features

System

Improve UX

Total: 12 Total: 8
Techniques 20
10.16 DECISION ANALYSIS
• Decision Matrices
• Can be simple or weighted.
• A simple decision matrix totals the number of evaluation criteria
matched for each alternative.
Decision Matrices

• A weighted decision matrix computes the values of alternatives by

totaling up ranks of evaluation criteria multiplied by factors of their
importance.

Techniques 21
10.16 DECISION ANALYSIS
• Decision Matrices
• Simple decision matrix
Decision Matrices

Alternative 1 Alternative 2 Alternative 3

Criterion 1 Meets criterion n/a n/a

Criterion 2 Meets criterion Meets criterion Meets criterion

Criterion 3 n/a Meets criterion Meets criterion

Criterion 4 Meets criterion n/a n/a

Score 3 2 2

Techniques 22
10.16 DECISION ANALYSIS
• Decision Matrices
• Weighted decision matrix

Alternative 1 Alternative 2 Alternative 3

Decision Matrices

Weight Rank Value Rank Value Rank Value

Criterion 1 1 3 3 5 5 2 2

Criterion 2 1 5 5 4 4 3 3

Criterion 3 3 5 15 1 3 5 15

Criterion 4 5 1 5 5 25 3 15
Score 28 27 35

Techniques 23
10.16 DECISION ANALYSIS
• Decision Trees
• Are used for assessing the preferred outcome where multiple
sources of uncertainty exist.
• Allow for assessment of responses to uncertainty to be factored
across multiple strategies.
Decision Trees

• May include decision nodes, chance nodes, and terminator or end

nodes.
• Are also used in 10.17 Decision Modelling.

Techniques 24
10.16 DECISION ANALYSIS

Time Tracking System

Analytical Hierarchy Process

1.00

Cost User Integration Mobile App

0.55 Friendly 0.25 0.10
0.10
(AHP)

Solution 1 Solution 2 Solution 3

0.75 0.85 0.50

Techniques 25
10.16 DECISION ANALYSIS

Required Action within Control

Proposed Totally Partially Not

Totally- Partially -Not

Change
Time Tracking Finance is the
Integration with owner of
Payroll payroll,
Operations the
owner of time
entry process.

Manual to Operations is
Automatic the owner of
Tracking the time entry
process.

Techniques 26
10.16 DECISION ANALYSIS
• Trade-offs
• Are relevant when a decision problem involves multiple, possibly
conflicting, objectives.
• For more than one objective it is not sufficient to simply find the
maximum value for single variable.
• Methods for handling trade-offs include elimination of dominated
Elements

alternatives and ranking objectives on a similar scale.

Techniques 27
10.16 DECISION ANALYSIS
• Strengths
• Provides a prescriptive approach for determining alternate options.
• Helps to eliminate subjective biases in making decisions.
Usage Considerations

• Helps to avoid false assumptions.

• Encourages constructing appropriate metrics for comparing both
the financial and non-financial outcome evaluation criteria.

• Limitations
• Due to the effort required and the lack of necessary information,
may not suit decisions that must be made immediately.
• The results may be perceived as more certain than they are.
• Analysis paralysis can occur.
• May require specialized knowledge, such as math knowledge in
probability and strong skills with decision analysis tools.

Techniques 28
10.18 Document Analysis
(Pindy)
10.20 Financial Analysis
(Ron)
10.25 Interviews
(Ivy)
10.26 Item Tracking
(Alan)
10.26 ITEM TRACKING
• Purpose
• Used to capture issues and assign responsibilities in order to resolve
the issue in a timely fashion
Purpose and Description

• Description
• An organized approach to address issues, enhancements, defects,
or other concerns

Techniques 33
10.26 ITEM TRACKING
1. An item record may include
• A unique identifier
• A summary or description of the issue or defect
• A category or group of similar issues
• The date the issue was first identified
Elements

• The person who reported the issue

• The impact of the issue
• The priority of the issue
• The team member or owner who is assigned to manage the issue
until it is closed
• The status of the issue
• The date that the issue is resolved
• The resolution of the resolved issue
Techniques 34
10.26 ITEM TRACKING
2. Item Management
• Track the item from the date it was identified (or open) to its closure
3. Metrics: Track metadata regarding the item
resolution process Determines how well:
• Items are being resolved
Elements

• The initiative undertaken is progressing

• The tracking process is going

Techniques 35
10.26 ITEM TRACKING
• Strengths
• Ensures concerns around stakeholder requirements are captured,
tracked, and resolved.
Usage Considerations

• Allows ranking of items to determine importance level as compared

to other items.

• Limitations
• Stakeholders could become immersed in overly detailed data.
• The time and effort used to manage items may outweigh the benefits
of recording items.

Techniques 36
10.27 Lessons Learned
(Pindy)
10.29 Mind Mapping
(Sophie)
10.32 Organizational
Modeling
(Cecilia)
10.35 Process Modeling
(Holly)
10.35 PROCESS MODELING
• Purpose
• Process modeling is a standardized graphical model used to show
Purpose and Description

how work is carried out and is a foundation for process analysis.

• Description
• A process model can be constructed on multiple levels, each of
which can be aligned to different stakeholder points of view.
• At a high (enterprise or context) level, the model provides a
general understanding of a process and its relationship to other
processes.
• At lower (operational) levels, it can define more granular activities
and identify all outcomes, including exceptions and alternative
paths.
• At the lowest (system) level, the model can be used as a basis for
simulation or execution.
Techniques 41
10.35 PROCESS MODELING
• Description
• The business analyst can use a process model to define the
Purpose and Description

current state of a process (also known as an as-is model) or a

potential future state (also known as a to-be model).
• Process models generally include:
• The participants in the process
• The business event that triggers the process
• The steps or activities of the process (both manual and automated)
• The paths (flows) and decision points that logically link those activities
• The results of the process

Techniques 42
10.35 PROCESS MODELING
• Types of Models and Notations
• Many different notations are used in process modeling. The most
commonly used notations include the following:
• Flowcharts and Value Stream Mapping (VSM): used in the business
domain
• Data Flow diagrams and Unified Modelling Language TM (UML®)
Elements

diagrams: used in the information technology domain

• Business Process Model and Notation (BPMN): used across both
business and information technology domains; is increasingly adopted as
an industry standard
• Integrated DEFinition (IDEF) notation and Input, Guide, Output, Enabler
(IGOE) diagrams: used for establishing scope
• SIPOC and Value Stream Analysis: used for process modeling

Techniques 43
10.35 PROCESS MODELING
• Types of Models and Notations
• Process models typically contain some or all of the following key
elements:
• Activity: an individual step or piece of work that forms part of the
business process
• Event: a zero-time occurrence which initiates, interrupts, or terminates an
Elements

activity or task within a process or the process itself

• Directional Flow: a path that indicates the logical sequence of the
workflow. In general, diagrams are drawn to show the passage of time in
a consistent fashion
• Decision Point: a point in the process where the flow of work splits into
two or more flows (paths), which may be mutually exclusive alternatives
or parallels. A decision can also be used to locate rules where separate
flows merge together
• Link: a connection to other process maps
• Role: a type of person or group involved in the process. Its definitions
typically match those in the organizational model
Techniques 44
10.35 PROCESS MODELING
• Types of Models and Notations
• Flowchart: Flowcharts are used commonly with non-technical
audiences and are good for gaining both alignment with what the
process is and context for a solution.
• A flowchart can be simple, displaying just the sequence of
activities, or it can be more comprehensive, using swimlanes.
Elements

• A swimlane is a partitioned area (horizontal or vertical) that

segregates those activities in the process that are carried out by a
particular role.

Techniques 45
10.35 PROCESS MODELING
Use a real example or practic
Flowchart

Techniques 46
10.35 PROCESS MODELING
• Types of Models and Notations
• Business Process Model and Notation (BPMN) provides an
industry-standard language for modeling business processes in a
form that is accessible by both business users and technical
developers.
• BPMN is designed to cover many types of modeling, including both
Elements

internal (private) processes and collaborative (public) processes. It

can be the input to process automation technologies.
• A key feature of BPMN is its ability to distinguish the activities of
different participants in a process with pools and swimlanes.
• Commonly, a process includes one pool for the customer and a
second pool for the organization under study, although it is
possible for a process to include any number of pools.

Techniques 47
10.35 PROCESS MODELING
• Types of Models and Notations
• Business Process Model and Notation
Elements

Techniques 48
10.35 PROCESS MODELING
• Types of Models and Notations
• The Activity Diagram is one of the use case realization diagrams
defined in the Unified Modelling Language TM (UML®).
• Originally designed to elaborate on a single use case, the activity
diagram has been adopted for more general process modeling
purposes, including business process modeling.
Elements

• While similar in appearance to a flowchart, the activity diagram

typically employs swimlanes to show responsibilities,
synchronization bars to show parallel processing, and multiple exit
decision points.

Techniques 49
10.35 PROCESS MODELING
• Types of Models and Notations
• Activity Diagram
Elements

Techniques 50
10.35 PROCESS MODELING
• Strengths
• Appeals to the basic human understanding of sequential activities.
• Most stakeholders are comfortable with the concepts and basic
Usage Considerations

elements of a process model.

• The use of levels can accommodate the different perspectives of
various stakeholder groups.
• Effective at showing how to handle a large number of scenarios
and parallel branches.
• Can help identify any stakeholder groups that may have otherwise
been overlooked.
• Facilitates the identification of potential improvements by
highlighting “pain points” in the process structure (i.e. process
visualization).

Techniques 51
10.35 PROCESS MODELING
• Strengths
• Likely to have value in its own right. They provide documentation
for compliance purposes and can be used by business
Usage Considerations

stakeholders for training and coordination of activities.

• Can be used as a baseline for continuous improvement.
• Ensures labeling consistency across artifacts.
• Provides transparency and clarity to process owners and
participants on activity responsibilities, sequence and hand-overs.

Techniques 52
10.35 PROCESS MODELING
• Limitations
• To many people in IT, a formal process model tends to reflect an
older and more document-heavy approach to software
Usage Considerations

development. Therefore, project time is not allocated to developing

a process model, especially of the current state or problem
domain.
• Can become extremely complex and unwieldy if not structured
carefully. This is especially true if business rules and decisions are
not managed separately from the process.
• Complex processes can involve many activities and roles; this can
make them almost impossible for a single individual to understand
and ‘sign off’.

Techniques 53
10.35 PROCESS MODELING
• Limitations
• Problems in a process cannot always be identified by looking at a
high-level model. A more detailed model with reference to
Usage Considerations

metadata (such as path frequency, cost, and time factors) is

usually required. It is often necessary to engage with stakeholders
directly to find the operational problems they have encountered
while working with a process.
• In a highly dynamic environment where things change quickly,
process models can become obsolete.
• May prove difficult to maintain if the process model only serves as
documentation, as stakeholders may alter the process to meet
their needs without updating the model.

Techniques 54
10.38 Risk Analysis and
Management
(Cecilia)
10.38 RISK ANALYSIS AND MANAGEMENT
• Risk Identification
• Example of risk register
Example of risk register for pre-billing process Telecommunication Company (2007 Revenue: US$212 million)
# Risk Event or Condition Consequence Probability Impact Risk Level Risk Modification Plan Risk Owner Residual Risk
Probability Impact Risk Level
Billing is not correct Execute report of calls per hour and Patricia, Billing
(underestimated) switching centre Analyst/SME
Customer complaints due to If missing calls, call switching centre Patricia, Billing
Elements

wrong free minutes deducted coordinator (expert technician) Analyst/SME

If technician does not Fine by the Bureau of Consumer
1 High High High Low Medium Low
load all CDRs Protection

Revenue loss if customer cancels

phone line (Gov.)

Billing is not correct Execute report of tickets that

Patricia, Billing
(overestimated) and taxes are contains ticket number, ticket name;
If tickets or manual Analyst/SME
overpayed low, average, and highest amount
charges are duplicated
2 Customer complaints due to Low High High Delete suspicious ticket after Cecilia, Billing Low Low Low
or entered with wrong
duplicated charges verifying certain conditions Manager
amount
Fine by the Bureau of Consumer
Protection
If customer tax rate is
Execute report of Residential Salvador, Billing
3 incompatible with Loss of revenue Low Medium Low Low Low Low
customers with tax rate equal to zero Analyst/SME
customer category
Patricia, Billing
Execute report of local and national
Analyst/SME &
4 If call is 23 hours long Loss of revenue due to fraud Medium High High calls with a duration greater than 23 Low Low Low
Rebecca, Fraud
hours
Analyst
Elaborated by Cecilia Vasquez Vancouver, Oct/10/2017

Techniques 56
10.40 Root Cause
Analysis
(Holly)
10.40 ROOT CAUSE ANALYSIS
• Purpose
• Root cause analysis is used to identify and evaluate the
Purpose and Description

underlying causes of a problem.

• Description
• Root cause analysis is a systematic examination of a problem or
situation that focuses on the problem's origin as the proper point of
correction rather than dealing only with its effects.
• Root cause analysis looks at the main types of causes such as
people (human error, lack of training), physical (equipment failure,
poor facility), or organizational (faulty process design, poor
structure).

Techniques 58
10.40 ROOT CAUSE ANALYSIS
• Description
• Root cause analysis helps organize the information in a framework,
Purpose and Description

which allows for deeper analysis if needed. Root cause analysis

can be used for:
• Reactive Analysis: identifying the root cause(s) of an occurring problem
for corrective action
• Proactive Analysis: identifying potential problem areas for preventive
action.
• Root cause analysis uses four main activities:
• Problem Statement Definition: describes the issue to be addressed.
• Data Collection: gathers information about the nature, magnitude,
location, and timing of the effect.
• Cause Identification: investigates the patterns of effects to discover the
specific actions that contribute to the problem.
• Action Identification: defines the corrective action that will prevent or
minimize recurrence.
Techniques 59
10.40 ROOT CAUSE ANALYSIS
• A fishbone diagram (also known as an Ishikawa or cause-and-
effect diagram) is used to identify and organize the possible
The Fishbone Diagram

causes of a problem.
• This tool helps to focus on the cause of the problem versus the
solution and organizes ideas for further analysis.
• The diagram serves as a map that depicts possible cause-and-
effect relationships.

Techniques 60
10.40 ROOT CAUSE ANALYSIS
Replace with a real
example
The Fishbone Diagram

Techniques 61
10.40 ROOT CAUSE ANALYSIS
• The five whys is a question asking process to explore the nature
and cause of a problem.
• The five whys approach repeatedly asks questions in an attempt to
get to the root cause of the problem.
The Five Whys

• This is one of the simplest facilitation tools to use when problems

have a human interaction component.
• To use this technique:
1. Write the problem on a flip chart or whiteboard.
2. Ask "Why do you think this problem occurs?" and capture the idea
below the problem.
3. Ask "Why?" again and capture that idea below the first idea.
Continue with step 3 until you are convinced the actual root cause has
been identified.

Techniques 62
10.40 ROOT CAUSE ANALYSIS
• This may take more or less than five questions—the technique is
called the five whys because it often takes that many to reach the
root cause, not because the question must be asked five times.
• The five whys can be used alone or as part of the fishbone
The Five Whys

diagram technique.
• Once all ideas are captured in the diagram, use the five whys
approach to drill down to the root causes.

Techniques 63
10.40 ROOT CAUSE ANALYSIS
• Strengths
• Helps to maintain an objective perspective when performing cause-
and-effect analysis.
Usage Considerations

• Enables stakeholders to specify an effective solution at the

appropriate points for corrective action.

• Limitations
• Works best when the business analyst has formal training to
ensure the root causes, not just symptoms of the problem, are
identified.
• May be difficult with complex problems; the potential exists to lead
to a false trail and/or dead end conclusion.

Techniques 64
10.50 Workshops
(Paula)
10.50 WORKSHOPS
• Purpose
• Workshops bring stakeholders together in order to collaborate on
Purpose and Description

achieving a predefined goal.

• Description
• A workshop is a focused event attended by key stakeholders
and subject matter experts (SMEs) for a concentrated period of
time.
• May be held for different purposes including planning, analysis,
design, scoping, requirements elicitation, modelling, or any
combination of these.

Techniques 66
10.50 WORKSHOPS
• Workshops generally include:
• A representative group of stakeholders
Purpose and Description

• A defined goal: generate ideas for new features or products, reach

consensus on a topic, or review requirements or designs.
• Interactive and collaborative work
• A defined work product
• A facilitator: experienced, neutral; may be a team member
• A scribe
• A business analyst may be the facilitator or the scribe in these
workshops.

Techniques 67
10.50 WORKSHOPS
Prepare for the Workshop
• When preparing for a workshop, business analysts:
• Define the purpose and desired outcomes,
• Identify key stakeholders to participate,
• Identify the facilitator and scribe,
Elements

• Create the agenda,

• Determine how the outputs will be captured,
• Schedule the session and invite the participants,
• Arrange room logistics and equipment,
• Send the agenda and other materials in advance to prepare the
attendees and increase productivity at the meeting, and
• If appropriate, conduct pre-workshop interviews with participants.

Techniques 68
10.50 WORKSHOPS
• Workshop Roles
• Sponsor
• Frequently not a participant in the workshop, but does have ultimate
accountability for its outcome
• Facilitator
Elements

• Establishes a professional and objective tone for the workshop

• Introduces the goals and agenda for the workshop
• Enforces structure and ground rules
• Keeps activities focused on the purpose and desired outcomes
• Facilitates decision making and conflict resolution
• Ensures that all participants have an opportunity to be heard

Techniques 69
10.50 WORKSHOPS
• Workshop Roles
• Scribe
• Documents the decisions reached during event in the format determined
prior to the workshop
• Keeps track of any outstanding items or issues
Elements

• Timekeeper
• May be used to keep track of the time spent on each agenda item.
• Participants
• Includes key stakeholders and subject matter experts
• Are responsible for
• providing their input and views,
• listening to other views, and
• discussing the issues without bias.

Techniques 70
10.50 WORKSHOPS
• Conduct the Workshop
• Facilitators generally begin the workshop with a statement of its
purpose and desired outcomes.
• Establishing agreed-upon ground rules can be an effective method
for establishing a productive environment for collaboration.
Elements

• Throughout the workshop, the facilitator maintains focus by

frequently validating the session’s activities with the workshop’s
purpose and outcomes.

Techniques 71
10.50 WORKSHOPS
• Post Workshop Wrap-Up
• Facilitator
• follows up on any open action items that were recorded at the workshop,
• completes the documentation, and
• distributes documentation to the workshop attendees and any
Elements

stakeholders who need to be kept informed of the work done.

Techniques 72
10.50 WORKSHOPS
• Strengths
• Can be a means to achieve agreement in a relatively short period
of time.
Usage Considerations

• Provides a means for stakeholders to communicate, collaborate,

make decisions, gain trust, and build a mutual understanding.
• Costs are often lower than the cost of performing multiple
interviews.
• Feedback on the issues or decisions can be provided immediately
by the participants.

Techniques 73
10.50 WORKSHOPS
• Limitations
• Stakeholder availability may make it difficult to schedule the
workshop.
Usage Considerations

• The success of the workshop is highly dependent on the expertise

of the facilitator and knowledge of the participants.
• Workshops that involve too many participants can slow down the
workshop process.
• Conversely, collecting input from too few participants can lead to
the overlooking of needs or issues that are important to some
stakeholders, or to the arrival at decisions that don't represent the
needs of the majority of the stakeholders.

Techniques 74
CHAPTER 9 Underlying Competencies

Group Practice

Watermark Online Exam

75