You are on page 1of 11

Evaluating Investment Projects with a Group Decision Support System

Joo Paulo Costa; Paulo Melo; Pedro Godinho and Luis Dias Faculdade de Economia da Universidade de Coimbra Av Dias da Silva n 165, 3004 - 512 Coimbra, Portugal INESC - Coimbra

ABSTRACT
This work presents some issues concerning the utilization of the AGAP system (Aid to Groups of Analysis and evaluation of Projects). The AGAP is a group decision support system (GDSS) that was developed (at the Faculty of Economics of the University of Coimbra) as a distributed system allowing multiple decision makers to cooperate in order to evaluate and select investment projects. This work reports on several lab tests focusing one of the main activities supported by the AGAP system: the generation of alternatives (investment projects). The tests were conducted as a first step to start field tests, in order to ascertain the adequacy of the system to support: a group process; specific task structuring activities, both individually and in group; and several specific financial methods to evaluate investment projects. The test results are discussed and modifications on some functional modules of the AGAP system are proposed. Keywords: Group Decision Support Systems, Project Analysis and Evaluation, Lab Tests.

1. INTRODUCTION
This work presents some issues concerning the utilization of the AGAP system (Aid to Groups of Analysis and evaluation of Projects). The AGAP is a group decision support system (GDSS) that was developed (at the Faculty of Economics of the University of Coimbra) as a distributed system allowing multiple decision makers to cooperate in order to evaluate and select investment projects. The system incorporates a set of a state of the art financial methods and measures, implemented as tools that can support multiple criteria project evaluation. Non-financial criteria can also be incorporated whenever a decision maker feels their necessity. Furthermore, multiple criteria decision aid methods are available to the decision group, incorporating several risk analysis and evaluation techniques and models. The recent development of information and communication technologies enabled the implementation of some classes of applications that are broadly classified as Groupware. In [10] one can find the review and classification of more than 200 recent papers of this area. Most of the reported applications try to embody several already developed concepts and noncomputational techniques and tools with information technologies, in order to attain better communications and processes of collaboration among people engaged in some specific problem. Among these one can find: - Computer-Mediated Communication System (CMCS): to use the computer to structure, store, process, and distribute human communications [6], [13], [4], [7]. - Group Decision Support Systems (GDSS): to facilitate the solution of unstructured and semi-structured problems by a group of decision makers working together as a team [9], [12], [11], [8] and [5]. Both GDSS and CMCS are moving toward providing any time/ any place both communication and decision support. Moreover, they can support not only synchronous meetings (all participants attend the meeting at the same time), but also asynchronous sessions, where each participant can attend on his/her most convenient schedule. In AGAP we consider that most meetings are asynchronous and each participant would act as an individual problem solver and would concentrate his or her attention on the specific aspects he or she feels relevant. An underlying assumption is that group members can be concerned with different sets of criteria, different parameters, different alternatives and different characterizations of those alternatives. Moreover, they can create and test their own alternatives (which may be hypothetical or utopic) just to learn, to better understand or to structure their knowledge. Thus, the system must consider both individual and group problem solving processes and how they interact. This work reports on several lab tests performed with the AGAP system. The tests were conducted (as a first step to start field tests) in order to ascertain the adequacy of the system to support: a group process; specific task structuring activities, both individually and in group; and several specific financial methods to evaluate investment projects. There are two main activities to perform when analyzing or evaluating investment projects: to generate the alternatives and then to compare them with each other or against some reference, in order to evaluate them. Both these activities are supported by the AGAP system. In this communication we focus on the first main activity. The reported tests were organized focusing on the problem of

