• No results found

TOWARDS A BETTER UNDERSTANDING OF INDIVIDUAL IT USER DEVELOPMENT

N/A
N/A
Protected

Academic year: 2021

Share "TOWARDS A BETTER UNDERSTANDING OF INDIVIDUAL IT USER DEVELOPMENT"

Copied!
39
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

TOWARDS A BETTER

UNDERSTANDING OF INDIVIDUAL

IT USER DEVELOPMENT

Master thesis, MSc Business Administration - Change Management

University of Groningen, Faculty of Management and Organization

June 2014

Arjan van den Top

Student number: S2386917

(2)

2

ABSTRACT

This research examines the development of individual IT use by determining post-adoption stages users go through, influential critical incidents, and changes in emotions, cognitions, and behaviors. Twelve interviews are conducted within a Dutch advocacy organization, which implemented a packaged

information system on January 1st, 2012. During the interviews I used a sports metaphor and a timeline to help respondents think of their staged development. The critical incident technique is used to determine events that influence individual IT user development. The results of this study point out that users can be situated in five developmental stages. Critical incidents, which are divided into four categories,

sometimes turn out to yield or contribute to stage transitions. Additionally, the occurrence of critical incidents can lead to short-lived emotional state switches. The findings are visualised in multiple models.

Keywords: information systems; post-adoption stages; critical incidents; emotions; cognitions;

behaviors; IS use patterns; user development.

INTRODUCTION

The benefits gained from information systems frequently do not meet expectations or fail to materialize at all (Fadel, 2012). Previous research showed that this is caused by underutilization of the system by individual users (Jasperson, Carter & Zmud, 2005; Barki, Titah, Boffo, 2007). For effective use of a system, users need to develop themselves through various stages of the post-adoption phase. Premkumar, Ramamurthy & Nilakanta (1994) describe three distinct stages: routinization, infusion, and extension. In an ideal situation, users categorized in the routinization stage learn how the system can support their tasks in an adequate manner. Subsequently, in the infusion stage, users master the process to become as

effective as possible within the current possibilities of the system. Lastly, in the extension stage, users find possibilities to make the current process even more effective. However, according to Jasperson et al. (2005), ―users employ quite narrow feature breadths, operate at low levels of feature use, and rarely initiate technology- or task-related extensions of the available features‖ (p. 526) (Davenport, 1998; Lyytinen & Hirschheim, 1987; Mabert, Soni & Venkataramanan, 2001; Rigby, Reichheld & Schefter, 2002; Ross & Weill, 2002). For that reason, they call for development and application of ―richer and more complex research models in examining the variation within and across individuals‘ post-adaptive

(3)

3 Aside of the abovementioned gap, Saeed & Abdinnour (2013) argue that the categorization of stages within the post-adoption phase is unclear. They maintain that there is no clear approach that can confirm whether a user is in the routinization stage, in the infusion stage or in the extension stage. This implies more knowledge has to be obtained to be better able to categorize these stages. Previous research indicated that use patterns might be helpful to get a better representation of stages (Saeed & Abdinnour, 2013). Ortiz de Guinea & Webster (2013) describe in their research that users engage in an automatic IS use pattern or an adjusting IS use pattern during the post-adoption phase. They maintain that, over time, different IS use patterns come and go, whether or not these are triggered by critical incidents, such as IT events. However, they did not link the emotions, cognitions, and behaviors, of which IS use patterns are composed, to critical incidents or the post-adoption stages. Also Fadel (2012) describes more research is needed to how users adapt one‘s self, modify procedures and routines, or change technology over time.

This research aims to fill the gaps mentioned above. I want to research how individual IT users develop themselves over time. Looking at this development, I focus on stages users go through, critical incidents they consider important for their development, and emotional, cognitive and behavioral changes they experience over time. The following research question is formulated:

How develops individual IT use over time and which critical incidents play a role in this development?

To be able to answer this question, I have formulated four sub questions: 1) Which post-adoption stages do individual IT users go through?

2) How do individual IT users’ emotions, cognitions, and behaviors (IS use patterns) develop over time? 3) Which critical incidents have played a role in the development of individual IT users?

4) To what extent can critical incidents be linked to stage transitions and emotional, cognitive, and

behavioral development?

(4)

4 The remainder of this paper is organized as follows. First, the theoretical foundation, on which this research is build, in introduced. Second, an elaboration is given of the methods used in this research. Third, the results of this study are presented. Fourth, a conclusion of the results is given. Thereafter, the results are discussed, implications for research are shown, and possible interesting areas for further research are determined. I conclude with the implications for practitioners, and the limitations this research entails.

THEORETICAL FOUNDATION

As the notion of development can be interpreted in different ways, it might not be superfluous to provide explanation. Especially in the context of IT, readers might think of development as the creation of new system functionality. However, when I write about development in this research, it comprises the progress individual users make in their IT use. To be better able to grasp the complex process of user development, a staged approach is used. Previous research elaborated on the various stages of the post-adoption phase.

Stages Within the Post-Adoption Phase

The adoption process of innovation consists of three general phases, namely pre-adoption, adoption and post-adoption (Damanpour & Schneider, 2006). Various authors distinguished stages of the post-adoption phase on the individual level. In this research, I draw on three stages described by Premkumar et al. (1994), starting with routinization, going through infusion to the extension stage. In the routinization stage, individual users are getting used to the new IT and make it part of their routine. According to Saeed & Abdinnour (2013), mainly expanded usage is shown in this stage, defined as ―the extent to which the users are leveraging the different features of IS to perform tasks‖ (p. 225). I follow Cooper & Zmud (1990), describing that the routinization stage ends when the IT itself is perceived as ordinary and the use of it as a normal activity. After routinization, infusion takes place. This stage comprises advanced incorporation for more elaborated use, leading to more effectiveness. In the infusion stage, most use is integrative, defined as ―the extent to which the users are able to effectively integrate the IS into their work‖ (Saeed & Abdinnour, 2013, p. 225). I consider the effective use of IS features the user is familiar with to execute the tasks at hand as the ending point of this stage. The last stage is extension, in which individuals further familiarize with IT, resulting in the ability to perform a more comprehensive set of work tasks. According to Jasperson et al. (2005), extension includes exploring features within or outside of the IT that are not primarily needed for task execution. Saeed & Abdinnour (2013) describe

(5)

5 By theorizing about post-adoption stages, it is easier to understand the development process.

Additionally, it becomes apparent that researchers take a linear perspective in describing these stages. This linearity can be depicted as shown in Figure 1 (Saeed & Abdinnour, 2013, p. 223).

Figure 1 - Individual IT User Development and the Post-Adoption Stages (adopted from Saeed & Abdinnour (2013))

Now I have introduced the post-adoption stages, the focus will be on concepts that can be related to this staged development and, possibly, stage transitions. Critical incidents, recalled by users themselves, might be influential for their development. These incidents can stem from both inside and outside the system. As one can think of an infinite number of critical incidents stemming from outside the system, no attention is devoted to these. Critical incidents within the system are called IT events.

