Information processing Systems

1. Information processing Systems M. A. KHAN– U4364891

2. Ch 8: Information Processing Systems Information System Development – Methods in Action Brian Fitzgerald Nancy L. Russo and Erik Stolterman pp. 137-146

3. Introduction Categorization of Systems • Families of Systems • Similarities but dynamics of change • System Purpose • Entertainment v Efficiency • Systems for Control and Communications • System Complexity • Size, Interaction or use complexity, System thinking

4. Information Processing Systems • Unique versus Standard • ISD- a process of composition • SYSTEMS AND CHANGE • Shifting and drifting of a system (Cibborra,95) • Safety critical v creative systems • Importance of Understanding IS properties &Types

5. R5: Matching Methodology to Problem Domain by Robert L.Glass • How and when to use methodology! Prescriptive methodologies are unlikely to cope– Use approaches tailored to each project • Need for research to Taxonomize the available methodologies, the problem domains and matching process • Communication chasm between academics and practitioners; Academics spending sabbaticals in industry, and practitioners as adjuncts in academies • Fallacy of software field

6. R10 & 96:Selecting the Appropriate methodology • System Development Life Cycle Methodology Linear approach; Analysis, Design, Program Development and Implementation. Failures due to inadequate understanding of the requirements resulting into ‘freezing’ of the design. • Primarily used for transaction processing systems • Advantages include predictability, stability, control of the development process, rational behaviour in problem solving, ease of planning and ease of integration

7. Prototyping • Existing system v imaginary system • Concrete approximation of the system • New requirements incorporated in new prototype; High User involvement • Fast development time requiring use of the requisite tools

8. Prototyping • Benefits of Prototyping; • Higher level of user satisfaction • Cost reductions due to reduced programming time • Some Problems of Prototyping • Less efficient systems produced due to lack of initial analysis and design • Documentation and testing activities by passed

9. Types of Prototyping • Level one prototyping (Input/Output Design) - Generation of online screens and printed reports • Level two prototyping (Heuristic Design) - Extends the prototype to include interaction of files and transaction • Level three prototyping (Adaptive Design) - User and developer experiments with the prototype until the end product is build

10. Background • End-User Development : Many Users developing their own applications due to the availability of powerful personal computer and user-friendly software tools. • Factors Affecting the Choice of Methodologies: • 3 contingency variables • Project Uncertainty • Project Complexity • User’s System Experience

11. Mixed Methodology • Mixed Methodology integrates both of the two major methodologies-System Life Cycle and Prototyping • The Prototype is discarded after the user requirements are obtained and the specifications are frozen • Phased Design Methodology • Entire system is designed at a coarse level. Each subsystem is refined and approved

12. A Contingency Approach to Methodology Selection • Prototyping less suitable for large or complex systems • Davis and Olson’s One dimensional contingency approach to the selection of requirement determination strategy. • Project size, degree of structuredness, user Task Comprehension, Developer task Proficiency used to determine degree of uncertainty inherent in a project.

13. A Contingency Approach to Methodology Selection • Two-dimensional contingency approach based on project uncertainty and project complexity • Project Complexity High Low Low High Project Uncertainty • Three contingency to determine project uncertainty: 1. Degree of Structuredness 2. User Task Comprehension 3. Developer Task Proficiency

14. A Contingency Approach to Methodology Selection • Four contingencies to determine project complexity: 1. Project Size 2. Number of Users 3. Volume of New Information 4. Complexity of New Information • Prototyping for one user may not be difficult but it may be so for many. A modification requested by one user may be approved by all

15. A Contingency Approach to Methodology Selection • For projects with low uncertainty and low complexity, any one of the three methodologies would be appropriate • Application of same development techniques to all projects is no longer possible as projects have different characteristics and needs • The ability to choose the most appropriate development methodology is important and contingency approach answers to this need

16. The Research Model • Dependent variables : • User Satisfaction • System Utilization • Two Premises: • The appropriate methodology for development of a system is dependent on the three contingency variables. • The level of user satisfaction and system utilization higher when there is ‘match’ between Methodology and each combination of contigency variables

17. The Hypotheses • Based on the literature, the SDLC is prescribed for high complexity and low uncertainty; • Prototyping could be used along with the SDLC with the level depending on the user’s system experience in high complexity and high uncertainty. • Prototyping if the system is high in uncertainty and low in complexity; if the user is experienced , the level of prototyping needed should be less than if the user is not experienced. • Mixed methodology for high uncertainty and high complexity

