HCI Lecture 18 socio-organizational part 1

Lecture 18
socio-organizational
issues and stakeholder
requirements –Part 1
Today’s Topics
Introduction to Social Aspects of system
 What are Requirements?
 Organizational Issues
 Capturing Requirements

 Socio
Technical Model
 Custom Method
 Open System Task Analysis
Introduction
The different people affected by the
introduction of a system are known as
stakeholders and their needs can be both
complex and conflicting.
 Introduction of a new system effect the
organizational and work practices in any
organization.

 Several
issues can effect the acceptance of
new technology.
Introduction

Requirement engineering mostly focus on
functional requirements.
 what

the system must be able to do
Mostly less emphasis is given on nonfunctional human issues such as usability
and acceptability.
Requirements?

Requirements are statements of
 what
the system must do,
 how it must behave,
 the properties it must exhibit,
 the qualities it must possess, and
 the constraints that the system and its
development must satisfy.
Requirement Engineering

Requirements engineering emphasizes
the use of systematic and repeatable
techniques that ensure the completeness,
consistency, and relevance of the system
requirements [Sommerville 1997a].
Requirement Engineering
Functional Requirement

A functional requirement describes what a
software system should do
 For
example, functional requirement would be
that a system must send an email whenever a
certain condition is met (e.g. an order is
placed, a customer signs up, etc).
Usability

Usability is the measure of a product's
potential to accomplish the goals of the
user.
Acceptance

Typical scenarios under which user will
use the accepted system.
 Real
world testing of user acceptance or beta
testing corresponds to the acceptance of
software system.
Organization issues

There are several organizational issues
that effect the acceptance and relevance
of
information
and
communication
systems.
Organizational Issues

These mainly includes
 Cooperation
or conflict?
 Changing Power Structures
 The Invisible Worker
 The beneficiaries
 Free Rider Problem
 Critical Mass
 Automating Process Workflow and (BPR)
Business Process Reengineering
 Benefits Evaluation
Cooperation or Conflict?
The term ‘computer-supported cooperative
work’ (CSCW) seems to assume that
groups will be acting in a cooperative
manner.
 People in organizations and groups have
conflicting goals, and systems that ignore
this are likely to fail spectacularly.

An Example
Imagine that an organization is already highly
computerized, the different departments all have
their own systems and the board decides that an
integrated information system is needed. The
production manager can now look directly at
stocks when planning the week’s work, and the
marketing department can consult the sales
department’s contact list to send out marketing
questionnaires. All is rosy and the company will
clearly run more efficiently – or will it?
Conflicting Requirements

If the user requirements are not fully
understood,
 The
system will gradually lose respect as the
data it holds is incorrect,
 Confidence in the organization suffers and
productivity drops.
Changing power structures

The identification of stakeholders will
uncover information transfer and power
relationships
that
cut
across
the
organizational structure.
 However,
the official lines of authority and
information tend to flow up and down through
line management.

New
communications
challenge and disrupt
managerial structures.
media
may
these formal
Changing Power Structures

The physical layout of an organization
often reflects the formal hierarchy:
 Each
department is on a different floor, with
sections working in the same area of an
office.
 If someone from sales wants to talk to
someone from marketing then one of them
must walk to the other’s office.
Changing Power Structures

The ‘levelling’ effect even makes it
possible for subordinates to direct
messages
‘diagonally’
across
the
hierarchy, to their manager’s peers, or,
even worse, to their manager’s manager!
 Email
messaging helps doing so!
Changing Power Structures

Technology can be an important vector of
social change, but if violent reaction is
to be avoided, the impact of the
technology must be assessed before it is
introduced.
 In
the short term, solutions must be carefully
matched to the existing social and
organizational structures.
The invisible worker

The ability to work and collaborate at a
distance can allow functional groups
to be distributed over different sites.
 For
example, cross-functional neighborhood
centers, where workers from different
departments do their jobs in electronic contact
with their functional colleagues.
The Invisible Workers -- Problems

Management by Presence
the approach in an organization is ‘management by
presence’, that is someone is working because they
are in the office, then there is no way a remote worker
is going to be trusted.
 If

Management by Objectives
the style is ‘management by objectives’, that is the
subordinates are working because they are doing
their jobs and producing results. Then there will be no
problem.
 If
The Beneficiaries

Main problem is people who get benefited from
the system are different from people who work in
the system.
 For