IT Events

When people make use of IS, they can face both expected and unexpected IT events (Ortiz de Guinea & Webster, 2013). Before I turn to the definitions of expected and unexpected IT events, task-technology fit (TTF) theory will be introduced. Goodhue (1995) describes TTF as the extent to which the characteristics of IS match the users‘ needs for task completion. While it might be assumed that organizations introduce IS to assist people in executing their tasks, users might also be hindered in the performance of tasks (Goodhue, 1995). In the case of expected IT events, IS matches the expectations of users while executing their tasks (Tyre & Orlikowski, 1994), creating a task-technology fit. Unexpected IT events can be divided into two types. Unexpected negative IT events, which will be referred to as discrepant IT events in this research, are events in which users expect something else from IS than actually occurs (Louis & Sutton, 1991). On the one hand, such a discrepant IT event can be experienced by users as a threat, since

Individual IT User Development

Routinization Stage

Users use the various features that IS has to offer

Infusion Stage

Users integrate the IS in their work

Extension Stage

(6)

6 the event could hamper task completion (Ortiz de Guinea & Webster, 2013). Here, there is a

task-technology misfit. On the other hand, discrepant IT events can be seen as an opportunity for learning and simultaneously improve the task-technology fit. Unexpected positive IT events, which are called

discovery IT events (Ortiz de Guinea & Webster, 2013), are ―characterized by the discovery of new functionality of the technology‖ (p. 1168). Ortiz de Guinea & Webster (2013) describe that events could occur sequentially: users might encounter an error message while executing their task. This error message challenges them and ultimately leads to a solution to better task performance. In this example, a

discrepant IT event triggers a discovery IT event.

This theory about IT events provides an overview of possible critical incidents within the system that can lead to user development or possible stage transitions. The appearance of IT events also elicits IS use patterns (Ortiz de Guinea & Webster, 2013). To provide a clear definition of these IS use patterns, I first introduce the concepts of emotions, cognitions, and behaviors.

Emotions, Cognitions, and Behaviors

(7)

7

IS Use Patterns

Ortiz de Guinea & Webster (2013) combine the types of emotions, cognitions, and behaviors to create two broader constructs, namely an automatic IS use pattern and an adjusting IS use pattern. An automatic IS use pattern is characterized by emotions unrelated to the event (positive, neutral or negative), non-computer-related thoughts, and exploitive behaviors (Ortiz de Guinea & Webster, 2013). This pattern is related to expected IT events. They maintain that an adjusting IS use pattern is characterized by negative emotions (negative affect and lower physiological arousal) related to the system, computer-related thoughts, and adaptive behaviors. This pattern is related to discrepant IT events. Ortiz de Guinea & Webster (2013) do not link an IS use pattern to discovery IT events, because in their research these events did not occur frequently. However, I consider discovery IT events important in my research. For that reason, I link these events to a positive adjusting IS use pattern, which comprises positive emotions (positive affect and low physiological arousal) related to the system, computer-related thoughts, and adaptive behaviors. This engenders an adjusting IS use pattern related to discrepant IT events is considered as a negative adjusting IS use pattern.

A visualization of the relation between (IT) events and IS use patterns can be found in Figure 2.

Figure 2 - IT Events and IS Use Patterns

(8)

8 Emotions, cognitions, and behaviors, which are combined into IS use patterns, might change as a result of individual IT user development. When combining all concepts, a conceptual model can be created. The conceptual model of this research is depicted in Figure 3.

Figure 3 - Conceptual Model

Whereas the main focus of this research is not on discovering how emotions, cognitions, and behaviors influence performance of individuals, this might be a subject this research touches upon and in which businesses are particularly interested. It is, for instance, not necessarily true that a certain IS use pattern is more desirable than another. Instead, as I will discuss now, automatic IS use patterns have both

advantages and disadvantages compared to adjusting IS use patterns. These (dis)advantages also depend on whether one focuses on short-term or long-term performance.

Short-Term and Long-Term Performance

Bargh (1994) describes automaticity is the mentally efficient execution of tasks by unaware users, who show intentional, but not fully controllable behavior. The first characteristic that can be derived from this description of automaticity is mental efficiency, which means that users save ―memory space and

Critical Incidents IT Events Events IS Use Patterns Cognitions Emotions Behaviors Individual IT User Development

(9)

9 processing time‖ (Polites & Karahanna, 2013, p. 224). This saving is confirmed by Ortiz & De Guinea (2013), describing that automatic IS use patterns improve short-term performance. However, they maintain that automatic IS use patterns withhold users from learning activities, jeopardizing long-term performance. The second characteristic of automaticity is unawareness, which means that users may be either unaware of the trigger leading to certain behavior, or unaware of their interpretation of the trigger (Polites & Karahanna, 2013). This may harm both short-term and long-term performance, as people cannot recall why they acted the way they did. The third characteristic of automaticity is intentionality, referring to behaviors for the functional achievement of goals. For instance, users with an automatic IS use pattern navigate in a certain way through the system to get the output they want. Users connect this habitual way of navigating to the outcome they are willing to achieve. Fourth, automaticity can lead to behaviors that are not fully controllable. Users can encounter difficulties acknowledging the urgency to change behavior, because they feel stuck to executing a task in a particular way (Polites & Karahanna, 2013).

METHODOLOGY

This is, to the best of my knowledge, the first study researching to what extent critical incidents can be related to stages within the post-adoption phase. Also, I have not discovered a study focusing on the development of emotions, cognitions, and behaviors through these stages. By combining concepts described in previous work within the IS field, this research is considered as an inductive theory building study. This type of research is needed when the literature field is scattered and faces unresolved issues (Aken, Berends & Van der Bij, 2012).

Data Collection

To get my results, I conducted semi-structured interviews supported by the use of a metaphor, a timeline, and the critical incident technique (CIT). The interviews were held within a big Dutch advocacy

(10)

10 does hear known information rather than new phenomena (Glaser & Strauss, 1967). Interviewees had to be experienced IS users, since it is impossible to deliver input if users have not passed through

development stages. For the interviews an interview guide is used, consisting of two broad categories. The first questions relate to the timeline and critical incidents. These questions help interviewees to think of stages and important incidents in their individual development in IS use. After the timeline is

constructed, the conversation turned to the development in emotions, cognitions, and behaviors over time. Questions in this category also test whether this development can be possibly linked to the stages or critical incidents. Aside of these questions, some demographic data are collected, such as years of IS experience, gender and age. Despite contextual factors are not taken into account in this research, these factors may still influence the outcome. By having insights in some demographical data, I am better able to discuss possible limitations and possibilities for further research. The demographic data of the

interviewees can be found in Table 1.

Table 1 - Demographic Data Respondents

(11)

11 this inconsistency in thinking, Alvesson (2003) suggests the interviewer could establish a storyline that creates a shared ―miniparadigm‖ (p. 20). In my research, I expected interviewees to have trouble understanding four main perspectives of my research. First, interviewees might assume the interview is about group or organizational development instead of their individual development in the IS. This would lead to inconsistency in the level of analysis. Second, the assumption might arise that the research focuses on development in a broad sense, while the research is pinpointed on IS development only. Third,

interviewees might assume that development is gradually, while I am especially interested in development stages and the difference in emotions, cognitions, and behaviors in these stages. Fourth, interviewees might not think of critical incidents that influence their development. As I aim to understand the

contribution of critical incidents to the development in stages, clarification on this particular perspective is needed. I thought of a metaphor that brings forward the individual level of analysis, the specific focus of the research, the staged character and the emphasis on critical incidents. The storyline of individual progress in sports over time turned out to be helpful. Before I showed the interviewees my individual timeline concerning my development in the sport I do, I asked the interviewees whether they practice any sport. Thereafter, while describing my development, I connected to the likely similar development of the interviewee in their sport. It is likely similar, because people generally have to make the basics of a sport part of their routine, before they can possibly improve: a soccer striker first has to learn how to control and hit the ball, before he will possibly be competent enough to score goals. Likewise, a person who participates in zumba group classes first needs to know basic moves, before he or she is possibly able to master a choreography. As becomes partly evident in the above examples, people can increase

effectiveness in their sport after they routinized the basics. These can be seen as two different stages in sports progress. Notwithstanding differences between sports, critical incidents can contribute to a transition or even make people move to the next developmental stage. For instance, a tennis player can remember his introductory training as a critical incident for helping him to understand the basics, whereas a motorcycle racer describes the purchase of a faster motorcycle as a critical incident that heralds his or her move to the next development stage. Also, in sports, emotions, cognitions, and behaviors can change as a result of a critical incident or a move to the next stage. A good example is a runner, who mastered himself an unconscious, but good rhythm of breathing. Through this, the runner can practice his sport in a straightforward manner (behavior), and is able to clear his mind (cognition), making him activated and cheerful (emotion). The sports progress metaphor is clearly focused on the individual level, and makes people think of their development on a specific subject.

(12)

12 meeting systematically defined criteria‖ (Flanagan, 1954, p. 327). Flanagan (1954) describes that, among others, these criteria are: actual behavior should be reported, all relevant factors should be taken into account, criticalness of behavior should be judged and explanation of why behavior is critical should be given. To be critical, consequences of an incident should be ―sufficiently definite to leave little doubt concerning its effects‖ (Flanagan, 1954, p. 327). This is what I consider as the definition of significance in this sense. CIT is first applied by the United States Air Force, while interviewing officers about their work to get knowledgeable of requirements for new pilots of the airline (Flanagan, 1954). A total of 24 critical requirements turned out to differentiate potential successful pilots from unsuccessful ones. Along its differential value, the first application of CIT shows that this technique also has a narrow focus, samples retrospective data and is easily applicable during interviews (Thomas & Bostrom, 2010). Later, CIT is proven to be useful within the field of IS (Serenko & Turel, 2010). I consider CIT beneficial for my research, because critical incidents could provide explanation for developmental stage transitions of individual IT users.

This is not the first research making use of the combination of a timeline and CIT. For instance, Chell (2004) reports using both techniques together made participants better able to recall and order events. While this helps generating a complete picture of the individual‘s post-adoption, it also heralds the appointment of certain events that might not be actually critical for users. Therefore, laddering was used to identify the means-ends chain (Reynolds & Gutman, 1988). Laddering gives insight in the underlying assumptions of interviewees‘ answers and encourages them to elaborate on true meaning (Schultze & Avital, 2011). In my research, laddering helped to find out the criticality of a particular incident (mean) for the individual‘s development in the IS (end). This was done by asking why and how questions

(Schultze & Avital, 2011), such as: why is this critical incident important for your personal development? As a constructed timeline can be seen as an all-embracing output, researchers weigh the advantages versus the disadvantages of recording the interview. Mazzetti & Blenkinsopp (2012) decided not to record their interviews to enable interviewees ―to talk freely and frankly about their experiences of [career] events‖ (p. 652). They based their decision on the finding of Musson (2004) that anonymity is essential for making people share their life history. Fontana & Frey (1994), both followers of the romantic interviewing approach, argue that the atmosphere of the interview is important. Without discussing the possible role of recording, they maintain that engaging in an equal, real conversation allows interviewees to express inner feelings. I followed this romantic approach, which matches interviews with a semi-structured character. Semi-semi-structured interviews start with specific questions, but the further direction of the interview depends on the interviewee‘s thoughts (Blumberg, Cooper & Schindler, 2011). By

(13)

13 interviewees. For that reason, all interviews were taped and transcribed. During the interview I did not name the routinization, infusion and extension stages, because the individual timeline had to be

constructed without any restrictions. Neither did I name, nor define the IS use patterns, because this might lead to biased answers. Interviewees might, for instance, unconsciously match their felt emotions with cognitions and behaviors that together form an IS use pattern. I only introduced the definitions of emotions, cognitions, and behaviors, as these are given by Ortiz de Guinea & Webster (2013). I tried to obtain answers as much as possible via unaided recall of interviewees. However, sometimes a

clarification was needed to obtain the required answers.

Data Analysis

For the analysis of the critical incidents I followed the process prescribed by Flanagan (1954), starting with creating a frame of reference, followed by category formulation and ending with determining the level of specificity. The first step, creating a frame of reference, has to do with the classification of the critical incidents. After all data were collected, I enumerated all critical incidents that were mentioned during the interviews and grouped these in several ways to find possible categorizations. The second step is category formulation, and contains the categorization of identified critical incidents into the

classification system. Based on what I found to be the most logical categorization, I defined critical incident categories. The third and last step is the determination of the specificity level, and includes the decision for the number of (classifications of) incidents that is reported on separately. I decided to report on the highest level of categorization, containing four main categories.

I have mentioned above that the specific stages of the post-adoption phase and the specific IS use patterns were not named nor defined during the interviews. First, this entails that the stages defined by the

(14)

14 occurrence of a critical incident. These results will be derived from a combination of interview transcripts and timeline data.

RESULTS

For structuring purposes, I will first discuss the stages users went through in the post-adoption phase. Thereafter the critical incident categories will be discussed. Then emotions, cognitions, and behaviors of users and the perceived development will be described. I end up with relating all concepts.

Dynamics of the Post-Adoption Stages

From all timelines I can derive a total of 17 stages within the post-adoption stage. These can be divided into five higher-level stages. Below the five stages will be discussed separately. The sequence, in which the stages are discussed, does not necessarily display the sequence in which users enter these stages. The categorization of the stages in the post-adoption phase can be found in Table 2.

Table 2 - Categorization Post-Adoption Stages

Make It Routine

