A task-based modeling method for process modeling

and automation in project management

Jingmin Wang, Xin Liu

Department of Economy and Management
North China Electric Power University
BaoDing, Hebei province, China, 071003
China_liuxin@163.com

Abstract—By introducing “best practices” as standard process
models, business process standardization and reengineering have
assisted in achieving the efficiency of the project development.
However, they have also resulted in many problems because a
standard model has limited flexibility to suit different practices of
different projects. This paper presents a Task-Based Modeling
method (TBM) for modeling processes in project management.
Key business tasks are defined as the basic task components.
Supplementing each task with an execution method and detailed
attributes, its action can be fully defined and its outcome can be
measured. A business process model can then be created to meet
the need of the particular business by using the task components
as the basic building blocks. A request-driven approach is also
proposed to instantiate an instance of a process model. A
purchasing process is used as an example to illustrate the
presented methodology.
Keywords-Process automation; Project management;
Workflow; Task-based modeling;
conveniently customize the standard process models and to
efficiently construct its own business process models.
Business process automation demands not only
advancement in computer and software engineering
technologies, but also parallel matching methods in
management science [4]. This paper presents a Task-Based
Modeling (TBM) method for modeling project management
business processes. The basic idea is to define common
management tasks as the basic reusable software components.
In order that a task component can be connected with other
needed task components to formulate a process model, its
function and corresponding data structure must be defined.
Accordingly, constructing a business process model can be
accomplished by selecting and connecting relevant reusable
task components. After a process model is constructed, an
existing workflow management system can be used to execute
the model.

I. INTRODUCTION II. THE TASK-BASED MODELING METHOD (TBM)

Business processes are widely regarded as an important
building block in today’s project management [1]. Business
processes may deal with customers, business partners, and
different departments across the entire project. Executing a
process consumes time and resources. Automating business
processes has been recognized as an effective approach for
improving project efficiency and productivity by reducing the
time and resources [2].
Business process automation today is mainly achieved
through process standardization and reengineering. Many
business processes can be reengineered with the industry-wide
“best practices”. In the mean time, many researchers and
practitioners have argued that reengineered business processes,
especially with dramatic changes from previous ones, represent
the major barriers that have slowed down the adoption of
Workflow technologies and some implementations were even
abandoned due to strong rejections from the employees.
Moreover, it has proven to be time consuming and expensive to
customize the standard processes [3]. The project management
is characterized by many non-standard practices. To further
promote and advance business automation and Workflow
technologies in project management, corresponding
technologies must be developed to enable the end user to
Due to non-standardization, different processes may be
used by different users to accomplish similar or same business
objective. An examination of the different processes indicates
that many common management tasks are used in these
processes. For instance, a purchasing process may vary from
project to project, but it always requires the following common
tasks: search for qualified suppliers, request for price
quotations, evaluate the received quotations, and place a
purchase order. Therefore, instead of trying to standardize a
business process, TBM intends to focus on standardizing lower
level management tasks [5].
To enable reusability, a task must be developed as an
atomic software component with the characteristics of
independency, encapsulation, completeness, and consistency.
In general, modeling a business process with standard task
components requires the following issues to be addressed: 1)
How to define a task as a generic atomic component so that a
business manager can understand it and use it for constructing
business process models? 2) What is the data structure for the
task component to carry specific management information and
to communicate with other task components in the same
process model? 3) How to measure the outcome of a task

978-1-4244-2108-4/08/$25.00 © 2008 IEEE 1

