1. SD A Poor record! The Traditional SAD Process -Success or Failure? Mowshowitz found in a survey of North American organisations that:- Only 20% of systems achieved intended benefits 40% showed marginal gains 40% were failures Other surveys have supported these findings

2. IT in the Public Sector In the public sector the Comptroller and Auditor General has produced several reports highly critical of IT applications in the:- Inland Revenue The NHS The Civil Service

3. IT in the Public Sector In the IR a major project was abandoned in 1985 costing 16.5 Billion pounds to be lost Failure was largely due to:- weakness in project management poor system design inadequate staffing lack of skilled IT staff

4. Examples of poorly developed/failed systems Large number of well publicised examples of failed systems within the Public Sector DHSS Privatisation of Government IT Services Ministry of Defence West Yorkshire Police Teachers Pensions Wessex Health Authority LAS

5. Reasons for failures The National Audit Office identified several key reasons including:- –Weakness in project management –Poor system design –Inadequate staffing –Lack of skilled IT staff –Lack of/inadequate training –Poor specification of requirements

6. Systems Failure More recent evidence suggests that systems failure continues to be a problem Survey by KPMG revealed that in America 31% of software projects were never completed (KPMG 1995) The main reasons for these failures included –Poor project planning –Did not relate to organisations business needs –Weak poor definitions of requirements Subsequent survey in 1997 replicated previous findings (KPMG What went wrong? Unsuccessful IT Projects)

7. Recent Systems Failures The computer press almost weekly continue to report on the failure of a particular system In the last 36 mths the following systems have experienced difficulties due to a range of factors including human technical & organisational –A 4million MET Police System ‘SID’ May 1996 –25m DSS welfare benefits system scrapped –Passport Agency delays 2X slower than old system 1999

8. What went wrong? The SA&D methods developed in the 60's and 70's These were applied to well understood and relatively straightforward applications Invoice generation Rates These were BATCH processing applications Users were mainly concerned with running the application and entering data

9. SAD Issues The advent and proliferation of PC's the type of applications and the tasks that the system is expected to be able to do has meant that :- – Processing is now done more in REAL TIME – Centralised computing resources have become decentralised – Greater number of users now have direct contact with computers – Users are different!! Thus there has been a fundamental shift in the issues that need to be addressed in the SA&D process

10. Evidence suggests that IT implementation has not been a great success Design criteria should be to develop a system capable of serving organisational goals - not simply to develop a technical system which is only capable of delivering a technical service This can lead to a system which does not serve the users

11. SAD Issues Now there is the need to not only consider the technical aspects of system design, must also consider the social aspects and the organisational consequences of computerisation Unlikely to achieve real benefits unless ways can be found to ensure that the design process adequately addresses the human organisational and technical requirements Traditional methodologies failed to adequately address these aspects

12. Design Methods Leads to Socio- Technical Design of IT systems when this is achieved we may experience and expect a greater chance of success Suggests that we must look for methods that place less emphasis on the technical aspects of systems design

13. Systems Design Methods As a result of the changes in technology and in recognition of the need to consider human issues design methods have changed dramatically in recent years The following major methods of design have emerged:- Traditional Data Processing design Structured Design Methods - SSADM Soft Systems Design - SSD Participative Design Methods - ETHICS Socio Technical Systems Design User Centred Design End - user Developed Systems RAD OOAD

14. Structured Design Methods (SDM) These provide a well documented and consistent set of procedures for the developers of the system to follow They follow the traditional cycle of development but include a number of important innovations They place emphasis on the entities as well as the processes in the application They require extensive and specific documentation at key stages They inject discipline into change control - a change to one part of the proposed system means that any consequences for other interdependent parts will be thoroughly examined they provide for progress reports at key stages which the user ' signs off ‘

15. SDM At the end of each stage there is a formal user review before progression to the next stage Implicit in this methodology is the concept of a customer - contractor relationship At various stages the designers are obliged to provide evidence of progress and customers are empowered to assess the progress of the design Design cannot proceed until the customer is satisfied that the system is being designed to meet their requirements Thus the user formally accepts the specification and the design On the face of it this provides users with a greater input and involvement in the design process

16. SDM Stages - Documentation Documents required from stage 2 DFD's ELH's LDS Problem requirements list Function catalogues entity descriptions Event catalogue

17. Stage 3 - examples of steps in stage 3 Create technical options User selects from technical options

18. Problems with SDM What do you consider the kind of problems that this particular method might have? La ck of technical knowledge –Communicating with specialists –Defining needs –Seeing opportunities –Which users –Resolving conflict –Technical not organisational design –Acting quickly - must specify early in the process - therefore presents users with a limited 'window' for making a contribution to the design process

19. Addressing H& O issues Hornby & Clegg Article