Discovering the process of user expectating in a pilot implementation:Expectations and Experiences in Information Systems Development

Abstract

This Ph.D.-dissertation addresses the call for more research on “how” and “why” users change their expectations in Information Systems Development (ISD). Contrary to many previous studies on user expectations in the IS literature, the study takes an interpretative, qualitative approach to address the research question of: "How do users change their expectations in an Information Systems Development (ISD) project?"The findings of the study are that users in the case studied characterised their expectations in different ways and did not define an expectation, as previously assumed, as belonging to a single type. Users are also found to direct their expectations in several directions and not only towards product performance or functionality.The study derives a framework called “user expectating” from the IS literature and uses this framework to explain the phenomenon of how users change their expectations of an IS as a development project. It is proposed that more variables appear in the ISD context than previously believed. The framework is applied qualitatively to a longitudinal case study in the Danish Emergency Medical Services (EMS) Sector and the study finds that users change their expectations by reprioritising the directions of expectations and recharacterising them as both “will”, “hope”, “want”, “should” and “must”. These changes happened primarily when stakeholder actions (including those of the users) of “announcing”, “experiencing” and “giving feedback” took place in the project.Users would use the “should” and “must” characteristics when their experiences of the technology followed announcements from management or when users’ experiences followed giving feedback to management. Furthermore, users would change the directions of their expectations when experiencing that their expectations of e.g. functionality was met. Thus I propose that in an ISD project where an organisational prototyping approach is chosen it seems to be a basic condition that users change their own expectations when hearing new announcements, when experiencing the technology or project events or when providing feedback on their usage experience.The theoretical implications are that researchers should be wary of attempting to assess and measure users expectations in an ISD project using prior prevalent theories on user expectations since they do not fully seem to explain the phenomenon in an ISD context. Implications for practice are that while organisational prototyping approaches such as pilot implementations seem to have potential for improving organisations and technology through learning, they should be used with caution since users can quickly become weary of the iterative development context. The potential of the “user expectating” framework in practice is to use it as an indicator for whether progress of the project is made at all. If users change directions of expectations but not characteristics the project may seem to be on the right track while a project with continuous recharacterisations with no redirections may seem to be in trouble. However, this also assumes that the framework can be applied quantitatively.This Ph.D.-dissertation addresses the call for more research on “how” and “why” users change their expectations in Information Systems Development (ISD). Contrary to many previous studies on user expectations in the IS literature, the study takes an interpretative, qualitative approach to address the research question of: "How do users change their expectations in an Information Systems Development (ISD) project?"The findings of the study are that users in the case studied characterised their expectations in different ways and did not define an expectation, as previously assumed, as belonging to a single type. Users are also found to direct their expectations in several directions and not only towards product performance or functionality.The study derives a framework called “user expectating” from the IS literature and uses this framework to explain the phenomenon of how users change their expectations of an IS as a development project. It is proposed that more variables appear in the ISD context than previously believed. The framework is applied qualitatively to a longitudinal case study in the Danish Emergency Medical Services (EMS) Sector and the study finds that users change their expectations by reprioritising the directions of expectations and recharacterising them as both “will”, “hope”, “want”, “should” and “must”. These changes happened primarily when stakeholder actions (including those of the users) of “announcing”, “experiencing” and “giving feedback” took place in the project.Users would use the “should” and “must” characteristics when their experiences of the technology followed announcements from management or when users’ experiences followed giving feedback to management. Furthermore, users would change the directions of their expectations when experiencing that their expectations of e.g. functionality was met. Thus I propose that in an ISD project where an organisational prototyping approach is chosen it seems to be a basic condition that users change their own expectations when hearing new announcements, when experiencing the technology or project events or when providing feedback on their usage experience.The theoretical implications are that researchers should be wary of attempting to assess and measure users expectations in an ISD project using prior prevalent theories on user expectations since they do not fully seem to explain the phenomenon in an ISD context. Implications for practice are that while organisational prototyping approaches such as pilot implementations seem to have potential for improving organisations and technology through learning, they should be used with caution since users can quickly become weary of the iterative development context. The potential of the “user expectating” framework in practice is to use it as an indicator for whether progress of the project is made at all. If users change directions of expectations but not characteristics the project may seem to be on the right track while a project with continuous recharacterisations with no redirections may seem to be in trouble. However, this also assumes that the framework can be applied quantitatively