component? and 4) How to create a business process model by
using the provided task components?
A. Defining a management task
Despite different functions and complexities, a the indirect object of the action if applicable. “What” is always
management task has the following common features:
• Action — It takes an action (or a series of related
actions) to execute the task.
• Method — It may be conducted with certain methods.
• Object — The action may work on an object that
affects the means of executing the task.
1) The action of a task
The action to be taken by a project management task can be
best characterized by a “verb”. “Send the meeting information
to the participant list”, for instance, is an action defined by the
verb “send”. Verbs are the key words for performing daily
business functions. As one works in an environment, he/she
has learned how to react to these verbs according to the project-
wide or department-wide practice.
To use TBM, it is necessary to identify the key “verbs” that
are essential for the given business. Each task must then be
developed as an atomic and reusable software component.
2) The method of an action
There are sometimes multiple means to perform the action
of a verb. Therefore, an execution method should be given to
define how to perform the task according to the specific need.
For instance, sending a meeting schedule may be performed
with the following methods: internal memo, regular mail, e-
mail, facsimile, or telephone. To specify how to execute a
“send” action, a method must be given. In general, a verb can
be supplemented with a method.
3) The object of an action
A transitive verb in the English language has a direct object
to act on, and the type of the object may affect how the action
should be performed. For instance, “estimate an activity cost”
and “estimate activity duration” require two different methods
to execute “estimate”. In this case, the object can join the verb
to define the action method. Sometimes, either a method or an
object may define the means of executing a task. Sometimes, a
verb may need both an object and a method to fully define how
to execute it.
We can define a task as shown in Syntax 1(shorten as
Syn.1).
Verb_Object_Method Syn.1
B. Detailing A Management Task
Syn.1 describes how to execute the action, but does not
detail what to do. To fully execute a management task, it must
be associated with specific information to detail its action in
the given process. In general, the information for detailing a
task can be structured into two parts: “What” and “WhatElse”
respectively. Attaching the information to Syn.1, completed
task syntax becomes:
978-1-4244-2108-4/08/$25.00 © 2008 IEEE
Verb_Object_Method [What, WhatElse] Syn.2
“What” is used to detail the direct object of the action; and
“WhatElse” is used to provide further information for detailing
necessary for any action, but “WhatElse” may be optional.
With differently associated “What” and “WhatElse”
information, the same task can perform different actions in
different business processes. Therefore, component reusability
is accomplished.
The “What” and “WhatElse” data of a task fully detail what
to do in the action while its corresponding business process is
under execution.
In addition to detail the action of a task, “What” and
“WhatElse” also facilitate data exchange and information
sharing between tasks in the same process. Process level
variables are used in “What” and “WhatElse” so that they can
match with the variables of the process and the tasks in the
process.
III. MODELING BUSINESS PROCESSES USING ATOMIC T ASK
COMPONENTS
A number of task components, including both tasks that are
common across different businesses and tasks that are project
specific only, must be developed in order to model various
business processes for a given project management. For ease of
use, the task components can be grouped according to the
classification of their business functions, such as general office,
accounting, time management, equipment management, etc.
The entire developed task components should be implemented
in a component library, which will provide the basic building
blocks for constructing process models.
A process model is constructed at the design stage. Using
TBM to create a process model for a given business process
involves selecting needed task components from the library and
connecting them in the right logical sequence. Although each
task is developed as an independent component, all of the task
components in a process model must share information with
each other and work together in order to achieve the objective
of the process. To do so, process-level variables must be
declared and be used in all related tasks in the same process.
When a task is added to a model, its “What” and “WhatElse”
compositions are assigned with relevant process-level
variables. These variables will retrieve their values during the
process execution.
On the other hand, a process model describes a general
procedure of performing a type of concerned business process.
It can be repeatedly used for similar business functions.
Executing a particular process corresponds to instantiating an
instance of the process model at the runtime stage when the
model is called into execution. Therefore, a process model
must be general and flexible enough to accommodate all
intended usage. If necessary, a variation of different models
may be created to meet different needs for the same function.
2
 IV. EXECUTING A BUSINESS PROCESS MODEL
A management process is driven by a request, which is a
question, a problem, or a need. When a management request is
raised, a management process must be performed in order to
accomplish the request or to find a solution for the question. In
general, executing a business process involves the following
steps: 1) raise a request; 2) instantiate an instance of a process
model; and 3) execute the model task by task, and trace the
dynamic status of the model.
A. Raise a request
A request is the starting point of a business process. It also
comes with background information for the request. Raising a
management request can be best served with a custom-request
form, which is similar to conventional administrative
request/order forms such as purchase order and travel request.
The form provides blank fields to be filled out by the requester.
A request must be associated with at least one process
model. If it is associated with multiple models, one model must
be selected in order to fulfill the request. The selection may be
accomplished through one of the two approaches: 1) An
intelligent module can select the most suitable model for a
request; and 2) The requester may decide which model to use
based on the need of each particular request. A simple scenario
is to associate each request form with one process model.
A number of request forms must be designed according to
the practice of a particular industry or an enterprise. The forms
may be organized according to business functions so that end
users can easily find their needed forms to raise their requests.
The active instance of a model is fully traced until its
completion or the request is accomplished. To trace
management responsibilities, the start time, finish time, and
change of status of the model are recorded along the process's
execution. A workflow engine provides such needed facilities.
V. PURCHASING EXAMPLE
Purchasing is a common business process. It usually starts
with a purchase order by a requester. The purchase order is
then processed by a purchase officer. This example is used to
illustrate the above presented methodology.
A. The purchase request form
A project manager may initiate a purchase request for a
project. The request form is filled out by the requester with
specific information. Raising the request will drive a
management process to start.
B. The process model
Although the process for handling this request may vary
from company to company, a process model is shown in Fig. 1
as an example. In this process model, there are eight different
task components as follows:
Quotation not required
1. Select auto
Quotation required
2. Search_database (for qualified suppliers)

B. Instantiate an instance of a process model 5. Search_manual Supplier not found

(for qualified
After a request is officially raised, an instance of the suppliers)
selected process model will be instantiated. The instance 3. Select auto
representing the expected business process will be added to the Supplier found
pool of the active processes in the Workflow Management
6. Update_database 4. Send_email (to selected supplier)
System (WfMS). When a new instance is added, a unique ID
(supplier database)
will be assigned, and system resources will be allocated to run
the model instance and to trace its status.
7. Rank (received quotations)

C. Execute a process model