generating and structuring the investment projects (that is the alternatives). The AGAP conceptual model for dealing with this problem imposes three levels of information gathering and processing: the individual level, the interpersonal level and the collective level. Therefore, we tried to test a group process including all these three levels and the transitions among them. Specifically, the objectives of the decision group engaged in the tests were: - to analyze some projects prepared by other, - to create new possibilities and to study them, - to reject the alternatives that were not considered good enough, and - to choose a set of criteria to rank the alternatives. Note that the selection of one alternative is not an objective of the test group. The test results are discussed and modifications on some functional modules of the AGAP system are proposed. Some of these changes are being addressed, in an upgraded version of the system under development. It was found that the most inadequate module is the one that supports the collective work on the same work area. Some interface issues were also identified as requiring redesign. It was also found the need to perform a deep research study concerning the module that supports the choice of the preferred criteria to evaluate the investment projects. The remainder of this paper is organized as follows. Section 2 presents an overview of the features of AGAP system. It also presents some usage procedures, focusing on creating alternatives and on communicating, which are the most relevant procedure usage for the reported tests. Section 3 describes the tests. Section 4 presents the test results and their discussion, including some proposals to modify the system. Finally, in section 5 we conclude the paper with a brief summary.

2. AN OVERVIEW OF THE AGAP SYSTEM


A more detailed description of the AGAP system can be found in [2] and [3]. It was implemented with Delphi as an MSWindows (95 or NT) based distributed system using TCP/IP. There is a central unit and several (4 to 6) work stations. Each group member has his/her own work station (a PC). A user cannot directly access the data stored at another members computer. Structured communication is organized as "documents" of related data, that are sent via the central unit. The AGAP also supports unstructured communication (such as messages) and voting. All of these are controlled by the central unit. Group access permissions to data can be stipulated by the group element (the owner) that originates that data or that communication. See Figure 1 for the architecture of the AGAP system.
OTHER WORK STATION OTHER WORK STATION

CENTRAL UNIT

DATA SHARING - COMMUNICATIONS

Projects, Cases and Attributes

Evaluation and Decision Processes

Multicriteria Decision Aid Methods

Voting Processes

Message Passing

INTERFACE - WORK STATION I

Figure 1. The architecture of the AGAP system. The system provides the kind of support usually found in decision support systems planned for a single decision maker (DM). Therefore, a DM can create his/her evaluation process to analyze the groups problem as if he/she was the only DM. Furthermore, the DM can create several of such evaluation processes in order to test several hypotheses. By doing this the DM can learn before discussion starts or while the group discussion takes place. The system allows for strict confidentiality concerning this individual analysis, which is done locally at the DM's work station. A decision process can have several evaluation processes. Each evaluation process can belong to an element or to a sub-set of elements of the group. Related to each evaluation process, there are the project cases under analysis and evaluation, the chosen criteria, the methods of evaluation (usually multicriteria) and the obtained results. This structure facilitates performing a large amount of experiments and the comparisons of their results. The AGAP manages all the evaluation processes using a case-based structure. An investment project originates cases belonging to an element of the group or to a sub-group of elements. Different cases of the same project represent alternative ways to characterize or to implement it. There is an exploration phase where the cases are analyzed and understood by each element and afterwards the interesting cases are presented to the group and discussed.

The project cases are characterized by attributes. There are several pre-defined attributes at the system, but the users can define new ones. Moreover, the users can define the new attributes based on attributes defined earlier. These new attributes can sometimes be defined as syntactic expressions, involving other attributes, that are computed by the system whenever needed. Models and data manipulation processes are stored as data, enhancing the computational support to the modeling phase, due to the availability of structural information on the attributes. Combined with the case structure, this allows a user to do virtually everything he/she wants to characterize a project. The data structure storage uses relational databases concepts and is distributed. The way data are distributed is essential for the security of the system and therefore is managed by the central unit. The database structure is replicated on all the work stations but each work station only stores information of the DM or information that the DM has access to (granted by the information owner).
Define Attributes Define Scenarios and Characteristics

Define Cases of Projects

Alternatives

Choose Criteria

Choose Cases

Apply Multiattribute Aggregation Methods

Evaluation Process

Evaluate Results

Figure 2. Sequence of the tasks to perform. Several loops (omitted from the schema) can be performed among the tasks.

Using the AGAP system


