Developing Information Systems - Getting the users involved
- Getting Users Involved
in Developing Information Systems
By Robin Beaumont
e-mail:
Saturday, 05 January 2008
Version 3
Contents
How this document should be used:
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.
Who this document is aimed 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
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 Computer Anxiety, Job satisfaction and stress 22
13. 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
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
- 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:
- 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
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.
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.
Learning outcome / Tick boxBe able to identify various stakeholders
Be able to discuss various frameworks that classify stakeholders / q
Be able to discuss the reasons why user involvement is important in systems development / q
Be able to discuss the reasons why undue emphasis is placed on ‘specification compliance’ in traditional system development methods. / q
Be able to discuss the relationship between user education, user involvement, user satisfaction and system use / q
Be able to discuss the three levels of user involvement proposed by Mumford / q
Be able to discuss the educational requirements when considering user involvement / q
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 / q
Be able to discuss the advantages and disadvantages of user groups / q
Be able to discuss the various communications strategies that can be used with user groups / q
Have a broad grasp of the USU method / q
Have a broad understanding of Agile and eXtreme Programming methods / q
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 / GroupMoney / 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.
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).
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 play a part in decision-making.
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.
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 AdministratorsTheir 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: