The problem of understanding and improving the decision making process, through the use of technology, has been broadly investigated over the last decades. An expressive number of tools was created to support the different phases of the decision making cycle (e.g. before decisions are made, at the moment they are made). Tools vary according to domains (e.g. financial, medical) and to technological approaches, including the so called DSS (decision support systems), EIS (executive information system), ES (expert system), DW (datawarehouse), among others.
The CSCW (computer-supported cooperative work) perspective brought also additional contributions with the use of Group Decision Support Systems. This approach brought a different viewpoint, i.e. being more focused on the process of group decision making by removing common communication barriers, providing techniques for structuring decision analysis, and systematically directing the pattern, timing, or content of discussion [4].
Still inside of the domain of decisions, very little has been done regarding the process that takes place after a decision is made, also know as decision follow-up, or post-decision consolidation [5] or enactment of decisions [1]. One simple explanation for this fact concerns the difficulty in creating a tool, which can be applied to all ranges of post-decision situations.
One possibility to tackle with this problem is to look only at decisions made in meetings and how to use the natural way people communicate electronically and execute their activities to provide follow-ups to decisions made. Some of our previous work dealt with this problem through the use of workflow management systems [3] and through the content analysis of emails [6]. This paper focuses on a different ap-proach that is based on the idea of creating follow-up to decisions based on the tasks related to them.
Decision meetings are not isolated events. They are part of a continuous cycle of premeeting, meeting and post-meeting activities [3]. The meeting itself is considered to be the most important part of this cycle, but the other components are complementary. Making premeeting and post-meeting activities explicit may be the first step to enhance the whole cycle and thus, to obtain better decisions as a final result. The three phases can be considered equally important, since they deal with different aspects of a decision. Nevertheless, only few tools have being proposed to support premeetings and post-meeting phases. Besides that, one needs to record or analyse the activities realized by decision implementers after a meeting is finished, in order to obtain decision follow-up. The second big problem we observe, then, is the lack of traceability of activities related to decisions in an automatic way. Creating a new tool only for providing such support would probably not compensate for the users efforts.
Through informal observations in various projects, we could notice that meeting minutes often contain outcomes in the form of decisions and assigned tasks -however, there is no linkage between an assigned task and the actual fulfillment of the task. Moreover, sometimes the information is "there" (i.e. in the minutes), but in a much unstructured way, difficult to be analyzed by any automated mechanism. An initial attempt at post meeting support can be a report which allows meeting outcomes to be displayed, as well as a means for the actor involved to update the status of the task. Such an implementation provides the users with the ability to track each task to its current status, and provides accountability and closure to assigned tasks.
Our decision follow-up mechanism is related to post-meeting activities; however our proposal encompasses support for the three meeting phases, since we believe they are interconnected. In the pre-meeting phase users can define, collaboratively, the organization of a meeting and the topics to be inserted in the agenda. During the meeting our system supports the elaboration of meeting minutes and its dissemination to the attendees and related people. And for the post-meeting time, our system considers collaborative review of items defined in meeting minutes, and task management support.
The agenda module is following a classical approach of defining organizational data regarding the meeting, like location, automatic invitations and notifications, and the definition of issues to be discussed during the meeting. Invited people can start collaborating, inserting or changing issues to be discussed in a collaborative way.
Then, during the meeting, a person responsible to take notes (scribe) will list each "issue" discussed in a meeting, one or more "decisions" that are associated to it, and for each "decision" one or more "tasks" that are associated it, defining a high level of granularity (short description, responsible, deadline). Thus, the set of tasks related to a specific decision is defined during the meetings' dynamics or in a review process that takes place after the meeting. Tasks, in our context, are assignments, logics unit of work, or simply atomic processes.
Finally, during the post-meeting activities, the system is supporting users in reviewing the minutes, adding missing points, changing details that affect the implementation of task, negotiating further practical consequences. The review of meetings is similar to the review of agenda items. Users can review issues, decisions, and mainly tasks, but any change is recorded so that the historical data is not lost and elements can be easily traced.
The link between decisions and tasks is made during the meeting minutes documentation process and keeps on going during the execution and change of each task status by each assigned user. The tasks can have their status changed between: started, accepted, declined, cancelled, postponed, reproposed, completed and withdrawed.
Each change on a task can represent a follow-up for a decision, if the task is hooked to a decision. Since the system also allows for creating personal tasks without being related to any decision.
At any moment, a user with the adequate access rights (e.g. a project manager or the task involved people) is able to request a decision follow-up report from the system, which provides a summarized view of what has occurred since the decision was made, how the tasks evolved till then. The user receives a simple summary, with the most recent status of each task, but has the possibility of checking all the details of tasks evolutions. We realize that through versioning tasks changes.
The system is implemented as an extension of the document management system BSCW [2] and includes two main modules:
Meeting support package: with agenda, meeting minutes, notification support. This module communicates with the Task Management module in order to make the link between decisions and tasks feasible. Task Management package: contains all basic task management features, plus the possibility to be automatically linked to meeting outcomes. Both are implemented in Python, just following the BSCW standard.
One of the most interesting aspects of this proposal is to use the opportunities of daily activities of task management, common to many users, in order to provide a follow-up for decisions, not creating an extra tool or an extra effort from the user's perspective.
Although we did not execute any formal evaluation until this moment, 8 interviews (4 professors and 4 project managers) were done in the early phases of the project in order to validate the ideas here described.
We are currently working at implementation improvements on the BSCW package and user interface, and we aim at realizing formal evaluations in April.
We are sure that this proposal will not be the solution for all problems concerning decision follow-up, but we expect that it brings some contribution to this problem. We are aware we are not dealing with a solution for all problems, and we can already predict some of them. For instance, the restrictions of using BSCW for supporting meeting activities, since this system is based on asynchronous interaction. In order to deal with this restriction, in particular, we plan to develop some modules to allow for offline work (e.g. agenda and minutes elaboration offline) with late upload to the document management system, where the system will parse automatically the content of the offline created document, creating the corresponding elements (e.g. issue,
decision, tasks), assigning tasks to the right users and notifying users of the system changes. This will be realized using a simple document following a structured form.