Interview Execution

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 
136 137 138 139 140 141 142 143 144 145 146 

The main approach taken was to conduct interviews at the interviewee’s site. The main

arguments for this approach was that by doing so interviewees would feel more

comfortable with being interviewed and would not have to waste time on travel in a busy

work schedule. Nevertheless, four of the interviewees preferred to have the interviews

conducted on campus and another at a local coffee shop.

Due to the length of the overall interview, only the first five sections in the interview guide

(see Appendix B) were fully covered in all interviews. Within the topical segments, we

found the most effective approach was to begin by posing a broad general question

intended to gain the participant’s uninfluenced view of an area. We then followed up with

more specific questions. For example, we would ask a broad general question such as,

“What models or approaches did you use for documenting our last IT development

project?” We would then continue by asking if the participant used use cases models,

then asking if they used sequence diagrams, following the list of UML models. We also

asked if they used data flow diagrams, data modeling diagrams, and any other models.

This procedure allowed us to receive an uninfluenced view from the interviewee,

suggesting ideas most salient from their point of view, while still investigating each of

the specific tools comprising UML and, thereby, gaining more detailed insight into the

adoption and “customization” of their use of UML toward providing a richer picture of

the nature and not just quantity of usage.

Lessons Learned from Conducting the Interviews

We found the interview protocol to be invaluable in two respects. First, during the

sessions, it provided a stable background to move through various items of interest with

respondents. On occasions when the discussion would go into detail in an area, it gave

us a point of reference to return to from which we could continue in another area. Second,

in examining our data after completing the interviews and transcriptions, it provided a

framework of issues that were addressed in one way or another by each of the

interviewees allowing for more systematic comparison of answers in light of differing

roles within projects and other differentiating demographic elements of the participants.

One decision that presented difficulties pertained to referencing a particular project. We

asked participants to think of a particular project in order to make the questions

concretely related to actual experience, rather than derived from how they think “it should

be”. However, in spite of this, we found that respondents often strayed into more general

discussions regarding how they used various approaches across a range of projects.

Methodological purity might have suggested forcing the participants back to discussion

of the one identified project, however, some of the more interesting points were raised

in consideration of the comparison among projects. Our observation is that even as the

conversation drifted away from a particular project, it remained based on their experiences,

though more generalized across a set of projects. We also found that they might

pull details from a variety of project experiences — for example, they might report on their

experience with sequence diagrams on one project where they did not use class diagrams,

but report on another project using class diagrams but not sequence diagrams. In

retrospect, beginning with a single project was probably a good approach because it

tended to keep participants from responding only with generalities. But it was also good

to allow the respondents to drift away from that particular project in order to report on

the broader array of their experiences. In conclusion, we found that the steps taken to

strengthen the voice of “you” (Bohman, 2000) was the correct interview approach.

Table 1. Example of the analysis table

C-

#

R P-

#

Statement Cause Effect

31 2 4 We’re still trying to get people to understand

the IS model and our roles because people

look at us when we say we need to be part of

their planning units and their teams and so for,

they look at us “We’re not ready for IT yet.”

We say, “No, no, you don’t understand. We’re

a part of your team. We need to understand

prior to when you think you need technology

so that we can best help you. It also helps us

in our planning.” So we’ve got varying

degrees of people understanding our role but it

is starting to grasp on. People are starting to

understand that role and I can’t seem to have

enough people to fulfill those roles.

Early

involvement

User

understanding

32 2

4 Also, recently, in the business integration

team, we had taken on process mapping,

which makes sense because if you don’t

understand the process, it’s difficult to start

mapping out a project and mapping out

technology. So we are also facilitating and

training process mapping so that’s also new.

Process

mapping

Project

organization

33 2 6 We had a team, a fairly large team, that pretty

much encompassed a good portion of our IS

department internally as well as we brought in

external consultants because we didn’t feel we

had the expertise and knowledge in doing

everything that we were going to be embarking

upon.

Addition of

consultants

Enhance

knowledge base

for project work

34 2 7 We had some knowledge but it wasn’t

practical. It was textbook knowledge and we

wanted some practical experience so we

hired, actually, multiple consultants. We didn’t

have one firm. We brought in multiple people.

We project managed it but we had a project

manager from the consulting firm work with us

hand-in-hand.

Addition of

consultants

Enhance

knowledge base

for project work

35 2 7 I thought I could because my background

seems like I could do that but I very quickly

learned that if I got caught too much in the

technical details, I couldn’t manage the overall

scope of the project.

Focus on

overview

Project

management

success

36 2 9 And we went out and personally trained all 100

distributors when we rolled out phase one.

They liked that. They thought that was great.

Personalization

of training

User satisfaction

Note: The abbreviations in column headings denote: C-# (comment number), R (respondent

number), P-# (page number in interview transcript).