Figure 2 presents a schema of the task sequence to perform in order to come out with the final result. This sequence must be performed regardless of the number of decision makers (one or more) and of the detours or even restarts that may be needed to improve the results and the decision makers confidence on them. It is necessary to define the alternatives and to set an evaluation process. The alternatives are defined by setting their performances on several attributes that are considered relevant and establishing the scenarios assumptions (economic macroindicators, for instance) that affect them. After defining the alternatives, it is necessary to set an evaluation process: to choose and characterize the criteria, to choose a sub-set of alternatives to evaluate and to apply a multiattribute aggregation method, according to the decision at stake (to select a project, to rank or to classify the projects). The criteria are selected among the attributes characterizing the project cases (alternatives), and more than one multiattribute method can be applied in the same evaluation process.

The alternatives
In this subsection we present the details concerning the alternatives and the processes of their creation and sharing, since the reported tests focus exactly on these activities. The key structural element of information is the case. A case works as an alternative (some authors call it an action). It includes relevant data, characterizing an investment project, reference to some environmental data for scenario analysis and the identification of the groups elements associated with it. In the AGAP system an alternative is identified by case p.n, where p is the number of the project and n the number of the project version, i.e., the same project can be planned and implemented in several ways, each one substantiated in a case of that project. In order to complete this task it is also necessary to define the interdependencies among the alternatives. For instance, if there are two projects (or cases) for building at the same piece of land, they will obviously exclude each other. They cannot be both selected for investment. Other kind of interdependencies can also arise. The cases are characterized by attributes. Each attribute has its own identification and definition. The cases have performances on the attributes. Not all the available attributes have to be used to characterize a project. There are several predefined attributes, but a user can identify and define other ones in order to fully characterize a case. A user can also define new attributes as functions of already existing ones. The AGAP system stores these functions as syntactic expressions and evaluates them whenever needed. Consider, for example, that there is a pre-defined attribute, the attribute A, and the user defines another attribute: attribute B. This user can build an attribute C that is based on attribute A and B. For instance C =

(A-B)/2. Whenever the attribute C is used by the system, an expression evaluator is triggered to obtain its performance. Note that, if a case characterization includes attribute C, it must also include attributes A and B. Suppose that project 1 is about enhancing a textile production line. The case 1.0 is created. This case has all the data needed to roughly characterize the project. Several cases can then be derived from the case 1.0, having drastic differences among them or just minimal. For instance, Should we enhance the textile production line through purchasing a special machine?, or Should we buy the services of that machine from other company?. Another example could be just to have different concepts about the reinvestments of the cash-flows. When creating case 1.1, for instance, it is not necessary to repeat all the information of the case 1.0. It is only necessary to state and store the differences. Cases 1.x inherit the characteristics of case 1.0. A user that builds a case at his/her work station is its owner. After creating a case, he/she can decide to share that case with the others. If so, he/she can grant permission to other elements of the group and send the case to the central unit. When connected to the central unit, a work station automatically downloads the information addressed to its user. A user can compare the cases of other owners with their own, exploring the differences, but without loosing control of the ownership of ideas and preferences. Moreover, a user can create a case (an alternative) mixing attributes and other information from several owners (group members). On sharing one case, several pieces of information are packaged in order to maintain context. For instance, if a user wants to share case 1.1 (first version of project one), the system will prepare a document encapsulating information related to: - the case 1.1 itself; - the attributes associated with case 1.1; - the case 1.0 (that has the basic data for project one) and the attributes associated with it; - the scenarios of case 1.0 and case 1.1; - the characteristics of those scenarios; and - all the stored comments and justifications that are associated with these pieces of information. It is not possible to directly share unstructured data (e.g. just an attribute), among databases. Therefore, the context must be also shared when sharing cases.

Hands-on use of AGAP


This subsection details some usage procedures of the AGAP system (just the most relevant ones for the performed tests).

Creating alternatives: To create a new alternative it is necessary to define a case of a project. Therefore, it is necessary to define a project, or to use one project already defined. After opening the application at the decision makers workstation, the usage procedure to define a project is the following: 1) Go to the PROJECTOS (projects) dialog box (through the menu) to input the project identification code, its name and a short description. The system marks the project as belonging to the decision maker that owns the workstation and creates the case zero of this project. 2) Go to the ELEMENTOS BSICOS (basic elements) dialog box to define new attributes. All the relevant attributes to characterize the project case must be defined. Some of them can already be defined (in order to characterize other projects), but the new ones must be input, providing the following information: an identification code, the attribute name and a short description. The attribute is automatically marked as property of the workstation owner.

