IMS3230 - Information Systems Development Practices - PowerPoint PPT Presentation

liam
ims3230 information systems development practices n.
Skip this Video
Loading SlideShow in 5 Seconds..
IMS3230 - Information Systems Development Practices PowerPoint Presentation
Download Presentation
IMS3230 - Information Systems Development Practices

play fullscreen
1 / 35
Download Presentation
IMS3230 - Information Systems Development Practices
192 Views
Download Presentation

IMS3230 - Information Systems Development Practices

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. IMS3230 - Information Systems Development Practices Organisational Themes; People themes Semester 2, 2005

  2. References • Avison, D.E. & Fitzgerald, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London. Chapters 1, 4.2-4.6, 6.6, 7, 15, 16 • Kolb, D.A., Rubin, I.M. and Osland, J. (1995). Organisational Behaviour: An Experiential Approach. (6th ed) Prentice-Hall, Englewood Cliffs. • Schermerhorn, J.R., Hunt, J.G. and Osborn, R.N. (2000). Managing Organizational Behavior. (7th ed). Wiley, New York.

  3. Organisational themes in ISD • Strategic information systems • Business process re-engineering (BPR) • Information systems planning • Organisational change

  4. Organisational themes in ISD strategic information systems: early computerisation focused on basic transaction processing: cost savings quantifiable, perform same processing more efficiently limitations of further efficiency gains: opportunities limited as more projects completed some opportunities unlikely to demonstrate these types of savings emergence of an additional role for information systems and IT: a direct tool for gaining competitive advantage

  5. strategic information systems use information systems to improve the business in the market place: competitive advantage: - redefine the boundaries of specific industries - develop new products and services - change the relationships between customers and suppliers - establish barriers to deter new entrants to the market place cost justifications more difficult: - benefits are not reduced costs - need to show that benefits (e.g. improved service) will be recognised - implications for methodologies

  6. Business process re-engineering (BPR) business process re-engineering (BPR): opportunity to re-engineer business processes which is enabled by technology: “the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed” Hammer and Champy (1993) what an organisation should do, how it should do it, what its concerns should be, not what they currently are

  7. Business process re-engineering (BPR) motivations for re-engineering - no choice commercially - competitive forces require re-aligning business processes with strategic positioning - organisation management see re-engineering as an opportunity to streamline and to overtake their competitors - the “band wagon” effect: copy the competitors

  8. Business process re-engineering (BPR) Hammer and Champy’s model - combine several jobs which are performed by a “case worker” responsible for an entire process - “case team” members are empowered to find ways to: improve service and quality, reduce costs and cycle times - process integration means less checks and controls - less defects as the entire process is completed by those responsible for the final product - process steps determined by those completing the task - parallel processing of entire operations is possible

  9. Business process re-engineering (BPR) BPR: experiences of project failures (and failure rates) - senior managers lack motivation for organisational change: BPR must be driven from the top - extent of necessary change not fully recognised - piecemeal approaches mean individual process gains not translated into organisational level improvement - failure by top management to adequately define future operations - non-critical business operations addressed - motivation is publicity/bandwagon or management’s reputation - short-term financial pressures result in lack of resources - BPR is radical change, not TQM etc.

  10. Information systems planning planning approaches: stress the planning required to develop an organisation’s information systems top management involved in analysing the organisation’s objectives plan for the use of IS/IT to achieve the business objectives avoid a piecemeal approach to IS development align IS/IT with the business planning at three levels: long term, medium term, short term

  11. Information systems planning approaches - organisation-wide perspective promotes integration - involvement of top management - IBM's BSP (Business Systems Planning 1975) • strategic management view of entire organisation • top management defines organisational needs and priorities • establish a stable information architecture • implementation from bottom up

  12. Organisational change • introducing and managing organisational change: - new information systems - new information technology • for systems development: - new system development methodologies - new system development technologies - new system development techniques • user perspectives • systems developers as users: changing roles and technology

  13. Organisational change organisational targets for change (Kolb et al 1991) • the people subsystem: personnel flow, education • the authority subsystem: formal authority relationships, informal leadership patterns • the information subsystem: formal, informal • the task subsystem: job satisfaction, technology • the policy/culture subsystem: formal explicit, informal implicit • the environmental subsystem: internal physical environment, external environment

  14. Organisational change resistance to change: • feedback that can be used constructively by the change agent • why do people resist change? - fear of the unknown - doubts about future competence - comfort with the status quo - vested interests threatened - “surprise” factor - poor timing - lack of resources - job security

  15. Organisational change three phases of planned change: 1. unfreezing 2. changing 3. refreezing

  16. Organisational change acceptance criteria for changes: • changes must have clear, appropriate benefits • changes must be compatible with existing values and experiences • changes must not be too complex • changes should be able to be tried on an incremental or experimental basis

  17. Organisational change strategies for gaining support for change: • force - coercion: legitimacy, rewards, punishment • rational persuasion: expert power, rational argument • shared power: trust-based, common vision

  18. Organisational change dealing with resistance to change: (Schermerhorn et al 1994) • education and communication • participation and involvement • facilitation and support • negotiation and agreement • manipulation • explicit and implicit coercion

  19. Initiating and managing change SCOUTING The Process of Planned Change ENTRY DIAGNOSIS PLANNING ACTION Kolb et al (1991) p. 593 EVALUATION INSTITUTIONALISATION

  20. Initiating and managing change scouting determine readiness for change, obvious obstacles entry negotiate a "contract" with entry point representatives diagnosis the perceived problem, goals, resources available planning define change objectives, alternative solutions, strategies action implement change: activities, resistance, monitor evaluation relate to objectives institutionalisation complete vs continuous

  21. People themes in ISD Some potential solutions: • Participative approaches • Management commitment/leadership • Improved human-computer interfaces • Training and education: developers and business users • End user computing • JRP and JAD sessions

  22. User participation • early systems development approaches: - focus on technical aspects of computer systems - little actual decision-making by users • problems: - users resented developers as “outsiders” with little understanding of the business environment - systems “imposed” on users and not “user friendly” - systems did not adequately support business needs

  23. User participation: definitions • Barki and Hartwick (1989) distinguish between: user participation a set of activities and behaviours performed by users user involvement a subjective, psychological state when a user considers a system to be both important and personally relevant How do these affect system usage and user satisfaction? How can we define and measure user satisfaction?

  24. User participation: definitions participation as user involvement in systems design: “ a process in which two or more parties influence each other in making plans, policies or decisions. It is restricted to decisions that have future effects on all those making the decisions or those represented by them” (Mumford 1983, p. 22) participation may have different meanings for different groups: e.g. morally right, employee commitment, management tool, empowerment of employees etc.

  25. Mumford’s three levels of user participation three levels are identified by Mumford (1983): • consultative all users are consulted about/contribute ideas to the design process but the design task is carried out by systems analysts • representative design groups formed from elected or selected representatives take design decisions • consensus design group members constantly discuss ideas and solutions with all users

  26. User participation expected benefits of user participation: • improved system quality: more complete, accurate requirements provides expertise about the organisation avoids development of unacceptable or unimportant features improves user understanding of the system • increased user acceptance: realistic expectations “arena” for conflict resolution users more committed to the system decreased user resistance

  27. User participation and ISD methodologies • Structured analysis user walkthroughs, users select implementation option • SSADM user walkthroughs, user representation in development teams, users select technical option, • Information Engineering users active in design activities, management involved in ISP and BAA, user reviews • SSM users part of team: problem owners and solvers • ETHICS users do the design

  28. End-user computing • Enabled by PCs and application packages for non-IT people e.g. spreadsheets, database, VisualBASIC etc • Users in business organisations were able to build their own business applications, either stand-alone or integrated with organisational systems • Definitions of end-user computing: e.g. “the practice of end-users developing, maintaining, and using their own information systems” (Mirani and King 1994)

  29. End-user computing • Early 1980s: user-driven computing -end-user computing enabled by introduction of PCs -decentralisation of computing resources • Resulted in user satisfaction: -met needs unlikely to be satisfied by IT departments -some pressure off IT departments -end-users “close” to the business problems -systems resourced/costed within user department budgets

  30. End-user computing • problems of control: validity and integrity of data lack of documentation security issues maintainability application “islands” duplication and inconsistencies assistance required by users

  31. End-user computing • A “solution”: Information Centres -Staffed and run by IT department -Provide consultation, software and tools, liaison with vendors etc. to assist users in developing their own departmental information systems • Significant in 1980s and early 1990s • Increasingly sophisticated users of today have no need for Information Centres • Users today need support from IT corporate specialists when developing customer-oriented systems in particular i.e. change from the tactical, problem-solving role of the past to a strategic, consultant role

  32. JAD (Joint Application Development) • can be for analysis and/or design • originated in late 1970s at IBM • bring together key users, managers, systems analysts in a group meeting with a specific structure of roles and agenda • JRP (Joint Requirements Planning): key system requirements • JAD: specify the system’s design (external design only) • group meeting: avoid distractions identify areas of agreement and conflict resolve conflicts during the period of sessions

  33. JAD sessions: roles • JAD participants: • facilitator: organise and run the sessions • scribe(s): takes notes on a PC, CASE tool etc • users: understand the system requirements • managers: organisational overview • systems analysts: technical knowledge, learn about the system • sponsor: senior executive who commits and funds the process

  34. Joint Application Development (JAD) JAD sessions: • from one to five days • structured meeting room with white boards etc., CASE tools • located away from users’ workplace • outcome is documents detailing the system: workings of/requirements for the system/design

  35. JAD sessions benefits: • reduced time to move requirements/design forward (group vs one-on-one, details worked on between meetings) • key people work together to make important decisions • commitment is focused and intensive, not dissipated over time • conflicts and differences can be understood and resolved improved quality and productivity