example, a shared calendar system, Manager is a
beneficiary of meeting schedules but personal
secretary works to enter schedules.
 Chaos
is
resulted
when
a
meeting
is
automatically arranged and the subordinates may
have to rearrange commitments that have not been
recorded on the system.
Symmetry in IS

Information systems should aim for some
level of symmetry.
 “If
you have to do work for the system, you
should obtain some benefit from it.”
Free Rider Problem

This occurs when people can enjoy a good
service without paying anything (or making
a small contribution less than their benefit.
 This
issue is termed as free rider problem.
A few free riders in a system are often not
a problem, as the danger is more likely
from too much activity.
 This problem can be managed by
increasing the visibility of participants.

Critical Mass
It is a very important or crucial stage in a
company's development, where the
business activity acquires self-sustaining
capability.
 When a company reaches critical mass, it
is thought that they can remain viable
without having to add any more
investment.

 Free
rider problem solutions need to develop
critical mass for a technology.
Critical Mass

The beneficiaries of the
increases its pervasiveness.
 More
technology
people talk about technology, the more
it will be common.
Critical mass
strong benefit when
lots of users
.. but little benefit
for early users
solution – increase
zero point benefit
Automating processes Workflow
and BPR

A major problem in many organizations is
“paper work”.
 Workflow
systems aim to automate such
work.

Workflow systems aim to automate much
of the process using electronic forms,
which are forwarded to the relevant person
based on pre-coded rules.
Business Process Reengineering

Business Process Reengineering (BPR) is
defined as the fundamental rethinking and
radical redesign of business processes to
achieve dramatic improvements in critical
contemporary measures of performance
such as cost, quality and speed.
Business Process Reengineering

BPR aims to make the structure of an
organization
serve
the
flow
of
products/services and result in the
production
of
leaner
and
fitter
organizations.
BPR

It posses,
 Identify
business processes
 Review, update & analyze as-is business processes
 Design to-be business processes
 Test & implement to-be business processes
Evaluating the benefits
After successful installation of system,
benefits in term of cost should be
calculated.
 Some benefits may be in terms of job
satisfaction.

 For

example email facility.
Some other
quantify.
benefits
are
difficult
to
Capturing Requirements

Problems can arise when a system is
introduced without a full understanding of
all the people who will be affected by it.

In order to better understand and support
complex
organizational
structures,
workgroups and potentially conflicting
stakeholder needs, we capture and
analyze information
Capturing Requirements

There are several approaches:
 Socio-technical
modeling,
 Soft systems methodology,
 Participatory design,
 Ethnographic methods and
 Contextual inquiry.

All are aimed at understanding the reality
of work contexts and the perspectives of
different stakeholders.
Stakeholders?
Anyone who is affected by the success or
failure of the system is a stakeholder.
 Understanding stakeholders is key to
many of the approaches to requirements
capture.

Stakeholders

Types
a)Primary stakeholders -people who actually use the system –
the end-users.
b) Secondary stakeholders - people who do not directly use the
system, but receive output from it or provide input to it.
c) Tertiary stakeholders - people who do not fall into either of
the first two categories but who are directly affected by the
success or failure of the system
d) Facilitating stakeholders - people who are involved with the
design, development and maintenance of the system.
Who are the stakeholders?
Example: Classifying stakeholders – an airline booking
system
An international airline is considering introducing a new
booking system for use by associated travel agents to sell
flights directly to the public.
Primary stakeholders: travel agency staff, airline booking
staff
Secondary stakeholders: customers, airline management
Tertiary stakeholders: competitors, civil aviation
authorities, customers’ travelling companions, airline
shareholders
Facilitating stakeholders: design team, IT department staff
Who are the stakeholders?

Designers need to meet as many
stakeholder needs as possible
 usually
in conflict so have to prioritise
 often priority decreases as move down
categories e.g. primary most important
 not always e.g. life support machine
Socio Technical Model

Early in the twentieth century, studies of
work focused on how humans needed
to adapt to technical innovations.
 The
socio-technical stress that work systems
were composed of both human and machine
elements and that it was the interrelationship
between these that should be central.
Socio-Technical Model

Socio-technical models for interactive
systems are therefore concerned with
 technical,
 social,
 organizational
and
 human aspects of design.
Socio Technical Model

Recognizes the fact that technology is not
developed in isolation but as part of a
wider organizational environment.
 It
is important to consider social and technical
issues side by side so that human issues are
not overruled by technical considerations.
Socio-Technical Models