In the first stage users encounter, they make the system part of their routine. In this stage users learn how to work with the system and find out what functionality could be consulted for their tasks. Ten

(15)

15 Naomi: “In the beginning you have to learn everything, also where you can find functionality and enter

data. Over time, you start to know these things by heart.”

This quote implies that inexperienced users start from nothing and make a system routine by simply finding useful functionality and subsequently use it extensively. When new functionality is added to the system, users might also need to familiarize with the new way of working. Whether users enter the ‗Make It Routine‘ stage depends, among others, on the extent to which new functionality affects individuals tasks.

Stand Still

After users made the system part of their routine, stagnation of development might occur. All respondents indicated that they, at some moment, went through the ‗Stand Still‘ stage. It depends on the user whether being in this stage is acceptable or not. A first group of users feels comfortable working with the system, but does not have the urge for working more effectively.

Julia: ―If everything goes well in a certain way, I will keep on doing it that way, because this gives me

certainty. I might be able to skip two or three steps, but I don't know and I think it is tricky to test such possible improvements.”

This quote implies that some users have peace with being in the ‗Stand Still‘ stage. Users in the second group cannot be considered as users anymore, because they do not actually use the system.

Charlotte: “Putting the system on hold was not convenient for my habituation. I could only consult the

system by then.”

This quote shows that users who are not using the system are not able to develop themselves in it. As a result, these users find themselves in the ‗Stand Still‘ stage. Just like the first group, this second group does not regret standing still. In contrast, a third group of users regrets being restricted by the system, while they are willing to work more effectively. To illustrate users in this group, I will use the example of the accommodation of the assessment process and competency management in the system.

Clara: “If you want to make good use of this functionality, you have to assess on 30 competencies and

(16)

16 Because the system does not facilitate the demands of the organization, users cannot work with the system, resulting in stagnated development. Before users in this third group are able to improve, they do need to solve one or more problems first.

Get More Effective

Some users who are willing to work more effectively, actually succeed in finding better ways of working. These users, eleven in my sample, have found themselves in the ‗Get More Effective‘ stage. One

respondent gave the following example:

Anna: “If I recorded a new employee in the system, I constantly had to fill in the same data. I started

searching and found out the possibility to create profiles.”

Now, when for instance a new trainee joins the organization, the user who records the new employee can select the trainee profile, which contains all general data for trainees. Obviously, this saves time and increases user effectiveness.

Solve Problems

As indicated above, in situations in which users run into problems while trying to work more effectively, these problems have to be addressed. While addressing the problem, users are in the ‗Solve Problems‘ stage. I will build on the example of the accommodation of the assessment process and competency management in the system. To solve this problem, one employee described:

Clara: “I had to cluster everything and put information in various fields to make it as clear as possible…

Eventually, employees were assessed on 12 clustered competencies.”

In such a way, a workaround solution solves the problem the organization is dealing with. However, a workaround is not the only possible solution to solve system problems. One could think of changing the configuration, for instance by giving more rights to certain users. Another option is to solve the problem by changing the process to adjust to the system. In this organization, the decision is made to make two users responsible for addressing system problems. This means that the other users report their problems and have to wait before they know whether the problem can be solved or not.

Find Possibilities

(17)

17 ways to get to these improvements. First, users can engage in a conversation with the software vendor to proactively pinpoint desired functionality. Second, users have the possibility to connect a complementary system with the current system.

Clara: “We have a recruitment and selection tool specifically designed for advocacy…Students are

followed in that tool and when someone becomes employee at our organization, we will connect the tool with our personnel information system. The current system also contains some recruitment and selection functionality, but this is insufficient for our organization.”

This quote implies that individual IT user development increases through finding possibilities outside of the functionality of the current system. It could also be that possibilities are found within the current system, mostly because users are not fully aware of all functionality the system offers.

The stages of the post-adoption phase are depicted in Figure 4. Furthermore, possible outcomes of the ‗Solve Problems‘ and ‗Find Possibilities‘ stages are provided. When an outcome is achieved, users mostly enter the ‗Stand Still‘ or ‗Get More Effective‘ stages. However, for instance when new functionality is added, users might need some time for routinization. This model emphasizes the circularity of the staged development of individual IT users.

Figure 4 - Post-Adoption Stages

Four Critical Incidents Categories

During the interviews a total of 26 critical incidents were recalled. First, these incidents were grouped into lower-level categories, and based on these a total of four broad, higher-level categories were formulated. The first critical incident category is ‗Organization‘. Incidents within this category relate to events inside the organization that affected the way the system is used. The second critical incident category is

New Configuration New Functionality Process Change System Connection System Update Workaround Stand Still Solve Problems

(18)

18 ‗Learning‘, which consists of knowledge sharing via social processes or documentation that helped or constrained users developing themselves in the system. The third category is a collection of critical incidents connected to the ‗System‘. These incidents are mostly outside the control of users and can work out positively or negatively for their development in the system. The fourth category consists of critical incidents that could not be related to another category. This category is named ‗Others‘. Critical incidents have one important characteristic, which I already hinted upon above, namely that the influence of critical incidents can be divergent. Critical incidents can be unrelated to the development in post-adoption stages, either a contribution or restriction to individual development in post-adoption stages, or the trigger to move to the next post-adoption stage. An overview of the critical incidents found in this research and their effect on user and staged development can be found in Table 3.

Table 3 - Critical Incidents Related to User and Stages Development

(19)

19

Table 4 - Categorization Critical Incidents

Organization

There are many decisions made within the organization, but not all of them affect the development of users in the IS. Users pointed to three critical incidents related to the organization that were definitely influential for their development. The first and most influential one was the appointment of a new colleague. Before this colleague was appointed, users were not really involved in the process of system improvement. As one respondent compared, the pastor of the new colleague was more independent and determined individually, while the new colleague asks input of employees.

Grace: “My new colleague’s approach is: you say what you would like to see and I am the intermediary

between the software vendor and you.”

(20)

20 regarding personnel, while this was previously done at the payroll. Because the HR department was not familiar with the data entry task, they had to make it part of their routine, which imposed changes in the way they used the system. However, the payroll was still responsible for getting payslips out of the system, checking them and paying the salaries based on the data in the system. Due to the separation of the data entry and data use function, the process became less transparent, which slowed down effective use of the system. Both of the previous decisions were made on the organizational level. However, as the definition of this critical incident category implies, a decision on the departmental level also falls within this category. An example of a critical incident on this level is the decision to develop documentation about system processes. According to one respondent, documentation is not only crucial for the user who writes the documentation, but also for other users:

Nora: “I can become ill, and I can leave the company, and therefore it is good to document knowledge to

others.”

This quote shows the importance of an organizational or, in this case, departmental decision for the system knowledge of users. When a knowledgeable user becomes ill or leaves the company, it is critical that knowledge is documented. The availability of documentation is also an enabler of the learning process.

Learning

