11.1

Organisational Themes;People themes

Semester 2, 2005

IMS3230 - Information Systems Development Practices

11.2

References

Avison, D.E. & Fitzgerald, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London. Chapters 1, 4.2-4.6, 6.6, 7, 15, 16

Kolb, D.A., Rubin, I.M. and Osland, J. (1995). Organisational Behaviour: An Experiential Approach. (6th ed) Prentice-Hall, Englewood Cliffs.

Schermerhorn, J.R., Hunt, J.G. and Osborn, R.N. (2000). Managing Organizational Behavior. (7th ed). Wiley, New York.

11.3

Strategic information systems Business process re-engineering (BPR) Information systems planning Organisational change

Organisational themes in ISD

11.4

strategic information systems:

early computerisation focused on basic transaction processing:

cost savings quantifiable, perform same processing more efficiently

limitations of further efficiency gains:

opportunities limited as more projects completed

some opportunities unlikely to demonstrate these types of savings

emergence of an additional role for information systems and IT:

a direct tool for gaining competitive advantage

Organisational themes in ISD

11.5

strategic information systems

use information systems to improve the business in the market place:

competitive advantage:

- redefine the boundaries of specific industries

- develop new products and services

- change the relationships between customers and suppliers

- establish barriers to deter new entrants to the market place

cost justifications more difficult:

- benefits are not reduced costs

- need to show that benefits (e.g. improved service) will be recognised

- implications for methodologies

11.6

business process re-engineering (BPR):

opportunity to re-engineer business processes which is enabled by technology:

“the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed”

Hammer and Champy (1993)

what an organisation should do, how it should do it, what its concerns should be, not what they currently are

Business process re-engineering (BPR)

11.7

motivations for re-engineering

- no choice commercially

- competitive forces require re-aligning business processes with strategic positioning

- organisation management see re-engineering as an opportunity to streamline and to overtake their competitors

- the “band wagon” effect: copy the competitors

Business process re-engineering (BPR)

11.8

Hammer and Champy’s model

- combine several jobs which are performed by a “case worker” responsible for an entire process

- “case team” members are empowered to find ways to:

improve service and quality, reduce costs and cycle times

- process integration means less checks and controls

- less defects as the entire process is completed by those responsible for the final product

- process steps determined by those completing the task

- parallel processing of entire operations is possible

Business process re-engineering (BPR)

11.9

BPR: experiences of project failures (and failure rates)

- senior managers lack motivation for organisational change: BPR must be driven from the top

- extent of necessary change not fully recognised

- piecemeal approaches mean individual process gains not translated into organisational level improvement

- failure by top management to adequately define future operations

- non-critical business operations addressed

- motivation is publicity/bandwagon or management’s reputation

- short-term financial pressures result in lack of resources

- BPR is radical change, not TQM etc.

Business process re-engineering (BPR)

11.10

planning approaches:

stress the planning required to develop an organisation’s information systems

top management involved in analysing the organisation’s objectives

plan for the use of IS/IT to achieve the business objectives

avoid a piecemeal approach to IS development

align IS/IT with the business

planning at three levels: long term, medium term, short term

Information systems planning

11.11

- organisation-wide perspective promotes integration

- involvement of top management

- IBM's BSP (Business Systems Planning 1975)

• strategic management view of entire organisation

• top management defines organisational needs

and priorities

• establish a stable information architecture

• implementation from bottom up

Information systems planning approaches

11.12

introducing and managing organisational change:

- new information systems

- new information technology

for systems development:

- new system development methodologies

- new system development technologies

- new system development techniques user perspectives systems developers as users: changing roles and technology

Organisational change

11.13

organisational targets for change (Kolb et al 1991) the people subsystem:

personnel flow, education the authority subsystem:

formal authority relationships, informal leadership patterns the information subsystem: formal, informal the task subsystem: job satisfaction, technology the policy/culture subsystem: formal explicit, informal implicit the environmental subsystem: internal physical environment,

external environment

Organisational change

11.14

resistance to change: feedback that can be used constructively by the change agent why do people resist change?

- fear of the unknown

- doubts about future competence

- comfort with the status quo

- vested interests threatened

- “surprise” factor

- poor timing

- lack of resources

- job security

Organisational change

11.15

Organisational change

three phases of planned change:

1. unfreezing

2. changing

3. refreezing

11.16

Organisational change

acceptance criteria for changes:

changes must have clear, appropriate benefits

changes must be compatible with existing values and experiences

changes must not be too complex

changes should be able to be tried on an incremental or experimental basis

11.17

Organisational change

strategies for gaining support for change:

force - coercion: legitimacy, rewards, punishment

rational persuasion: expert power, rational argument

shared power: trust-based, common vision

11.18

Organisational change

dealing with resistance to change:

(Schermerhorn et al 1994)

• education and communication

• participation and involvement

• facilitation and support

• negotiation and agreement

• manipulation

• explicit and implicit coercion

11.19