The key focus of the socio-technical
approach is to describe and document the
impact of the introduction of a specific
technology into an organization.

Information gathered using interviews,
document analysis etc.
Socio-Technical Models

Identify and describe:
 organizational

context
primary goals, historical background
 stakeholders

motivation, job satisfaction, knowledge, skills, power,
tasks, needs for training
 workgroups

43
role, characteristics, relationships within/without the
organization
Socio-Technical Models

Try to capture:
 The

There is a need to understand why the technology
is being proposed and what problem it is intended
to solve.
 The

problem being addressed
stakeholders affected
Including primary, secondary, tertiary and
facilitating, together with their objectives, goals and
tasks.
Socio-Technical Model

Socio Technical model captures
 Workgroups


The workgroups within the organization, both
formal and informal.
Change

The changes or transformations that will be
supported.
technology and how it’ll work
 External constraints
 Proposed
Custom Methodology

CUSTOM
is
a
socio-technical
methodology designed to be practical to
use in small organizations.

It is based on the User Skills and Task
Match (USTM) approach, developed to
allow design teams to understand and fully
document user requirements.
CUSTOM Methodology

CUSTOM
focuses
on
stakeholder requirements:
establishing
 all
stakeholders are considered, not just the
end-users.
Applied to initial stage of design.
 Provides useful framework for considering
stakeholder requirements.

Custom Methodology

Six key stages to carry out.
Describe
the
organizational
context,
including its primary goals, physical
characteristics, political and economic
background.
2. Identify and describe stakeholders.
1.

All stakeholders are named, categorized (as
primary, secondary, tertiary or facilitating) and
described
with
regard
to
personal
issues, their role in the organization and their job.
Custom Methodology
3.
Identify and describe work-groups.

A work-group is any group of people who
work together on a task, whether formally
constituted or not.
 Work-groups are described in terms of their
role within the organization and their
characteristics.
CUSTOM Methodology
4.
Identify and describe task–object pairs.
 These
are the tasks that must be performed,
coupled with the objects that are used to
perform them or to which they are applied.
CUSTOM Methodology
5.
Identify stakeholder needs.
 Stages
2–4 are described in terms of both the
current system and the proposed system.
 Stakeholder
needs are identified by
considering the differences between the two.

For example, if a stakeholder is identified as
currently lacking a particular skill that is required in
the proposed system then a need for training
identified.
CUSTOM Methodology
6.
Consolidate and
requirements.
 Here
check
stakeholder
the stakeholder needs list is checked
against the criteria determined at earlier
stages.
CUSTOM Stakeholder Analysis

CUSTOM questions investigate a range of
stakeholder characteristics, such as the
following,
 What
does the stakeholder have to achieve? How is
success measured?
 What knowledge and skills does the stakeholder
have?
 What attitude towards computer technology does the
stakeholder have?
 Does the stakeholder have to consider issues of
responsibility, security, or privacy?
 etc.
53
Open System Task Analysis (OSTA)

An alternative socio-technical approach.
 attempts
to describe what happens when a technical
system is introduced into an organizational work
environment.

Like CUSTOM, OSTA specifies both social and
technical aspects of the system.
 However,
whereas in CUSTOM these aspects are
framed in terms of stakeholder perspectives, in OSTA
they are captured through a focus on tasks.
OSTA Stages

Eight main stages
The primary task which the technology must
support is identified in terms of users’ goals.
2. Task inputs to the system are identified.
These may have different sources and forms
that may constrain the design.
3. The external environment into which the
system will be introduced is described,
including physical, economic and political
aspects.
1.
OSTA Stages
The transformation processes within the
system are described in terms of actions
performed on or with objects.
5. The social system is analyzed, considering
existing work-groups and relationships
within and external to the organization.
6. The technical system is described in terms
of its configuration
and integration
with other systems.
4.
OSTA Stages
 Performance
satisfaction
criteria
established, indicating the social
technical requirements of the system.
 The new technical system is specified.

are
and
OSTA uses notations familiar to designers,
such as data flow diagrams and textual
descriptions.
Summary of Today’s Topics
There are several organizational issues
that affect the acceptance of technology
by users and that must therefore be
considered in system design: systems
may not take into account conflict and
power relationships.
 Those who benefit may not do the work
 Not everyone may use systems.

Summary
In addition to generic issues, designers
must
identify
specific
stakeholder
requirements within their organizational
context.
 Socio-technical
models capture both
human and technical requirements.
