The Why and Why not of User Participation in IOS Development

This paper argues that user participation can enhance the development of interorganisational systems (IOS). Under certain circumstances participation may be particularly desirable or may be facilitated; other circumstances make participation seemingly less

When interorganisational systems (IOS) are developed, the intention is that these systems are adopted by users out-side the initiating organisation. Such us-This paper argues that user participation can enhance the development of interorganisational systems (IOS). Under certain circumstances participation may be particularly desirable or may be facilitated; other circumstances make participation seemingly less important or inhibit participation. Such contingen-cies for participation during IOS development are identified and described.ers may be private individuals (for in-stance, users of Internet or of automated teller machines) or may be organisations (for instance, users of order entry sys-tems or corporate cash management sys-tems). Implementation of IOS and sys-tem uptake by intended users is not nec-essarily easy or successful. There are a number of measures and practices which organisations can employ to enhance implementation. Some of these (like large-scale marketing of the system) are used after a system has been developed, at a time when the IOS is ready to be offered to potential users. It is also possible to take a proactive stance towards facilitat-ing implementation and encouraging adoption of the IOS by users; by seeking participation of intended users during the development process, the opportunity is created to consider potential implemen-tation problems before the IOS has been built.

the concept and the final design of the IOS take account of various interests.When the IOS addresses intended users’needs and interests, the system is more likely to be accepted and used by the intended users.

While the argument in favour of partic-ipation is compelling, there are also argu-ments against participation. One of those is that IOS are so new to users that the users can not possibly know what they need and cannot express what they would like from the system. Another argument against participation is that different or-ganisations pursue their own self-interest and that it may be difficult to achieve full co-operation from various parties. How-ever, by encouraging participation, an organisation can be seen to want to co-operate with other parties. Also, the par-ticipation effort itself can make inter-ests of various parties explicit and can allow latent needs to surface. Once the wish to co-operate is apparent and the various interests are clearly expressed,participation can be used to try and achieve consensus on the concept of the system to be developed.

-Intended use of the system

Systems which are to be imposed on users and use of which is compulsory, do not necessarily require participation of users during development to enhance user adoption of the system: whatever the outcome of the system development effort, users will be forced to use the system. On the other hand, systems which rely on voluntary adoption and use can benefit greatly from participation. When those cases participation may not neces-sarily be required , participation is still desirable . Mandatory systems, systems with a high degree of structuredness, and systems with a low number of potential interest groups can still benefit from par-ticipation. After all, participation enhanc-es user understanding, acceptance and commitment to the system; as such par-ticipation can smooth the implementation stage of development. In addition, seek-

Table 1: Contingencies impacting on potential importance of participation in IOS development

What is ‘User Participation in IOS Development’ ?

Participation of intended users during development of a system refers to the practice of involving users in activities during the development process. Such participation should not just take place during testing of the system, but partici-pation should allow users to help shape the system by collaborating during the problem definition phase and the specifi-cation phase of development. Participa-tion is aimed at building a system which is acceptable to intended users and this in turn should facilitate implementation and encourage adoption and use of the sys-tem by the intended user group.

Participation in the IOS context in-volves gathering together representatives of various interest groups from outside the organisation before starting actual development and seeking active involve-ment of those users during the develop-ment process. In this way, the IOS is developed with input and (hopefully) with the consensus of intended users which, if carried out correctly, should ensure that

Contingencies that Make Participa-tion more or less Pertinent

There are several conditions where there is a greater or lesser apparent need for participation of intended users in the IOS development effort (see Table 1).adoption of the IOS is voluntary, it is particularly important to ensure that the needs/wishes of user organisations are taken into account during development.

-Nature of process to be automated When the processes to be addressed by the IOS are highly regulated and stand-ardised, then IOS development is rela-tively structured and straightforward. In that case IOS development is concerned with the automation of existing, well-de-fined procedures which does not neces-sarily require involvement of intended users to define the system concept or to define specific requirements. Alternative-ly, systems can also be aimed at auto-mating less structured processes and systems can significantly change exist-ing processes. In these situations partic-ipation of intended users can aid the development process and facilitate im-plementation of the proposed system.-Number of interest groups

When developing a system for a specific interest group it is possible that the sys-tem initiator can oversee and anticipate the needs of that group without requiring any specific input from that group during development of the IOS. In contrast, when there are a large number of potential interest groups it is more difficult for the system initiator to intuitively understand the needs and requirements of all differ-ent groups. This problem may be ad-dressed by consultation with representa-tives of all potential interest groups early on in the development process and by seeking participation of representatives during development of the IOS.The Why and Why not of User Participation in IOS Development

It is clear that there are circumstances where there may be less need for partic-ipation to enable development of an IOS than in other circumstances. Although in

EM - Electronic Markets / No. 13-14 / January 95 / Page 8

* by Dr. Angèle L. M. Cavaye Delft University of Technology

This paper argues that user participation can enhance the development of interorganisational systems (IOS). Under certain circumstances participation may be particularly desirable or may be facilitated; other circumstances make participation seemingly less

