Application of PrinciplesApplication of Principles

Discussion of principles in

User Centred Methods

Computer System for Asylum SeekersComputer System for Asylum Seekers

• £77 million system• Plan to reduce time consuming paperwork• Installed 1998 and dogged by problems• Immigration Service Union

– current methods of dealing with asylum seekers virtually collapsed– process is a “criminal racket”

• Immigration and Nationality Directorate have had to take thousands of extra staff

• 69,000 processed in 2000, only 9000 left country• 2001 - 66,000 application backlog• Political party involvement• 2003 - 15,000 asylum seeking families allowed to stay in the UK

NHS Systems ModernisationNHS Systems Modernisation• System designed to allow doctors to access information

(through patient records) whether at local GP surgery or in hospital or outside local NH Trust area

• Declared cost £6.2 billion• Estimated total costs between £18.6 and £31 billion• NHS systems developer quoted in Computer Weekly

(2004)– “It is generally accepted in the IT industry that implementation

costs are some 3 to 5 times the cost of procurements.That is reflected in the business case that was made for the national programme”.

User concerns with systems User concerns with systems developmentdevelopment

• IT people have too much power and control over departments through use of technology

• IT people have elevated status in the organisation

• IT people continue to be highly paid even though IT systems often fail !

• exacerbated by lack of communication and use of jargon

Principle of User Centred Principle of User Centred ApproachApproach

• Addresses many of the issues associated with system development / software development failure

• Ownership of process• Helps address risk• Taps into source of knowledge• Embeds socio-technical, cultural and

organisational issues

Reasons for User ParticipationReasons for User Participation

• Ethics– people have the basic right to control their own

destinies

• Expediency– if people do not have a say in decisions or changes,

they are more likely to reject

• Expert Knowledge– people who do the job are experts on the job

• Motivating force– participation is a great motivator

Principle of Involving Users in Principle of Involving Users in System DevelopmentSystem Development

• Derived from socio-technical satisfaction fit model

1. knowledge fit• knowledge being developed to make staff increasingly competent

2. psychological fit• job matches employee’s status, advancement and work interest

3. efficiency fit• effort-reward bargain• work controls matching employees expectations• supervisory controls

4. task-structure fit• degree to which tasks are demanding or fulfilling

5. ethical fit• match between employee values and organisational values

Who are the Users ?Who are the Users ?

Potential users?

Internal/external

Position inorganisation

Skill & knowledge

Frequency ofuse

Prescribed orad hoc use

Physicalcharacteristics

Values, interests,background...

Direct / indirect

Other considerations ...

StakeholdersStakeholders

• “all those claimants inside and outside the organisation who have a vested interest in the problem and its solution.”

(Mason & Mitroff, 1981)

Systems Development and Systems Development and OrganisationOrganisation

Systems Development Organisation

Purpose

Direction

ChangeProgramme

ChangeProject

ActionsandDeeds

AllowableBehaviour

Culture

BeliefSystem

GuidingPrinciples

IT, the User, and Organisational IT, the User, and Organisational ChangeChange

• Eason (1988) states that “the introduction of information technology can revolutionise organisational life”.

• add in the pace of change and the magnitude of change and the impact becomes greater !

• organisational change can take one of two forms– planned, as part of the introduction of systems

development, see Collinson (1993)– reactive, as a result of implementing information

system, see Buchanan and Huczynski (1991)

Model of DevelopmentModel of Development

Feasibility

Analysis Prototype

Design andBuild

PlanIncrement

RollOut

UserAcceptance

Development spectrumDevelopment spectrum Rapidity ofDevelopment

Degree ofRigour

Hacking CodeTogether

Development Projects

Formal Methods

highly visible user interfaces

well defined narrow user community

few system interfaces

definable immediate business value

quality criteria not a big issue

time-boxing is viable

high degree of potential commonality

wide user community

stringent quality criteria

value is not always immediate

interface between legacy software, dbases and software packages

timeboxing not viable

Users and DevelopmentUsers and Development

Working together or against each other ?

??Empowerment or Deskilling?

Types of user (1)Types of user (1)

Primary - regular, direct users of the system Secondary - occasional users of interactive

systems, or those who work with system outputs

Tertiary - people who don’t use the system themselves but are affected by its operation, often customers or suppliers.

From Eason, (1988)

Types of user (2) Types of user (2)

• Governing body– part of organisation which determines strategy

• Sponsor– commissioner of system

• User specifier (ambassador user in DSDM)– key user with knowledge

• End user– operators

• Input generator– non-direct users who generate data, e.g. sales rep

• Output receiver– non-direct users who get information from the system

From Lodge (1989)

Types of Computer UserTypes of Computer UserUser Type Task Frequency

Complexity of Use Adaptability

Professional High High High

Enthusiast High Low High

Servant Low High High

Malleable User Low Low High

Needful User High Low Low

Demanding User High High Low

Habitual User Low High Low

Forgetful User Low Low Low

