INTRODUCTION
In the early days of computers, expertise was needed not only to develop systems, but also to use them. As IT tools have become more powerful and user friendly, more and more people have been able to use computers and programs as tools when carrying out working tasks. Nowadays it is even possible for people without special IT training to develop information systems that only IT specialists could have done some years ago.
BACKGROUND
In this article the conditions and effects of user systems development (USD) using a spreadsheet program (SP) are discussed. USD is characterized as a sub-area of end-user computing. USD is performed by a user-developer, a person who acts both as a user and a systems developer. A typical feature of a user-developer is that he has a good knowledge of the business and the work related to the information system (IS) in question, which is called the user-developed application (UDA).
To a large extent USD is a question about learning. User-developed applications are often developed in order to learn and understand. In Figure 1 the difference between traditional systems development (TSD) (1) and USD (2) is outlined in order to demonstrate the nature of USD in contrast to TSD, since TSD is familiar to the IS community. To the IT specialist, knowledge about IS development tools (e.g., methods, program languages) (1a) is in primary focus when developing TISs (1c). This is the core of the user-developer’s professional knowledge. Knowledge about business (1b) is of course essential, but not primary. To the user-developer knowledge about business (2a) is in primary focus and knowledge about IS development tools (2b) is just a means to accomplish business-oriented tasks, eventually by developing UDAs (2c). The IT specialist has access to knowledge about IS development tools that is hard to access for nonprofessionals. Some business knowledge is hard to access for the IT specialist, since this knowledge is not in the professional knowledge domain of the IT specialist. The user-developer on the other hand is the expert on business knowledge. His professionalism depends on his knowledge about business. No one can replace him in this matter. In order to perform USD, the user-developer needs some knowledge about IS development tools. It is not possible though to have access to as much knowledge about IS development tools as the IT specialist has.
To both the IT specialist and the user-developer, both kinds of knowledge are to some degree necessary. In order to make an information system, the most important kind of knowledge is in general knowledge about business, since the information system is about the business. The thick arrow in Figure 1 demonstrates this circumstance.
In order to develop information systems, knowledge about business has to be transferred from business specialists to IT specialists. This transfer is problematic since people have different frames of references (Yourdon, 1989; Alter, 1996). The whole intention of the sender can therefore not be transferred to the IT specialist. The IT specialist cannot, on the other hand, fulfill the requirements since he cannot completely understand the business specialist. Complex systems development tasks still have to be performed through TSD, but as more powerful systems development tools are at hand, the possibilities to perform USD are enhanced from year to year. Spreadsheet programs have properties that give the user-developer access to IS development features without being an IT specialist. Of course there are other ways to overcome this gap, for example, by performing systems development with a participative approach like RAD (Tudhope, Beynon-Davies, Mackay & Slack, 2001). The systems discussed in this article are often small and local, and thereby often are not suitable for traditional systems development projects.
CONDITIONS AND EFFECTS OF USER SYSTEMS DEVELOPMENT
As a framework model, a modified version of the model of generic practice (the ToP model) (Goldkuhl & Rostlinger, 1999) is used to systemize empirical findings and related theory. The model can be used to specify the conditions and result of a specific practice, such as a controller practice or an IT specialist practice. The modified model consists of a set of conditional categories—knowledge, norms, and tools. The categories that express the specific practice are named producers (the user-developer) and their actions (user systems development). The last category is the result of the practice (the application). When a user-developer develops UDAs, he acts in at least two types of practices, the primary (e.g., controller) practice and the secondary (developer’s) practice. Each practice is related to a profession, such as a controller and an IT specialist profession. The model makes it possible to separate the conditions of the different practices. It also makes it possible to discuss which parts of the developer’s practice can improve the main practice without consulting an IT specialist. The use of the model makes it possible to show how different practices exchange conditions and effects. The result of user developer practice might, for example, be a condition of the controller practice. The model is described in Figure 2.
Figure 1. Relation between knowledge and development
The ToP model is slightly related to the Work Systems model (Alter, 2002), in that the model focuses on practice without specific references to IT artifacts. The ToP model emphasizes knowledge aspects more explicitly, which makes it especially suitable to analyze the practice of user systems development. The nature of ToP model categories is described below.
Information Systems (Result)
A UDA is an information system, and an information system is a result of systems development. The difference between a traditional information system (TIS) and a UDA is mainly a question of how it is built. UDAs are built by user-developers with a good knowledge of the business, while TISs are built by IT specialists.
User Systems Development (Actions)
Traditional systems development can be characterized by the notion of the ‘Life Cycle’, where tasks are specialized and activities are separated and systemized. USD and TSD are profoundly different in many ways. USD actions are seldom organized nor planned (Avdic, 1999). Specific work-related tasks or problems make the user-developer aware of some information need. USD is looked upon as work rather than systems development by the user-developer. From the user-developer’s point of view, any tool is useful that might help him solve work-related problems. Compared to TSD, USD is characterized by integration rather than specialization. Where TSD professionals get specialized in programming, analysis, or database design, the user-developer integrates skills and performs the entire life cycle by himself.
Success factors of USD have been discussed in the scientific community for more than two decades. The reasons why USD is successfully adapted in an organization have been claimed to depend on the presence of informal channels of communication and how common training on USD tools is (Kruck, Maher & Barkhi, 2003; Brancheau & Brown, 1993). Basic conditions (suitable tasks, equipment, knowledge, and certain independence) must be fulfilled to make USD possible (Carlsson, 1993). If business and information needs are dynamic, USD can be justified. USD is appropriate when user-developers also have access to well-organized data, and get support from management and the IT department (Auer, 1998). Perceived importance is also claimed to be vital (Blili, Raymond & Rivard, 1998).
Figure 2. ToP model
When discussing how to manage and control USD, advocates of high control recommend (strict) organization ofUSD activities (e.g., Andersen, 1994). Advocates of low control consider USD as time saving and appropriate because of the lack of detailed monitoring (e.g., Speier & Brown, 1997).
The discussion of what factors determine successful USD is implicitly aimed at organizing USD activities with a certain degree of control. This discussion is not really relevant since the user-developers are professional in their respective professions. They use IT tools when they find it relevant in relation to their work tasks. Since they do not separate USD from running work, they have the same quality demands on the USD result as on the rest of their work. Contrary to some research (e.g., Teo & Tan, 1999), we claim that the risk of poor quality in UDA information output should be related to the user-developer’s professionalism rather than to design methods or tool properties.
User-Developers (Producers)
A user-developer is a person with a good knowledge of the business who develops UDAs that support the user-developer in his work. The user-developer is primarily a professional (e.g., a controller) who integrates to some extent the role of one or more IT specialists when performing USD. The user-developer could have good knowledge about IS development tools. This does not disqualify him as a user-developer; it rather makes him even more efficient.
User-developers can be categorized in different ways. Commonly, categorization is done by knowledge of computing technologies. Rockart and Flannery (1983) and Govindarajulu (2003) are using the following types:
• Non-programming end-users, who are developing very simple applications and who are using a very limited set of tool functions.
• Command-level users, who are developing applications using declarative functions (e.g., formulas and functions).
• End-user programmers, who are developing applications that can be more complex (e.g., multi-user) applications using declarative as well as procedural functions.
With regard to the second and third types, the combination of deep knowledge about business and knowledge about IT tools makes it possible for the user-developer to perform systems development without engaging IT specialists.
Knowledge
When performing USD, knowledge is divided between the user-developer and the tool (SP). Certain kinds of (not too complex) knowledge are formalized into the SP and can be used in the SP-UDA. Other kinds can be formalized by the user-developer into the SP-UDA. Some kinds of knowledge (e.g., of critical evaluation of the relevance of formulas) cannot be formalized at all. Still, this kind of not easily formalized (sometimes tacit) knowledge can be taken into consideration when using the UDA, since the user-developer (with business knowledge) is the user of the system. We also claim that goals, not easily formalized, can be taken into consideration when performing USD.
Knowledge about tools can be used to deepen knowledge about business. User-developers can make tacit knowledge explicit when developing USD, which in turn makes it possible for others to evaluate and criticize the UDA and its output (Adam, Fahy & Murphy, 1998). The user-developers are conscious that an ongoing change in the company/authority’s environment makes it important to develop not-yet-known knowledge about conditions and circumstances of their work. One important aim of the user-developer is to articulate knowledge about business and that the UDA is an important means to do this.
Norms
Norms and knowledge are closely related and sometimes hard to keep apart. One set of norms that are central is professional ethics. Professional ethics are crucial to the user-developer since the professionals’ activities are monitored not by procedures, but by professional and business ethics. Professional ethics as well as professional tacit knowledge (see above) cannot easily be transferred to IT specialists in systems development projects. Therefore when USD is performed by user-developers, professional ethics and tacit knowledge can be taken into consideration in a way not possible in TSD. Ongoing questioning of business using UDAs can implicitly or explicitly challenge existing models as well as their norms.
Tools
USD tools are closely related to norms and knowledge, since norms and knowledge are implemented in tools. The main tool when performing SP-USD is of course the SP. The SP integrates functions for input, output, storage, processing, and presentation. This integration results in interactive development and use. The open nature of the SP can cause different kinds of errors (Panko & Sprague, 1998; Kreie, Cronan, Pendley & Renwick, 2000). Knowledge of business, tools, and design can prevent some of these errors. Lack of experience and training can also be a problem related to the tool (McGill, 2002).
FUTURE TRENDS
Since IT is becoming more and more common in different environments, it is likely that USD will also become more common. Rapid change in most aspects of everyday life and business contexts will make it more important to be able to deal with situations, questions, and specific information needs that are not anticipated in standard packages and systems developed years ago. The increased need of learning tools, eventually Web based, will therefore increase the need of flexible tools aimed at providing user-developers with learning possibilities. This way end-user computing and knowledge management will merge together and inspire future research.
CONCLUSION
SP-USD is characterized by integration, interactivity, and capacity of questioning. The notion of integration can be looked upon in several dimensions: 1) aspects of ISs (integration of collecting, storing, processing, and distribution of information), 2) roles (integration of developer, user, and manager roles), 3) roles of actors in systems development (integration of analyst, programmer, database, and designer roles), and 4) integration of processing functions of the IS. The integrated nature of USD results in interactivity. Interactivity means that the user-developer can change quickly between developing and using the SP-UDA. During the USD process the user-developer knowledge of the business and USD increases. This is actually the goal of the user-developer. Since the user-developer’s knowledge of the business increases when performing USD, the user-developer can analyze and also question aspects of business (e.g., production measuring methods). The questioning aspect makes it possible to improve business.
SP-USD can be used as a means of controlling continuous changes in the environment of the organization by changing business with the help of USD (see Figure 3). A business analysis (1) can result in a revaluation of the business (2), which can result in a revaluation of its goals (3) (and norms), which can result in a revaluation of methods of measurement (4), which can result in new analytical models (5) (UDA), which can lead to a new business analysis (1), and so on. USD is discussed as one way to meet change as a permanent business condition, which differs from traditional methods for systems development.
This way of reevaluating organizational goals can be related to double-loop learning, as presented by Argyris and Schon (1996). This includes not only changes in behavior or strategies. It means that norms of the organization can be changed. The ongoing questioning of business practice that is performed through USD can imply this form of norm changing.
Figure 3. Continuous change and user systems development
KEY TERMS
End-User Computing: “…the adoption and use of information technology by personnel outside the information systems department to develop software applications in support of organizational tasks” (Brancheau & Brown, 1993, p. 437).
Information System: A system consisting of functions for input, processing, storing, output, and presentation of information.
Spreadsheet Program: The most common standard package next to word processors, suitable for user systems development.
Systems Development: A process where an information system is developed.
Traditional Systems Development: Systems development carried out according to the ‘life cycle’ model.
User Systems Development: Systems development initiated and performed by user-developers, who have good knowledge about and who are (partly) responsible for (part of) the organization the system is to serve.
User-Developed Application: An information system developed by a user-developer. The system is often small and dedicated to a specific task in the user-developer’s working environment.
User-Developer: A person who develops UDAs that support the user-developer in his work. The user-developer has deep (often tacit) knowledge about, and is often (partly) responsible for (part of) the organization the system is to serve.