Figure 3. The AGAP dialog box that organizes communications. 3) Go to the CASOS (cases) dialog box to create a new case. First, it is necessary to select the corresponding project. At least the zero case is already created (step 1). The decision maker can use this case or create another one. If he/she wants to use case zero there is nothing to accomplish in this dialog box. If not, he/she must input the identification code of the case (it corresponds to the number of the project version), the name of the case and to choose one scenario to associate with it. This scenario is chosen among the ones already defined. See step 5 in order to define and characterize a scenario. 4) Go to the DESEMPENHO CASO (case performance) dialog box to enter the case performance on each attribute. First, it is necessary to select the case on which we are working. Second, it is necessary to choose an attribute among the earlier defined ones. Then we must characterize the type of the attribute: a deterministic number, a range or a probability distribution. Finally we input the expression defining the performance. Considering that it is a deterministic number, this expression can be a real number (inputted directly) or a string of characters. The AGAP system evaluates this string whenever it is used. There are some syntactic rules to write the expression but they are out of the scope of this paper. It is possible to use other attributes as variables, algebraic relations and functions of financial calculus. This means that the user can build his/ her own analytic models in order to define the performance of an attribute. 5) Defining a scenario is alike defining an alternative. First, it is necessary to define the characteristics of the scenarios just like for the attributes. Secondly, a scenario must be created, like a project, but with some other probabilistic information. Finally, the performance of each characteristic associates it with its scenario, like the performance of the attributes on the cases.

Communicating: Figure 3 presents the fundamental dialog box for communicating. The labels are in Portuguese language because the AGAP system was developed within the Portuguese context, but a glossary is presented in appendix, translating the used labels. On the left part of the dialog box presented in Figure 3 an hierarchical menu to choose the type of communication is presented to the user. The options are: - Message Passing (Mensagens) - There are three sub-options under this option: to send (A Enviar), sent (Enviadas) and received (Recebidas). The first one is activated in order to send a new message or to open a new message passing channel between several decision makers. The second option exists in order to verify the communications, that is to check if the messages were actually sent. The last allows the user to see received messages of old communications. The presentation of these messages is organized according to the decision process in which they were generated, to the communication session to which they belong (the channel) and according to their age (time). Moreover, they are associated with the corresponding already sent messages. - Voting processes (Processos de Votao) - Five sub-options exist. 1) Creating and defining (Para Enviar) a new voting process. 2) To actually vote (A Realizar) in an already created voting process. A voting process can be created by any of the users engaged in a decision process. The creator defines several things including who votes. 3) To see past votes in past voting processes (Votos Enviados). 4) Too see detailed information about past decision processes (Concluidos). Finally 5), too see the final results of completed voting processes. - Information interchanging (Intercmbio de Informao) - There is only one sub-option (Informao Disponvel). It allows to see information of the local data base that is available to send to other users. There are two possible packages of