users. In contrast, when different users or groups of users are easily distinguished,then seeking participation from users is facilitated.

-Number of potential interest groups When the number of potential interest groups increases, a participation effort becomes more difficult to co-ordinate and consensus is less likely to be achieved in a short period of time. Foreseeing difficult discussions and time delays, the initiator of such an IOS may prefer to develop a system without participation hoping to create a norm or standard which other participants then accept and use. Alter-natively, participation during development of an IOS with a focused user group would create less difficulty for the initiator which makes the seeking of participation from intended users more likely.-Number of competing systems

In industry sectors there may at any one time be one, few or many competing,similar IOS. When there is no competitor or when there are only few competing systems, an IOS initiator may not feel forced to seek participation of intended users. On the other hand, when many IOS flood the industry, participation of users in (further) development of the IOS is encouraged. Participation then is likely on two counts: the initiator will need to be sure that the new system is competitive compared to others and that it accurately meets market needs. Secondly, the initi-ator may seek rationalisation among com-peting IOS and may invite participation from sponsors of other IOS in order to discuss possibilities for a common, shared IOS.

ing participation, especially when not strictly necessary, demonstrates the initi-ator’s wish for a collaborative and posi-tive relationship with partners and this could enhance the overall trading rela-tionship.

Contingencies that Inhibit or Facili-tate Participation

There are a number factors that are known to inhibit participation in the devel-opment of any system, whether internal or external. Those factors include lack of time (participation is known to increase the amount of time required for develop-ment); and lack of funds (participation increases the cost of development by lengthening development time and in-creasing requirements). These factors will not be discussed here; instead we focus on the factors which are specific to the IOS context (see Table 2).

-Power distribution among participants In many trading situations there are dom-inant players; this can happen in vertical relationships and in horizontal relation-ships. The fact that there is a dominant player need not affect participation, but it often does. The dominant player is in a position of power and may use influence to ensure that an IOS development serves its own interests. When the dominant player is the system initiator, participation from other players may not even be sought or, if it is, participation can become a highly political process with every party seeking to get the best out of the situa-tion.

-Nature of the market

The intended user market may be closed and may have a known set of users or user groups; alternatively, the market may be open and have an undefined number or set of users. In a closed group different (groups of) users are known and clearly defined; in an open group the different users may not be clearly identifiable.When different groups of users cannot be clearly identified, it is difficult for the IOS initiator to invite participation from those

Table 2: IOS contingencies inhibiting and facilitating participation

the development effort. The people and the potential users of the system are then considered the most important compo-nent in the information system. When the initiator embraces a neohumanist world view, participation of intended users be-comes the default and the norm.

One of the factors in Table 1 (factors indicating greater or lesser need for par-ticipation) also appears in Table 2 (fac-tors inhibiting or facilitating participation):IOS contexts with many different interest groups could benefit from including users during development and yet the sheer number and variety of different user groups works as an inhibitor on participa-tion. It seems ironic that one of the situa-tions where participation seems particu-larly necessary and important is also a situation which tends to have an inhibiting effect on participation!Concluding Comments

Participation in the IOS context is per-haps more complicated than participa-tion in internal system development -after all, participants are separate and independent from the initiator. And yet,participation in IOS development can be very rewarding since it enhances co-op-eration with trading partners and also potentially enhances implementation suc-cess. Sadly, in practice there are many situations where participation may not seem necessary or may be inhibited.Practitioners should carefully consider the benefits of participation of intended users during development of an IOS and must be aware of the participation contin-gencies. Only then is it possible to make a conscious decision concerning the rel-evance of participation during develop-ment of a particular IOS.* Dr. Angèle Cavaye (acavaye@sepa.tudelft.nl) is Assistant Professor at the Department of Systems Engineering, Delft University of Technology, The Nether-lands.

EM - Electronic Markets / No. 13-14 / January 95 / Page 9

-World view of initiator

Many system development methodolo-gies were and are based on functionalist assumptions aiming at efficiency and ef-fectiveness. A functionalist view of sys-tems considers user participation as a means to an end: participation of intend-ed users is only sought if this is clearly necessary to enhance the system. In contrast, in the neohumanist world view,participation is accorded a central role in

References

[1]Barki, H.; Hartwick, J.: Rethinking

the Concept of User Involvement, in:MIS Quarterly, March 1989, pp 52-63.

[2]Hirschheim, R. A.; Klein, H. K.: Real-ising Emancipatory Principles in In-formation Systems Development, in:MIS Quarterly, March 1994, pp 83-111.

[3]Konsynski, B.R.; McFarlan, F.W.: In-formation Partnerships - Shared Data, Shared Scale, in: Harvard Busi-ness Review, September-October 1990, pp 114-120.

[4]Moss Kanter, R.: Collaborative Ad-vantage: the Art of Alliances, in: Har-vard Business Review, July-August 1994, pp 96-111.

本文来源：https://www.bwwdw.com/article/g8z1.html