Users differ in the way they prefer to get used to the system, while they are simultaneously enabled or constrained by organizational factors. For instance, learning via documentation is not possible if no one ever took effort to develop this documentation. The same counts for learning opportunities via social interaction: if the company has an individualistic culture, users will be less open to helping others. As described above, the organization puts emphasis on documentation development. Users describe the consultation of documentation as a critical incident for their individual development in the system. As one respondent puts it:

Grace: “You can just grab the manual if something is unclear…This is something I immediately asked for

when the system was introduced.”

Aside of process documentation and manuals, checklists were consulted to prevent users from skipping process steps.

(21)

21 These quotes make clear that all types of documentation help users in their developmental process. Another critical incident within the learning category is a system problem. One respondent at the payroll distinguished between generic and specific problems, and considered these types of problems as incidents with different impacts. As this difference is linked to the stages of the post-adoption phase, I will

elaborate on this separation later. When a system problem is encountered, users try to find a solution. While respondents named various methods to overcome problems, the support of a colleague is seen as the most evident critical incident to develop in the system.

Ella: “The help of one colleague has been absolutely crucial for me.”

This quote shows that, along the availability of documentation, users appreciate some kind of super user. At the same time, one crucial human factor for system development makes an organization vulnerable, because users are dependent on one person for the occurrence of a critical incident.

System

Critical incidents that connect to the ‗System‘ category mainly come from outside the organization. Specifically, these external changes are changes to the software applied by the vendor. Respondents mentioned two types of changes that influenced their development within the system. First, the vendor can carry through system updates, which influence individual system use. Updates are changes or

additions to current functionality that can either not influence, positively influence or negatively influence individual development within the system.

Clara: “After an update is done, I check if it influences our processes or whether we can do something

with it.”

Because of this active checking, users are aware of possible improvements in their individual processes within the system. Second, system use can be affected by the introduction of new functionality. This can be new generic functionality, developed by the vendor for all of their clients. Besides, it can be existing or new functionality, configured and partly customized to the wishes of the organization. A few respondents described how the digitalizing of the overtime record changed their system use.

Clara: “In the past, a pile of paper overtime documents was delivered every month, and all of these

documents were processed manually in the system.”

(22)

22 Anna: “Now, the supervisor approves overtime, and thereafter it is processed automatically in the system.

As a result, I basically do not do anything related to overtime recording anymore.”

This quote implies that new functionality can save time of users, making them better able to develop themselves further. I also found an internal system factor, restricting users in their individual development within the system.

Clara: “Something I regularly run into are the boundaries the system. Then you have to be creative by

thinking of workarounds or trying to get as close as possible to the demands of the organization.”

Here it becomes clear that systems can also restrict users in their task execution. While executing their work, users felt restricted due to insufficient functionality, unavailability of data and usability problems. However, as this quote implies, users try to overcome system boundaries by seeking possibilities to make the system work for them.

Others

There are three critical incidents that I could not relate to another category. First, the simple fact of time passing by can result in a critical incident. People within some professions have a lot to do with time and for them, time can be really important. For instance, a payroll employee is responsible for the payment of the monthly salary, the yearly tax return, and the provision of annual statements. All of these tasks can be complex, especially in a system users are not familiar with. Normally, if something is unclear during task execution, it is an easy practice to check how the same action is done previously. However, this

information was not available in the new system. As one respondent indicated:

(23)

23 individual development. Specifically, an employee agreed with the organization to double weekly

working hours.

Lucy: “I try to be proactive in finding improvements, but because I only worked two days a week in the

first few months, it went slower. Now I work things out quickly and that helps me being proactive.”

This quote implies that the higher the amount of time users work with the system, the better development within the IT is possible. Another possible explanation is that the increase in weekly working hours has a positive effect on job involvement, which on its turn leads to more willingness to improve both individual and organizational processes.

One important remark is that, despite the division of critical incidents into categories, incidents can be related to each other. Moreover, there is a possibility that the occurrence of one critical incident excludes another critical incident. For instance, the dismissal of a knowledgeable colleague hinders a user in getting the support needed to tackle a system problem. In other words, a critical incident within the category ‗Organization‘ prevents a critical incident within the ‗Learning‘ category from happening.

Emotions, Cognitions, and Behaviors

In this research emphasis is put on the emotional, cognitive, and behavioral development of individual IT users. I also found contingencies related to emotions, cognitions, and behaviors. Both developmental and contingency factors are discussed below.

Emotions

In studying users‘ emotions, I used the affect and arousal concepts. As described in the theoretical foundation, affect describes the dimension of pleasure-displeasure. While coding, a distinction is made between a group of users who described affect as a constant and a group of users who recognize

(24)

24 Charlotte: “I cannot say that I am very satisfied with the system now, although improvements have been

made.”

This quote indicates that users with negative emotions about the introduction of the system will not turn into users with positive emotions after some improvements are made. Looking at the arousal concept, going from sleepy to activated, I can make the same distinction as was made above. However, there were only two users who felt their arousal changed over time. The other users described their arousal was constant, and mainly expressed neutral feelings with the system over time. It is very important to note that changes in emotional states can be long-lived, but are mainly short-lived. Nine users pointed out that they experienced short-lived emotions. These emotions endure a short time, and vanish when the event that caused this emotional state switch is remedied. Some events can lead to negative emotions one time, while having a positive effect on feelings another time. For instance, users described different emotional reactions on a system update. While an update could satisfy some users, another respondent described: Clara: “It happened that I was not immediately aware of an update. Twenty users were not able to work

the next day, and I was busy for half a day to get the system up-and-running again. That really annoys me.”

In this case, negative emotions follow from communication problems between the vendor, who carried through the update, and the organization. However, it can also be that the same update satisfies one group of users, but hinders the other. Short-lived emotions can be caused by several factors, on which I will elaborate later. I found that emotions are strongly determined by users‘ experiences with previous systems. If an individual perceives the process became less efficient in the new system, compared to the previous system, negative emotions will rise up. In the opposite case, users feel positive emotions.

Cognitions

While working in the system, users‘ cognitions can be computer-related, task-related or unrelated to the task. When interviewees were asked for their development in cognitions, ten acknowledged a switch from computer-related thoughts to task-related thoughts.

Nora: “First my focus was on: where can I find functionality. Now I know how to get to the intended

result.”

(25)

25 benefits of an update, thoughts are directed to the system for a short period of time again. No single respondent recalled a longer period of having thoughts unrelated to the task. Five respondents revealed they sometimes had short-lived thoughts, which were unrelated to the task. Four of these respondents indicated that their cognitive activity is dependent on the task that had to be executed.

Ella: “For some tasks I can just look outside and listen to my music, then it is just a dull tool you are

working in.”

This quote shows that for simple tasks, users can be cognitively inactive.

Behaviors

Behaviors during system use can either be exploitive or adaptive. Ten respondents pointed out that they showed both types of behaviors, and that the type of behavior is dependent on other factors. Four