Executing a business process model requires a workflow 8. Send_email (to the requester)
engine. Several commercial workflow engines are available in
the market. An engine manages all active process instances and
executes the model task by task by following the logical 9. Decide_quote (by requester)
sequence as given in the process model. Executing a task
component also requires instantiating an instance of the task
Quotation not selected
object. Before starting a task, the process information must be
passed to it; and after completing the task, the obtained results 10. Select auto
must be returned to the process to serve as inputs to other tasks Quotation selected
in the model.
11. Place_order (by the purchasing officer)
Executing a process model may involve multiple users at
different computers in different departments. Therefore, the
engine must be deployed to work in the internet environment, 12. Update_database (order database)
in which clients and servers can communicate with each other
and the process model can be executed in a distributed Figure 1. A purchasing process model
platform.

978-1-4244-2108-4/08/$25.00 © 2008 IEEE 3

 • Select_auto — an automated task. It selects one process variables: Product, Quantity, RequiredDate,
succeeding route from given options; ResponseDate, and ContactPerson to form a message which is
sent to “WhatElse”: QuaSuppliers. Ranked Quotations are
• Search_database — an automated task. It searches obtained from executing Task 7 so that the requester can make
records from a given database; his decision at Task 9 based on the ranking. “Suppliers” is the
• Search_manual — a manual task. It involves a manual directory and database name where the supplier information is
process to search for a list of qualified items; stored. Returned Quotations is entered by the purchase officer
when Task 7 is executed after receiving the quotations from
• Send_email — an automated task. It sends an email suppliers. SelQuotation is the returned value from executing
with given content to the specified recipients; semi-automated Task 9. Finally, the new order is added to the
order management database, named Orders.
• Rank — a semi-automated task. It requires a
responsible person to manually rank a given list of Executing the model starts with task 1 until the last task is
items in an order; executed. Its dynamic status must be fully traced during the
process.
• Decide_quote — a semi-automated task. It requires a
manager to make a decision on selecting a quotation;
VI. CONCLUSION
• Place_order — a manual task. It requires a manager to
This article presented a task-based modeling methodology
place a purchase order;
(TBM) for modeling construction business processes. TBM
• Update_database — an automated task. It updates a defines key verbs in business processes as the basic task
database with new records. components. Supplementing a verb with a performing method
and detailed information, its action can be fully defines and its
A total of 12 tasks are used to construct the process model outcome can be measured. Using the task components as the
as shown in Fig.1.The “What” and “WhatElse” compositions basic modeling elements, a business process model can be
of the 12 tasks are summarized in Table.1. The last column of created by connecting the needed tasks. On the other hand,
Table.1 describes the expected action of each task in the model. kicking-off a business process is initiated by raising a request.
The request then drives a corresponding process model to be
TABLE I. TASK INFORMATION AND ACTIONS executed. A purchasing example was used to illustrate the
presented methodology.
Task
Code Action Description of action TBM presents a more practical and flexible method for
1 Select_auto Select a route based on whether or not modeling and automating project management business
quotations are required processes in comparison to the “best practices” approach.
2 Search_database Search the supplier database for qualified Considering the reality that the project management is
suppliers characterized by nonstandard practices, promoting “best
3 Select_auto Select a route based on whether or not practices” as a means to accomplish business process
qualified suppliers are found automation has faced a lot of resistance and hurdles. Instead, if
4 Send_email Send a message “Request for quotations” to we can focus our effort on identifying key management tasks
the qualified suppliers and developing corresponding reusable software components
5 Search_manual The purchase officer finds new suppliers and for these tasks, various process models can be easily and
enters them to the system
6 Update_database Update the database with new suppliers
effectively created to meet the need of a particular user by
7 Rank The purchase officer ranks the returned reusing the available task components. In summary, TBM
quotations provides a solution for project management business process
8 Send_email The ranked quotations are sent to the modeling and automation.
requester
9 Decide The requester makes a decision on the
acceptance of a quotation REFERENCES
10 Select_auto Select a route based on whether or not the
requester accepts a quotation [1] White D, Fortune K. Current practice in project management – an
11 Place_order The purchase officer places an order empirical study. Int J Project Manage 2002;20(1):7.
[2] A. Fitzgerald, Enterprise resource planning (ERP) – breakthrough or
12 Update_database Update the order database buzzword? Third International Conference on Factory 2000,
Competitive Performance Through Advanced Technology, Conf. Publ.,
vol. 359, IEEE, U.K, Jul. 1992, pp. 291–297.
C. Executing the model
[3] F. Leymann, D. Roller, Workflow-based applications, IBM Systems
After an instance of the model is instantiated, some process Journal 36 (1) (1997).
variables can retrieve their values from the request form. Other [4] D. Georgakopoulos, M.F. Hornick, F. Manola, Customising transaction
process variables will get their values from executing the models and mechanisims in a programmable environment supporting
function-type tasks. QuaSuppliers is returned with a list of reliable workflow automation, IEEE Transactions on Knowledge and
suppliers from Task 2 so that Task 4 can send a request for Data Engineering 8 (4) (1996) 630–649..
quotation to QuaSuppliers. The “What” part of task 4 is [5] C. Ellis, J. Wainer, A conceptual model of groupware, Proceedings of
the Conference on Computer Supported Cooperative Work, ACM, New
combined by adding a string “Request for quotation” to the York, 1994, pp. 79–87.

978-1-4244-2108-4/08/$25.00 © 2008 IEEE 4