- Getting Users Involved
in Developing Information Systems
By Robin Beaumont
e-mail: robin@organplayers.co.uk
Saturday, 05 January 2008
Version 3
Contents
Developing Information Systems - Getting the users involved
How th is d ocu m en t sh o u ld b e u sed :
This document has been designed to be suitable for web based and face-to-face teaching. The text has been made to
be as interactive as possible with exercises, Multiple Choice Questions (MCQs) and web based exercises.
If you are using this document as part of a web-based course you are urged to use the online discussion board to
discuss the issues raised in this document and share your solutions with other students.
Wh o th is d ocu m en t is aim ed at:
This document is designed for three types of people:

Those who wish to become involved in systems development but are not interested in the nuts and bolts of
programming, such people are commonly called domain experts and act a bridges between a professional
group (e.g. medics, Solicitors etc) to which they belong and IT experts.

As an introduction for those just beginning professional computer science courses

Those at "board" level for hospitals who wish to gain greater understanding of systems development issues
I hope you enjoy working through this document.
Robin Beaumont
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 2 of 29
Developing Information Systems - Getting the users involved
Contents
1.
Before you start ............................................................................................................................................... 4
1.1
Prerequisites .................................................................................................................................................... 4
1.2
Required resources .......................................................................................................................................... 4
2.
Learning outcomes check list for the document ............................................................................................... 5
3.
Introduction ..................................................................................................................................................... 6
4.
Stakeholders and users .................................................................................................................................... 6
4.1
The Problem with Saboteurs ............................................................................................................................ 7
4.2
Identifying and assessing stakeholders ............................................................................................................ 8
5.
Fundamental aim of systems development ....................................................................................................10
6.
Importance of user involvement .....................................................................................................................11
7.
Should users always be involved in systems development? ............................................................................11
7.1
User knowledge / expectations ..................................................................................................................... 12
7.2
Complexity of organisation ............................................................................................................................ 13
7.3
Complexity of system ..................................................................................................................................... 13
8.
Mumfords levels of user involvement .............................................................................................................14
9.
Commitment and training Issues ....................................................................................................................16
10.
User groups .................................................................................................................................................18
10.1
Communications strategies............................................................................................................................ 18
11.
Is User involvement a Panacea? ..................................................................................................................19
12.
ETHICS .........................................................................................................................................................20
12.1
13.
Computer Anxiety, Job satisfaction and stress .............................................................................................. 22
Users/Systems developers and Use (USU): A development method ...........................................................23
13.1
Independent evaluation / contract negotiation team ................................................................................... 24
13.2
Process ........................................................................................................................................................... 24
13.2.1
Contract negotiation and standards setting ............................................................................................................... 25
14.
Agile Techniques and eXtreme Programming ..............................................................................................25
15.
MCQs ..........................................................................................................................................................26
16.
Summary .....................................................................................................................................................28
17.
References ..................................................................................................................................................28
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 3 of 29
Developing Information Systems - Getting the users involved
1. Before you start
1.1 Prerequisites
This document assumes that you have the following knowledge and skills:
1. Basic knowledge of information systems - You should feel confident to be able to answer the following questions
concerning basic knowledge of Health care information systems
1.
2.
3.
4.
The systems view of the world describes everything using three basic aspects. What are they?
I mention the 5 ‘W’s and H to consider when describing a system. What do they stand for?
Information Systems are often classified into one of three tiers. What are the names given to the tiers?
James Martin in 1981 suggested Information Systems could be divided into two types. What were they?
If you have any difficulty answering any of the above questions go to the following link and find the answers in the
document "Types of Health information systems" at
http://www.robin-beaumont.co.uk/virtualclassroom/chap12/s2/systems1.pdf
2. Basic knowledge of systems development methods - You should feel confident to be able to answer the
following questions concerning basic knowledge of systems development methods:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What are the names of the two most common methods of developing Information systems?
What are the three levels found in the ‘functional specification’?
What are the main stages of the Waterfall method?
What does PIR stand for?
What is the more modern name for a systems analyst?
What are the two main types of prototyping?
What is the other name given to evolutionary prototyping?
What is the audit cycle similar to?
If I develop a system and gradually add different modules to it, what type of prototype is it?
If I develop a system and gradually make each of the modules have more 'bells and whistles' what type of
prototype is it?
If you have any difficulty answering any of the above questions go to the following link and find the answers in the
document "Information systems development methods" at
http://www.robin-beaumont.co.uk/virtualclassroom/chap12/s3/des1.pdf
Exercise 1.
If you are working through this document as part of an online course post your answers to the above questions on
the discussion board.
1.2 Required resources
Access to the Internet to check out the links mentioned in this document.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 4 of 29
Developing Information Systems - Getting the users involved
2. Learning outcomes check list for the document
This document aims to provide you with the following skills and information. After you have completed it you should
come back to these points, ticking off those you feel happy with.
Tick box
Learning outcome
Be able to identify various stakeholders
Be able to discuss various frameworks that classify stakeholders

Be able to discuss the reasons why user involvement is important in systems development

Be able to discuss the reasons why undue emphasis is placed on ‘specification compliance’ in
traditional system development methods.
Be able to discuss the relationship between user education, user involvement, user satisfaction
and system use


Be able to discuss the three levels of user involvement proposed by Mumford

Be able to discuss the educational requirements when considering user involvement


Be able to describe the relationship between technical/social aspects and job
satisfaction/efficiency within the ETHICS (Effective technical and human implementation of
computer systems) method
Be able to discuss the advantages and disadvantages of user groups

Be able to discuss the various communications strategies that can be used with user groups

Have a broad grasp of the USU method