dependencies turned out to be important. First, just like cognition, behavior is dependent on the task to be executed. While simple mutations are done in a straightforward manner, more extensive tasks require adaptive behavior to carry them out more efficiently. Second, the behavior shown by users is dependent on work pressure.

Charlotte: “There is so much work, that I do not always have the time to think proactively of possible

improvements.”

This quote implies that users show more adaptive behaviors when they do not feel work pressure. Third, user behavior hinges on expected possibilities.

Henry: “Sometimes, when I think a task can be executed more practically, it turns out to be a matter of

system change. I can’t change that, that’s not up to us, but up to the software vendor.”

Here, it is shown that if users have the perception that they cannot change the system, they are less likely to show adaptive behaviors. Obviously, in the internal organization users are also dependent on their authorization level. Some users simply do not have the rights to adapt the system configuration, automatically forcing them to behave in an straightforward fashion. Fourth, behavior of users is dependent on experience with the system. However, users described the relationship differently. Ella: “When I came here, I was looking for opportunities in the system…I could compare this system to

the one I previously worked with, and then you are trying to find the best of both worlds.”

(26)

26 Ella: “I also recognize that when you are working with a system for a longer period, you become blind

for new possibilities and improvements.”

Another user indicated:

Anna: “I held back in the first month, but on a certain moment, when you start to know where you are

talking about, you start proposing improvements.”

These quotes indicate that there is a difference in how the relation between user experience with the system and user behavior can be explained. Whereas some users immediately see possibilities and become blind later, others first want to understand why a system works in a certain manner and then start to look for possible improvements.

Linking Post-Adoption Stages, Critical Incidents, and Emotions, Cognitions, and Behaviors

Now I have presented the model of the five stages in the post-adoption phase, I will put emphasis on how these stages are linked to emotions, cognitions, and behaviors, and the critical incidents. It turns out that emotions are mainly short-lived and changes in emotional state are triggered by critical incidents within the ‗Learning‘ or ‗System‘ category. Users particularly recall facing system problems and running into system boundaries as critical incidents that change their emotional state for a short period of time. Leo: “Sometimes when I click from the one screen to the other, the system is very slow. That could be

annoying.”

This quote implies that system problems, such as low system speed, affect the emotional state of users on the short term. This is depicted in Figure 5.

Figure 5 - Critical Incident Categories and Short-Lived Emotions

Critical Incident Categories Learning

System

(27)

27 Whereas I cannot generally match emotional state switches to post-adoption stages, two patterns are recognized in the occurrence of critical incidents triggering emotional switches. First, the longer users make use of the system, the more likely it is they have been confronted with a system problem before. These problems have either been solved in the past and will not occur again, or users encounter the same or a comparable problem, and can easily solve it.

Clara: “When there is a certain desire within the organization, I can rather say that it is not possible, or

that we have to search for other possibilities. That is because of my development in the system.”

In other words, experienced users reasonably have gone through the ‗Stand Still‘ and ‗Solve Problems‘ stages multiple times, reducing the chance of emotional state switches as a result of the occurrence of critical incidents. Second, the specificity of problems will enlarge as user experience increases. Just after the system is implemented, problems are more likely to be generic, and might be solved by, for instance, configuration adjustments. In a later stage, users only face specific problems, which normally require more effort to solve. With respect to user cognitions, it seems that computer-related thoughts can be related to the ‗Make It Routine‘ stage and that task-related and unrelated thoughts pop up in the other four stages. Whether a user has task-related or unrelated thoughts in these four stages seems not to depend on the stage the user is in or the occurrence of critical incidents, but on the level of required active cognition for task execution. This is shows in Figure 6.

Figure 6 - Cognitions and Post-Adoption Stages

Cognitions Post-Adoption Stages Computer-Related

Task-Related

Unrelated to the task Solve Problems Stand Still Get More Effective

Make It Routine Make It Routine

Find Possibilities Required Active

(28)

28 The nature of the task also seems to determine user behaviors. Other factors that seem to determine user behavior are work pressure, expected possibilities and experience with the system. I could not link behaviors to post-adoption stages or critical incidents. Looking at the relationship between the critical incident categories and the post-adoption stages, a pattern can be recognized. Despite more than half of the critical incidents falls within the ‗Learning‘ category, only two of these incidents herald a new stage. Users perceive critical incidents in this category mainly as contributing factors for their development. In contrast, the occurrence of a critical incident within one of the other three categories is likely to go hand in hand with the beginning of a new post-adoption stage. This is shown in Figure 7.

Figure 7 - Critical Incident Categories and Stage Transitions

When combining Figure 5 and Figure 7, the relation between the critical incident categories, and short-lived emotions and possible stage transitions becomes apparent. This is depicted in Figure 8. As already touched upon above, an arrow means a higher likelihood of one of the four critical incident categories leading to short-lived emotions or stage transitions. Meanwhile, it is not said nor intended to convey that short-lived emotional switches or stage transitions are restricted to the occurrence of a critical incident within a connected category.

Demographic data

Looking at the demographic data, I can only recognize a pattern in respondents‘ emotions, based on the function they have. Users at the HR department use the system on another level, depth, and intensity than users on the finance department or resource managers. Building on this, I found that the system has a stronger impact on users‘ emotions when system use captures a significant part of a working day.

Critical Incident Categories Organization

Others System

(29)

29

Figure 8 - Critical Incident Categories, Short-Lived Emotions, and Stage Transitions

CONCLUSION

Building on the stages within the post-adoption phase, and users‘ emotions, cognitions, and behaviors, this research aimed to 1) challenge the post-adoption stages as categorized in current research, 2) find critical incidents that lead, or contribute to stage transitions and emotional, cognitive, and behavioral development. I found users can go through five stages. Normally, the individual IT user development process starts with a stage in which they make the system part of their routine. Subsequently users either get more effective working with the system, or they enter a period of stagnation, mostly because users encounter a problem. After this problem is addressed, users go back to the ‗Stand Still‘, ‗Get More Effective‘, or sporadically to the ‗Make It Routine‘ stage. When users increased their effectiveness within the current possibilities of the system, they might enter a stage in which they explore new possibilities. Just like when a problem is solved, users go back to either of the three other stages after an intervention is done. In the ‗Make It Routine‘ stage, users cognitions are computer-related. In the other four stages, cognitions can either be task-related or unrelated to the task, depending on the level of active cognition needed for the task at hand. Stage transitions can be initiated by critical incidents in the categories ‗Organization‘, ‗System‘ and ‗Others‘. The fourth critical incident category I found, ‗Learning‘, only contributes to user development in most cases. The latter critical incidents category and incidents within the ‗System‘ category can cause short-lived emotional state switches.

Critical Incident Categories

(30)

30

DISCUSSION AND THEORETICAL IMPLICATIONS

Post-Implementation Stages

