Get documents about "The reputation Reputation of IT developersDevelopers “Development
Document Sample
The Reputation of IT Developers: “Validation of an IT-User Gap
Theory”
By
Georges Arnaout
garnaout@cs.odu.edu
Advisor: Dr. Joan Mann
Email: jmann@odu.edu
Project Oral Presentation Date: 2/11/08
Department of Computer Science
Old Dominion University
1
Index
Acknowledgements……………………………………...3
Abstract ………………………………………………....4
1- Introduction…………..………..……….…….……....5
2- Literature Review .…………..…………….………...7
2.1 Relevant IT research streams……..….…...7
2.2 IT-User Gap Studies.………........………..10
3- Methodology…….…………………….……...….....12
3.1 Phase 1….……...…..……………..……....13
3.2 Phase 2 ………………….……………….14
3.3 Phase 3 .……....…………...……………..18
4- Results.............................................………….……...18
5- Conclusion and Implications..……….………..…...34
6- Limitations and Future Plan..………………...…...36
References: ……….…………………………….…......37
2
ACKNOWLEDGEMENTS:
I would like to thank Dr. Joan Mann for her continuous support throughout all the last year.
She has provided me with very helpful tips and advices that improved my work and my
knowledge. Despite her cancer treatment, Dr. Mann did not hesitate to provide me with all
the time that I needed, in order to guide me and answer every single question that I had.
I wish you all the best for a rapid recovery.
3
ABSTRACT:
It is undoubtedly true that nowadays, that most organizations seeking success have invested
significant resources in information technology. However, several empirical studies indicate
that companies that spend more on IT are not necessarily rewarded with better business
performance. This is known according to several studies as the “Productivity Paradox” and it
occurs due to the lack of appropriate use of information technology in the organization. One
of the possible causes for this phenomenon is the IT-User gap, which is when users and IT
cannot work together effectively or when IT fails to improve user productivity.
The research in this area tended to be focused on either user satisfaction with specific
technologies, user-developer dynamics within an IT project or on the characteristics and
workplace climate of developers. These studies ignore the growing conflict between end-
users and IT developers. However, an existing theoretical framework identified several
different forms of the IT-User gap and described how each one impacts user effectiveness
and influences overall business performance. The framework was developed using
references to the gap in IT academic and practitioner literature but it has never been
empirically validated through operationalization and use.
The goal of this paper is to validate the framework empirically and to infer possible solutions
for reducing the gap that exists between IT professionals and users. The methodology used
was content analysis of a discussion of the IT-User gap on a popular bulletin board. In the
end of the study, the model was validated and also enhanced with new constructs, new sub-
constructs within existing constructs and better definitions that improve the model's usability.
1- INTRODUCTION:
It is undoubtedly true that nowadays, most organizations seeking success have invested
significant resources in information technology. However, not all companies that adopt
4
information technology are affected positively. In fact, the success rate for information
technology projects is still considered to be very low. Several reasons are related to projects‟
failure. Studies pointed the problem as what Robert Solow and many called, the IT
Productivity Paradox.
On one hand, computer scientists, generally known as „Techies‟, are competent in building
systems according to specific requirements. However, their systems fail to meet the users‟
need in most of the cases (Mann 2002).
On the other hand, the lack of the business knowledge by the IT personnel was not the only
reason causing the misconception. The end-users, or „IT Users‟, lacked the efficient knowledge
about computer systems and the software related.
The lack of business knowledge on the techies‟ side followed with a lack of computer
knowledge on the users‟ side created what is known by business schools as the IT/USER GAP
(Mann, 2002).
In a study of 8,000 projects by the Standish Group (Group. 2006), only 35% were successful
while the rest were either challenged or canceled. Dr. Joan Mann from Old Dominion
University (Norfolk, VA) blamed it on the constantly growing conflict between users and the
IT developers. After analyzing descriptions of the IT-User gap found in IT academic and
practitioner literature, Mann (1) supported the IT User Gap theory (the gap already existed
but perhaps identified in different names); (2) showed that the IT User gap is pervasive and
long- standing; and (3) demonstrated that it is complex and multi-faceted, caused by both IT
personnel and end-users (Mann, 2002).
The section below illustrates the multiple facets (the types) of the IT-User gap:
Perspective Gap – incomplete viewpoints
Ownership Gap – who owns/is responsible for infrastructure/processes
Cultural Gap – professional acculturation
Foresight Gap – who sees the future better?
5
Communication Gap – inability to understand what the other is saying
Expectation Gap – who is realistic?
Credibility Gap – issues of past history
Appreciation Gap – lack of recognition
Relationship Gap – stereotypes never checked
Each category of gap has an IT side and a User side. The cultural gap for example, is a gap
that related to developers and users at the same time. IT people tend to be more introverted
and analytical while Users tend to be extroverted and intuitive. Moreover, within each gap
there may be multiple themes. Therefore, until the model is operationalized and used, we
cannot be sure that the theory is complete and useable.
Mann‟s paper analyzed the gap and identified its categories. However, no evidence was
shown proving the IT-User Gap theory, thus, further study is needed.
This study is expected to fill the gap that other studies have failed to identify. The project
examines thoroughly the IT-User Gap and identifies the possible ways to solve this major
problem. The objective of this project is to address the issue by validating the journal paper
published by Dr. Mann, Joan in 2002. According to our knowledge, no other studies have
focused on identifying the possible solutions to reduce the IT-User Gap. Once the theory has
been validated and/or enhanced both researchers and practitioners will be able to study the
IT-User Gap in organizations in order help organizations get the most benefit from the
information technology and be able to increase performance.
This leaves us with the question: Is the Gap Theory operational in real life? Is there enough
evidence to prove its existence?
2- LITERATURE REVIEW:
The current studies in the area of „productivity paradox‟ have covered different facets of the
problem. However, they have not addressed the IT-User gap directly. Three important
research streams cover several different aspects in this area.
2.1- Relevant IT Research Streams:
6
Many studies were made concerning fields related to projects failures, IT personnel, Users
and other related aspects. We identify the most important streams:
2.1.1- User Satisfaction
Related research has proven that users‟ satisfaction is highly proportional to the degree of
his/her involvement in the project. In addition, the user‟s satisfaction with the IT systems
used is proportional to the following factors: relevance, content, accuracy, and timeliness of
the information produced by the system (Seddon 1992).
Other papers focused on the different methods to measure user‟s satisfaction and information
system effectiveness using empirical studies and experiments. Using questionnaires, one
paper thoroughly examined users‟ information satisfaction and diagnosed the problems
decreasing their satisfaction. Later in the paper, a framework has been given to detect and
diagnose problems with user satisfaction (Baroudi 1988). However, the paper did not
thoroughly examine the different ways to tackle these problems and their relationship with
the developers‟ side.
2.1.2- Failure/Success in IT Projects
After performing a study on a large number of successful projects (Frese 2003), the top
five factors found in those projects were the following:
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
While the following factors were found in failing projects:
1. Incomplete Requirements
2. Lack of user involvement
3. Lack of Resources
4. Unrealistic Expectations
7
5. Lace of Executive Support
6. Changing Requirements & Specifications
7. Lack of Planning
8. Didn‟t Need it Any Longer
9. Lack of IT management
10. Technical Illiteracy
The above study implied that there was a gap between the IT Developers and the end-
users. However, the focus of studies on success/ failure was on the project management
and how to make sure the projects succeed rather than focusing on reducing the IT/User
Gap, although some of the case studies might have mentioned dysfunctional IT-User
relationship during projects. The IT-User Gap must be investigated as a general
phenomenon. In addition, both User Satisfaction and Project Success/Failure research
makes the assumption that IT-User interactions only occur during project development or
when users actually interact with systems that have been developed but IT-User Gap also
occurs when user interacts with the IT personnel, by calling the help desk, by complaining
about migrating to another system, training etc.
2.1.3- IT Personnel Studies
Research on IT personnel has identified specific personality traits of IT professionals.
One study (Wingreen 2002) identified a conflict between the IT professionals and the
organization itself. The study has shown that the IT professionals are in need of a continuous
training to keep up with the technology. The problem lies in the type of training program that
the IT professionals need. The organization may perceive that the IT is in need of a certain
training program while the IT considers that other programs suit them more. This could lead
to a turnover by the IT professionals. They would seek other organizations that are a fit with
their perceived needs for training (Wingreen 2002).
Another aspect is that service quality has been successfully associated with end-user
satisfaction (Kettinger 1995), but there is evidence that service quality is not enough to create
a strong reputation in the minds of end-users and user-managers (Powell 2004)
8
Many studies targeted the work climate of the IT personnel identifying their traits. For
example, studies have shown that exhaustion (Moore 2002) and burnout (Sethi 1999) affect
the behavior of IT workers.
To summarize, research tended to focus on single projects and single systems. IT personnel
studies ignored the user side.
2.1.4- Suggested Solutions to the IT-User Gap:
Other studies found different ways to reduce the User-Developer gap by introducing
modeling software. Charles Babcock discusses on InformationWeek, how modeling tools
can reduce the existing gap between the developers and the users, by modeling the business
processes so that it could be carried forward into system design and later into development.
Java modeling tools from Borland, Compuware, and others promise to help developers build
applications that business users want (Babcock 2005)
Solutions were suggested in order to solve the IT-User Gap problem where most of them
came from practitioners. Many studies identified a “Recruitment Gap” where although
several firms asserted their emphasis on hiring individuals with business knowledge and
strong technical skills, the job advertising aspect of the recruiting process has focused on
"hard skills". The conclusion was that the changing demand patterns for IT professionals
requires life-long learning skills not only for IT practitioners but also for the academics who
teach them (Gallivan 2004). Although this article studies the ways to reduce the existing gap,
it does not focus on the gap, but gives a solution from the developers‟ side that does not have
any proof of future success.
These studies have merely focused on specific information systems and ignored the
interaction and relationship between the users and the developers. According to our
knowledge, the literature was not centered directly to the IT-User gap and did not deal with
the different types of existing gaps and their solutions.
2.2- IT-User Gap Studies:
9
As mentioned earlier, one study (refer to Introduction) identified the gap (Mann, 2002) and
characterized different categories for the IT-User Gap. Figure 1 illustrated the different
categories. In the next paragraph, we explain the definition of each of these categories.
Perspective Gap: when the viewpoint of one group is incomplete. IT sometimes forgets
that systems must provide value to the business by meeting evolving business goals and that
the world does not revolve around the IT department (Scalet 2002/2001). End-users
sometimes forget that IT is only a tool not a cure-all and become dazzled by it (Pender
2000/2001).
Ownership Gap: Too often IT feels ownership over the infrastructure and end-users feel
ownership over the business processes. This leads to territorial conflicts that strain the
IT/User relationship and create mis-conceptions (Lin 2000). End-users feel IT personnel are
technical elitists and IT staff feels end-users are reactionary.
Cultural Gap: when the different groups have different traits, values, working behaviors,
and/or priorities because each group either attracts certain kinds of individuals or it
acculturates members in the group. For example, IT people tend to be more introverted,
analytical and tend to use rational persuasion to influence others. Business end-users tend to
be more extroverted, intuitive and use more sophisticated influence strategies (Shah 1994).
Both end-users and IT personnel adopt the culture of their respective professions. These
differences in behaviors and norms can make it difficult for effective interaction to occur.
Foresight Gap: when one group is better able to see the future but cannot convince the
other group. IT may be in a better position to foresee that user solution will not work from a
technical standpoint. On the other hand, end-users may be better able to determine why the
project or the system to be built will not be accepted or will have a negative impact on the
current situation (Fisher 1999).
Communication Gap: when one group fails to understand what the other means. Users
feel that IT speaks in jargon but users have their own jargon as well. IT fails to translate
business users needs into useful systems because they don't fully understand business
processes(Business 1999).
Expectation Gap: when end-users have unrealistic expectations of what IT can do.
Ironically, users expect more from IT because they have become more computer literate or
because IT has done such a good job ('IT will always come through') (Whiting 1998). On the
10
other hand, IT is notorious for promising more than they deliver and expecting all users to be
technologically naive.
The client/server environment has also been blamed for the expectation gap because it makes
the information infrastructure of the organization look more adaptable than it is.
Credibility Gap: when the track record on the IT side is poor. It may be related to systems
development projects that failed but it can also be related to poor customer service, as in a
help desk that doesn't help (Business 1999). IT personnel may have found end-users to be
resistant to change or overly demanding in the past.
Appreciation Gap: when one group feels the other group does not recognize their value.
IT may feel their hard work, long hours and contributions to the organization go unnoticed
except when something goes wrong (ex: the network is down) (Mottl 1999). There is also
some evidence that IT personnel want to be more involved in business decisions but are not
asked to do so(Hayes 1997). IT personnel don't always appreciate that end-users are experts
in their knowledge domain and the social complexities of their situation.
Relationship Gap: when the two groups do not interact frequently and effectively enough.
Each group's pre-judgments of the other group never become resolved. Relationship becomes
'us' versus 'them' (Shah 1994).
The many different forms of IT-User Gap may well contribute to failed systems development
projects and the strained relationship between IT and users. Moreover, the longevity of the
problem has prompted organizations to take steps to solve it on their own.
The above study supported the IT-User Gap theory and proved its complexity by illustrating
the different facets of the gap (Refer to Figure 1). In addition, the study demonstrated that
the gap is pervasive and long-standing by showing how organizations tried to resolve the
problem that lasted for a long period and forced organizations to create “Hybrid Positions” –
personnel that have a sufficient business knowledge as well as a sufficient computers
knowledge – that acted as a form of liaison between the IT personnel and the Users.
As already mentioned above, the theory has not been proved. We are attempting to validate
the IT-User gap theory.
3- METHODOLOGY:
11
Dr. Joan Mann wrote the article: “Education‟s Failure to Deliver Successful Information
Systems: Now is the Time to Address the IT-User Gap”. This study was the first attempt to
understand the complexities of the gap. Until then, there were no academic studies of the gap
phenomenon beyond the project or individual case study level. However, while the model
was generalized by deduction from several articles, it was never validated by using it to
analyze new text, which would require an operationalization of the different gaps.
After the above paper was published, Marc Fisher, an editorialist from Washington Post
referred to the article in one of his editorials (Fisher 2003). Later, the same topic was posted
on Slashdot, a famous online discussion forum (http://slashdot.org), with the name: “Why
Users Hate IT Products and Developers?” The thread contained 874 comments which we
imported into qualitative research software and did a content analysis on them. This database
of comments was a perfect way to determine if the theoretical model was complete and
usable.
Since large text contents are being studied, the methodology of the project is “Content
Analysis”. The standard type of methodology was chosen because the coding is done by
humans which was proven to be more reliable and accurate. The data analyzed in the
analysis was the comments posted by the users in Slashdot forum.
Aiming to validate Dr. Mann‟s Gap theory, the work was divided into two phases:
Phase 1: “Downloading and Categorizing Speakers”
We downloaded all the comments (874 comments on 210 hard copy pages) in text format
with the threads intact, from the Slashdot website. Then, we manually imported the text
to qualitative analysis software, and created a different node for each speaker. Each
speaker‟s node had all the comments posted by that speaker. We then analyzed each
speaker‟s comments and assigned him/her to one of four categories: Developer, User,
User and Developer and Unknown Speaker. Assigning each speaker‟s category was done
individually by each of the two researchers. The categories were finalized by coming
together creating the finalized list through consensus.
12
Phase 2: “Validation of the Gap Model”
In the second phase, each researcher worked independently on creating the initial code for
the comments first using the hard copy pages of the discussion for practice and later using
the qualitative software (see illustration in figure 3). The goal was to see if we could find
comments that fit the different gaps from the theoretical model as defined by the model.
When we first came together after coding some hard copy pages, it was clear that we
needed better operationalization in order to be sure that the gaps had strong convergent
and divergent validity so that each gap was capturing something unique. We continued to
meet regularly as we worked to fine tune the coding. Finally, we developed a „Cognitive
Map‟ of coding relationships (see Figure 2) and a dictionary of coding operationalizations
(see Table 1).
13
Figure1. Cognitive Map
Figure1 shows the different gaps and their relationships with each other and it also includes
some newly identified concepts that relate to human behavior or interaction between people.
14
For Example, we included „Adaptability‟ referring to comments where IT personnel or users
had adaptability issues with a certain change (refer to table1 for details). Since the gap
constructs and the new constructs all focused humans, we collected them together under
People issues. Some new comments, however, were not as people related as they were about
the technology itself and their reaction to the technology. While indirectly related to the
developers that create the technology, we decided to keep these separate and so put them
under Technology.
15
Nickname Full Name Description
Grouping
Gap Gap Any type of dysfunctionality between users and IT personnel
Culture Cultural Barriers Norms or Levels of intelligence/skills or demographic factors that
make users or IT personnel think or act dysfunctionally
Communication Faulty When users and IT personnel fail to understand each other when
Communication they interact
Credibility Poor Credibility When speaker refers to past behavior or history when complaining
about other side
Perspective Incomplete When either users or IT fails to see all aspects of the situation
Perspective
Appreciation Lack of Appreciation When users do not appreciate developer challenges, intelligence,
hard work. When IT personnel do not appreciate user
intelligence, knowledge, skill
Ownership Ownership Issues When respondent believes that a task or role belongs to users or
IT. When users or IT personnel act like they 'own' something that
they really do not (ex: users own process, IT owns technology.
Relationship Poor Relationships Is there too little interaction or is the interaction dysfunctional
Expectation Unrealistic When users or IT personnel expect too much from each other or
Expectations technology
Mixed Message Mixed Message When users or IT personnel have contradictory expectations
Problems with Change Adaptability issues or motivation for making changes
Change Adaptability Failure to Adapt When users or IT personnel dislike any change
Evolving Motivation to Evolve The reasons why users or IT personnel choose to change or who
makes the decision to change
Technology Technology Comments that speak more about technology than users or developers (though there
Issues may be an implied link to developers or companies that sell technology)
Adaptation Adaptation Issues How much training or help is required to use technology
Evolution Dysfunctional Whenever changes are too radical, too frequent, unnecessary or
Changes dysfunctional. Also analogies made to other technology if related
to change
Usability Lack of Usability When technology is less useful than it could be
Table 1. Coding Dictionary
Table 1 shows the dictionary created with the definition for each of the gaps and the
additional constructs that we added during the coding of the comments. During the
coding, existing gaps‟ definitions have been modified either to broaden the definition or
to improve operationalization. For example, the Culture Gap definition was limited to
the behavioral factors due to cultural differences (Mann, 2002). With our study, the
definition improved to the following:
Norms differences (values, typical behaviors); Levels of intelligence/skills or
demographic factors that make users or IT personnel think or act dysfunctionally.
16
Figure 2. Classifying the Gap Categories in MS Word
Figure 2, shows how the gap categories were classified in order according to Speaker‟s
type (whether Developer, User, Both, or Unknown Speaker).
Phase 3: “Looking for Themes”
Since every gap category had several themes. We studied the comments and identified
the themes related to each gap category. In the following section, we cover the themes
identified in each of the gaps defined in the introduction.
17
Figure 3. Coding in Atlas
Figure 3 shows how the coding was based on the gap theory (Gaps listed on the right
with the type of speaker).
4- RESULTS: (Forum 2003)
The amount of creative and important patterns collected from the comments was large.
We list the ones that were the most intuitive to us from each gap listed in the order of
importance:
4.1 Perspective Gap:
The perspective gap occurs when one of the conflicting sides (whether IT or Users) see
one aspect of the situation but not another side that is also important. Users sometimes
forget that IT is only a tool that assists them in their tasks while IT forgets sometimes that
the systems it creates must meet the goals of the end-users.
18
4.1.1 Developers’ Perspective:
Developers blamed the end-users for not reading the manuals: “Users don‟t like to read
the documentation” while users considered that a software that needs to be referenced by
the manual is not user-friendly. According to developers, users failed to understand that
IT only provides them with a tool, where the tool is supposed to assist users but not do all
the job. Here, the users failed to see an important aspect of the developer‟s role.
One developer blamed the gap on both sides stating that developers and users have
different definitions of the word „intuitive‟ where each side blames the other for not
having enough intuition. Users define an intuitive developer as a developer knowing
what to do without users needing to state the exact requirements. Developers define an
intuitive user as a user being capable of understanding the software (how to use the
software) without the IT‟s continuous assistance.
A comment posted by one developer defended the developers by stating that “developers
know about HCI (Human Computer Interaction) while users don‟t”. The post showed
that users expect IT products to solve all their problems, otherwise the product, according
to users, is not efficient. Here, there is an incomplete perspective from the users on what
the developers must deliver.
One comment tackled the users and in particular the managers: “Managers don‟t allow
developers to do training when changes occur – the care only about productivity”.
According to this developer, managers did not want to waste any resources (time or
money) on training users for new updates but just wanted to get more productivity from
the newly updated software.
“Managing time limit is the problem of bad designs”. The developer who posted this
comment blamed the managers for not giving developers ample time to build good
designs.
On the contrary, one developer simply stated: “If the design was good, nobody complains
(…)” blaming the developers for not building efficient designs. Another developer
blaming developers presented one solution to the problem by using time cards but also
19
blamed managers as well: “Developers could use Time cards for better designs. Also it is
the management‟s fault (…)”.
Other posts blaming developers stated that developers lack the necessary skills and also
that “developers throw unused features just to make their software better than other
software (…)”. The previous posts were views by developers who believed that
developers fail to see a major aspect of the situation, which is the user‟s interaction with
their products.
4.1.2 Users’ Perspective:
People who were both Users and Developers defended developers in general and blamed
Users for their lack of computer skills: “Users need proper training (not from IT)” and
“Software is aimed to everyone and not specific users (more training)”. According to
them, users failed to see a very important aspect which is the computer literacy that most
of them lacked.
However, most of the users were attacking the developers and agreed with all the
developers who were negative towards developers. Users agreed that the more updates
are being installed the more users are getting confused which was also confirmed by a big
portion of the developers: “Users want stability rather than having new features”;
“Upgrades cause problems (…)” and “Upgrades are a waste of time (…)”.
Users connected the upgrades issue with the developers‟ necessity to show that they are
working, in order to protect their jobs, where they add new features lacking any useful
necessities “Useless features come with upgrades(…)”; “Remove functions for no
reason” and “so many useless features” were all quotes posted by users complaining
about the updates. Some users simply stated that there is no need for IT: “IT job in
general is useless” and presented other solutions such as buying software from external
companies or simply adopt freeware: “Solutions might be free software”.
Two posts were attacking the developers by stating that what users want is not always in
the documentation: “Documentation doesn‟t have what you need(…)” and that if
developers create a system that is hard to use by users than developers have failed: “If
you cannot create a system that users can use then you failed”
20
“Programmers need more HCI (…)” was a solution posted by a person unknown
whether he/she was a developer or a user. The person was clearly targeting developers
for not knowing enough about HCI (human computer interaction). According to that
person, programmers learning more about HCI could solve a large amount of the
Perspective Gap. Other unknowns posters, blamed the gap on the users‟ lack of computer
skills.
4.1 Ownership Gap:
Starting with the Ownership gap, the gap category had two aspects, either too much
ownership was involved or not enough ownership was involved. If one of the
respondents, believes that a task or role belongs to users or IT and not himself/herself or
when one of the respondents act like they „own‟ something that they do not own, then,
we have an ownership gap.
4.1.1 Developers’ Perspective:
Some developers quoted “We move to new systems because 90% of the old system is not
being used”. The statement was a response to one user who complained about useless
updates containing useless features that just make the user‟s life harder. From the
developers‟ perspective, users were using only 10% of the features that IT provided them,
which forces the developers to create another version of the system that could be more
user-friendly and more useful. Thus, users were not taking enough ownership of the
system they have been given.
Other developers that were negative towards users went back to blame user‟s lack of
education since “computer literacy nowadays is a must” one of the developers quoted.
According to the developers, it was the users‟ responsibility to be computer
knowledgeable. Hence, users are not taking enough ownership of their literacy.
One comment: “Users should not specify features, but should describe tasks to be
performed so that the design is driven by what they need to do their jobs”, implied that
the requirements set by the users are not informative enough for the IT personnel to be
21
able to build the system that users want. According to developers, it was the users‟ role
to provide developers with informative and well specified requirements for the systems
they wanted developers to build.
Responding to a claim mentioned by one of the users that IT deals with matters that are
none of their business, “It is better if IT makes technology recommendations because they
know technology and do deserve fear and respect”. On the other side, some developers
admitted that the IT is somehow controlling by saying: “IT holds a monopoly in the
company”. Those developers agreed that this is one of the main causes for the IT-User
continuous conflict. One developer simply quoted: “IT management is my master and my
enemy is computer, users are the prey”. All these quotes proved that too much
ownership was involved. The IT personnel were acting like they owned the organization
by taking individual decisions without consulting the users (even if sometimes they were
right).
4.1.2 Users’ Perspective:
Although some developers were compassionate with the users in their comments, the
users were more aggressive towards the developers in the forum. A large number of
users complained that developers update the software for no reason implementing useless
features and making the software more complicated: “If changes need to be made, they
should be intuitive and self-evident to frequent users” quoted one user. Another one
quoted: “Useful features removed, useless features added to make it simpler – need to
balance needs of different types of users” and many users agreed. “If old system works,
DON‟T CHANGE IT!!!”. This takes us to the same point previously mentioned, in section
4.1.1. Developers were taking too much ownership by adding/removing features without
consulting the users.
Some users stated that it is the developers‟ job to meet the users‟ requirements as hard as
it may sound: “Developers should meet the users‟ requirements. EVERY USER”. It is the
developers‟ role to implement systems that are practical and functional by users.
22
Users felt that developers must take more responsibility for creating systems that are easy
to use, so that less time is needed in training and reading manuals. The software lacked
the ease-of-use required.
“Waste of user time to read manual, or get training when developer should have made
easy to use software”, “If users cannot understand the software without referring to the
manual then developers have failed(…)” and many others were quotes that clearly
identified the ownership gap existing and illustrated the theme uncovered with it.
Developers considered it is the users‟ responsibility to read the manual/understand the
software while users believed that developers owned that responsibility.
A large number of comments were posted (by unknown speakers) blaming the users for
not knowing/performing their responsibilities. “Giving social skills to developers will
not help if users are not willing to learn due to learned fear of technology” Surprisingly,
several users agreed with these speakers.
4.2 Culture Gap:
The culture gap includes conflicts between IT and Users that are due to cultural norm
differences or differences in personal characteristics, such as intelligence or
demographics. The cultural barriers between developers and users were numerous. From
each sides‟ perspective, the other side (or their own side) think or act dysfunctionally..
4.2.1 Developers’ Perspective:
In the Culture gap, most of the developers often felt that users were lazy (personal
characteristic). Developers commented that “Users don‟t bother using help”, “Users
never read the Documentation”, “users are naïve”, etc. One developer implied this is a
cultural norm “Users don‟t want to become independent of help desk.” Other developers
implied that users lack intelligence or retention (personal characteristic): “Can‟t transfer
23
skills from software package to another or don‟t remember what happened after called
help last time”. On the other side, developers that were negative towards developers
replied to the users‟ declarations by implying that developers make changes just to feel
that they have control and authority in the organization. “Making changes for no reason
gives developers a feeling of power” (not to be confused with Ownership Gap).
Therefore, one personality trait of developers is a need to feel powerful and a behavioral
norm of using IT to gain that power. Another theme was directly related to IT personnel
traits and behavior. For example, “Some developers are ignorant and arrogant – if we
show them why the interface is bad they say I don‟t understand – it works for me”.
Developers demonstrate the trait of arrogance and self-absorption by being oblivious to
individual differences in human computer interaction. Another uncovered theme was
highly related to demographic factors. A large number of developers agreed that young
users seem to be more intuitive then the older users: “Younger users seem better able to
learn”. On the other hand, some developers believed that management must hire new and
young users rather than spending resources on training the old staff. Some developers
denied that fact by quoting: “Users just need the proper training”.
4.1.2 Users’ Perspective:
Multiple users felt “Developers are arrogant”. (personal characteristic) One user
attributed the arrogance as a defense mechanism to cover a personality defect:
“Developers get defensive due to the insecurity about their skills (…)”
Another example was when users agreed that developers assume that users must be
computer knowledgeable: “Users don‟t share the developer‟s love of computers(…)”. In
contrast to the ownership gap, a remarkable number of users implied that most of the
users lack the ability to learn new concepts. “Some users CANNOT LEARN!” The
commentators who were Developers and Users at the same time agreed that users are the
cause of the culture gap. “99% of users are lazy – don‟t read documentation…” This
quote uncovered a major theme: „Developers perceive users as minor minds and
inefficient personnel‟.
24
Other posts stayed neutral but confirmed the existence of the culture gap. “Techies are
smarter than users and like to prove it” or simply blamed both sides: “Nobody wants to
learn anything new but they want all kinds of new toys and gadgets to play with.” This
quote in particular revealed a major picture to the issue. “People are lazy. End-users,
developers, project managers, everyone! (…)” The gaps were not related to one side of
the participants, but to both, users and IT.
4.2 Communication Gap:
The communication gap is a gap related to the failure of understanding between users and
developers during their interaction. Users consider that developers speak their own
jargon and vice versa. There is a sender and a receiver but little or no effective
communication between them.
4.2.1 Developers’ Perspective:
Some developers admitted that developers in general are not listening properly. For
example, a developer quoted: “Developers are not listening carefully to users”
“Developers must design the software, listen to user feedbacks and then redesign”
Another developer quoted: Developers must design the software, listen to user feedbacks
and then redesign” confirming the previous theme. “Developers cannot figure out what
users really want” was another quote posted by a developer.
In another aspect, a large number of developers blamed the management for not being
clear and not providing them with accurate requirements in order to do their job:
“Managers create poor business cases and requirements documentation (…)”. Here,
developers believed that managers are sending information that is inadequate for
developer‟s needs.
25
4.2.2 Users’ Perspective:
Users that are positive towards developers implied that IT is a tool that allows them to
achieve their daily tasks. However, it is their responsibility to tell the tool what to do
accurately. For example, a user quoted “tell them (referring to developers) what to do
and they will do it”. The user considered that users should explain their requirements in a
better way so no faulty communication would occur between the two sides (users and
developers).
Another user blamed users in general for not being technologically sophisticated. “All
users need techies, not all techies need financials”. Here, the user also implied that users
are forced to understand the developers‟ jargon; however, developers are not forced to
understand the users‟ jargon. Another quote: “It is difficult for users to communicate
because they don‟t have enough computer knowledge to understand” confirmed our point
about how one part of the users believed.
On the other hand, several users didn‟t blame either sides and just stated that there must
be a liaison to bridge the communication gap existing between the two sides.
One post (where the poster didn‟t mention if he/she was a developer or user) stated that
the solution to this gap comes from both sides by “proper communication (…)”.
4.3 Credibility Gap:
The Credibility Gap is when the speaker refers to past behavior or history when
complaining about the other side. For example, if a project failed in the past due to a
poor performance from the IT personnel, the users will believe that developers don‟t have
much credibility, and vice versa.
Developers negative towards developers mentioned that “Developers use technology as
an excuse” therefore they have a poor credibility. In other words, developers do not have
26
credibility because according to past behaviors, developers used „Technology‟ as an
excuse, thus, users don‟t trust developers in their statements.
Another statement (by an Unknown user) “When users complained that the software was
hard to use the designers did not ask why. Instead the designers concluded that „users are
stupid‟. Here, the post was referring to how developers pre-judged users on past
experience (referring to history) and concluded that users have no credibility. Therefore,
developers did not take the users‟ complaints seriously and considered them overly
demanding.
4.4 Appreciation Gap:
The appreciation gap occurs when one of the two sides (users and developers) do not
appreciate the other side‟s hard work and qualities. Users think developers don‟t
appreciate their business intelligence while developers consider that users do not
appreciate their technical skills and hard work.
4.4.1 Developers’ Perspective:
Some developers considered that IT‟s main role is to assist users in their tasks.
According to the, it is normal for the users not to be computer experts and should not be
treated as mentally challenged. “If users are seen as idiots than developers belong to a
different job”. Therefore, developers were blamed for this gap since most of the
developers tend to blame end-users for not having skills in computers.
Another post blaming the developers was: “Developers must learn about users‟ business
requirements”. Developers are building software according to the given requirements
without taking into consideration that users are not computer experts. Other posts
confirming this idea: “Developers are beaten up because they are smarter than users”
and “Developers must fit user needs”. Clearly, developers do not appreciate the users‟
intelligence about their business work but judge them according to their computer skills.
27
One developer stated the following: “Developers are disparaged by users because don‟t
know their jargon”. The developer was obviously blaming developers for not
appreciating the users‟ hard work to deal with the latest technologies and also blamed
them for not understanding their technical words.
On the other side, some developers who admitted the truth of the statements mentioned
above, quoted: “Can‟t say users are never wrong”. Developers that don‟t know what
users want must try to understand their requirements exactly but however, users, in many
cases can be wrong (or in other words not accurate in their product specifications and
requirements) in giving the requirements and confuse developers.
The main post that summarizes the idea of the appreciation gap is: “No one works harder
or longer than we do but feel like corporate punching bag”. The developer who posted
this comment stated how IT people tend to work the hardest but nobody appreciate their
hard work. IT personnel do not get praised for a job well done but are the first people to
take the blame in case anything goes wrong. Developers are not well appreciated.
Computer Literacy (Common for Appreciation and Ownership Gaps):
A large portion of developers blamed users for their low computer literacy: “No matter
how easy and simple developers make a software, there is always some users who will
have problems operating it”. The developers agreeing on this idea blamed the users for
not being good with computers and blame it on the IT ignoring the amount of work that
the developers spent on developing the software.
“Users say „If I wanted to learn how to do this why did I buy a really expensive software
application to do it for me?’” . Again, according to developers, it was the user‟s
responsibility to learn the software they will be using. The quotes concerning this theme
were numerous. A developer quoted an analogy of the “Plumber and his Tool” by stating
that the plumber should know how to use his tool referring to users that don‟t want to
learn their software.
28
4.4.2 Users’ Perspective:
In the appreciation gap, a large number of users blamed the developers. Comments such
as “Users are never wrong” showed that users believed that developers must not consider
the user as „unintelligent‟. One comment stated the following: “Developers should not
disparage user – should appreciate that they have other skills”.
Replying to one developer who blamed users for not appreciating their work, users stated
that developers build complex software and later, they add useless features to make it
even more complicated to users.
One developer and user at the same time mentioned that users don‟t mind learning, but
“do not want to learn five times without any benefits” referring to the useless upgrades
and irrelevant features that come with it.
Finally, some unknown speakers blamed developers for not appreciating the users‟
intelligence and not providing them with the right tools. "Users are customers. If
developers cannot satisfy them, then they must be replaced”.
An unknown speaker stated that the problem is related to both, users and developers, for
not appreciating one another and blaming each other: “Users and developers have
different skills. There shouldn‟t be any master or slave. Users and developers should
work together”. This post showed how users and developers fail to appreciate each other
and fail to understand that each side has its own skills that the other side tend to overlook
it.
4.5 Relationship Gap:
The relationship gap exists when there is too little interaction between users and
developers. Also, it exists if the existing interaction was dysfunctional.
4.5.1 Developers’ Perspective:
In this gap, it became clear how much conflict it exists between users and developers.
The IT/User gap was highly shown in the relationship between the end-user and IT.
29
Some developers sounded in their discussions like there is a “big” personal conflict
between them and the users. One of the developers posted: “Never feed the hand that
bites you” (which is the ironic version of „never bite the hand that feeds you‟) referring to
users as the ones asking for help and the ones able to cause the developers a great amount
of harm (by their continuous complaints to the upper management). Also, other
developers concluded that users tend to complain about everything: “Users find problems
in everything”. Other developers blamed users for not knowing anything about
computers and technology: “Users generally hate computers and give IT a hard time”
and then blame IT for this.
One developer blamed management for the relationship gap by saying: “Management
puts barriers between developers and users and the products come out ineffectual”. The
developer referred to the separation of the IT and users by the physical location in the
organization and also in their daily tasks (e.g. IT reports to different personnel than the
users).
On the other side, some developers believed that developers are the source of the
relationship gap by the way they deal with users on daily basis. “Developers must consult
the users” was posted by one developer who mentioned that developers complete their
tasks without consulting users and later complain that the users cannot understand the
finalized software. Other developers agreed that developers in general tend to ignore QA
(Quality Assurance) when they say that their software is not user-friendly.
In general, most of the speakers that are developers agreed that developers tend to be
arrogant while dealing with end-users. One developer summarized the dysfunctional
interaction between users and developers in one line: “Developers are masters,
computers are enemies and users are preys” (mentioned previously in another gap).
A solution to the problem was introduced by a developer who suggested the adoption of
prototypes to reach the users and get their feedbacks before proceeding to further steps of
product development. A large number of users agreed with him/her.
30
4.5.2 Users’ Perspective:
Users defended themselves by blaming it on developers: “Technology should not be the
concern of users” stated one user. The speaker believed that it is the developers‟ job to
make things easier on users. Another user agreed: “IT personnel are not doing their
job”. One user aggressively addressed the developers by stating: “Arrogant, disparaging
Techies like to make users feel stupid” and “IT people see themselves as the MASTERS”
The speaker was referring to the „arrogant‟ developers who do not consult users in
anything but expect them to like the final product. “Developers just need to be patient”
agreed another user. Other users mentioned that they are being very patient with the
developers and still, developers tend to be arrogant: “Must use extreme patience with
them”.
A user quoted the following: “IT people don‟t really help – have to fix things myself”
implying that IT people do nothing except confuse users with their updates. Another user
agreed: “IT is a waste of time and a complete intrusion”.
A user and a developer at the same time suggested that developers should consult users
while they are writing the software (not before and not after) and listen to users‟ feedback
at all the stages of the software. Another speaker (also user and developer at the same
time) quoted: “Developers do not take users‟ knowledge into consideration” which is one
of the main causes of the relationship gap. Developers do not communicate with users or
they don‟t take their ideas seriously. Finally, one speaker (unknown if user or developer)
ended the discussion by a statement: “Global firm is downsizing but IT doesn‟t get
cheaper or better. Like it is independent with no one questioning them” where according
to the speaker is a major reason why users hate IT and eventually do not communicate
with them. The speaker continued to discuss how IT report to IT bosses and IT bosses
report to managers, jumping over users.
31
4.6 Expectation Gap:
Each side is expecting unrealistic expectations from the other. IT is expecting users to be
technical (experts about computers) and users are expecting unrealistic deadlines from
the developers (or technology).
4.6.1 Developers’ Perspective:
Some Developers agreed that when users complain, it is the developers fault because
users are expecting easy and efficient software: “When users are having problems with
your software, it‟s the fault of the design and not them”. Other developers pointed the
problem by the developers not being able to understand users and their expectations. In
general, developers considered users to be unintelligent with unrealistic expectations:
“Users are not stupid, they just don‟t think the way we do – don‟t expect them to
understand”. The solution according to this speaker was for developers not to expect
from users to understand the amount of work and time some requirements need by
developers because users think differently. Another issue was that “Developers
overestimate what users can do”. This post was the contrary of the one above. Here,
developers expected users to know more than they should about computers and
technology.
On the other side, several developers complained about unrealistic deadlines set by
managers followed by unrealistic expectations from the users: “Managers don‟t give
enough time to create a prototype, redo, etc.” which, according to most of the
developers, is the cause of the expectation gap. One developer posted: “Power or ease.
You cannot have both!” referring to users who want powerful software but also expect
the software to be extremely simple and easy to use, which developers believe it is
impossible. Another developer added: “It‟s simply impossible to design a software that
is usable by all”.
32
4.6.2 Users’ Perspective:
Users complained that the software built by developers are not efficient: “Software need
more work”. Users expected more from the technology and the developers. One user
quoted: “Developers don‟t understand what users want. Users want smoother design,
ease of use, speed, and stability”. Developers seemed to fail of meeting the users‟
expectations with their products.
On the other hand, users admitted that most of them exaggerate with their expectations.
“Users expect the computer/software to read their minds”. According to those speakers,
developers were doing more than enough for the users who are just expecting too much
from the IT.
“Some users are just not inquisitive and want their tasks to be self-completed” was
posted by a speaker who was both developer and user at the same time. The speaker
concluded that although developers expect users to be too quick in learning their
software, some users are „slow‟ in their learning process when it comes to computers and
technology.
An unknown speaker blamed it on managers “Managers just wants it finished on time”.
According to the speaker, managers set the deadlines which are unrealistic. Developers
and users get the blame. Another unknown speaker concluded that “users want to learn
without using the manuals”. This makes them think that the software is complex while
they didn‟t try to refer to the manual/documentation for help. Also, another unknown
speaker blamed users for resisting technology changes “Users cannot expect technology
to remain unchanged”. Finally, an unknown speaker quoted “If you give me free
software, I won‟t get mad if it is bad but, if you make me pay, I want more” which is the
case in most of the times. Most of the users tend to complain if IT charged high for a
software development and didn‟t deliver according to their expectations. That brings us
to the main theme of this gap, which is that cost is a major attribute in a software that for
some (users in particular) is even more important than usability. “If usability and
reliability were important then Apple would have won” quoted a speaker.
33
4.7 Mixed Message Gap:
The occurrence of this gap is when users and developers have contradictory expectations.
It is not to be confused with the expectation gap where users or developers expect
unrealistic expectations from each other. The mixed message gap was found rarely in the
discussion.
One developer mentioned: “users don‟t know what they want. Must balance what you
want VS what you need”. The developer implied that users tend to ask for requirements
that themselves are not exactly sure whether they really need. Another developer quoted:
“users want more from computers but are resistant to change” which showed the major
contradiction with the users where some of them wants change (better product) while
others want ease (user friendly product) and surprisingly most of them want both!
An unknown speaker confirmed this idea by quoting “users don‟t want to learn anything
new but want new toys”. Another unknown speaker just blamed it on the managers:
“Managers encourage upgrading to stay current but hate changes too – they don‟t pay to
train” which showed the major contradiction that developers are complaining about.
Remarkably, none of the developers or the users blamed IT for this gap.
5- CONCLUSION and IMPLICATIONS:
This study was able to uncover several factors and dynamics that make up the IT-User
gap through the use of content analysis of an online discussion framed by the IT-User gap
model of Mann (2000).
The analysis supported some aspects of the IT-User gap model but also enhanced it.
Overall, the analysis corroborated the existence of the ownership and culture gaps and
showed that often developers and users agreed as to the nature of each gap. This finding
34
encourages us to see users and developers on various continuums, with some users and
developers having a wide gap between themselves and other developers/users that are
less alienated from each other and can see the other side‟s perspective.
The results from analyzing the ownership and culture gaps have implications for theory
and practice, which are presented below.
Contributions to Theory:
The IT-User Gap identified in a previous study (Mann, 2002) was empirically supported.
We have found evidence that it exists and that it is a useful model for observation and
analysis. However, the usefulness of the model was improved by expanding the
definitions of the gaps.
Although the comments did not completely match the definition from Mann‟s paper, the
issue of ownership and culture gaps showed up just in a different form than the original.
The ownership gap was defined in Mann‟s paper as the conflict caused by who owns/is
responsible for infrastructure/processes. The themes identified in the comments
supported the definition but also revealed the existence of two forms of ownership. One
form where not enough ownership was given to Users/IT personnel and another form
where too much ownership was involved which caused a conflict between both sides.
As for the culture gap, the definition was expanded to include more than just cultural
traits that come from acculturation. Traits, behavioral norms, level of intelligence/skill
and demographic factors were added as facets of the culture gap.
This study also improved the model by operationalizing each gap. For example, the
ownership gap was identified when users or developer‟s used words or phrases such as,
“should”, as in “users should learn” or such as “responsibility”, “must”, etc.
Operationalization of the culture gap meant focusing on a consistency of behavior
(tendency to use IT to gain power) or a generalization to all members of one side (users
are lazy).
35
Contributions to Practice:
We present a summarized section of the conclusions that resulted from the IT-User Gap
study, and that is expected to contribute to practitioners:
By examining the conflict between both groups, users and developers, and even
examining the conflict within a group itself (developers defending users or vice
versa), we have concluded that the IT-User Gap is a very complex problem that
cannot be resolved but must be continually managed.
In several cases, developers are building efficient software that users are not
taking the most out of it. The solution is to let developers assist users in learning
the software by providing users services such as online tutorials, software
manuals or even personally helping them. The idea behind this is to make the IT
personnel transfer their knowledge to the users in an effective way. Meaning, no
computer jargon, nice attitude, not too much information in one session, and
always start teaching the user as if he/she never operated on a computer before.
We supported a previous study (Mann, 2002) and others, which stated that IT
developers and Users must be taken out of their solitude (being located in
different physical locations) and must be blended together.
No side could be directly blamed or unilaterally require a change in perspective or
behavior. Both sides, Users and IT personnel, are not fully acting according to
their responsibilities.
6- LIMITATIONS & FUTURE PLANS:
There are only two limitations in our study. (1) The comments were not collected via
standard sampling techniques as the respondents were self-selected. (2) The topic of the
discussion was not focused on the IT-User gap exclusively as it was entitled „'Why Users
Hate IT Products and Developers‟. This explains why some of the new constructs were
related to technology and not IT professionals directly, even though it is IT professionals
that create IT products.
36
On the other hand, by not being bounded by our theoretical model, the respondents
allowed us to uncover additional facets of the gaps that might have been missed
otherwise.
As for future plans, once themes have been uncovered for all constructs, a journal article
summarizing the validation of the gap model will be written and submitted to
Communications of the ACM. A second paper on the technology oriented construct
themes is also planned.
REFERENCES:
Babcock, C. (2005). "Closing the Developer-User Gap." Information Week(July 11,
2005).
Baroudi, J. J., Orlikowski and Wanda J., (1988). "A Short-From Measure of User
Information Satisfaction: A Psychometric Evaluation and Notes on Use." Journal of
Management Information Systems 4(4): p44, 16p
Business, N. G. W. B. t. G. t. (1999). Computer Weekly.
Fisher, J. (1999). "Improving the Usability of Information Systems: The Role of the
Technical Communicator." Journal of Information Systems: 8, 294-303.
Fisher, M. (2003). "Royal Standard Has Given Way To a Royal Pain." Washington
Post: Page B01.
Forum, S. D. (2003). "Why Users Hate IT Products and Developers."
Frese, R. (2003). "Project Success and Failure: What Is Success? What is Failure?
And How Can We Improve Your Odds For Success?".
Gallivan, M. T., Duane. Kvasny, Lynette. (2004). "Changing patterns in IT skill sets
1988-2003: a content analysis of classified advertising." ACM.
Group., S. (2006). "There’s Less Development Chaos Today."
37
Hayes, F. (1997). Giving IT the Business. Computerworld: 31,8.
Kettinger, W. a. L., C. (1995). "Exploring a ‘Gap’ Model of Information
Services Quality." Information Resources Management Journal 8:3, 5-16.
Lin, A. C., T. (2000). "Framing Implementation Management." Proceedings of the
International Conference on Information Systems: 197-205.
Mann, J. (2002). "IT Education's Failure to Deliver Successful Information Systems:
Now is the time to address the IS-User Gap." Journal of IT Education: 253,267.
Moore, J. B. L. (2002). "How to turn around 'turnover culture' in IT."
Communication of the ACM: 45, 73-78.
Mottl, J. N. (1999) Respect, Training Top IT Wish List. Volume, DOI:
Pender, L. (2000/2001). How to Communicate Value. CIO Magazine Online.
Powell, A. Y., Susan. (2004). "Exploring Reputation Differences in Information
Systems Groups." Journal of IT Cases and Applications 6:2, 5-26.
Scalet, S. D. (2002/2001). The View from the Top. CIO Magazine Online.
Seddon, P. Y., Siew-Kee, (1992). "An Empirical Evaluation of User Information
Satisfaction (UIS) Measures for Use with General Ledger Accounting Software."
Journal of Information Systems Vol. 6(1): p75, 18p
Sethi, V., Barrier, T. et al. (1999). "An examination of the correlates of burnout in
information systems professionals." Information Resources Management Journal: 5-
13, 12.
Shah, H. U., Dingley, S. & Golder, P. (1994). "Bridging the Culture Gap between
Users and Developers." Journal of System Management: 45, 18-21.
Whiting, R. (1998). Dangerous Liaisons. Software Magazine.
Wingreen, S. B. E. K., Marcy (2002). "The Relationship Between IT Professionals’
Individual Factors, Training Climate Fit, And Turnover Intentions." ACM.
38
Related docs