information that can be sent: the alternatives, i.e., projects, cases and all related information, and the evaluation processes, i.e., a set of alternatives, their evaluating criteria and the used multiattribute aggregation methods. We will focus on the alternatives. This sub-option was chosen in the picture of Figure 3 and due to that the right part of the dialog box presents some information about the projects and their cases. In the upper of the right part of the dialog box, one can choose one project to send. Pressing the right mouse button over that project, an option to send it can be chosen. Doing this, another dialog box appears: it allows for the selection of the users to who the information will be send, and of their permissions. On sending a project a package of information is prepared, including all available cases of that project and the information associated with each one of them, according to what is presented in the sub-section The alternatives. If the user wants to send just one case of a project (not all the cases of it), he/she can press the right mouse button on one of the cases presented in the lower of the right part of the dialog box, presented in Figure 3. The procedure is identical to the one to send a project, but not all the cases are sent, just the chosen one, and the context information associated with it, as explained before. The procedure to send an evaluation process is also almost identical to this, but it is necessary to choose different options. - Information sharing (Partilha de Informao) - The idea of this option is close to the previous one. In this option the information is not directly sent to a user or a group of users. It is sent to the central unit with permissions to other users. These users must perform some procedures to go to the central unit and to pick the information. The idea behind it, is that sometimes a user does not want or need to have in his/her workstation all the information that the others allow to share, but only some of it. With this option a user can choose to download only the information he/she wants, and the information is not pushed directly to his/her database. - Decision process (Processo de Deciso) - This option is for starting a decision process. It allows the definition and identification of the system users that are engaged in a particular decision process. The AGAP system can be installed in several work stations, but not all its users will be part of all the decision processes currently in progress. It is necessary to identify who belongs to each decision process. All the information that is generated in the scope of a decision process can only be accessed by users that belong to it (that is permissions can not be given to system users that are not identified as belonging to that decision process).

3. THE TESTS
The tests were based in a real problem that a textile production company faced two years ago. It was necessary to define and evaluate the enhancement of a production line. There were three mutually exclusive alternatives, prepared by the companys staff. The data, characterizing the projects and presented in Tables 1 and 2, were supplied by the staff. The scenario or macro economic context, presented in Table 3, was also from the staff. The decision group organized by the company had four decision makers, each one from each of the companys departments. Project 1 can be roughly described as an investment in new machines, that will allow the company to make new textile products. The company will make contracts with others in order to have the design of those products. Project 2 includes not only the investment on the new machines, but also on Computer Aided Design and other equipment allowing also the design of the new products. Finally, project 3 is like project one (just the industrial machines), but there is another company that will share the investment. In return, this last company will buy all the new products at a low pre-established price during the next three years.
0 P1 P2 P3 -62500 -81893 -10500 1 2040 6050 -12319 2 6603 15068 78159 3 19833 13864 -52462
3

4 23039 24583 -9505

5 57545 58819 3572

Table 1. Project cash-flows per year. (K Esc.) Table 1 presents the cash-flows of the different projects. These cash-flows were computed by subtracting the expected company cash-flow without the project from the expected company cash-flow with the project. The projects have five years of live, after that the equipment is obsolete and will be sold by its salvage value. Although it is the basis of all data, the company budget is not presented in this paper, due to the amount of data. Table 2 presents the project attributes prepared by the companys staff: - NPV is the net present value of the project, that is the present currency value of all the cash-flows discounted at the appropriate discount rate, r (The companys staff considered r=8%, where r is somehow a risk indicator). NPV is nowadays considered to be one of the best economic profitability measure. - PI is the profitability index, that is the quotient of the present value of the future cash-flows generated by the project and the initial investment.

Project 1 NPV (r=8%) PI (r=8%) IRR DPB (r=8%) ROAI Dependency Employment Quality Pollution Flexibility 16894 K3 Esc 1.27 14.58% 4.53 years 26.09% 0.265 7 Medium Good Good

Project 2 5735 K3 Esc. 1.07 9.93% 4.79 years 18.73% 0.007 12 Good Very Good Very Good

Project 3 -1099 K3 Esc 0.89 19.92% infinite -64.73% 0.275 15 Medium Good Medium

Table 2. Project attributes. - IRR is the internal rate of return, that is the discounted rate at which the NPV equals zero. - DPB is the discounted payback period, that is the elapsed time required for the accumulated discounted cash-flows to equal the initial investment amount. - ROAI is the return on average investment, that is the quotient between the average yearly accounting profit, which excludes depreciation, and the average book value. - Dependency is the average quotient between the costs of the tasks that are subcontracted to other companies and the selling revenues. It can be an indicator of the fragility of the company against market turbulence. - Employment indicates the number of new jobs generated by the project. - Quality is an estimate of the production quality. - Pollution indicates the environmental impact of the project. - Flexibility indicates the power of the company for changing their course of action in the following years. Table 3 presents the macro economic context, inputted in AGAP as scenario data. A good textbook of economic project analysis and evaluation, where further details about project financial attributes can be found, is [1]. 1 2 3 4 3.0 1.109 5 3.0 1.142