This research yielded a total of five high-level post-adoption stages. Users in the ‗Make It Routine‘ stage are focused on learning. They make working with the system and its functionality part of their routine. This stage is highly comparable with the routinization stage, which is frequently described in previous research (Cooper & Zmud, 1990; Premkumar et al., 1994; Saeed & Abdinnour, 2013). The second stage I found users go through is the ‗Stand Still‘ stage. Previous research did not distinguish this stage as a separate one, which is highly remarkable, because all respondents within my sample indicated that they all have had a period in which they were not able to or did not want to work with the system. Agarwal (2000) describes user development in an IS on a continuum from stagnation to full integration. According to Saeed & Abdinnour (2013), this continuum is related to the infusion stage, characterized by integrative use. Following this logic, the ‗Stand Still‘ is part of the infusion stage. The ‗Get More Effective‘ stage clearly matches the infusion stage, since both stages are about working towards effective integration of the system in users‘ work practices. Another stage that is not explicitly mentioned in previous research is the ‗Solve Problems‘ stage. Cooper & Zmud (1990) indicated that problems will be encountered

(31)

31 circular model, as depicted in Figure 4. In their way to increase effectiveness, users cannot prevent periods of stagnation. After the problem that triggered this period of stagnation is addressed, users might find themselves in the infusion stage again. Besides, the current linear model does not take into account new periods of routinization resulting from events, such as system updates or the introduction of new functionality that affects user processes within the system. A circular model, such as the one suggested in this research, better accommodates the complexity of IS user development. Future research could

examine my circular model and test its logic and completeness.

Critical Incidents Technique

Before I turn to the discussion of the critical incidents, emotions, cognitions, and behaviors, emphasis is put on the value of the critical incident technique (CIT) in this research. As described in the

methodological part, all respondents were asked to think of critical incidents that played a role in their development in the IS. Besides, possible linkages between these incidents and emotional, cognitive or behavioral state switches, and development in stages were examined. The successful use of CIT in this research proves the applicability of this technique in three ways. First, CIT again turned out to be useful in the IS field, which is conforming to the validity and fruitfulness of this technique in IS research, reported by Serenko & Turel (2010). Second, CIT helped to identify short-lived, but also seems to be applicable for discovering long-lived emotional state switches. This confirms findings of the applicability of CIT on the emotional level (Gertsen & Søderberg, 2010; Petzer, De Meyer, Svari & Svensson, 2012; Yamamoto, Gardiner & Tenuto, 2013). By using CIT, I also found a cognitive state switch between the ‗Make It Routine‘ stage and the other stages. However, CIT appeared not to be useful to find out switches in behaviors. This might be an explanation why previous studies have not used CIT to discover

development in behaviors. However, future research could further examine the applicability of CIT for the discovery of behavioral development. Third, CIT proved helpful for interviewees to distinguish post-adoption stages they went through. This increased validity of CIT to identify a staged development, as CIT was applied by Ulbrich, Troitzsch, Van den Anker, Plüss, & Huber (2011) for the same purposes.

Critical Incidents

(32)

32 learning. As I found similar critical incidents leading to individual development within the IS, my results conform to those of Jasperson et al. (2005). However, decisions made on the managerial or departmental level that made learning possible, which we accommodated in the ‗Organization‘ category, are not described in previous research. Also, the influence of organizational incidents such as a change in role and task division or the appointment or dismissal of colleagues on individual IS use is not covered in research to date. Ortiz de Guinea & Webster (2013) deliberately left out events stemming from anything but the IS itself and merely focused on IT events in the current system. Future research could further investigate the effects of organizational incidents on individual IS use. Coming up against system

boundaries, which is a critical incident in the ‗System‘ category of my research, is similar to encountering discrepant IT events, the concept used by Ortiz de Guinea & Webster (2013). Expected IT events are not mentioned as critical incidents. A possible explanation is that users do not memorize events that meet their expectations of the system. I found a few examples of ―discovery IT events‖ (Ortiz de Guinea & Webster, p. 1168), but those are not always mentioned as a critical incident. For instance, a few

respondents mentioned that sometimes workarounds were created to be able to match task execution with the demands of the organization. Notwithstanding these workarounds helped users performing their tasks, these were not mentioned as critical incidents for their development within the system. In contrast, some respondents recalled system updates and the provision of system rights as critical incidents, and these are discovery IT events as well.

Emotions, Cognitions, and Behaviors

(33)

task-33 technology misfit. Cognitive development related to IS seems to be a subject researchers did not devote attention to. Neither opposing nor supporting findings have been found for my findings illustrating that computer-related thoughts rise up when users are confronted with new functionality. Additionally, this research indicates that cognitive activity and user behavior depend on the difficulty of the task. Research to date has not revealed the relationship between task difficulty, and cognitive activity or user behavior separately and in an IS context, as is done in this research. However, my findings connect to the research done by Cacioppo, Petty, Feinstein & Jarvis (1996), who related the concept of need for cognition to task difficulty. The need for cognition refers to ―a stable individual difference in people‘s tendency to engage in and enjoy effortful cognitive activity‖ (p. 198). Cacioppo et al. (1996) argue that, overall, people with a high need for cognition are ―more likely to generate issue- or task-relevant thoughts‖ (p. 231), and ―have more positive attitudes toward stimuli or tasks that require reasoning or problem solving‖ (p. 198), compared to people with a low need for cognition. They maintain that, on the one hand, people with a high need for cognition perform better during execution of tasks that require cognitive activity, because they put more effort in it in the sense of information acquisition, reasoning, and problem solving. On the other hand, people with a high need for cognition achieve worse results while performing novel tasks, because they have trouble executing the task in a straightforward manner. By dividing user cognitions and behaviors, I found that users can have task-related thoughts and show both exploitive and adaptive

behaviors. This adds to the findings of Cacioppo et al. (2006), by putting forward that such users might be most effective in executing both complex and novel tasks. Meanwhile, this implies that the idea that people possess either high need for cognition or low need for cognition needs to be revisited. Cacioppo et al. (2006) also pointed out that time pressure influences cognitions and behaviors, which is confirmed by my findings. Notwithstanding, no explanations were found for the relation between user behavior and expected possibilities or user experience with the system. Overall, I call for more research to cognitive and behavioral development of individual IS users.

IS Use Patterns

(34)

34 (2013) propose a discrepant IT event leads to an [negative] adjusting IS use pattern, characterized by ―negative emotions, computer-related thoughts, and adaptive behaviors‖ (p. 1172). Again, I did not find that a discrepant IT event by definition triggers an [negative] adjusting IS use pattern. An example of this that I found is the inevitable waiting time users are confronted with while using the system. For some requests, the system needs to acquire so much information that it takes some seconds, or even minutes, before the information is available to the user. Despite users feel negative emotions when this occurs, they simultaneously know that it cannot be fixed and therefore no adaptive behaviors will be exhibited.