18. Research Framework

19. The Hypotheses • Two General hypotheses: • H1 : When the utilized methodology matches the prescribed methodology, user satisfaction will be high • H2 : When the utilized methodology matches the prescribed methodology, system utilization will be high

20. The Hypotheses • 8 Specific Hypotheses ( Tested similarly in terms of System Utilization) • H1.1 Under conditions of high complexity, low uncertainty , and low user’s system experience (USE) , user satisfaction will be higher for those who use the SDLC approach than those who use other approaches • H 1.2 Under conditions of high complexity, high uncertainty, and low user’s system experience (USE), user satisfaction will be higher for those who use

21. The Hypotheses Prototyping level two than those who use other approaches. • H1.3 Under conditions of high complexity, low uncertainty, and high user’s system experience (USE), user satisfaction will be higher for those who use the SDLC approach than those who use other approaches • H 1.4 Under conditions of high complexity, high uncertainty, and high user’s system experience (USE), user satisfaction will be higher for those who

22. The Hypotheses use prototyping level one or two than those who use other approaches • H 1.5 Under conditions of low complexity, high uncertainty, and high user’s system experience (USE), user satisfaction will be higher for those who use prototyping level one or two than those who use other approaches • H 1.6 Under conditions of low complexity, low uncertainty, and high user’s system experience (USE), user satisfaction will be higher for those who

23. The Hypotheses EUD than those who use other approaches • H 1.7 Under conditions of low complexity, high uncertainty , and low user’s system experience (USE), user satisfaction will be higher for those who use prototyping level two or three than those who use other applications • H1.8 Under conditions of low complexity, low uncertainty, and low user’s system experience (USE), user satisfaction will be higher for those who use

24. The Research Model Prototyping level two or three than those who use other approaches • Research Methodology 1400 members of Association of System Management were issued questionnaires containing a list items dealing with Project uncertainty and project complexity. Users were forwarded questionnaires regarding satisfaction and system utilisation

25. Results • T-tests conducted to find out if there was a significant difference in user satisfaction and system utilization between those who used the prescribed methodologies and those who used non-prescribed approaches. • At 5% significance level, it was found that user satisfaction and system utilization were significantly higher in projects that used the prescribed methodologies than in those using other methods.

26. Results • Satisfaction Hypothesis: Hypotheses H1.2, H1.3 , and H1.6 were supported at alpha= 0.05 • Utilization Hypothesis: Hypotheses H2.1, H2.3 , H2.7 and H2.8 were supported at alpha of 0.05

27. DISCUSSION OF THE RESULTS • Managerial Implications Managers may use the level of three contingency variables of project uncertainty, project complexity and user’s system experience instead of solely relying upon their judgments • Research Implications • Importance of isolating the user’s system experience (USE) which was considered part of uncertainty • Importance of contingency relationship demonstrated

28. Portfolio approach to Projects • R20: A Portfolio Approach to IT Projects - Lynda M. Applegate - Robert D. Austin - F. Warren McFarlen R107: A portfolio approach to information systems - F. Warren McFarlen

29. Risks • Three major reasons causing Project failures: 1) Failure to assess the implementation risk of a project at the time it is funded 2) Failure to consider the aggregate implementation risk of a portfolio of projects 3) Failure to recognize that different projects require different managerial approaches

30. Sources of Implementation Risk • Project Size • Dollar amount, number of departments, time duration • Experience with technology • New Technology • Project Structure • High Structured • Low Structured

31. Project Categories and Degree of Risk • Assessing risk for individual projects Low company- Relative Technology High company-Relative Technology • Questionnaire to assess the risk (42 questions) e.g Total development hours 100 to 3000 Low 1 15,000 to 30,000 Medium 2 More than 30,000 High 3

32. Project Categories and Degree of Risk; Portfolio Risk • A company loaded with high-risk projects may be vulnerable to operational disruptions:

33. Project Management: A contingency Approach • Management Tools: Four principal types: • External Integration tools • Internal Integration devices • Formal Planning tools • Formal result –control mechanisms • Influences on Tool Selection • High Structure/Low-Technology Projects: Formal Planning tools like PERT, CPM for such stable projects

34. Project Management: A contingency Approach, Tool Selection • High-Structure/High-Technology Projects • Converting a mainframe system to run on client-server architecture and a firms’ initial efforts at Web-enabling access to key content for internal use by company employees are some of the examples. • Interaction between the Project Team and the Users is not so crucial as outputs are well-defined • Technical leadership and internal integration are the keys in this type of projects

