Task Instance Changes

i.e. moving the transferred task to the to-do list in the local workspace of another user. Transfer is considered for cases when a user is no longer able to process a task and should be substituted with another user, who takes over the job in its current state. A transfer can be triggered to only one person at a time and only on root tasks or accepted tasks. The transferred sub-state can occur in combination with any of the other states and is not shown in Figure 4.4 for simplicity. A task is set in the transferred sub-state when a procedure for transferring the task to another user is triggered. The procedure may be collaborative or administrative. In collaborative transfer, the user that is currently responsible for the task, i.e. who has the task in their to-do list, triggers a transfer by sending a transfer request to another person as discussed further in this chapter. In administrative transfer, the task is reassigned by an administrator, who changes the task assignments on the server. Administrative transfer may be required if the person that is currently responsible for the task is not available for collaborative transfer. A transferred task is loaded from the server to the to-do list of the new assignee. All relationships to dependent collaborative tasks are updated for the new assignee and supported with notifications as discussed in Chapter 5.

When the transfer procedure is completed thetransferred sub-state is removed.

task instance change entity in the way that these are associated to the task instance (cf. Figure 4.2). Instead, only the identifiers of root and parent task instances are contained in the task change entity, whereas the full contents of the respective root and parent task instances can be recovered from their correspondingtask created changes. This recovery is necessary in order to capture the complete example of how a process was structured and managed even if some of the task instances have been removed from the task management system during or after process execution.

Such recovery is not considered in related task management models [GOR+07].

Task moved changes assign values to the: (i)root task identifier - if a task has been moved to another process, i.e. root task (cf. Section 4.4.1.1); (ii)parent task identifier – if the task instance has been moved to another parent task; (iii)index – if the index of the task in a parent task’s sub-tasks collection has changed.

Task removed changes assign values to the task identifier attribute. The place in the task hierarchy, from which the task has been removed, can be determined from previous task changes.

Task context changes refer to changes in the values of task attributes that are visible and used by end users for task management such as:name,description,start date,due date, priority, status andpercent complete, and task instance associations with artifacts (cf. Figure 4.2). Hence, task changes from thetask context change type receive values to all changed attributes of task instances, and references to one or more artifact changes where applicable.

identifier time type

root task identifier parent task identifier task identifier type index name description start date due date priority status

percent complete task instance change

Figure 4.5: Task instance change attributes 4.4.3 Exchange of Tasks and Deliverables

A significant body of research discusses that collaborative processes are influenced by the social nature of human work. [Win86] proposes a “language/action perspective” for designing cooperative work. This perspective is leveraged in [FGHW88] where organizational interaction is designed as a“network of negotiated commitments” based on speech acts. Further studies analyze offices as “systems of communicative action” and apply a speech act based approach for modeling office information systems [ALL88]. Such studies strongly support the use of speech act techniques for the exchange of tasks and deliverables in the context of collaborative task management. Speech acts are further seen as related events that “participate in larger conversational structures” [Win86]. Thus, for enabling email-integrated exchange of tasks and deliverables (R2), the runtime task management model utilizes two generic entities – messages and dialogs.

4.4.3.1 Messages

Messages are emails, which have generic types that pertain to basic speech acts. The actual discourse during message exchange takes place in the email text. This allows open-ended collaboration and prevents from submitting user behavior to strict speech act rules, which is a known limitation in speech acts’ adoption [But94]. Each message can have one or more associated artifacts (cf. Figure 4.2 and Section 4.6), which are included in the message as common attachments.

Messages are exchanged for the following collaborative operations: (i) task delegation, (ii) consolidation of operations that affect multiple collaborative tasks throughout a task delegation graph (e.g. task cancellation and completion), and (iii) collaborative transfer of a task to a different user. The various messages are discussed in the following whereas the complete collaborative handling for task delegation is discussed in Chapter 5.

4.4.3.1.1 Messages for Task Delegation

The messages for task delegation are:request, request negotiation, request acceptance, request declination, request termination, completion declaration, acceptance of completion declaration, and declination of completion declaration.

