Previous | Table of Contents | Next |
The second reason has to do with a one-way model of learning. If the more influential individual leads the ISD process, he or she has more to offer in terms of being able to share his or her knowledge or expertise than the less-experienced individual. As a result, learning generally takes place in one direction as in a typical teacher/student relationship.
An example of this type of relationship is an experienced developer teamed with a novice user. The users limited knowledge or experience may make it difficult to specify their requirements. The developer may then attempt to control or lead the ISD process, in which users contribute to the best of their knowledge or expertise.
Since these individuals perceive their goals as being positively related, the potential for resistance may be low. The user may view the development process as an opportunity to learn about the technology from the developer and may be easily influenced by the developer. An information system may be developed and viewed as successful; however, as the user becomes more experienced and familiar with the system, he or she may begin to request changes. Subsequently, these requests may result in higher maintenance costs later on.
In this quadrant the user and developer share the same degree of influence and have positively related goals. Here users play a more active role in the ISD process than a novice, as their knowledge and level of expertise is greater. Because the developer also is experienced and knowledgeable in ISD, the potential for a two-way model of learning exists.
Users, for example, learn how the technology supports their needs, whereas the developer learns about the business processes. Because the goals of these individuals are positively related, the potential for resistance is low. Subsequently, a two-way model of learning suggests a higher degree of mutual learning and understanding where a system is being built successfully with lower maintenance costs later on.
In the third quadrant the individuals exhibit more of a dictatorial relationship, in which the individual with the greater potential to influence leads the ISD process. Resistance is high, because the goals of these individuals are negatively related. If the developer has the greater potential to influence the user, for example, he or she may view the user as a passive source of information. Users may perceive themselves as lacking any real chance to participate and then subsequently offer a high degree of resistance. The developer may build a system that fits the developers perception of user needs or wants to attain his or her goals. As a result, a system is developed that does not meet the initial requirements of the user and ultimately exhibits high maintenance costs. The system might be characterized as a technical success but an organizational failure. On the other hand, if the user has the greater potential to influence the developer, the user tries to increase, for example, the functionality of the system to attain his or her goals. As a result, the developer offers passive resistance when asked to comply with the users requests to minimize what the developer perceives as a losing situation. Conflicts may be settled through coercion with limited learning occurring between these individuals.
The fourth quadrant suggests a situation in which both the user and developer have an equal balance of influence but negatively related goals. Mutual learning is limited or exists only to the degree needed by an individual to attain his or her goals. Settlement of conflicts is achieved through political means, and a high degree of resistance results if one side perceives themselves as being on the losing side. Conflicts increase each individuals motivation and emotional involvement in the situation, making defeat less desirable or more humiliating than both parties losing. These individuals may become more suspicious, hostile, and ready to exploit or reject the other partys needs or requests. Subsequently, this type of relationship may potentially be the most destructive and could lead to the abandonment of the IT project if neither side is willing to capitulate.
The framework presented in the previous section may be used to assess and structure the relationship between users and developers. A three-step process is now presented to assess, structure, and then monitor the social relationship between these individuals.
Assessment of the user/developer relationship is useful for choosing project participants as well as for gaining insight during the project if problems begin to arise. Using the framework presented in the previous section, a manager may begin by determining the potential balances of influence. Examples of such factors that affect the balance of influence for both developers and users include:
Other factors relevant to the project or organization can and should be used to assess the balance of influence among individuals. Subsequently, the manager should begin to get a clearer picture as to whether the balance of influence will be one sided or balanced. The next step is to assess individuals goals. An easy way to make this assessment is to ask each individual to list or identify factors that are important to him or her. Examples include:
After having both users and developers list what is important to them, a manager can compare these items to determine whether the individuals have potentially conflicting goals. End users and developers need not have exactly the same items of interest; these items need only not cause a win/lose situation. Asking the individuals to list how they would determine whether the project is a success or failure may uncover other potentially conflicting goals. For example, a manager may discover that users value functionality over cost, whereas the developer is concerned with ensuring that the project is developed by a specific date.
Previous | Table of Contents | Next |