Have a broad understanding of Agile and eXtreme Programming methods

Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 5 of 29
Developing Information Systems - Getting the users involved
3. Introduction
This document investigates the importance of human communication in the Information System development
process, frequently euphemistically called ‘user involvement’. We begin by considering who is actually involved and
then why communication is so important and ends by describing three systems development methods that consider
communication to be an essential activity.
Most people outside the Information Systems development fraternity would probably assume that communication
between the ‘experts’ developing the system and those that purchase it only needs to occur at two points: when
the contract is being drawn up and then at the end when the system is handed over. In fact, it is often a source of
much frustration for the client if developers attempt to increase this level of communication by constantly
questioning the client rather than ‘getting on with it’.
Newman & Rosenberg 1985 call this ‘top managers strategic withdrawal’ (p399) and cite references for this being
the cause of failure in implementing many information systems. In almost any project, there are usually several
groups of people that must be taken into account when developing any system, and we will begin by considering
such groups.
4. Stakeholders and users
The section on 'information systems development methods' provided an overview of the traditional waterfall
approach, which precluded vendor involvement in most of the development process. The more recent iterative
prototype development method encourages greater vendor involvement, but just what is this heterogeneous group
of people?
Most of the systems development methods of which there are hundreds, including the two described above,
encourage the involvement of various 'stakeholders' of which one may or may not be the user. Often the first job an
analyst does is a stakeholder analysis, literally finding out who the stakeholders actually are.
Stakeholders are considered to be those that have some power over the proposed system. This power may be in
various guises:
Power Aspect
Group
Money
Purseholders (vendor)
Decision making
Champions/Managers/Policy makers
Professional power
i.e. Doctors/Paramedics/professional bodies
Data quality (data entry personnel)
Potential saboteurs
Often systems, particularly those in the NHS, are implemented for political rather than organisational reasons. This is
related to both philosophical issues regarding information systems (see my 'Theories underlying approaches to
systems modelling a http://www.robin-beaumont.co.uk/virtualclassroom/chap11/s4/sa1.pdf ) and the social context (see
my 'being online document at: http://www.robin-beaumont.co.uk/virtualclassroom/chap4/soc3/soc3.pdf )
Frequently the 'purseholder' has requirements that are at odds with those of the other stakeholders. It is therefore
often necessary to prioritise and consolidate the conflicting requirements of these stakeholders at the very
beginning of the development process. It should be noted that all the stakeholders, except the potential saboteurs,
are at the top of the organisational hierarchy.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 6 of 29
Developing Information Systems - Getting the users involved
4.1 The Problem with Saboteurs
Yet these potential Saboteurs are the ones that hold possibly the most power when the system is implemented
(Newman & Rosenberg 1985; Mechanic 1962). Quoting Newman and Rosenberg p394:
"The dysfunctional effects of introducing comprehensive information systems into organisations are widely known if poorly
understood [references provided in article]. These dysfunctions can emerge in organisations as aggression or sabotage. Thus
operating personnel may deliberately distort or destroy input data such as time cards or production control information. . . . The
McKinsey report (McKinsey 1969) indicated that this phenomenon was widespread even in 1969. Many organisations are finding
the implementation process not merely complex but that it amplifies and reproduces strains in the internal political system."
While the above reference is over fifteen years old (1985), little has changed. A recent report (Beaumont 2000)
reviewing an 'ergonomic evaluation' for a UK-wide Probation Service Case Management Information System
(CRAMS) is indicative of a 'user sabotage' process. The original review was 'suggested' by the relevant professional
bodies/unions. Covertly it was an attempt to prevent employees from using the system. Furthermore this was not
the only report to be commissioned as one of the provincial Probation Service Departments also commissioned a
report investigating the possible stress related effects of using the software, clearly with similar aims in mind.
A similar process of frustration and 'user resistance' can be demonstrated with the failed London ambulance Service
Information System (see Page et al 1993 or Beynon-Davies P, 1999), the diagram below illustrated on incident (taken
from Page el al 1993).
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 7 of 29
Developing Information Systems - Getting the users involved
Sabotage and aggression are not the sole domain of the user:
"...related a technique that one of his previous colleagues used to overcome resistance. The employees flatly refused to use the
new stock system so the analyst went in one weekend, took all the stock cards and burned them. The employees then had to use
the new system." (Newman and Rosenberg 1985 p402)
Traditionally, probably due to the desire for short-term success with the stakeholders, the 'top level' stakeholders
were considered the most important in systems development. Unfortunately a large percentage of systems failed,
for some of the reasons described above, when they were implemented using this top down approach, and as a
consequence bottom up approaches have been developed. A fundamental characteristic of the bottom up approach
is the participation of the user throughout the development process.
Both the top down and bottom up approaches require a management framework while in contrast a radical new
approach called Extreme Programming demands that the programmers and users actually work side by side with
the user watching the programmer work and making suggestions as they work together. There are several good web
sites along with books describing Extreme programming which has provoked a lot of discussion. Some say this
maverick approach is nothing more than returning to the days when programmers hacked out code, whereas others
see it as a much welcomed liberation from the bureaucracies that have come to dominate the other approaches.
We will now look briefly at two methods of assessing stakeholders.
4.2 Identifying and assessing stakeholders
Numerous frameworks have been developed to assess stakeholders. One such method is that of Johnson and
Scholes 1993. They suggested that stakeholder analysis be concerned with assessing power against several other
characteristics, such as predictability of behaviour and level of interest as shown below. The diagram also indicates,
via the shaded area, those
stakeholders that should
Predictability
Level of interest
High
Low
High
Low
play a part in decisionmaking.
Few problems
Low
Unpredictable but
manageable
Power
Low
Keep informed
Minimal effort
Power
Powerful but
predictable
Greatest danger or
opportunities
High
Key players
Keep satisfied
High
Johnson & Scholes 1993
also suggest that each of
these are assessed by
considering actions of the
stakeholders and their
managers. In the matrix
below the action considerations for each quadrant are shown.
Level of interest
High
Low
Power
High
Low
Stakeholder name /group:
Stakeholder name /group:
Proactive or reactive:
Proactive or reactive:
What is done:
What is done:
What more should/could be done:
What more should/could be done:
Keep informed
Minimal effort
Stakeholder name /group:
Stakeholder name /group:
Proactive or reactive:
Proactive or reactive:
What is done:
What is done:
What more should/could be done:
What more should/could be done:
Key players
Keep satisfied
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 8 of 29
Developing Information Systems - Getting the users involved
Within the healthcare setting, it might be sensible to add another dimension such as interest in improving patient
care!
Boddy and Buchanan (1992) suggest that an informal diagram is produced which identifies each group. (A similar
technique would be to produce a 'rich picture' if you are familiar with the technique.) Following on from this, a table
should be drawn up containing a number of criteria. These are shown in the following table, which uses as an
example the possible effects upon two stakeholders (Ward Nurses and Administrators) with the introduction of an
Order Entry System (OES) for the ward:
Stakeholder group/name
Ward Nurses
Ward Administrators
Their goals
Provide nursing care
Manage day to day information
Past reactions
Animosity – seen as an administrative role
Mixed
What to expect
Furious if creates more administrative tasks
Frightened about being replaced if they
can’t cope with the new technology
Impact: negative/positive
Minimal – if administrative staffing improved
Minimal as they already know Word
processing and email
Possible future reactions
Dependent upon success of present system
Favourable (reduction of waiting on the
phone, etc)
Management ideas
Keep informed; arrange regular meetings with senior
Administrator regarding task allocation
Arrange visit to unit already using the
system for senior Administrator
Stakeholder analysis is a useful technique in a large number of situations, not just the situation of developing a
Computerised Information System. As with most management techniques, the above process and table format can
be adapted. For example, if the system developers were based away from the implementation site, a further
category might be the form and frequency of communication to each stakeholder group. In fact the above process
can be used to identify those groups you may wish to communicate with or not, and how, in any scenario. For
example, the technique would be useful in the following three scenarios:

Setting up a local audit group for GPs

Supporting a local Alzheimer's society

Decommissioning a health clinic
Exercise 2.
a. Given the relatively weak power base of 'data entry' personnel but pivotal role regarding data quality and possible
subversive activities do you think the above type of matrix analysis is useful in the systems development context? If
you answer is ‘no’ what alternative matrix's might you come up with?
b. Considering the above table, what subversive activities do you think the above stakeholders might get up to?
What could you do to prevent, or stifle, such activities?
Moving swiftly back to the topic of Computerised Information Systems, we will now take a quick look at what I
believe to be the fundamental aim of any such system.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 9 of 29
Developing Information Systems - Getting the users involved
5. Fundamental aim of systems development
Possibly, the most important aim of systems development from the purseholders perspective is to achieve:
USE
However, few activities within most systems development lifecycles explicitly measure or present this as an area of
focus. Instead, the specification, and compliance of the system to it, has become the focus of activity. I feel this is
because:
1.
Traditionally it has been difficult to measure system use
2.
Much effort has usually been invested in developing the specification, so it becomes the reason for the
system existing
3.
Measuring specification compliance provides a cop-out for project managers when systems fail
4.
Measuring specification compliance provides a cop-out for software developers when systems fail
Main emphasis of traditional systems development
Specification
Specification
Compliance
???System use???
The common fallacy that adherence to a software specification is equivalent to system use, when in reality they
often are diametrically opposed presents real problems for those systems developers who actually wish to end up
with systems that will be used.
Achieving system use nearly always requires the user to be involved in the systems development process. In fact,
'User involvement' in the development process is now considered to be a necessary condition for any system
development method. We will now consider this in more detail.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 10 of 29
Developing Information Systems - Getting the users involved
6. Importance of user involvement
The importance of user involvement in Information Systems (IS) development has been known since the 1970's
(Newman and Rosenberg p404). Similarly, for the same period, the dire consequences of not involving users has
been known. For example, see the excellent book Why Information Systems Fail by Henry Lucas 1975.
Why is it so vital to ensure that users are involved in the design process? Some reasons have already been given such
as: the failure of modellers (systems analysts) to understand the complexity of the system required, or the negative
effect upon working practices resulting in user dissatisfaction when modellers are aware of how the users actually
work.
In addition to having general discussions with the users, there is a need for user involvement in technical procedures
such as the process of data/dynamic modelling and normalisation (basically structuring of the data). Within the
healthcare arena, it is often necessary to spell out the significance of particular data items as the systems developers
will rarely have any understanding of particular data items in a context (such as serum K in a patient with renal
failure). Users often perceive as common sense what the system developers find incomprehensible, illogical or
unnecessarily complex. Similarly, their role in the User Interface (UI) design aspects is vital.
At a more personal level, involvement of the users creates a sense of ownership and often loyalty to whatever is
developed. Unreal expectations are often a problem with users that are very difficult to modify. However,
involvement in the design process is an excellent way of achieving a more realistic viewpoint. (Newman and
Rosenberg p398).
Various studies, from the groundbreaking empirical research of Baroudi, Olson and Ives in 1986, up until the present
have demonstrated that increased user involvement increases user satisfaction that in turn increases system use. I
would also suggest that user education is also vitally important. (Hwanga &Thorn 1999; Au, Ngai & Cheng, 2002 ).
Downing 1999 suggested that user satisfaction and system usage where so highly correlated that one could be used
as a proxy measure for the other.
User education
User involvement
User satisfaction
System use
With the danger of labouring the point user involvement basically increases system use which I would say is a
measure of system success.
7. Should users always be involved in systems development?
While it is ideal that users are always involved in systems development, the consequence of not involving them is
directly related to three issues:

User knowledge / expectations

Complexity of the organisation

Complexity of the system
Each of these will be discussed in turn.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 11 of 29
Developing Information Systems - Getting the users involved
7.1 User knowledge / expectations
A well known book concerned with developing systems, Nielson 1993, suggests that 'The user is not always right'
(p11) when it comes to asking what they want and provides several examples:

A group of telephonists asked if they would like lighter handsets, said no; However when given them they did
prefer them.

73% of respondents, when asked if they would use a proposed traffic information system said no; However
when a prototype was set up, 84% said they would in fact use it.
I feel that Nielson is rather unfair on the user here. Possibly, what would be more appropriate is to suggest that the
un-informed user is not always right. It is therefore important to educate users to obtain valid requirements.
A common scenario
Un-informed
users
High
Compliance
to
specification
Initial
Specification

Project manager happy followed the rules

Systems developers happy know its not what they really
want but they know they will
make more on the maintenance
contract

Users realise, only afterwards it
was NOT what they wanted.
A typical sequence of events is shown below. A set of uninformed users develop a paper specification for a new
Information System which, after a number of months negotiating with several suppliers, they agree upon. The
company goes away, creates the system as described in the specification and finally delivers it. Unfortunately once
implemented, the commissioners realise that it is not what they wanted after having gained the experience of using
a system.
From the above scenario the importance of prototypes, even non-functional screen mock-ups, for educating and
engaging users in the development process can be comprehended immediately.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 12 of 29
Developing Information Systems - Getting the users involved
7.2 Complexity of organisation
By 'complexity' I mean the level of structural rigidity and prevalence of 'autonomous professional groups'. Such
aspects as the actual number of employees and/or number of locations is not the issue.
For example, those organisations which are highly structured and possess few autonomous professional groups may
get away with a low level of user involvement. This is particularly true with regard to simple transaction processing
systems. However, unstructured organisations with many autonomous groups would be heading for disaster if a
minimal level of user involvement were
Highly structured and few
Un-structured and many autonomous
used in the system development
autonomous professional
professional groups = complex
process.
groups = simple
Royal Mail
Health Service
Mc Donalds
Criminal justice system
Marks & Spencers
University
Police force
Exercise 3.
Considering the above table, draw up a list of two or three simple and complex organisations in your country.
7.3 Complexity of system
As with the type of organisation the type of system under development determines to some extent the importance
of user involvement required for a system to be successful.
The term 'complexity of system' needs
some explanation in this context. It is
more to do with the complexity of the
User involvement
algorithms and uses the system is
important
System
complex system
supposed to undertake rather than the
'complexity'
Importance of
size or geographical coverage of the
(Structure
of
user
activities)
involvement
system. For example it would be much
more important to involve users in the
development of a specialist system to
help with diagnosis of skin conditions
User involvement unimportant
than a nation wide billing system for a
simple system
computer supply house. Transaction
processing systems (often of the back office type) are simple in comparison to those designed to assist professionals
carry out complex largely self-determined tasks. Churchill, Kempster & Uretsky suggested in 1969 that systems could
be related to the level of structure of the tasks undertaken. The simplest systems working with the most structured
tasks and the most complex working with unstructured individually defined tasks. While the simpler type of systems
has become common place since 1969 few, if any computer systems, to support the relatively unstructured tasks
have emerged. Friedman & Cornford 1989, provide a wonderfully insightful discussion of the history of systems
development
Relationship between possible 'complexity' of system and importance of user involvement
This can clearly be seen in the medical context. Large numbers of GPs use computer systems for routine highly
structured tasks such as prescribing and patient registration. However it is a very different story concerning 'expert
systems' that is those that carry out part of the diagnostic process. Despite literally hundreds of projects
demonstrating the diagnostic accuracy of these systems compared to appropriate doctors, none have gained wide
spread use. The feeling now is that the best one can hope for in this context is to develop systems that 'Support'
these unstructured tasks rather an automate them although political issues may change this. The reasons for this
are complex, involving at least professional and system adequacy factors.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 13 of 29
Developing Information Systems - Getting the users involved
8. Mumfords levels of user involvement
Enid Mumford (http://www.enid.u-net.com/ ) wrote for many year about 'participative design'. She became
involved in large systems developments including international banking. More importantly she produced several
books describing how her method has been used in the Health sector (1993) Enid Mumfords approach to systems
development is based upon the idea that any system should fulfil two critical criteria:

Increase the satisfaction of staff.

Increase their work efficiency (Mumford 1983, p3). See: http://www.enid.u-net.com/
Related to the above criteria she introduces two additional concepts; the idea of 'Job enrichment' which the aim is
to improve the relationship between the individual and his work. Secondly the 'Socio-technical method' which is
the idea of small units of workers that develop very close joint working relationships and take control over a specific
area.
Exercise 4.
List five ways a computer system might enrich your job and increase your job satisfaction
If you are working through this document as part of an online course post your answers to the above question on
the discussion board, you might even want to tell others how computer systems have had a negative effect upon
your job satisfaction!
Mumford 1983, identified three levels of user participation:
1. Consultative participation - The users are consulted but most of the decision making is still left with the
traditional systems design group (top level stakeholders and the designer).
2. Representative participation - Design group formed from representatives of all grades of staff in each
department. Members selected by management. 'Representative participation has the advantage that clerks and
systems analysts work together on equal terms. It has the disadvantage that it assumes that representatives
really do represent the interests of their constituents and this may not always be the case.' (Mumford 1983 p6).
3. Consensus participation - Attempts to involve all staff. Design group formed from representatives of all grades of
staff in each department but these time members selected by elections from the shop floor.
Exercise 5.
Which of the above three levels of participation do you feel is most appropriate in your organisation? Provide
reasons.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 14 of 29
Developing Information Systems - Getting the users involved
Obituary The Guardian Tudor Rickards Wednesday May 3, 2006 for Enid Mumford
Sociologist devoted to making computers work for people
'A woman down the mines?" Enid Mumford's classic sociological research for the National Coal Board had a strong
impact on unbelieving miners. Later, as an active advocate for women's rights, Enid, who has died aged 82, enjoyed
recounting her early experiences: "They were terribly nice to me whenever I turned up, but they were awfully
embarrassed at what I might catch them doing." Enid would "drench herself with perfume", so that the ventilation
system would give the miners a chance to prepare themselves for her arrival at the coalface. In such ways, Enid
began her contributions to social theory, with its challenges to action researchers like herself.
She was born and brought up on Merseyside. Her father, Arthur McFarland, was to become chief magistrate of
Liverpool; her mother, Dorothy Evans, had been a headteacher. Enid's secondary education was at Wallasey high
school, after which she crossed the Mersey for her first degree, in social science, at Liverpool University, which was
acquiring an international reputation in social anthropology.
From 1946 to 1948 she spent time in industry, in personnel and production roles, experiences which were to inform
her lifetime interest in the human and economic aspects of work, before returning to Liverpool as a faculty member
until 1956.
Her initial academic work examined industrial relations in the Liverpool docks and the north-west of England coal
industry. She became an assistant in the canteens used by the stevedores, and spent months underground talking
with miners, who provided her with rich research insights and vivid anecdotes.
A year at the University of Michigan followed, studying and working for the university bureau of public health
economics. On returning to England, she completed her doctorate at the University of Manchester, and joined the
new Manchester Business School in 1966, investigating the human and organisational impacts of computer-based
systems. She also directed the MBA programme for several years.
Colleagues recall both her persuasive charm, and her outstanding ability as academic, project initiator and
administrator. During this time, 1979-88, she became the first woman to hold a full professorship at a UK business
school. While female professors, such as Joan Woodward and Rosemary Stewart, had made considerable
contributions to business studies, they had done so largely from outside the chauvinistic male cultures of the
emerging business schools. In 1983, she won the US Warnier prize for her contributions to information science. In
1999, she was the only Briton to receive a Leo lifetime achievement award of the Association for Information
Systems. Her citation recognised her as a world leader in the application of socio-technical concepts to information
systems development.
Mumford became interested in the socio-technical approach to work organisation of the Tavistock Institute, of
which she later became a council member, and adopted these principles into her system Ethics (Effective Technical
and Human Implementation of Computer-based Systems), a method for designing computer-based information
systems which attended to the basic needs of users.
It was typical of her participative style that, dissatisfied with the publicity efforts of academic publishers, she
published Ethics herself. Cartons of books accompanied her on assignments and would appear on a table at the back
of her lecture theatres. She took ironic pride in the success of this entrepreneurial venture and later made the book
available in electronic format. During this period she also found time to become an accomplished painter.
In 1988, Enid became emeritus professor of the University of Manchester and a visiting fellow at Manchester
Business School. She was also made a companion of the Institute of Personnel Development and a fellow of the
British Computer Society. In more recent years, Enid turned her attention to broader social issues, applying sociotechnical concepts to solving complex and intransigent global problems related to cyber-crime and drugs.
She is survived by her husband James, whom she married in 1947, and their children Michele and Colin.
Enid Mumford, social scientist, born March 6 1924; died April 7 2006
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 15 of 29
Developing Information Systems - Getting the users involved
9. Commitment and training Issues
Within a complex organisation, many levels and types of training are required. For example, the NHS in the UK has
provided advice on training at various levels since its inception in the 1940s. Commitment to training is also an
important aspect. Unfortunately the degree of commitment to training, particularly concerning IT/informatics has
never been enthusiastic within this organisation.
A note: Personally I was unable to convince anyone in the NHS either at local or national level to second
me to complete a MSc in computing (there were no courses in Health Informatics!) at the beginning of the
1990's because it was felt inappropriate and unnecessary for nurses to develop such skills, instead I
decided to drop out of the NHS, to carry out the course. Subsequently I set up a company which was
contracted to the Regional Health Authority, making much more money than if I have been an employee.
The history of IT/Informatics training within the NHS within the past 15 years also clearly demonstrates its lack of
commitment to the concept.
In
the
early
1990s,
the
NHS
enabling
clinicians
project
provided
support
http://www.doh.gov.uk/ipu/develop/nip/annexb.htm (old link active until 2003) and subsequently in 2003 a new
organisation the NHSIA: http://www.nhsia.nhs.uk/def/home.asp. (old link active until April 2003) was set up and
developed
a
NETD
(National
Education,
Training,
Development)
strategy
http://www.nhsia.nhs.uk/wowwi/pages/default.asp which was subsequently renamed to “National Health
Informatics Development (NHID)” at: http://www.nhsia.nhs.uk/nhid/pages/default.asp (old link active until April
2003). Subsequently in 1 April 2005 The NHS Information Authority (NHSIA) was reorganised to form the NHS
Connecting for Health and the Health and Social Care Information Centre, both of which took on training/education
roles.
The Education Training and Development portal o the Connecting for health Web site is shown below
(http://www.connectingforhealth.nhs.uk/systemsandservices/etd) and presents a good example of the lack of
dynamism concerning training, having not been updated for the last six months, assessed on 4th Jan 2008.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 16 of 29
Developing Information Systems - Getting the users involved
Luckily there are also numerous professional bodies that have a role regarding IM&T education and training (e.g. the
various Royal Colleges and numerous healthcare worker groups such as Assist: http://www.assist.org.uk/) (Link
active 05/01/2008).
Clearly if users at all levels are to be involved in the design process to develop valid user requirements, training will
be required. This also requires additional resourcing to allow people to drop out from their present work
commitments. Related to this is the issue of commitment. Using this approach to systems development means that
the users cannot be passive but must 'take control' of the development process.
Unfortunately if eager users are not effectively educated, they can become problematic (often disparagingly called
'fiddlers'). Within the GP community, this problem is managed to some extent by the user groups an issue we will
look at in a section further on.
Potential groups may include:
IM&T professionals within the organisation - Clearly the organisation must have the infrastructure or develop one
to support these activities. Most IM&T professionals will require training in participative development techniques.
The use of training consultants should at all costs be avoided, as the aim is to develop skills in house.
Managers - Education regarding modern systems development methodologies should be a priority for these.
Professional bodies / Unions - These can often provide either the necessary carrot or stick to encourage user
involvement.
Movers and shapers - As part of a long term strategy potential 'movers and shapers' should be identified and given
highly desirable incentives to undertake computing / informatics courses. These preferably should be full time and
lead to degree or MSc. status.
Ground level users - These possibly should be the focus of the educational process.
Students - It is most important to involve students in the process. This may well result in innovative requirements
and use of data such as production of log books for training accreditation.
Clients / Patients / Cases - If the system is intended to be used in situations that involve any of these groups they
will also require training.
Besides just generally discussing with users their needs in certain situations, it will be necessary to teach them some
of the following techniques:

Data modelling (e.g. object modelling, data dictionary design, business normalisation)

Dynamic modelling (e.g. dynamic models, process models, Business process design)

User interface design (e.g. story boarding, screen painting, screen prototype evaluation)
This is quite a hefty task for most people, emphasising the degree of commitment required by top level stakeholders
for this method to work. A significant number of people will need a significant amount of time out for training and
subsequent system design activities and for complex systems the process will undoubtedly be ongoing. This
emphases the requirement to develop the necessary infrastructure rather than depend upon consultants.
Commitment may need to be bought by offering financial incentives.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 17 of 29
Developing Information Systems - Getting the users involved
10. User groups
A more pragmatic approach taken regarding user participation for long term system developments is the setting up
of user groups. These groups, which are often set up by software companies, provide a number of advantages.
These include providing a method of filtering and prioritising design suggestions and provision of a set of individuals
to try out new software before going on general release (beta testing). The disadvantage of such groups results
from the lack of power they often have, suggestions are ignored or the user group is just political window dressing
for the software company.
Within the NHS user groups exist for most of the large PAS systems, as well as for Read codes. Also 'care pathways'
have a user group which has representatives from over 150 hospitals. All the major GP systems have user groups.
Most user groups provide a number of methods for communicating with and between users including dissemination
of knowledge. For example The National Library for Health (NHL) Care pathways library provides a excellent example
(http://www.library.nhs.uk/pathways/) :
10.1 Communications strategies
These may include:







Regular face to face meetings
Annual meetings / conferences
Newsletters
Bulletin boards
Web sites
Electronic discussion groups (open and closed)
Ad Hoc comments sheets (to monitor 'critical Incidents' or niggles)
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 18 of 29
Developing Information Systems - Getting the users involved
11. Is User involvement a Panacea?
There are those who question the fact that user involvement is essential in determining the success of an IS
suggesting that it is often nothing more than political window dressing. I firmly believe, based upon the empirical
evidence mentioned in the previous sections, that all stakeholders must be involved. However I accept that it is not a
typical viewpoint and suggest that you read the following paper by Richard Heeks at the Institute for Development
Policy and Management at the University of Manchester to allow you to gain possibly a more rounded viewpoint
Exercise 6.
Richard Heeks March 1999 The Tyranny of Participation in Information Systems. Institute for Development Policy
and Management University of Manchester.
1. Download the above paper at:
http://unpan1.un.org/intradoc/groups/public/documents/NISPAcee/UNPAN015538.pdf (active 05/01/2008) Note
that the url given at the beginning of the paper is incorrect
(i.e. http://www.man.ac.uk/idpm/idpm_dp.htm#devinf_wp).
2. While reading the paper consider if you think resource-deficit participation is, or could be, a problem in the Health
Service?
3. Also think about the following questions provided by Richard Heeks.
a.
What problems arise in practice with participation as a technique?
b.
How can we best address the problems with participation in information systems projects?
c.
What benefits can participation bring to IS development?
d.
Are there other 'magic bullet' techniques - apart from participation - that are almost universally
recommended for IS development and operation? What could you conclude about such techniques?
e.
We are very keen to find simple solutions and 'magic bullets' to address organisational and social problems
which are often highly complex. Is this helpful or harmful?
f.
What - if anything - can industrialised countries learn from developing countries about information and
information systems?
g.
Why does so much knowledge flow from industrialised countries to developing countries, and so little flow
in the reverse direction?
We will now look at three systems development methods that place the user centre stage in the process.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 19 of 29
Developing Information Systems - Getting the users involved
12. ETHICS
ETHICS is an acronym for Effective Technical and Human Implementation of Computer Systems, it is a method that
Enid Mumford developing over several decades. In contrast to most systems design methods, in ETHICS user
participation is fundamental at every stage.
ETHICS is also unusual in that it forces the search for solutions that take into account 'social' as well as technical
factors. The whole process can be considered as a method of balancing the costs and benefits of social and technical
solutions upon job satisfaction and efficiency.
Technical problems /
solutions
Social problems /
solutions
Job satisfaction & efficiency
The ETHICS methodology contains six stages which are further divided into twenty-five steps (Mumford, 1983b).
These are shown below.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 20 of 29
Developing Information Systems - Getting the users involved
Stages in ETHICS (from Hirschheim, Klein & Lyytinen 1995 p249)
Step 3:
Step 4
Step 5
Step 6
Step 7
Step 8
Step 10
Step 1:
Identify
Problem
Describe existing system
Specify key objectives
Identify key tasks
Identify sets of tasks
Identify information needs
Identify variance
Forecast future needs
Step 11:
Set and rank
efficiency and job
satisfaction needs
Step 2:
Identify system
boundaries
Step 1:
Diagnose job satisfaction
needs
Step 19:
Take technical
decisions
Step 16:
Specify priority
technical and business
objectives
Step 18:
Check that technical
and social objectives
are compatible
Step 20:
Take social
decisions
Step 17:
Specify priority social
objectives
Step 12:
Identify technical and
business constraints
Step 14:
Identify technical
resources available
Step 15:
Identify social
resources available
Step 13:
Identify social
constraints
Step 22:
Set out alternative
social solutions
Step 21:
Set out alternative
technical solutions
Step 23:
Set out comparable
socio-technical
solutions
Step 24:
Rank compatible pairs
of socio-technical
solutions
Step 25:
Prepare detailed work
design
Stage 1 Essential Systems analysis (steps 1 to 11)
This is the preliminary phase of the ETHICS method. It involves identification of the boundaries of the system (e.g. a
particular clinical department) as well as a description of the current system, if any is present. The key tasks and
objectives of the proposed system are stated. Each of the interested groups then rank the list of objectives on a
scale of one to five. Both the efficiency and job satisfaction requirements are initially considered separately before
being consolidated.
Stage 2 Socio-technical systems design (steps 12 to 20)
This stage attempts to reconcile the social side with the technical side of systems design. Firstly the business, social
and technical constraints are identified. Two different groups are formed (one focusing on the social aspects of the
system; the other the technical aspects) whose job it is to find socially and technically desirable design options.
After identification of the social and technical constraints, the resources available for each of the socially and
technically desirable options are considered. The objectives (in ranked order) are then checked for comparability
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 21 of 29
Developing Information Systems - Getting the users involved
before actual technical and social systems decisions are taken. Revision may be necessary before this final step is
completed.
Stage 3 Setting out alternative solutions (steps 21 to 23)
This stage involves the evaluation of any alternative technical or social solutions. These are set out in a matrix form
evaluating possible advantages and disadvantages as well as overall compatibility with the established objectives. As
in the previous stage, each will be evaluated against three criteria, priority, constraints, and resources. Once
doubtful solutions are eliminated, a short list of technical solutions and one of social solutions is drawn up.
Stage 4 Setting out compatible solutions (step 23)
This stage merges the short lists from stage three to see which solutions are most compatible. Incomplete solutions
are discarded. Technical and social solutions found to operate well together are entered into an evaluation matrix
for the next stage.
Stage 5 Ranking socio-technical solutions (step 24)
The matrix set up from the previous stage is now ranked using information generated in stage 3, while ensuring all
socio-technical solutions meet the criteria outlined in stages 1 and 2.
Stage 6 Prepare a detailed work design (step 25)
A detailed list and description of all tasks people would perform under a particular socio-technical solution's
implementation is drawn up. Tasks are ranked in order of simplicity and attempts are made to provide a balanced
spread of required skills and complexity of tasks. Checks are made to ensure that created jobs are as interesting and
satisfying as possible using a set of 'issues of concerns'. If the highest ranking socio-technical solution scores high on
these issues while achieving the technical objectives, it is accepted as the final solution. If this is not the case,
another short listed solution is tried in the same manner.
ETHICS adopts a number of special methods for systems development. For example, there is a special diagramming
method used for describing work layout. There is also a job diagnostic questionnaire which is used to elicit views on
the job situation. More importantly, ETHICS, employs a facilitator who seeks to find a consensus on the systems
development exercise using special questionnaires.
12.1 Computer Anxiety, Job satisfaction and stress
While Job enhancement and job satisfaction are related concepts the
measurement and importance of job satisfaction has spawned far more
literature (for an early example Wanus & Lawler 1972). This particularly is
regarding the relationship between job satisfaction and stress at work (for a
typical example within gp see Simoens & Scott, 2002) or Arnetz, Arnetz and
Petterson 1996, concerning stress from violence in Swedish nurses. Karasek and
Theorell, 1990 provide an excellent introduction to the literature.
It must not be forgotten that IT itself can be a source of stress, a recent study
has shown that Email at work is a particular problem. See Email stress - the new
office workers' plague The Observer Sunday August 12 2007. To test your own
level
of
computer
anxiety
go
to
http://www.robinbeaumont.co.uk/virtualclassroom/chap3/companx/questanx2.htm
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 22 of 29
Developing Information Systems - Getting the users involved
13. Users/Systems developers and Use (USU): A development
method
Most systems development methods have several problems: they assume limited input from end users; they
encourage the centrality of the specification, and they assume the commissioning body has the ability of to carry out
prolonged detailed negotiations with systems developers.
The proposed development method described below is derived that which was successfully adopted by Prodigy. An
iterative software development for GPs to support electronic prescribing in the UK.
Commissioning body
Steering group
Ongoing
System developer
Ongoing
Independent Evaluation / contract
negotiation team
Users
Evaluation / system
requirements / training
elucidation team
Contract negotiation
User support /
training
User groups
In the above setup, there are a large number of different groups, including managerial, commissioning and steering
committees. More importantly, there is an Independent Specification/Evaluation/Contract Negotiation Team
(SECNT) along with a separate Systems Development Team. All users provide feedback via the SECNT. There is also a
user group associated with the systems developer who provides support and training. Within SECNT there exist
communications personnel and Modellers.
Some aspects of the above diagram are discussed further below.
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 23 of 29
Developing Information Systems - Getting the users involved
13.1 Independent evaluation / contract negotiation team
Within the development method, there is a need for an independent evaluation to make it valid. Because the
evaluation is so closely linked with the specification and contract negotiation aspects of the process, the most
natural setup is to have the three functions within the same department. The team provides the following functions:

Ongoing quantitative/qualitative feedback to users and steering group

Analysis of users views and requirements.

Specification development including standards setting

Contract negotiation based upon results of continuing evaluation along with input from the
steering group.
Now let's look at the actual process.
13.2 Process
The actual development process can be thought of as 'iterative' which is covered in more depth elsewhere. The key
stages are (notice that the same four stages keep recurring):











Initial prototype development with very limited functionality
Evaluation
Formulation of new specification
Contract negotiation
New prototype
Evaluation
Formulation of new specification
Contract negotiation
New prototype
Evaluation
Etc: no end point
The relationship between the various activities is shown below.
National dissemination meeting
End user questionnaires
Newsletters / web site etc
User Log files
Ad hoc comments
Focus groups
Evaluation
team
internal
reports
Specification and
contract for next
iteration
User Interface
development methods
Users
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 24 of 29
Developing Information Systems - Getting the users involved
Good project management is vitally important as the results from the various evaluation activities feed into the
specification development process for the next iteration.
13.2.1 Contract negotiation and standards setting
In contrast to traditional contract negotiations that centre wholly around system design specification this
development method additionally specifies minimum acceptable levels of Use and user satisfaction.
Realistic targets for the key items from the questionnaire(s) should be mutually agreed with the developers along
with penalty clauses and/or bonus incentives dependent upon the results. The quality, quantity and format of
training should be included along with a wish list for users in the questionnaire(s).
Typical headings from a system evaluation questionnaire might include:














System specific training
Ongoing support for the system
System supplier communication / feedback
Evaluation team communication feedback
Installing the system
Interacting with the system
Using the system during work (front office issues)
Coding issues
Screen layout / navigation
Help contents
System information issues
Output
Query details
Wish list
Some typical questions are provided below from the Prodigy evaluation questionnaires:
How would you rate the trainer's assessment of your particular learning needs for the system?
extremely limited limited adequate good expert
How would you rate the trainer's ability to communicate effectively when answering questions about the system?
extremely limited limited adequate good expert
How useful did you find the documentation as a . . .
General introduction to the system
Definitive reference
'How to do it'
Source of exercises etc.
Code reference
Guide of where to get additional help / documentation
How do you rate the layout of the output
Can you print output while with a client
not at all little use
not at all little use
not at all little use
not at all little use
not at all little use
not at all little use
grossly inadequate
yes
useful extremely useful
useful extremely useful.
useful extremely useful.
useful extremely useful.
useful extremely useful.
useful extremely useful.
inadequate adequate good excellent
no
You can view the complete questionnaire at: http://www.robin-beaumont.co.uk/virtualclassroom/chap3/s3/q19/008.pdf
The independent evaluation team should administer the questionnaire.
Numerous generic (i.e. QUIS see Chin et al 1988) and domain specific questionnaires (i.e. in the health arena Bailey
1990) have been developed. Anderson et al 1994 provides an appendix (p97) of 'survey instruments' as they are
called in the social sciences. The following website provides links along with a list of questionnaires
http://www.ucalgary.ca/~newsted/constructs.htm
Systems Evaluation is a large topic in itself and will be discussed further in a separate document.
14. Agile Techniques and eXtreme Programming
For more information about these techniques see section five of the document "Information systems Development
Methods" at http://www.robin-beaumont.co.uk/virtualclassroom/chap12/s3/des1.pdf
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 25 of 29
Developing Information Systems - Getting the users involved
15. MCQs
The help you assimilate the information provided in this document I have provided a small set of Multiple Choice
Questions (MCQs). If you are working through this document as part of an online course an excellent method of
revision is to share answers in the bulletin board.
Exercise 7.
If you are working online post your answers, along with possible comments, up on the bulletin board.
1. What is ‘top managers strategic withdrawal’ (Newman and Rosenberg 1985)?
a.
b.
c.
d.
The need of managers to retire from operational aspects to focus on strategic issues
Desire by managers for systems developers to leave then alone & just get on with it
The withdrawal of funding during a software project which is clearly going nowhere
The withdrawal of support from end users after the development stage
2. Which of the following are important stakeholders in most software developments (more than one may be true)?
a.
b.
c.
d.
e.
Champions
New employees
Potential saboteurs
Electricians
Programmers
3. Which of the following is an important characteristic of stakeholders that needs accessing?
a.
b.
c.
d.
e.
Educational level
Predictability
Professional group
Highest level of educational achievement
Learning styles profile
4. Traditionally what is often the measure of success of an information system?
a.
b.
c.
d.
e.
User interface satisfaction score
Down time
System use
Specification compliance
Specification completeness
5. Which of the following relationships have been found to exist in the systems development context?
a.
b.
c.
d.
User involvement -> System use -> User satisfaction
System use -> User satisfaction -> User involvement
User involvement -> System use -> User involvement
User involvement -> User satisfaction -> System use
6. Mumford 1983 identified several levels of user participation. Which are they?
a.
b.
c.
d.
e.
f.
g.
Minimal
Consultative
Formative
Representative
Consensus
Limited
Global
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 26 of 29
Developing Information Systems - Getting the users involved
7. To involve users fully in systems development, it is sometimes necessary to teach them certain technical
procedures. Which of the following represents one (or more) of these techniques?
a.
b.
c.
d.
e.
f.
SQL
Dynamic modelling
Visual Basic
Video analysis techniques
Time and motion techniques
Basic data dictionary development
8. Which of the following are functions of user groups (more than one may be correct)?
a.
b.
c.
d.
e.
Fund raising
Beta testing
Filtering requirements
Formally evaluating system
Providing training to end users
9. Which of the following provides a definition of resource-deficit participation?
a.
b.
c.
d.
e.
People are unable to participate fully because of time commitments
People are unable to participate fully because of situational or personal commitments or predisposition's
People are unable to participate fully because of financial constraints
People over come time constraints by reducing the use of resources per unit time
People do not participate fully and this results in a deficit in resource production
10. What does ETHICS stand for?
a.
b.
c.
d.
e.
Ethical Technical & Human Implementation of Computer Systems
Ethical Technical & Human Implementation of Clinical Systems
Effective Technical & Human Implementation of Computer Systems
Effective Technical & Human Implementation of Care Systems
Ethical Training & Human Information Computer Systems
11. ETHICS attempts to balance which of the following aspects (more than one may apply)?
a.
b.
c.
d.
e.
f.
g.
Technical issues
Social Issues
Maslow's hierarchy of needs
Job satisfaction
Financial reward
Self esteem
In service training issues
12. The Prodigy project used a development method that repeated which of the following sequences?
a.
b.
c.
d.
e.
Prototype -> Evaluation -> Specification development ->Contract negotiation
Prototype -> Evaluation -> Contract negotiation -> Specification development
Prototype -> Specification development ->Contract negotiation -> Evaluation
Contract negotiation -> Prototype -> Evaluation -> Specification development
Prototype -> Evaluation -> Prototype -> Evaluation
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 27 of 29
Developing Information Systems - Getting the users involved
16. Summary
This document has provided an overview of both why and how users should be involved in systems development.
Descriptions of three methods were given where user involvement is considered more important than in most. The
resource implications of such approaches were mentioned. The more traditional, pragmatic approach of long term
user groups was introduced along with a mention of the radical 'Extreme Programming" approach.
You should now revisit the list of learning outcomes at the beginning of this document and check that you
understand them. I hope you have enjoyed working through this document and feel that your time has not been
wasted.
All the best Robin Beaumont
17. References
Anderson J G, Aydin C E, Jay S J. 1994 Evaluating health care information systems - Methods and Applications. Sage
publications.
Arntez J E. Arntez B B. Petterson I L. 1996 Violence in the nursing profession. Work and stress 10 (2) 119 - 127
Au N, Ngai E W.T, Cheng T.C. E, 2002 A critical review of end-user information system satisfaction research and a
new research framework. Omega 30 (2002) 451 – 478
Bailey J E 1990 Development of an Instrument for the management of computer user attitudes in Hospitals.
Methods Information Med. 29 51-56
Baroudi J J Olson M H Ives B 1986 An empirical study of the impact of user involvement on system usage and user
satisfaction. Communications of the ACM 29 (3) 232 - 238
Beaumont R 1999 Review of Ergonomic assessment of CRAMS by John Dowell et al 1999 Internal report for the
Home Office. Available online: http://www.robin-beaumont.co.uk/probation/assess1.pdf
Beynon-Davies P, 1999 Human error and information systems failure: the case of the London ambulance service
computer-aided despatch system project. Interacting with Computers 11 699–720
Boddy D Buchanan D A 1992 Take the lead. London, Prentice Hall.
Chin J P, Diehl V A, Norman K L 1988 Development of an Instrument Measuring User satisfaction of the Humancomputer Interface. Conference Proceedings: Human Factors in Computing Systems (New York, 1988), ACM Press,
pp. 213-218. Also a computerised version "QUIS" available from Klnorman@umd2.umd.edu. And also
http://www.lap.umd.edu/webnet/paper.html [accessed 26/01/2008]
Churchill N C Kempster J H Uretsky M 1969 Computer based information systems for management. National
association of accountants. New York
Downing C E, 1999 System usage behavior as a proxy for user satisfaction: an empirical investigation. Information &
Management 35 203-216
Friedman A L Cornford D S 1989 Computer systems development: History, organisation and implementation. John
Wiley & sons Chichester
Hirschheim Rudy, Klein Heinz K, Lyytinen Kalle. 1995 Information systems development and data modelling:
Conceptual and philosophical foundations. Cambridge University Press. UK
Hwanga M I, Thorn R G, 1999 The effect of user engagement on system success: A meta-analytical integration of
research findings. Information & Management 35 229±236
Karasek R, Theorell T 1990 Healthy Work. Basic Books
McKinsey Company Inc. 1969 Unlocking the computer’s profit potential. Comput Automn 18 24 - 33
Mechanic D 1962 Sources of power of lower participants in complex organisations. Admve Sci. Q 7 (3) 349 - 364
Mumford Enid 1983 Designing participatively: A participative approach to computer systems design. Manchester
business school. UK
Mumford Enid 1983b Designing human systems - The ETHICS method. Manchester business school. UK
Mumford Enid 1993 Designing human systems for Health care - The ETHICS method. 4C corporation [ISBN 90 74687
01 6]
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 28 of 29
Developing Information Systems - Getting the users involved
Newman M Rosenberg D 1985 Systems politics of organisational control. Omega int j of mgmt Sci. 13 (5) 393 - 406
Nielsen J 1993 Usability Engineering AP professional London
Page D Williams P Boyd D 1993 Report of the Inquiry into the London Ambulance Service. South West Thames
Regional Health Authority. Available at: http://www.cs.ucl.ac.uk/staff/A.Finkelstein/las/lascase0.9.pdf
Simoens S, Scott A, 2002 Job Satisfaction, Work-Related Stress and Intentions to quit of Scottish Gps. Scottish
medical journal (SMJ) August 2002. Available at http://www.smj.org.uk/
Wanus J P. Lawler E E 1972 Measurement and meaning of job satisfaction. Journal of applied psychology 56 (2) 95 105
Document details
Written by Robin Beaumont Tel 0191 2731150 e-mail: robin@organplayers.co.uk
First version Date: 03/06/99
This version: 26/01/2008 21:01:01
Source: C:\HIcourseweb new\chap12\s4\des2.doc
Robin Beaumont robin@organplayers.co.uk 06/03/2016 Source: D:\106757447.doc
Page 29 of 29