A task request message is sent for a given task in the personal to-do list of a system user. It is the first message in a “conversation for action” [Win86, FGHW88]. The request message receives a parent task association to the delegated task, andrequester and recipient associations respectively to the sender and the recipient of the request message (cf. Figure 4.2). If a request for task delegation is sent to multiple recipients, these are split so that a single (replicate) message is sent to each recipient individually. The split allows managing a separate dialog for each recipient as discussed further in this chapter.

Request acceptance and request declination are basic speech acts in a “conversation for action” [Win86, FGHW88]. Corresponding messages are known also from common functionalities in office tools, such as e.g. meeting requests in Microsoft Outlook. Request acceptance produces a task in a recipient’s to-do list. This task receives aparent mail association to the accepted request message (cf. Figure 4.2). This association points at the message, from which a task has resulted. This message can be also the last negotiation message for a given task request that is sent by the requester.

Request negotiation allows users to discuss and change the boundary conditions of a task assignment. Negotiation of task requests is considered also in related task management models [GOR+07].

Request termination is an additional message type, which allows the requester to explicitly declare that a request is no more relevant, i.e. to recipient(s) who have not accepted or declined that request yet. Request termination can result for example if during negotiation the requester decides that the request is not feasible and wants to inform the recipient(s) for that final decision.

Completion declarations are an additional aspect of the task management model presented in the thesis which is not discussed in related task management models [GOR+07]. Completion declarations consider that task requests are interpreted by the different users as having

“conditions of satisfaction” [Win86]. These conditions may be interpreted differently by the requester and the recipient of a task. The handling (send, accept, reject) of completion declarations enables consolidation of the requester’s and recipient’s satisfaction criteria.

All message types except a task request are considered asresponses to previous messages. For example, request acceptance/negotiation/declination is a response to the corresponding request message. Iterative negotiations can be triggered, where each negotiation message is a response to the previous negotiation message. If a request termination is triggered, the termination message is considered as arising in response to the issued request message. The completion declaration is as well considered as a response to the request acceptance message. The response relationship is

depicted through a self-reference in the message entity in Figure 4.2. The complete information about a requester, requester task, recipient and recipient task in a delegation can be retrieved over the message references. In the local workspace of end users this information is available and transferred between different messages through embedded message attributes as discussed in the method for composition of weakly-structured process models in Chapter 5.

4.4.3.1.2 Messages for Consolidation of Operations with Global Impact

The messages for consolidation of operations with global impact on collaborative tasks are:

<operation> request, <operation> request negotiation, <operation> request approval,

<operation> request declination, and<operation> request termination, where<operation> can be one of:cancellation,completion,suspension, or resumption. These operations are discussed in detail in the method for composition of weakly-structured process models in Section 5.1.5. The provided message types pertain to basic speech acts and have analogous semantics to the corresponding message types for task delegation.

Anoperation request receives aparent task association to the task on which the operation is initiated, andrequester and recipientassociations respectively to the sender and recipient of the message (cf. Figure 4.2). If an operation request is sent to multiple recipients, these are split analogously to task delegation requests. Recipients for an operation request are determined through the server by evaluating tasks that are affected by a given global operation as discussed in the method for composition of weakly-structured process models in Section 5.1.5. All other message types for a global operation are associated asresponses to the corresponding previous message (cf. Figure 4.2).

4.4.3.1.3 Messages for Collaborative Task Transfer

The messages for collaborative task transfer are: transfer request, transfer request negotiation, transfer request acceptance, transfer request declination, and transfer request termination. In contrast to delegations, task transfer does not require exchange of deliverables. The request handling in collaborative task transfer is analogous to that for task delegation. The target of the agreement is the complete transfer of a given task to a new assignee.

A transfer request receives aparent task association to the task for which the request is issued, arequester and arecipient association correspondingly to the sender and recipient of the message (cf. Figure 4.2). Recall that a transfer can be triggered to only one recipient at a time and only on root tasks or accepted tasks, thus no split of recipients is necessary. All message types other than transfer request are associated as responses to the corresponding previous transfer message (cf.

Figure 4.2). When the requester of the transfer receives an acceptance for their request, they can trigger the transfer of the respective task in their to-do list.

4.4.3.2 Dialogs