Inflation 4.5 4.0 3.5 Rate [%] Prices 1.000 1.040 1.076 Index Table 3. Macro economic indicators.

In the tests, there are 4 decision makers. All the four decision makers used in these tests are Computer Science Engineers, that were somehow engaged with the objectives of the AGAP system. The tests aim at ascertaining the adequacy of the system to support real decision makers engaged in a project analysis and evaluation decision process. They are lab tests, but also the first step to start field tests. Specifically, the objectives of the test decision group were: - to analyze the projects prepared by the staff, - to create new possibilities and to study them, - to reject the alternatives that were not considered good enough, and - to choose a set of criteria to rank the alternatives. Note that the selection of one alternative or their ranking is not an objective of the test group, but just to agree upon a set of relevant criteria.

The data of Table 1, Table 2 and 3, were input into one of the work stations and sent to the other three. The company budget was not input in the system, but the decision makers had access to it through a written report. In order to achieve the stated objectives the decision makers can use all the features of the AGAP system excluding the ones associated with the evaluation processes. These last features are directly connected to such activities as: to state the relevance of the criteria (not only saying that one criterion is relevant but also saying its relative amount of relevance), to choose a multiattribute aggregation method and to fix its parameters. These activities are out of the scope of the tests reported in this work.

4. THE TEST RESULTS AND DISCUSSION


The test decision process evolved during six days, including a weekend. Several discussions about the data prepared by the companys staff took place and several more alternatives were generated. The new alternatives were generated based on changes in the first three ones. We start this section by presenting the outputs of the group decision process and then we present a summary of the complaints of the decision makers.

Outputs
1) Project 3 was rejected by all the decision makers, due to its low NPV value. 2) A decision maker proposed to the group (after individual analysis with the system) a new case (version) of project one: case 1.1. This case was accepted by all. The idea behind the case 1.1 is to improve flexibility and dependency of project one, through purchasing another industrial machine. The NPV of case 1.1 is lower than the NPV of case 1.0, see Table 4. 3) Another decision maker proposed the usage of a different discount rate ( r ) in the analysis of project 2. The argument is that the risk of this project is lower than the risk of the company, because the company would start a new and less risky activity (the design of products). Note that r=8% is the discount rate usually used by the company, due to its cost of capital. This proposal was refused by the group. 4) During the discussion of the reasons to refuse project 3, another case (3.1) was created. The idea behind it is to stop the production, and to sell the machines, immediately after the contract with the other company is finished, that is to consider only three years of life and to incorporate in the cash-flow of the third year the expected selling value of the machines. Note that case 3.1 resulted from a group discussion and not from an individual analysis. This case was conditionally accepted by the group, due to the difficulty on forecast the machines value at the third year of life. If this value could be calculated, case 3.1 would be reconsidered by the decision group. Table 4 presents the data of case 3.1 considering an approximation of this value. 5) Table 4 also presents the criteria that the group considered important to rank the alternatives. These criteria resulted of a huge amount of communications among the group members, due to several new attributes that were proposed by the group members. Most of these new attributes were not accepted by the group. Just one new was accepted: Flex/Depend. This attribute resulted from the aggregation of the attributes Flexibility and Dependency. Case 1.1 NPV (r=8%) PI (r=8%) Flex/Depend 14617 K3 Esc 1.17 Very Good Case 3.1 11743 K3 Esc 1,11 Medium

Table 4. New projects according to the criteria. 6) The group considered the necessity of a pessimistic scenario in order to asses the worst results of the investments. This new scenario considered that the forecast of the amount of the selling would drop 5%.

Discussion:
It is almost pointless the discussion of the financial quality of the results, because the tests were done at the Lab and there is no reference. Nevertheless, we could notice that several alternatives were proposed and that lots of data interchanging and argumentation did exist. The transition from the individual work of the group members to the collective work and argumentation, and backwards, was very easy and simple. The group members were constantly shifting from one type of work to the other and, at the end, everybody knew exactly from who was each alternative or opinion. We believe that this is a