35. Influence on Tool Selection • Low-Structure/Low Technology Projects: • Key to success lies in effective efforts to involve the users in design, development and implementation • Close, aggressive external integration • Low-Structure/High-Technology Projects • Outputs not clearly defined at the start of the project • Extremely difficult and complex projects like NASA’s Apollo moon project

36. Relative Contribution of Management Tool to Project success

37. Emergence of Adaptive Project Management Methods • Approaches to design, deployment, implementation, and investment that assume a need to gather information and to learn as one goes. • The adaptive methodologies are intended to replace SDLC involving : • Analysis and Design • Construction • Implementation • Operation and Maintenance

38. Adaptive Methodologies • Five basic characteristics of adaptive projects: • They are iterative • They rely on fast cycles and require frequent delivery of value . • Early delivery to obtain early feedback • They require skilled staff capable of making midcourse adjustments • They often investment decision making tools like ROI • Adaptive Methods and Change Management

39. Process Consistency and Agility in Project Management • Project Management involves tension between process consistency and process agility. • The tension arises as tools used to improve consistency- specifications, documentation, compliance mechanism- often are perceived as encumbrances that work against project responsiveness and agility. • Light Methodologies adopted containing essential elements of heavy methodologies but are not cumbersome.

40. A Minimalist Approach to Process Formalization • In order to balance discipline and agility, simple process management tools falling into following three categories are used: • Flow : Simple Schedules and flowcharts to understand the relationships • Completeness: Simple check Lists showing what needs to be done • Visibility : Computerized status-reporting systems and Wall charts that allows status to be tracked

41. Summary • The dimensions of implementation risks can be identified in advance • Management must make critical decisions on the aggregate implementation risk profile of IT Portfolio • Project Management in the IT field is complex requiring different tools for different projects • Importance of Risk assessment procedures and exploration of emerging project methodologies

42. Project Types R 92 : One Size Does not Fit All-True for Projects, True for Frameworks R98:Towards a typological theory of project management • Aaron J. Snehar • Dov Dvir

43. One size does not fit all • Introduction Common myths about project that all projects are the same and similar tools can be used for all projects i.e Project is a project is a project syndrome. Many project failed as management assumed that their current project would be the same as the previous one • Adapting right techniques for right projects is important for project success.

44. The Frameworks: How to distinguish projects • Strategic Goal Classification : Some have Long term business perspective while others are of exploratory nature. 5 different types • Extension Projects : Extensions of existing products. Short term ‘cash cows’. Slight modifications or upgrades like automobile models or stripped down models with less features. • Strategic projects : Long term perspective. Backbone of the organisations like Boeing 777

45. How to distinguish among projects • Problem-Solving Projects: Narrow-focused and short term aiming to just solve the problem. • Utility Projects : These projects are made to ‘ keep the lights on’. Necessary for organisational sustainability. Procurement and installation of new equipments, re-engineering or new software acquisition and implementation like ERP. Such projects may have low priority or slow time frames.

46. How to Distinguish among Projects • Research Projects : • Initiated for the purpose of learning, investment in the future. • Receive low priorities and often need to be separated from the urgent ones • The UCP (Uncertainty, Complexity and Pace) Model – A universal framework to distinguish the projects)

47. The UCP Model • Uncertainty : At the moment of Project initiation. External uncertainty involving Customers , etc, and internal uncertainty like product design. • Complexity : Complexity and Uncertainty not the same thing like building a high-rise office tower in a major city may involve low level of uncertainty but high complexity due to project size, number and variety of elements. • PACE : Time and speed. The higher the pace , the closer is project monitoring

48. The Sources of Project Risk • Market Uncertainty –External Introduction of new products like Walkman by Sony. • Three major categories : • Derivative Projects The projects include cost reduction, improvements and additions to existing lines. • Platform Projects Replace previous projects, Uncertainty high like new aircraft combat designs

49. The Sources of Project risk • Breakthrough Projects • First Personal Computer, First Microwave Oven. • Fast prototyping necessary. • Change in specifications inevitable after market feedback. • Technological Uncertainty ( Internal) Higher technological uncertainty at the time of project initiation requiring longer development phases, more testing.

50. Technological un-certainty dimension • Type A: Low technological uncertainty-Low tech projects • Familiar technologies like construction and road projects • Type B: Medium technological uncertainty-medium-tech projects • Involve adaptation of familiar technologies with limited amount of new technology like industrial projects of incremental innovation