A dialog (cf. Figure 4.2) represents a “larger conversational structure” [Win86] which is composed of multiple speech acts (messages) related to the collaborative handling of a given task between onerequester and onerecipient. A dialog is always initiated through a request message, considering a request as the first speech act in a“conversation for action” [FGHW88]. A dialog is determined through the associatedparent task, andrecipient of the request. Recall that if a task request is issued to multiple recipients, these are split and an individual request is sent to each recipient. Thus a single dialog is maintained between the requester and each recipient of a request message. The dialogs for different collaborative operations are discussed briefly in the following.

A dialog for task delegation is initiated through atask request and comprises the request and all subsequent messages related to the handling of the request including request acceptance, declination, negotiation, and termination. The dialog further comprises the messages related to the completion declaration, i.e. to the exchange and consolidation of task deliverables.

A dialog for consolidation of an operation with global impact is initiated through an operation request message and comprises all subsequent messages related to the consolidation of this operation between the requester and a given recipient. The recipients for the request are determined based on the tasks that are affected by the operation as discussed in Section 5.1.5.

A dialog for collaborative task transfer is initiated with a transfer request message and comprises all transfer-related messages. Collaborative task transfer can be performed only to a single person, thus no split of recipients is considered in this collaborative operation.

Dialogs for different collaborative operations may coincide if the request messages that initiate them are associated to the sameparent task andrecipient. For example, a dialog for consolidation of a global operation may coincide with a dialog for task delegation if there is a task delegation request message with the same parent task and arecipient association as the operation request message. In that case a single dialog is maintained which encompasses the agreements on the exchange of the task and the deliverables and all agreements on intermediate operations affecting the collaborative task.

To sum up, messages and dialogs enable enhanced transparency in evolving ad-hoc processes (R3) by complementing the structural overview of task delegation graphs with overview of collaboration and agreements on tasks. This transparency can help to reduce the search effort for task-related emails [BDHS03], and facilitate ad-hoc task and process management in email-centric task management environments.

4.4.3.3 Awareness for Collaborative Tasks

A central concept in the introduced approach for end-user driven business process composition is to enable a gentle slope of complexity [MCLM90] by allowing end users to gradually extend their skills with conventional task management (to-do list) and collaboration (email) applications. The task management model addresses a gentle slope of complexity through providing information about the further handling of collaborative tasks in the local workspace of end users. This information enables users to view the status of delegated tasks from the local workspace without entering a proprietary process overview. Indications about further delegations or transfer of collaborative tasks can provide incentives to end users to enter the process overview in order to view how a delegated task has evolved further and what other stakeholders have been involved.

The local awareness for collaborative tasks is provided through therequester info andrecipient info entities of the task management model (cf. Figure 4.2).

Requester info entities are relevant for accepted tasks. These entities contain information about the task requester depicted through the respective user association in Figure 4.2. Through the requester info, a task recipient is able to see who has requested a given task. Indications of the overall status and completeness percents of a requested task may be further provided through appropriate attributes. Awareness entities are managed through notifications. Basic notifications are discussed in Chapter 5.

Recipient info entities are relevant for delegated tasks and are managed in the local workspace of a task requester. These entities contain information about the task recipients depicted through the respective user association in Figure 4.2. Recipient info entities support collaborative task handling through a recipient status for a delegated task, which is maintained for each recipient based on the current state of the task delegation dialog. Following the message types discussed in Section 4.4.3.1.1, the following recipient statuses are considered for task instances:requested, request accepted, request negotiated, request declined, request terminated, completeness declared, completeness approved, completeness declined. The recipient statuses help a requester to get a quick overview of the collaborative status of tasks, without leaving the personal workspace. It is further possible to embed recipient’s task information such as percent complete and task status in the recipient info. Thereby a status that indicates further delegation (i.e. waiting for someone else) may provide incentives to the requester to enter the process overview in order to follow how the process has evolved further.

4.4.3.4 Guidance for Task Delegation

Suggested recipients associations for task instances (cf. Figure 4.2) are inherited from task patterns after reuse. These recipients are automatically suggested if a delegation for the given task instance is triggered. Extraction, adaptation and reuse of task patterns are discussed in Chapter 5.

Here it is important to stress that suggested recipients recommend expertise but do not point at persons that actually participate in the process. The suggested recipients can be involved in the process through explicitly sending task requests.