major advantage of using such a system. Moreover, the group decision process took 6 days, all the members did also other things in parallel, that is, each member did choose its more convenient time to be engaged in the decision process. Another issue did arise: the members of the group did not use very often the voting processes at their disposal. In fact, they almost always preferred to use message passing in order to come out with the collective outputs. The choice of the criteria was the only exception. They arrived to the conclusion that a voting process was necessary in order to decide upon the inclusion of one more criteria: NPV computed with a 5% drop in the sales revenues. The result was not to include that criterion. After that, the looser proposed another scenario with the same decline in sales. This scenario was accepted by the group.

Modification of the AGAP system


The decision makers complaints are gathered in two classes: changes on features already implemented and new features.

Changes on features:
Most of the changes can be classified as interface adjustments: - Default values are not properly chosen. - Automatic completion of data is difficult to use. - The copy and paste features work only locally, that is it is not possible to make copy and paste of large structures of data. - The usage procedures are incoherent, that is some of them are a little bit different from the others. - The help sub-system is not really helpful, because it does not include examples neither details on usage procedures; - The presentation of the data of the cases of a project does not properly account for the inheritance mechanism of information from the case 0 of the projects. In order to see all the data characterizing case 1.1, for instance, it is necessary to see the data of case 1.0 and the data of case 1.1. All the decision makers would prefer to see just the case 1.1 and the system would automatically join to that the relevant data of case 1.0. - A user must be connected to the central unit in order to send a communication (of any kind). The users would prefer to give the order to send even if not connected to the central unit. The connecting and sending problems should be automatically performed by the system.

New features:
1) A first observation about the AGAP system: the decision makers engaged in the tests complained about the lack of data translators. The companys staff supplied the data via files of a common spread sheet, and it was not possible to import it directly into the AGAP system. 2) Another feature or module that is not present in the system is a facility for visual comparison of the data from different cases of the same project or from different projects, with reports emphasizing the differences among them. This visual comparison should include graphic facilities as the ones nowadays found in common spreadsheets. 3) The decision makers complained about the lack of support to time series. That is, one can characterize the projects thorough several kinds of attributes, namely: deterministic, probabilistic distributions, range of values, etc. However, it is not possible to define an attribute as a time series of data. In order to input that kind of data it is necessary to define several attributes. 4) The users would like to have automatic acknowledges of the communications, that is some information about if the data (any kind) they sent were actually read or not. Moreover, they would like to know the date and hour of that activity. 5) The decision makers felt the necessity of open message passing channels directly connected to a case of a project. When creating a case, the system allows the users to add several comments and descriptions, that remain associated with that data. The problem is that the other decision makers that receive that case can only argue about it through the message passing facilities, or through creating a different case. The users would prefer that the messages concerning the arguing of a case could be organized and stored along with it. On visualizing the data of a case they could also see the messages and replies concerning it. This implies a major change of the philosophy of the AGAP system, that is to structure message channels and data analysis together. 6) The collective generation of a case of a project is supported by AGAP with a workflow like process (note that it is like a very flexible workflow). The users felt the necessity of having some support to collective generation of alternatives where everybody could write and read simultaneously, that is like 4 people sitting around a table and writing in the same sheet of paper with pens of different color. 7) The users found a lack of support for choosing an attribute to be a criterion. They would like to have support on defining the interactions and correlation among the attributes characterizing a project.

Some of these changes and new features are already being addressed, as an upgraded version of the system is being developed. All the interface simple issues are being adjusted and a deep research is being now undertaken in order to develop the features presented in point 6) and 7).

