Framework and Result

Since the chapter claims to be GT influenced, studies of related theory have been greatly influenced by the empirical studies. As a framework model, a modified version of the model of generic practice (the ToP model) (Goldkuhl & Röstlinger, 1999) is used in order to systemize empirical findings and related theory. The model can be used to specify the conditions and result of a specific practice, e.g., 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 and their actions. The last category is the result of the practice. When a UD 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, e.g., 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 nature of the categories is described below, together with presentation of findings from the studies.

Information Systems (Result)

A UDA is an IS and an IS 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 UDs with a good knowledge of the business, while TISs are built by IT specialists (Avdic, 1999).

SP-UDAs can be divided into four categories according to the how long learning time the UD need, in order to develop the SP-UDA. The first category is called "Simple SP-system." This rather common UDA consists more or less of structured text. It could be defined as a "pre-stage" to more complex UDAs. The next category is "Small SP-system." Typically it has simple formulas and eventually SUM-functions and simple diagrams. "Large SP-system" has more complex formulas and functions and can be distributed on several spreadsheets. The most complex UDA-system is "Application." It can be very complex and it can include programming code (Avdic, 1999). UDAs in the studies were of small and large types.

User Systems Development (Actions)

TSD can be characterized by the notion of the "life cycle," where tasks are specialized and activities are separated and systemized. User Systems Development (USD) and TSD are profoundly different in many ways. USD actions in the studies were, neither organized nor planned. Specific work related tasks or problems made the UD aware of some information need. USD was looked upon as work rather than systems development by the UD. Compared to TSD, USD is characterized by integration rather than specialization. Still it is systems development.

Success factors of USD have been discussed in the scientific community for more than a decade. 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 (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 UDs 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).

When discussing of how to manage and control USD, advocates of high control recommend (strict) organization of USD activities (e.g., Andersen, 1994). Advocates of low control consider USD as time saving and appropriate because of the lack of detailed monitoring (Speier & Brown, 1997).

The discussion of what factors are determining successful USD is implicitly aiming at organizing USD activities with a certain degree of control. In our study this discussion is not really relevant since the UDs are professional in their respective profession. They have used IT tools, if they have found it relevant, in relation to their work tasks. Since they did not separate USD from running work, they had the same quality demands on the USD result as on the rest of their work. In opposite to some research (Teo & Tan, 1999), our study shows the risk of poor quality in UDA information output should be related to the UDs' professionalism, rather than to design methods or tool properties.

User Developers (Producers)

A UD is a person with a good knowledge of the business who develops UDAs that supports the UD in his work. The UD 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 UD could have good knowledge about IS development tools. This does not disqualify him as a UD; it rather makes him even more efficient.

Knowledge

When performing USD, knowledge is divided between the UD 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 UD, 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 UD (with business knowledge) is the user of the system. The findings also show that goals, not easily formalized, can be taken into consideration when performing USD.

Knowledge about tools can be used to deepen knowledge about business. UDs in the studies could make tacit knowledge explicit when developing a USD, which in turn made it possible for others to evaluate and criticize the UDA and its output. The UDs were very conscious about that an ongoing change in the company's/ authority's environment made it important to develop not yet known knowledge about conditions and circumstances of their work. Our findings show one important aim of the UD is to articulate knowledge about business and that UDA is one 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 in the chapter is professional ethics. Professional ethics are crucial to the UD, since the professionals' activities are monitored not by procedures but by professional and business ethics. Professional ethics, as well a, professional tacit knowledge (se above) cannot easily be transferred to IT-specialists in systems development projects. Therefore, when USD is performed by Uds, professional ethics and tacit knowledge can be taken into consideration in a way not possible in TSD. Findings of the industry study also show that investigations made by the UD, when performing USD, can change organizational norms. Ongoing questioning of business using UDAs can implicitly or explicitly challenge existing models as well as their norms. In the study, the methods of measuring production was questioned, which in turn, resulted in changes in existing models and calculations. In the authority study, changes in the political situation resulted in demands of new models to assess the value of real estate. This does not mean that revolutionary effects take place every time a UDA is developed.

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). Knowledge of business, tools, and design can prevent some of these errors. Another circumstance that makes SP suitable for UDA is the fact that they are very common. In Sweden almost all employees can have access to a SP.

Because of the integrated nature of USD, learning, using and systems development take place at the same time. Learning applies to both the business and the tool. One conclusion of this is training in the use of a tool can improve the quality of USD, which in turn can improve business. One way for the management to support USD is to initiate and encourage UD-tailored training in the use of tools.