Derived from (Eason, 1988; Smith, 1997)

Factors in Measuring User Skill LevelFactors in Measuring User Skill Level

Low High

HighHigh

IT literacy

ApplicationKnowledge

Specific systemKnowledge

Novice

Expert

The Needs of the User Modelled !The Needs of the User Modelled !

UserNeeds

Functionaloperational taskrequirements

Physicalability / disabilityergonomic adaptability

Aspirationaljob satisfactionrewards

Functional - performs the specific tasks which the users require itto do in the operational situation

Physical - performs the tasks in a manner that is well suited to thephysical characteristics of the user

Aspirational - supports the medium to long-term personal goals of theuser

Initiation

Feasibility

Analysis

Design

TestingImplementation

OperationMaintenance

Users in the Development Life CycleUsers in the Development Life Cycle

Managers commission project and givestrategic requirements

Mangers and end users providefunctional requirements

Mangers and end users provide functional requirements, possible role in participativedesign

possible role in participativedesign

Mangers and end users,

End users take part in trials

Allusers

User Choice in Involvement !User Choice in Involvement !

• Do users have a choice in getting involved in systems development ?

• Do users have a choice in whether they use systems or not ?

• Managers may have discretion in whether they get involved or not !

• Operational users are more likely not to have the choice !

Changing RolesChanging Roles

• nature of systems changing

• nature of project development changing

• skills required changing

• tools available are developing

• need to work closely with other groups

• more technical requirements ?

UserUser AcceptabilityAcceptability

• Acceptability consists of usability and satisfaction• ISO definitions :

– usability “the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals”

• to take into account the user and the organisation

– satisfaction “the comfort and acceptability of the system”• relates to individual attitude within an organisational context

• Acceptability affected by :– resistance and rejection– attitude and behaviour

Change as a Result of Systems Change as a Result of Systems DevelopmentDevelopment

• introduction of computer systems leads to some form of change !

• change processes often involve conflicts of interest• successful implementation of systems requires careful

negotiation between affected parties• conflicts need to be brought into the open• Fullan (1991) argues that “conflict and disagreement are

not only inevitable but fundamental to successful change” • Mumford (1995) argues that “successful change strategies

require institutional mechanisms which enable all interests to be represented...” –

Levels of ParticipationLevels of Participation

• Consultative– design by IT, input by users

• Representative– design team includes user representatives

• Consensus– users are involved throughout the design

process

Issues in ParticipationIssues in Participation

• may result in polarising or fragmenting groups of users

• possibility of manipulation through selection of ‘tame’ users

• participation can cause resentment– from analysts / designers– from other users– from management

• growth in end user computing !

Problems (potential) in Problems (potential) in Participative DesignParticipative Design

• trust• election versus selection of the design group• conflicts of interest• stress• communication and consultation• role of professional systems designers • role of functional or departmental manager

Views on ParticipationViews on Participation

• management– a way of achieving changes that would otherwise have been

rejected– a means of democratising the development process

• user– lip service to concerns– opportunity to contribute to inevitable change (progress !)

• IT developer– nuisance, waste of time– method of getting it right by getting users on the “side” of

the development

Levels of InvolvementLevels of Involvement

• support

• active time

• training

• skills development

• knowledge

• understanding

• responsibility

Impact on User of ParticipationImpact on User of Participation

• new skills

• empowerment

• changing status

• changing expectations

• new stress

• relationship with management

Conflicts for the UserConflicts for the User

• job / role requirements

• task complexity

• speed / accuracy of information

• departmental requirements

• organisational requirements

• political constraints

• developmental concerns

SummarySummary

• User centred methods potentially lead to improvement in systems development and a reduction in development failure

• Opportunity to embed organisational, cultural, political and socio-technical change

• Systems development takes place in a complex and complicated environment

• Often it is not only the technical issues which are challenges to development teams

ReferencesReferences• Beach L.R (1990) Image Theory : Decision Making in Personal and Organisational

Context, Wiley

• Buchanan and Huczynski (1991) Organisational Behaviour, Prentice Hall

• Collinson D. (1993) ‘Introducing on-line processing: conflicting human resource policies in insurance’, in J. Clark (ed) Human Resource Management and Technical Change, Sage

• Eason, K. (1988) Information Technology and Organisational Change, Taylor and Francis

• Fullan, M., G., (1991) The New Meaning of Educational Change, London: Cassell

• Lodge, L. (1989) “A user-led model of systems development” in K. Knight, ed. Participation in systems development, UNICOM Applied IT Reports, Kogan Page, London

• Marcus (1983) ‘Power, politics and MIS implementation’, in Baecker, R.M., and Buxton, W.A. (eds) Readings in HCI, Morgan Kaufman

• Mason, R.O. & Mitroff, I.I. (1981), Challenging Strategic Planning Assumptions, New York: Wiley.

• Mumford, E., (1995) Effective Systems Design and Requirements Analysis: The ETHICS Approach, Macmillan