5. CONCLUSIONS
This work reports on several lab tests performed with the AGAP system. The AGAP is a group decision support system (GDSS) that was developed (at the Faculty of Economics of the University of Coimbra) as a distributed system allowing multiple decision makers to cooperate in order to evaluate and select investment projects. The tests were conducted (as a first step to start field tests) in order to ascertain the adequacy of the system to support a group process; specific task structuring activities (generating and structuring investment projects, that is the alternatives), both individually and in group; and several specific financial methods to evaluate investment projects. Specifically, the objectives of the decision group engaged in the tests were: - to analyze some projects prepared by other, - to create new possibilities and to study them, - to reject the alternatives that were not considered good enough, and - to choose a set of criteria to rank the alternatives. The test results were discussed and modifications on some functional modules of the AGAP system were proposed. Some of these changes are being addressed, as an upgraded version of the system is being developed. It was found that the most inadequate module is that deals with the support for the collective work on the same work area. Some interface issues were also identified as requiring redesign. It was also found the need to perform a deep research study concerning the module supporting the choice of the preferred criteria to evaluate the investment projects. The work presented here was partially supported by PRAXIS/PCSH/C/CEG/28/96.

6. REFERENCES
[1] R. Brealey and S. Myers, Principles of Corporate Finance, 4th Edition, McGraw-Hill, 1991. [2] J.P. Costa, P. Melo, P. Godinho and L. Dias, A Conceptual Description of the AGAP System: a GDSS for Project Analysis and Evaluation, Research Report, Management Science Series, N1/98, Faculty of Economics of the University of Coimbra, 1998. [3] J.P. Costa, P. Melo, P. Godinho and L. Dias, The Design of a GDSS for Project Analysis and Evaluation: the AGAP System, in ITI 98, Information Technology Interfaces, D. Kalpic and V. Dobric (Editors), 1998, pp 297-302. [4] A. Dennis, J. George, L. Jessup, J. Nunamaker and D. Vogel, Information Technology to Support Electronic Meeting, MIS Quarterly, December, 1988, pp 591-624. [5] G. DeSanctis and B. Gallupe, A Foundation for the Study of Group Decision Support Systems, Management Science, Vol. 23, N 5, May, 1987, pp 589-609. [6] B. Gavish, J. Gerdes Jr and S. Sridhar, CM3: a Distributed Group Decision Support System, IIE Transactions, Vol. 27, 1995, pp 722-733. [7] S. Hiltz and M. Turoff, Structuring Computer-Mediated Communications to Avoid Information Overload, Communications of the ACM, Vol. 28, N 7, July, 1985, pp 680-689. [8] T. Jelassi, G. Kersten and S. Zionts, An Introduction to Group Decision and Negotiation Support, in Readings in Multicriteria Decision Support, C. Bana e Costa (Editor), Springer Verlag, 1990. [9] G. Kersten, Support for Group Decisions and Negotiations - An Overview, in Multicriteria Analysis, J. Clmaco (Editor), Springer Verlag, 1997, pp 332-346. [10] J. McGrath and A. Hollingshead, Groups Interacting with Technology, Sage Library of Social Research Series, N 194, Sage Publications, London, 1994. [11] J. Nunamaker, A. Dennis, J. Valacich, D. Vogel and J. George, Electronic Meeting Systems to Support Group Work, Communications of the ACM, Vol. 7, 1991, pp 40-61. [12] E. Turban, Decision Support and Expert Systems - Management Support Systems, Prentice-Hall, 1995. [13] M. Turoff, S. Hiltz, A. Bahgat and A. Rana, Distributed Group Support Systems, MIS Quarterly, December, 1993, pp 399-417.

APPENDIX - GLOSSARY
A Enviar - To send A Realizar - To do Casos - Cases

Cenrio - Scenario Concludos - Concluded Descrio - Description Desempenho Caso - Cases Performance Elementos Bsicos - Basic Elements Enviadas - Sent Informao Disponvel - Available Information Intercmbio de Informao - Information Interchange Mensagens - Messages Nome - Name Para Enviar - To send Partilha de Informao - Information Sharing Processo de Deciso - Decision Process Processos de Votao - Voting Processes Projectos - Projects Recebidas - Received Resultados Finais - Final Results Sistema AGAP - AGAP System Votos Enviados - Sent Votes Utilizadores do Sistema AGAP - Users of the AGAP System

You might also like