SCOUTING

ENTRY

DIAGNOSIS

PLANNING

ACTION

EVALUATION

INSTITUTIONALISATION

The Process of Planned Change

Kolb et al (1991) p. 593

Initiating and managing change

11.20

scouting

determine readiness for change, obvious obstacles

entry

negotiate a "contract" with entry point representatives

diagnosis

the perceived problem, goals, resources available

planning

define change objectives, alternative solutions, strategies

action

implement change: activities, resistance, monitor

evaluation

relate to objectives

institutionalisation

complete vs continuous

Initiating and managing change

11.21

Some potential solutions:

Participative approaches Management commitment/leadership Improved human-computer interfaces Training and education: developers and business

users End user computing JRP and JAD sessions

People themes in ISD

11.22

User participation

early systems development approaches:

- focus on technical aspects of computer systems

- little actual decision-making by users

problems:

- users resented developers as “outsiders” with little understanding of the business environment

- systems “imposed” on users and not “user friendly”

- systems did not adequately support business needs

11.23

User participation: definitions

Barki and Hartwick (1989) distinguish between:

user participation

a set of activities and behaviours performed by users

user involvement

a subjective, psychological state when a user considers a system to be both important and personally relevant

How do these affect system usage and user satisfaction?

How can we define and measure user satisfaction?

11.24

User participation: definitions

participation as user involvement in systems design:

“ a process in which two or more parties influence each other in making plans, policies or decisions. It is restricted to decisions that have future effects on all those making the decisions or those represented by them”

(Mumford 1983, p. 22)

participation may have different meanings for different groups:

e.g. morally right, employee commitment, management tool, empowerment of employees etc.

11.25

three levels are identified by Mumford (1983): consultative

all users are consulted about/contribute ideas to the design process but the design task is carried out by systems analysts

representative

design groups formed from elected or selected representatives take design decisions

consensus

design group members constantly discuss ideas and solutions with all users

Mumford’s three levels of user participation

11.26

expected benefits of user participation: improved system quality:

more complete, accurate requirements

provides expertise about the organisation

avoids development of unacceptable or unimportant features

improves user understanding of the system increased user acceptance:

realistic expectations

“arena” for conflict resolution

users more committed to the system

decreased user resistance

User participation

11.27

User participation and ISD methodologies Structured analysis

user walkthroughs, users select implementation option SSADM

user walkthroughs, user representation in development teams, users select technical option,

Information Engineering

users active in design activities, management involved in ISP and BAA, user reviews

SSM

users part of team: problem owners and solvers ETHICS

users do the design

11.28

End-user computing Enabled by PCs and application packages for non-IT

people

e.g. spreadsheets, database, VisualBASIC etc Users in business organisations were able to build their

own business applications, either stand-alone or integrated with organisational systems

Definitions of end-user computing:

e.g.

“the practice of end-users developing, maintaining, and using their own information systems”

(Mirani and King 1994)

11.29

Early 1980s: user-driven computing

-end-user computing enabled by introduction of PCs

-decentralisation of computing resources

Resulted in user satisfaction:

-met needs unlikely to be satisfied by IT departments

-some pressure off IT departments

-end-users “close” to the business problems

-systems resourced/costed within user department budgets

End-user computing

11.30

problems of control:

validity and integrity of data

lack of documentation

security issues

maintainability

application “islands”

duplication and inconsistencies

assistance required by users

End-user computing

11.31

A “solution”: Information Centres

-Staffed and run by IT department

-Provide consultation, software and tools, liaison with vendors etc. to assist users in developing their own departmental information systems

Significant in 1980s and early 1990s Increasingly sophisticated users of today have no need

for Information Centres Users today need support from IT corporate specialists

when developing customer-oriented systems in particular

i.e. change from the tactical, problem-solving role of the past to a strategic, consultant role

End-user computing

11.32

can be for analysis and/or design originated in late 1970s at IBM bring together key users, managers, systems analysts in a group

meeting with a specific structure of roles and agenda JRP (Joint Requirements Planning): key system requirements JAD: specify the system’s design (external design only) group meeting:

avoid distractions

identify areas of agreement and conflict

resolve conflicts during the period of sessions

JAD (Joint Application Development)

11.33

JAD participants:

facilitator: organise and run the sessions scribe(s): takes notes on a PC, CASE tool etc users: understand the system requirements managers: organisational overview systems analysts: technical knowledge,

learn about the system sponsor: senior executive who commits and funds

the process

JAD sessions: roles

11.34

JAD sessions: from one to five days structured meeting room with white boards etc.,

CASE tools located away from users’ workplace outcome is documents detailing the system:

workings of/requirements for the system/design

Joint Application Development (JAD)

11.35

JAD sessions

benefits: reduced time to move requirements/design forward

(group vs one-on-one, details worked on between meetings)

key people work together to make important decisions commitment is focused and intensive, not dissipated

over time conflicts and differences can be understood and

resolved

improved quality and productivity