Furthermore, it is proposed that a discovery IT event can be linked to a positive adjusting IS use pattern, comprising system-related positive emotions, computer-related thoughts, and adaptive behaviors. I found that this link can be made. An example stems from one respondent, who delved into the system in conjunction with a consultant to make the right configuration changes for increasing effectiveness. This led to satisfaction on the side of the respondent after the right configuration adjustments were made. However, in this organization only two users actually explore system improvements, and for that reason my findings regarding discovery IT events might not be reliable. Based on the above analysis, it seems that all different emotions, cognitions, and behaviors of users cannot be accommodated in a few

comprehensive IS use patterns. Users obviously can engage in an automatic or an adjusting IS use pattern, but I posit that these are not sufficient to display the broad spectrum of emotions, cognitions, and

behaviors that users might experience. More research into IS use patterns might help to create a complete view of possible patterns. Meanwhile, this increases the value of describing patterns instead of separate emotions, cognitions, and behaviors.

PRACTICAL IMPLICATIONS

This research has several implications for practitioners. First, I examined 26 critical incidents that have had an influence on the individual development of IS users. Whereas some of these incidents are organization specific, most incidents can guide directors or managers to encourage successful user development in the post-adoption stage. Second, this research pointed out a number of emotional, cognitive and behavioral contingencies. These might give directors or managers understanding of why emotions, cognitions, and behaviors of certain users differ from those of others. Besides, this knowledge makes them better able to anticipate on, for instance, resistance or automaticity among users. Third, my results can create awareness of the complexity of the post-adoption stage. Both the organization and the software vendor are developing continuously, resulting in differing system demands of the organization and a changing software supply of the vendor. This implies that, even if a system is perfectly

(35)

35

LIMITATIONS

There are a few limitations of this research. First, my findings are based on self-reports that are recalled from the past. This entails that users might have forgotten certain incidents or stages that were actually important for them, or users might have distorted or withheld certain emotions, cognitions or behaviors they experienced. For that reason, such self-reports can be biased (Mauss & Robinson, 2009). Robinson & Clore (2002) pointed out that the validity of self-reports of current experience is probably higher than self-reports of experiences in the past. Future research could examine whether changing the setting to self-reports of respondents‘ current experience yields different results. Second, all interviews are held by one and the same researcher, what might lead to a researcher bias that harms reliability (Van Aken et al. (2012). To prevent biased research, I tried to steer the direction of interviews as little as possible. Besides, I strived to obtain answers via unaided recall by focusing on the use of as many open questions as

possible. Furthermore, I reflected upon my own interviewer behavior during the elaboration of the transcripts. Third, all interviews are held within one organization, reducing the external validity of the research. The researched organization operates within a very specific industry, and both the organization and the software vendor are focused on innovation. Both characteristics make the findings of this research difficult to transfer to other contexts. Finally, my sample was rather small and mainly consisted of female employees working on the HR and Finance departments. This might have influenced the outcomes. The reliability of my research could have been improved by increasing the number of respondents or by randomly selecting respondents representing all departments (Van Aken et al., 2012). However, the latter was not possible, since the system was only used intensively in a few parts of the organization.

REFERENCES

Agarwal, R. (2000). Individual acceptance of information technologies. In R. W. Zmud (Eds.), Framing

the Domains of IT Management: Project the Future Through the Past (pp. 85–104). Ohio, USA:

Pinnaflex Press.

Alvesson, M. (2003). Beyond Neopositivists, Romantics, and Localists: A Reflexive Approach to Interviews in Organizational Research. Academy of Management Review, 28(1): 13-33.

Bargh, J. A. (1994). The Four Horsemen of automaticity. In R. S. Wyer & T. K. Srull (Eds.), Handbook

(36)

36 Barki, H., Titah, R. & Boffo, C. (2007). Information System Use-Related Activity: An Expanded

Behavioral Conceptualization of Individual-Level Information System Use. Information Systems

Research, 18(2), 173-192.

Bhattacherjee, A. (2001). Understanding Information Systems Continuance: An Expectation-Confirmation Model. MIS Quarterly, 25(3), 351-370.

Blumberg, B., Cooper, D. R., & Schindler, P. S. (2011). Business Research Methods. London, UK: McGraw-Hill.

Burton-Jones, A. & Gallivan, M. J. (2007). Towards a Deeper Understanding of System Usage in Organizations: A Multilevel Perspective. MIS Quarterly, 31(4), 657-679.

Burton-Jones, A. & Straub, D. W. (2006). Reconceptualizing System Usage: An Approach and Empirical Test. Information Systems Research, 17(3), 228-246.

Cacioppo, J. T., Petty, R. E., Feinstein, A., & Jarvis, W. B. G. (1996). Dispositional Differences in Cognitive Motivation: The Life and Times of Individuals Varying in Need for Cognition. Psychological

Bulletin, 119(2), 197-253.

Chell, E. (2004). Critical Incident Technique. In C. Cassell & G. Symon (Eds.), Essential Guide to

Qualitative Methods in Organizational Research (pp. 45–60). London, UK: Sage.

Cooper, R. B., & Zmud, R. W. (1990). Information Technology Implementation Research: A Technological Diffusion Approach. Management Science, 36(2), 123-139.

Damanpour F., & Schneider, M. (2006). Phases of the Adoption of Innovation in Organizations: Effects of Environment, Organization and Top Managers. British Journal of Management, 17(3), 215-236. Davenport, T. H. (1998). Putting the Enterprise into the Enterprise System. Harvard Business Review, 76(4), 121-131.

Fadel, K. J. (2012). User Adaptation and Infusion of Information Systems. Journal of Computer

Information Systems, 52(3), 1-10.

Flanagan, J.C. (1954). The critical incident technique. Psychological Bulletin, 51(4), 327–358. Fontana, A., & Frey, J. (1994). The Art of Science. In N. A. Y. L. Denzin (Eds.), The Handbook of

Referenties

GERELATEERDE DOCUMENTEN

If a plant R can be arbitrarily pole assigned by real memoryless output feedback in the sense of Definition 2.3.1, then in particular does there exist a regular feedback law (2.29)

To conclude, there are good possibilities for Hunkemöller on the Suriname market, as it is clear there is a need for such a store in Suriname and that the potential target group

Linear plant and quadratic supply rate The purpose of this section is to prove stability results based on supply rates generated by transfer functions that act on the variables w

A suitable homogeneous population was determined as entailing teachers who are already in the field, but have one to three years of teaching experience after

The present text seems strongly to indicate the territorial restoration of the nation (cf. It will be greatly enlarged and permanently settled. However, we must

Until now, there is limited understanding on how the different skin layers and appendages (e.g. hairs) contribute to the global mechanical response of human skin. Knowledge on

When it comes to perceived behavioral control, the third research question, the efficacy of the auditor and the audit team, the data supply by the client, the resource

As Mr Simon did in his classic work, Mr Ridley provides ample statistical evidence here to show that life has indeed got better for most people in most places on most