An Integrated Project Management

Information System
Fredrick von Schoultz
Åbo Akademi University, Department of Computer Science
Lemminkäisenkatu 14, FIN-20520 Turku, Finland
e-mail: fschoult@abo.fi

Uwe Malzahn, Ralf Schulz

Universität Leipzig, Institut für Wirtschaftsinformatik
Marscherstraße 31, 04109 Leipzig, Germany
e-mail: schulz@wifa.uni-leipzig.de

Turku Centre for Computer Science

Technical Report No 33
June 1996

ISBN 951-650-801-4
ISSN 1239-1891
 Abstract
In industry, business has been organized and conducted in projects for a long time. Project
management is regarded as one solution to the challenges of modern business world like
accelerated product life cycles, customer-individual production and services, complex
processes and high time and cost pressure.
Although many project management tasks are supported by computer systems a lack of
integration among the systems is obvious. There is a need of integration with respect to
function and data exchange. The intention of this paper is to introduce a concept of an inte-
grated project management information system (IPMS). The IPMS provides computer
support for a composed set of project management functions and uniform data access. In
addition, it contains three new components filling certain gaps in today’s support environ-
ment: a communication and progress control tool, a tool for building new project plans and
a simulation tool for schedule analysis.
1. Introduction
In industry, business has been organized and conducted in projects for a long time. Project
management is regarded as one solution to the challenges of modern business world like
accelerated product life cycles, customer-individual production and services, complex
processes and high time and cost pressure.
Professional project management embraces a whole set of managerial tasks. Essential
project management functions are the management of scope, quality, time, cost, human
resources, contract, procurement and information. [PMI87] Existing computer systems
support a number of project management tasks. The most important group of project man-
agement software are systems based on network planning. [Dwo92] They provide schedul-
ing, cost and resource planning. Another group of project management software supports
specific tasks like risk assessment and cost estimation. The third group are general purpose
tools for text processing, charting, data administration etc.
Although many project management tasks are supported by computer systems a lack of
integration among the systems is obvious. There is a need of integration with respect to
function and data exchange. The intention of this paper is to introduce a concept of an inte-
grated project management information system (IPMS). The IPMS provides computer
support for a composed set of project management functions and uniform data access. In
addition, it contains three new components filling certain gaps in today’s support environ-
ment: a communication and progress control tool, a tool for building new project plans and
a simulation tool for schedule analysis.
The work presented has been done within The Intelligent Project Management Systems
Research Group1 of the Department of Computer Science at Åbo Akademi University and
Institut für Wirtschaftsinformatik at Universität Leipzig in cooperation with Wärtsilä Die-
sel Oy2 and the Department of Computing Science at Umeå University.

2. Functional model of IPMS

The functional model of IPMS contains all main project management functions supported
by software. The system components are logical entities independent of a particular imple-
mentation. A model of the implementation may differ from the functional model, e.g.
when a software package covers two functional components. The model consists of three
layers. The users form the first layer the of the IPMS. The second layer comprises the
applications the users interact with, and the third layer the project database as well as the
data base access tool. A diagram of the functional model can be seen in Figure 1.
In the following sections, the components are described in more detail. At first, compo-
nents which are quite common in existing project management systems are briefly charac-
terized, then some innovative components are introduced in section 3.

1. The Intelligent Project Management Systems Research Group at Åbo Akademi Univer-
sity participates within the SuperVision project in the Finnish national technology pro-
gramme PRODEAL on Development on Process Plant Realization, 1992-95. The
Federation of Finnish Metal, Engineering and Electrotechnical Industries (FIMET) and
Technology Development Centre (TEKES) are responsible for the coordination of the
programme. Funding for the project has been obtained from TEKES.
2. Funding for the project has been obtained from Wärtsilä Diesel Oy, Diesel Power Plants.

1
 1 2
project 1-2 subcon-
managers tractors

1-7
1-3
1-6
2-7
1-SF 1-5
1-4

SF 3 4 5 6 7
specific plan simulation planning reporting communication and
function tools builder tool tool tool progress control tool

SF-8 3-8 4-8 5-8 6-8 7-8

8
data base
access tool

8-9

9.1 9.2
data base case base

Figure 1. Functional model of an integrated project management information system.

2.1. Short description of existing components

Specific functional software
Specific functional software provides decision support for:
• estimating cost or work, e. g. function point method
• globally simulating project completion and cost (scenario), e. g. impact of uncertain
factors
• assessing risks
• managing project bids and contracts
Despite the low importance of specific functional software for the IPMS, this component
is included for comprehensiveness. The use of specific functional software mainly pre-
cedes the phase where the project plan is built and it does not base on work breakdown
structure (WBS) or project network (see section Project plans in Chapter 3.1.). Therefore,
data exchange between specific functional software and the other components of the func-
tional model is very unlikely and no recommendations for implemention of special func-
tional software in the model are given. However, some specific functional software works

2
on the basis of the project breakdown structure that is stored in the database of the IPMS.
For these tools the recomendations for integration given in Chapter 4 apply as for the other
components.
Planning tool
The planning tool is used to refine and administrate the project plan. Project plans are
stored in the database and are later updated as the project progresses. A project plan
includes project structure and hierarchy, schedule and sequential relationships (flows)
between tasks, resource assignment and workload and budget/cost. More details about
project plans are given in Chapter 3.1.
All project data may be stored in distinguished states, as planned, reviewed, actual etc.,
and in different plan versions.
The buyer of a planning tool can choose from a diversity of products that meet the basic
functionality. Software for project planning differs considerably in functionality and avail-
ability for operating systems and hardware environments. One can roughly distinguish two
main groups of planning tools, single-user and multiple-user tools. The first group (e. g.
MS-Project from Microsoft Corp., SuperProject from Computer Associates, PMW from
Hoskyns Group) is characterised by the following marks:
• Single-user system
• Limited functionality, especially for multi-project planning, resource planning and
cost tracking
• Storage of project data as files, inflexible file structure
The second group (e. g. Project/2 Series X from PSDI, Schedule Publisher from Artemis,
Projekt System from SAP) is characterised by:
• Multiple-user system, client-server (today’s standard) or mainframe (becomes obso-
lete)
• Rich functionality, several (optional) modules to add special functionality
• Storage of project data in relational data bases, flexible data structure
• Additional functionality for system administration and adaptation: administration of
user roles and data access rights, dialog editors, programming environment etc.
Not all planning tools can be subsumed under the two groups. Primavera Project Planner,
for example, has some multi-user features, can be extended with modules for risk analysis,
contract control and performance measurement, but still store data in file format. However,
the two groups of software for project planning represent the two main implementation
strategies for planning tools.
Reporting tool
The task of the reporting tool is to present data on output media. This function is tightly
linked to the function of database access (component 8), since the data has to be retrieved,
analysed and preprocessed prior presentation.
Forms of project reports are:
• Charts
• Organizational chart (resource structure and hierarchy)
• WBS (project structure and hierarchy)
• Network (sequential relationships (flow) between tasks)
• Gantt chart (task schedules along the timeline)

3
 • Milestone trend chart (actual or planned milestone dates at reporting dates)
• Resource chart (workload vs. time)
• Cost chart (budget/cost vs. time)
• Other charts
• Tables, e. g. time plan
• Text, e. g. task descriptions
• Audio and video (multimedia)
• Combinations of the forms named above
There are many software packages on the market for report generation, but a tool that can
handle all project-specific and non-specific report formats (s. component description) is
hardly to be found. The solution will be a combination of the retrieval functions of the
database access tool, the project-specific report functions of the planning tool and the
functions of a general-purpose graphical tool.
Any software for project planning provides at least sufficient features to get out project-
specific reports like WBS or workload diagrams. Their shortcomings are limited capabili-
ties to present data that is not included in the internal data model of the software, e. g. cer-
tain cost data, and to get out various general-purpose diagrams.
General graphical tools like presentation software or spreadsheets are often not capable to
generate project-specific diagrams. The software Graneda from Netronic constitutes an
exception. It is a special tool for generating project-graphics.
Reporting tools couple the functions of data retrieval, data manipulation and general data
presentation. If such a tool will be used it should be considered to choose a product that
can also serve as database access tool (component 8).
Database access tool
The database access tool provides a common interface to the databases for all components
of the second layer of the functional model. In addition, the database access tool is used
for administration and maintenance of the data stock and retrieval and preprocessing of
reporting data. It should provide features for data retrieval, data modification and data gen-
eration.
Relations among the components
The relations between the project managers (or subcontractors respectively) and the appli-
cations (1-SF, 1-3, 1-4, 1-5, 1-6, 1-7, 2-7) denote information flow in the man-machine
interface. Relation 1-2 expresses direct communication among managers and subcontrac-
tors, e.g. via telephone.
The relations between the database access tool and the application components (SF-8, 3-8,
4-8, 5-8, 6-8, 7-8) as well as between the data base access tool and the database / casebase
represent data flows. There are several ways to implement these dataflows, a short over-
view of some possible techniques is given in Chapter 4.

3. Description of innovative components

In this chapter the three new components, a plan builder, a communication and progress
management tool and finally a simulation tool for project scheduling are presented.

4
3.1. Plan builder
Project plans
To come up with a project plan represents an essential part of project management. A
project plan includes scope, time, budget, resources, risk, etc. Computer-based project
plans contain the following components:
• Work break-down structure (WBS): The project is decomposed into a hierarchy
of activities. It serves as a basic documentation for project coordination, risk analy-
sis, cost estimation, project monitoring, as well as a complete specification of the
services for the orderers. The WBS can be constructed according to the structure of
the product to be delivered, or according to the activities to be carried out.
• Network plan: The network plan serves to estimate the total duration of the project
and to control the progress of a running project. It contains a model of the project’s
activities with respect to time: The predecessor-successor relationships among the
activities are specified using some network plan techniques, e.g. CPM, MPM,
PERT. The network plan may be constructed for any level of activities in the WBS,
but for detailed planning it is useful to define it for the activity nodes in the WBS
hierarchy.
Furthermore, the following data can be included in the plan:
• Cost: budget of the project,
• Resources: e.g. personnel, appliances, material,
• Responsibilities: project managers, steering committee, subcontractors,
• Other project information, like risk, informal project description etc.
Case-based reasoning
When a new project has to be planned, the respective project manager has to create a basic
or initial project plan. Often there have been projects in the past similar to the current one.
It would be useful to reuse the project plans from those former projects at least partially in
the current situation. The plan builder is an IPMS component that aims to assist the project
manager in this task. We suggest case-based reasoning (CBR) to support this process. In
comparison with rule-based systems, another knowledge-based solution [Cur92], [Hos92],
CBR does not require acquisition and maintenance of explicit rules for project plan gener-
ation.
CBR is an approach of problem solving within AI that has recently attracted much atten-
tion [Aamo95],[Kolo93]. Its basic idea is to reuse specific knowledge from former prob-
lem solving episodes (cases) in the context of the current problem. In particular, the
solution of a previous problem is transferred to the new situation. This approach is based
upon the plausible assumption that similar problems lead to similar solutions.
Cases are stored in a casebase. Each case consists at least of a problem description and a
solution. Further documentation of the solution or the way of solving the problem may be
added. In the context of creating a project plan, it seems to be natural at first sight to define
a project represented by its corresponding project plan as a case. However, considering
more elaborate aspects, certain parts of project plans can be defined as cases. We will
assume for the moment that a project as a whole is regarded as a case.
With respect to planning a new project, the process of case-based reasoning consists of the
following basic steps [Alle94]:

5
 • Presentation: The project manager describes the new project using certain criteria,
for instance project type, country, or budget.
• Retrieval: The plan builder retrieves those project plans from the case base that
match the current project’s description most. The project manager then either rejects
the proposed project plans as they do not seem relevant enough to him, or he selects
one of them.
• Adaptation: The old project is used as a starting point for the planning of the new
project. The project manager adapts it to fit the new project requirements. For exam-
ple, a new appliance type of a power plant has to be considered.
• Validation: If an adapted solution is not sufficient, it has to be criticised till the new
project plan shows a good quality. The actual course of the project has to be docu-
mented and evaluated, especially all variations from the project plan.
• Update: A finished project is stored as a case to the case base and may further be
used to create similar project plans.
Representation of project plans as cases
In order to carry out a comparison between a description of the current project and any
project plan stored as a case in the case base (retrieval step, see above), it is necessary to
represent project plans as cases in an appropriate form. The most common way to do so is
to define a case as a set of attribute-value pairs. Each attribute may or may not be used in
the comparison process, depending on which attributes are regarded as relevant in a given
situation. Those attributes that are regarded as relevant for the comparison process will be
referred to as descriptors in the following. Descriptors are strongly domain-dependent. In
the context of project plans in general, there seem to be only three domain-independent
categories of descriptors. In the table below, an example is given for each category.
Descriptor category Descriptor Value
Cost Total budget 4 000 000 FIM
Time Total duration 2 years
Structure Activity build third floor
Table 1: Example of descriptors for project plans

Structure-related descriptors denote if a particular activity is part of the WBS. However,

this requires that there exists a predefined set of possible activity names. There may be
either one descriptor "activity" taking a list of activity names as its value, or several
descriptors "activity 1", "activity 2" etc. each taking one value.
Other domain-dependent descriptors have to be provided by the domain experts. As an
example, some possible descriptors for the domain of power plant projects are given:
• Power plant capacity
• Type of power plant
• Type of contract
• Country
• Risks, e.g. changing laws, uncertain soil and climate conditions
Retrieval of project plans
There are several ways to retrieve project plans which are similar to a current problem
description.

6
One way is to specify a query for previous project plans appropriate as starting points in
the current planning problem, as in conventional database environments. The plan builder
then retrieves all cases matching the query exactly. This retrieval function is provided by
the data base access tool, accessing the case base.
Another way is to perform a retrieval based on the nearest neighbour approach [Wats94].
For each descriptor, a degree of similarity between the descriptor value and the value of
the corresponding descriptor of every comparison case is computed using a local similarity
measure. Aggregating the local similarities, an overall degree of similarity is calculated for
each case comparison using a global similarity measure [Alth95].
Finally, a list of similar projects is presented to the project manager, ranked by degree of
global similarity. After browsing through the retrieved set of projects, it is up to the project
manager to decide which project plan out of this set is suited to serve as the initial plan in
his current project to start with or whether there is a suited one at all.
Adaptation of project plans
Adaptation of project plans can be performed manually or automatically. In manual adap-
tation, the project managers have a very active part in adapting the proposed initial plans.
Adaptation strategies and heuristics may give general recommendation how to proceed or
what to pay attention to in the adaptation process.
A part of the adaptation can be performed automatically using adaptation rules. A special
form of this approach is the use of parametrized adaptation rules representing quantitative
relations among descriptor values.
The automatic construction of structural components of project plans, e.g. network plans,
by copying and pasting partial networks from several projects and checking them for con-
sistency is not supported by CBR tools available today. Functions of this kind may hence
be thought of as future extensions for the plan builder.
Currently available software
There are about a dozen case-based reasoning tools on the market now [Alth95], [Wats94].
They differ significantly with respect to several features. Some important aspects are:
• Platform: All tools available are running in PC/Windows environments, most tools
are also available for Unix platforms.
• Case representation: The standard representation of cases is a set of attribute-value
pairs which is realized in every tool. Boolean, numeric, symbolic and string data
types are common, in addition some tools enable to construct symbol hierarchies
and ordering of symbol values. Extended features in case representation are the
option to build case hierarchies or nested case structures. Another feature, supported
by many advanced tools, is integration of arbitrary multimedia objects into cases.
• Case retrieval: There are two basic mechanisms to retrieve similar cases: Nearest
neighbour matching (see section 2.2.1. for details) and inductive retrieval. The latter
technique requires a learning phase in which general knowledge, usually in the form
of a decision tree, is extracted from cases using machine learning algorithms. This
general knowledge is used to guide the retrieval process. Nearest neighbour match-
ing as the standard retrieval method is supported by virtually all tools on the market,
inductive learning and retrieval is still implemented in many tools. The tools differ
in how far the user may parametrize the algorithms used. The tool ReMind from

7
 Cognitive Systems Inc. additionally offers template retrieval, i.e. database queries as
in SQL.
• Case adaptation: There are different facilities to perform automated adaptation of
retrieved cases: Usually functions, rules or adaptation formulas perform this task.
The presence or absence of adaptation facilities has been characterised as a discrim-
inative feature between first and second generation CBR tools.
• Interface customising: Advanced tools allow the user interface to be customised for
individual needs.
Further criteria having an impact on tool selection are robustness, performance of case
retrieval, and ease of integration with existing software environment.
Commercial tools available today are widely restricted to classification and diagnostic
problems. The functional requirements of the plan builder, as described in section 2.2.1.,
can be met. Extended options as configuration of project plans can hardly be realized with-
out additional programming efforts.
Technical solution based on CBR Express
As an example, we describe how a solution based on the tool CBR Express from Inference
Corp. from a technical point of view can look like. This tool is mainly used for application
development in the area of help-desk and call-center applications. There are quite a lot of
successful running applications in industry and commerce. The tool can be characterized
as a first generation tool since it supports only a simple adaptation technique and limited
forms of case representation and retrieval. Because of its robustness, good performance
and existing interfaces with many relational databases, it can be appropriately used for
applications that do not require sophisticated case adaptation or inductive learning and
retrieval techniques.
Project data may be stored in relational data bases. There is a data base interface (“data
integrator”) which enables access to Oracle 6.0 or 7.0, Microsoft SQL Server 4.2, Sybase
SQL Server 4.x or 10.0, Intersolv Q+E Database Library 1.1.5 data base drivers. Alter-
nately, the standard database interface to the Raima Data Manager is established. The rela-
tion between the components is shown in Figure 2.
CBR Express itself consists of two basic parts:
• The CBR Express User Interface is implemented in ToolBook from Asymetrix
Corp. It consists of five panels: Three panels (case, question and action panel) are
used for defining and editing cases and its components, they are password-protected
and accessible for case base administrator only. Two panels (search and tracking
panel) serve to define the current problem and to initiate case base searches. The
interface can be customized using ToolBook or any other GUI builder.
• The case retrieval is performed by the CBR Express Kernel which is a run-time
module of ART-IM, Inference Corp. ís Artificial Intelligence development tool. The
CBR Express Kernel operates as a server to the interface, carrying out case base
searches when it is activated by a user request. A set of retrieved cases is returned to
the interface for display.

8
 CBR Express User Interface

Case Base API

CBR Express
Kernel
Data Integrator
Raima
Data
Manager SQL
Oracle Q+E
Server

Index File Case Base Database

Figure 2. CBR Express architecture

Cases in CBR Express consist of three parts:

• a textual description, summarizing the essential aspects of the case in a sentence or
short paragraph
• a set of questions with answers, each question of type yes/no (boolean descriptor),
list (symbolic descriptor on nominal scale), numeric, or string
• a set of actions to be taken, forming the solution of the case.
Each question, as well as each action, can be enriched by additional information. As a
standard feature, plain text of arbitrary length can be written to give explanation for the
respective question or action. Alternately, external browsers may be invoked to present
information in their own data format. It is possible to define any executable file as an exter-
nal browsers, e.g. ToolBook applications may show multimedia presentations, or Micro-
soft Project may show the results of a simulation.
Using the Plan builder
The project manager inputs an initial verbal description to express the most important
aspects of the current project. The plan builder then retrieves a set of (by default) five cases
from the case base which match the description most. The descriptors of all retrieved cases
are presented to the project manager. He may now input values for some of these descrip-
tors and initiate a further search in the case base. This may be repeated several times until
the project manager finds an appropriate initial project plan. In the plan builder, the action
of every retrieved case serves as a link to more detailed information for the respective
project plan.

9
3.2. Communication and progress control tool
Communication plays a vital role in most managerial tasks. It is also of uttermost impor-
tance in keeping the project management data up-to-date by reporting the progresses made
in the different activities of the project. Traditionally reporting has been done using con-
ventional communication techniques such as mail, phone and facsimile. The progress of
the project has then been estimated by the project manager based on the reports received. It
is possible that up to a week may pass between the completion of an activity and the
update of the project database. Clearly this is an undesirable situation. The goal of com-
munication and progress management is to minimize the gap between the reported and
actual state of the project. We will introduce a comprehensive tool that goes beyond exist-
ing partial solutions. The concepts of a communication an progress control tool are base
on the work done within the SuperVision project [Ekl94], [Mör93], [Nyl95].
Functionality
The main function to be performed by the communication and progress management tool
is to offer a fast and convenient media for the different parties involved to communicate
over. The communication and progress management tool can be based on a client server
architecture with a central relational database server. Both server-client and client-client
communication has to be possible. Messages and files can be exchanged between the
users. An overview of the is shown in Figure 3. Another important function of the tool is to
offer automatic reminders to involved parties if an activity is running late. Perhaps the
most important advantage of using a communication and progress control tool is that the
project database more accurately will reflect the current status of the project.

Communication and
Project progress management tool
manager

Daemon

Database

Client
Sub supplier

Figure 3. The data flow between the project manager, the subcontractors and the progress
management tool.

Checkpoints
Traditional progress control requires the project manager to make an estimate of how far
an activity has progressed based on knowledge of the project. This knowledge is obtained
through communication with subcontractors and project associates using traditional meth-
ods.
If an activity carried out by a subcontractor has a long duration the project manager needs
to estimate how much of the activity is completed at a certain point in time in order to be

10
able to see if the project is on schedule. The need for the project manager to estimate how
much of an activity is completed can be eliminated by introducing of checkpoints within
an activity. An activity is assigned a number, minimum one, of checkpoints. The check-
points within the activities are agreed on by the project manager and the subcontractor.
The checkpoint often corresponds to some special event in the process, e.g. fuel injector
assembled. Each checkpoint has a percentage which indicates approximately how much of
an activity is finished when the checkpoint is reached. Checking if an activity is late is
done by calculating a date for each checkpoint using the percentage and the start- finish
date of the activity.
When a work related to a checkpoint is done the responsible person confirms it. However,
the checkpoint is not considered as reached until it has been approved by the project man-
ager. An activity is finished when the last checkpoint is reached. The percentage for the
last checkpoint should be 100.
Progress control
Progress management is the main functionality of the tool. It involves three different
phases.
• Checkpoint definition
• Checkpoint confirmation
• Checkpoint approval
In order for the system to be aware of an activity, which is assumed to already be present in
the project database, checkpoints must be defined and a responsible person added to it.
This is done by the project manager when setting up a new project. In addition to the per-
centage each checkpoint is also given a descriptive name. For each type of activity it is
possible to define a set of default checkpoints. These can be used as a base when defining
checkpoints.
Checkpoint confirmation is done by the responsible person. He is only able to see the
activities for which he is responsible. When a checkpoint is confirmed a message is auto-
matically sent to the project manager informing him of a change in the state of the project.
Approval of a checkpoint is done by the project manager. The operation is the same as for
confirming a checkpoint. Because the project manager is conceivably involved in several
projects he has the added possibility of specifying a view of the projects. A view may
specify that only activities from a certain project or domain should be shown.
The list of activities presented to both the project manager and the responsible person
describes the current state of the project. For each activity there is an icon whose function
is similar to that of a traffic light. If the activity is on schedule the light is green otherwise
it is red. This makes it easy for the users to get a quick overview of the activities in the
project.
The tool also includes an automatic reminder facility. The project manager can specify,
individually for each activity, to whom a reminder should be sent. Reminder can be sent to
the project manager, the person responsible for the activity, to both of them or then no
reminders can be sent.
Automatic reminders can be generated by a daemon process running on the server. The
daemon periodically checks the state of the projects in the project database. If it finds a late
activity for which a reminder is requested it sends a message to the appropriate recipients.
The text of the messages sent can separately be tailored by the system administrator for
each reminder level. He can also set the message generation frequency.

11
Communication
The communication tool offers three different ways of user to user communication.
• Messages
• Document transfer
• Talk
Messages in the system are similar to normal e-mail messages. They have a subject, mes-
sage text, sender and recipient. Additionally a message can refer to an activity. A list of
received messages, read as well as unread, is presented to every user when he logs in to the
system. When reading a message referring to an activity it is possible for the user to auto-
matically bring up a screen showing the referenced activity.
Document transfer allows users to exchange files between each other. Because it is not
uncommon that both the sender and receiver of a file are not logged in simultaneously the
server is used for intermediate storage. When a user sends a file it is first transferred to the
server and then a message is sent to the receiver. The user that received the message can
retrieve the file from the server to his client computer. After the file has been retrieved by
the receiver it is deleted from the server.
Talk is an interactive on-line communication between two users where the text typed by
one user appears on the screen of the other and vice versa. This requires that both partici-
pants in a talk session are logged in to the system. When a user wants to establish a talk
session he chooses a recipient from a list of logged in users and a talk request is sent to the
recipients computer. The talk request causes a window to be popped up on the recipients
computer asking him if he wants to accept the talk session. A positive answer will estab-
lish the talk session. Talk sessions can be saved for later reference.
The system offers intelligent support through automatic reminders and high lighting of
problematic activities. This eliminates the possibility of the project manager not noticing
problematic activities. Without this support the problematic activities might drown in the
stream of information.
If all changes in the projects status are updated using the system it is possible to have the
system to keep track of different kinds of statistics for example about the subcontractors.
This means that a knowledgebase could be updated at the same time as the project data-
base. An example of this is when a subcontractor updates a reached checkpoint, late or
early, it could affect his reliability rating.
ProgressView
A communication and progress management tool called ProgressView has been imple-
mented within the SuperVision project at Åbo Akademi University [Mör93], [Nyl95]. A
detailed descrption of the implementation1 can be found in [Kar95]. ProgressView is cur-
rently beeing used by Wärtsilä Diesel Oy. A short description of the prototype is given
below.
The first thing to be done when starting to use ProgressView in a new project is to define
the users involved. All users are given a group and a domain. The group defines the access
level for the user and the domain the company or division the user belongs to. Users that
have been involved in some project before do not have to be entered again. If a new com-

1. Credits should also go to Anders Holm in the Intelligent Project Management Systems
Research Group at Åbo Akademi University for developing and implementing large
parts of the system.

12
pany or division is to participate in the project a new domain has to be defined before add-
ing users that are to belong to this domain.
The next step is for the project manager to define the checkpoints for the activities in the
project, see Figure 4. Even though the project manager enters the checkpoints into the sys-
tem the definition of the checkpoint had been done together with the involved parties. At
this point the project manager usually also sets the reminder level. The project manager
would certainly want a reminder to draw his attention to a late activity. He might also want
a reminder to be sent to the responsible person in order to get an explanation for the delay.

Figure 4. Snapshot of ProgressView - define checkpoint.

When the users and checkpoints are entered the system is functioning. The system can
then be used for the parities to communicate over. Confirmations of reached checkpoints
are sent by the responsible persons to the project manager for him to approve. Besides this
the tool can also be used for other kinds off communication. Messages and files such as
documents and technical drawings can conveniently be sent between all involved parties.
At any time the project manager can browse through the activities in one or all of the
projects he is responsible for. Late activities are indicated with a red icon and activities that
are on schedule are indicated with a green icon. By clicking on an activity in the list he can
bring up the information about the checkpoints within that activity. The user of the system
can at any time press the person information button, as the result of this he will get infor-
mation about the person associated with the selected activity. This information includes,
full name, address, phone and fax numbers and information about the company or division
that the person is working for.
The project manager has the possibility to generate reports about the activities. He chooses
a certain project or domain to include in the report. The reports can be imported to e.g. a
spread sheet program for further processing.

13
3.3. Simulation tool1
If the duration of each activity is a known constant value there are efficient scheduling
algorithms for computing the completion date of the project. Often there are situations
where the duration of an activity is not know exactly. To explicitly take this uncertainty
into account the duration of an activity can be defined as a continuous non-negative ran-
dom variable of a known probability density function.
Experience shows that it is unrealistic to require persons in charge to express activity dura-
tions as probability density functions. PERT (Program Evaluation and Review Technique
[Mod70]) overcomes this difficulty in a smooth way by assuming that all activity durations
are independent beta distributed variables and requires for each of them only three, usually
easily accessible, estimates: an optimistic, a pessimistic and a most likely estimate.
[Pag90] A beta distribution can be fitted for these three estimates. [Bad91]
PERT is attractive because of the simplicity of the required input data and the clarity of the
achieved results. But PERT´s easiness is more apparent than real: it rests upon strong
assumptions whose acceptability always requires careful checking. Improper use of PERT
is not rare, and generally leads to deceptive results. [Pag90]
Scheduling and Critical Path
Scheduling planning and the critical path concept are also affected when introducing
expected activity durations instead of fixed ones. The earliest and latest time for an event
become the earliest expected time and the latest allowable time. These values can be calcu-
lated as in CPM (Critical Path Method) using the expected durations instead of the con-
stant durations.
The critical path is also based on the expected activity durations and allows calculation of
an expected project completion time. The critical path and the expected completion time
can be determined as follows.
Let p1, p2, ..., pn be paths from the source to the sink of the project and let d1, d2, ..., dn be
the sum of the random durations of the activities in the respective paths. The critical path
will be the path with the longest duration. The expected project duration will therefore be
max(d1, d2, ..., dn).
However this method can produce fallacious results if used incorrectly. This is due to the
fact that the durations of the paths has a variance since they are sums of independent ran-
dom variables.
Letting the activity durations be random variables gives the paths p 1, p2, ..., pn a probabil-
ity of being the critical path. Since the durations are independent random variables there
are an infinite number of possible executions of the project plan. In every execution at least
one of the paths has the longest execution time, i.e. is the critical path. This implies that the
path with the maximal expected execution time is not always the path with the highest
probability of being critical. It might also be that the path with the highest probability of
being critical has in absolute terms a very low probability of being critical.
A good example of a problematic situation can be seen in Figure 5. The frequencies of the
critical path are as follows. Path AB had the longest duration in 20% of the cases, AC in
20% AD in 20% and E in 40% of the runs. In the example activity A has a probability of

1. This section appears also in [vSch96] and is included in order to make this paper self-
contained.

14
 B
0.2

A C
0.6 0.2

Start D End
0.2

E
0.4

Figure 5. Example of a PERT network with a relativly low probability of the critical path
to actually be critical.

0.6 belonging to the critical path. However A does not belong to the path E which has the
highest probability of being the critical path. [Pag90]
This indicates that the notion of the critical path might not always be the best indicator of
criticality. Instead of monitoring and controlling more closely the activities with an
expected delay of zero it would be of interest to monitor the activities with the highest
probability of belonging to the critical path. This probability is estimated by means of fre-
quencies. Using some probabilistic simulation technique these frequencies can be
obtained.
In order to assure that the obtained results are as correct as possible the simulation should
only concern those parts of the project that are not finished. Therefore the simulation mod-
els should be built in a way that models the current state of the project. As model building
often is tedious work some degree of automation in the model refinement is desirable.
Simulation net models
Simulation nets are extended Petri nets specially designed for simulation. Simulation nets
were introduced by Törn in 1981 [Törn81].
Previous work shows that project plans can be modelled using Simulation Nets [vSch94].
These models can be executed i.e. simulated and statistics about the model can be col-
lected. By analysing the statistics obtained from the simulation the degree of criticality can
be determined for each path and activity.
Functionality
The simulation tool would have to
• generate the simulation model from the project plan
• execute the model
• collect statistics about the performance of the model
DSimnex
A prototype of the simulation tool has been implemented. The prototype consists of a
model generator, a simulation tool and a post-processor for the statistics.
The model generator is at this point a filter which accepts mpx-files as input an generates a
number of files needed for the simulation and compiling statistics. The files generated are
the simulation net model, a template file specifying what kind of statistics is to be col-
lected during the simulation and a file containing information about how to map the statis-

15
tics back onto the project. The simulation tool used at this point is at this point DSimnex, a
general purpose simulation tool developed at Åbo Akademi University. DSimnex consists
of two parts; a control tool and a simulation engine. The simulation engine runs as a dae-
mon on a farm of workstations, the engines task is to run the model, collect the results
from the run and report these to the control tool. The control tool is in charge of the model
construction, the loading of the model onto the workstations for independent parallel exe-
cution, and the aggregation of the simulation results, see Figure 6.
The model generator has been integrated into the control tool. Since the control tool is sep-
arated from the simulation engine it is possible to tailor it to meet the needs of the applica-
tion domain. The control tool is also platform independent, this would allow the control
tool to be implemented e.g. as an add-on module for some project planning tool. There is a
clear advantage of having the possibility to use other machines to run the simulation on
since the models in reality can be very large. To get statistics about the model several sim-
ulation runs has to be performed. The possibility to execute the model in parallel on sev-
eral computers will decrease the time needed for running the simulation. The speed-up is
nearly proportional to the number of computers available for the parallel execution.
Another positive consequence is a better utilisation of available computer resources.

Figure 6. Snapshot of DSimnex.

When the simulation is performed the results are processed and mapped back to the
project. The output includes information about which paths have been critical in the simu-
lation, the relative frequency of these paths and a list of the most critical activities. The
output can be altered to work as virtually any tool one wants to use to display the results
(spread sheets, word processors).

4. Integration
There are several possible ways to create an integrated PMS one obvious would be to write
a large system which contains all the functionality described. This however would require
an enormous amount of work.
The more practical solution is to develop intermediate parts that enable the existing and
new tools to share data. The foundation of such an approach is a database and a database
access tool. The database holds all data concerning current and former projects. Former
projects can be used as cases for the plan builder component.
The database access tool provides a common interface for all components of the second
layer of the functional model. In addition, the database access tool is used for administra-

16
tion of the data stock and retrieval and preprocessing of reporting data. It should provide
features for data retrieval, data modification and data insertion.
If a tool form the second layer of the IPMS model has the capability to access databases, as
several planning tools have (e.g. the PM-software PSDI Project/2 Series X), this feature
can be used to directly read data from the database and store data to the database. For com-
ponents that do not have this capability (e.g. PM-software MS-Project) the database access
tool has to generate files that can be used as input for these components.
It is necessary to harmonise the database structure with the requirements of the compo-
nents using direct database access. Conflicts concerning the database structure can arise
due to the requirements of the different components using direct database access. It can be
necessary to use the other form of data exchange for one of the components in order to
resolve such a conflict.
For the tools communication through files the import and export functions are used to
exchange data with the database through the database access tool. The files exported by
the components of this type (files in some format like dBASE IV, MPX, ODBS) are inter-
preted and the content is inserted into the database by the database access tool. To enable
dataflow in the opposite direction the database access tool generates files that can be
imported into the components.

5. Project management process using IPMS

From a more technical perspective we return to the management tasks supported by IPMS
and look at the whole picture of the project management process. Unlike management in
an on-going enterprise, project management is management of change. The kind and effort
of managerial activities as well as the type of computer based tools to support them vary
during the course of a project.
Figure 7 shows the flow of project management functions supported by IPMS during the
project life cycle. In the concept phase, where goals and feasibility of the project are deter-
mined, there are tools to support partial work of this phase like tools for effort estimation
and risk analysis.
In the development phase the project plan has to be established. The basic plan of IPMS
contains the work breakdown structure and the sequential relationship of the project activ-
ities. The plan builder helps the project planner to look for a plan that is similar to the cur-
rent project. Then time, costs and resources are attached to the basic plan using the
planning tool. The simulation tool enables evaluation of the schedule.
During the implementation phase the communication tool is the dominating tool. It sup-
ports communication between the project manager and the team members or subcontrac-
tors. It also serves in monitoring project progress. If the project does not run as planned, it
has to be replanned using the simulation tool and the planning tool. A terminated project is
stored in the case base with the plan builder to save documented “experiences” for later
reuse. The reporting tool supports the extraction and visual representation of project data
through all phases from the development of the project to the project termination.

17
 Project phases and Main activities with Supporting activities with External links to
typical activities1. IPMS IPMS IPMS
Concept
• Gather data
• Identify need Specific functional tools
• Establish: goals, feasibility, stake (SF)
Estimate costs
holders, risk level, strategy,
Assess risks etc.
potential team
• Estimate resources
• Identify alternatives
• Present proposals
• Obtain approval for next phase
Similar cases from Specific Project
the case base project data description
Development
• Appoint key team members
• Conduct studies
• Develop scope baseline: end Plan builder (3)
product(s), quality standards, Generate plan
resources, activities
• Establish: master plan, budget,
WBS, procedures
• Assess risks
• Confirm justification
• Present project brief Basic project plan
• Obtain approval to proceed

Planning tool (5) Simulation tool (4) Reporting

Define plan Analyze and tool (6)
refine plan

Implementation
• Set up: organization,
communications Report project
• Motivate team Final project plan
status
• Detail technical requirements
• Establish: work packages,
information control system
• Procure goods and services Simulation tool (4)
Comm & progr ctl tool (7)
• Execute work packages
Communicate with Planning tool (5)
• Direct/Monitor/forecast/control:
scope, quality, time, cost providers and monitor Analyze status
• Resolve problems project progress and change plan

Termination
• Finalize products Data on plans and
Supporting
• Review and accept course of the
documentation
• Transfer product responsibility project
• Evaluate project
• Document results
• Reassign project team Plan builder (3)
Store new case in the case
base

New case

1
The main phases and typical activities are adapted from: Project Management Institute: Project management
body of knowledge (PMBOK), Drexel Hill 1987, p. 1-4.

Figure 7. IPMS project management process.

18
References
[Aamo95] Agnar Aamodt and Manuela Veloso (eds.), Case-Based Reasoning -
Research and Development, Proceedings of the First International Confer-
ence on Case-Based Reasoning (ICCBR-95). Springer-Verlag, Berlin 1995.
[Alle94] Bradley Allen, Case-Based Reasoning: Business Applications, Communi-
cations of the ACM, Vol. 37, No. 3, pp. 40-42.
[Alth95] Klaus-Dieter Althoff, Eric Auriol, Ralph Barletta, Michel Manago, A
Review of Industrial Case-Based Reasoning Tools, AI Intelligence, Oxford
1995.
[Bad91] Adedeji B. Badiru, STARC 2.0: An Improved PERT Network Simulation
Tool, Computers ind. Engng, Vol 20, No 3, 389-400
[Cur92] Ken Currie, Brian Drabble, Knowledge-based planning systems: a tour,
International Journal of Project Management, Nr. 3, August 1992, p. 131-
137
[Dwo92] S. Dworatscheck, Marktspiegel Projektmanagement-Software, TÜV Rhein-
land, Köln 1992
[Ekl94] Patrik Eklund et al.., InterVision - A Communication and Decision Support
System for Distrebuted Project Management, Deliverable for the PRO-
DEAL Programme, Åbo Akademi University, 1994
[Hos92] O. A. Hosny, An Intelligent Decission Support System for Construction
Planning and Scheduling, University of Missouri - Rolla, 1992
[Kar95] Johan Karlsson, ProgressView - ett klient/server-baserat projektuppföljn-
ingssystem, Master Thesis, Department of Computer Science, Åbo
Akademi University, 1995, 61 pp
[Kolo93] Janet L. Kolodner, Case-Based Reasoning, Morgan Kaufmann Publishers;
San Mateo, CA, 1993.
[Mör93] Kenneth Mörk, Kommunikationsstöd inom projektstyrning, Master Thesis,
Department of Computer Science, Åbo Akademin University, 1993, 64 pp
[Mod70] Joseph J. Moder and Cecil R. Phillips, Project Management with CPM and
PERT, Van Nostrand Reinhold Ltd., 360 pp
[Nyl95] Kenneth Nylund, Stödsystem för datorbaserad projektadministration, Mas-
ter Thesis, Department of Computer Science, Åbo Akademi University,
1995, 61 pp
[Pag90] Anastasia Pagnoni, Project Engineering; Computer-Oriented Planning and
Operational Decision Making, Springer-Verlag, 239 pp, ISBN 0-387-
52475-4
[PMI87] Project Management Institute: Project Management Body of Knowledge
(PMBOK), PMI, Drexel Hill, 1987
[vSch94] Fredrick von Schoultz and Aimo Törn, SimNet, A Tool for Simulation with
Application to Project Network Analysis, Proc. SIMS´94, Stockholm, 1994,
144-149.

19
[vSch96] Fredrick von Schoultz, Simulating Project Progress, Turku Centre of Com-
puter Science, Technical Reports, No. XX, June 1996, ISBN 951-650-800-
6, 11 pp
[Törn81] Aimo Törn, Simulation Graphs: A General Tool for Modelling Simulation
Designs, SIMULATION 37:6, 187-194
[Wats94] Ian Watson, Farhi Marir, Case-Based Reasoning: A Review, The Knowl-
edge Engineering Review, Vol. 9, No. 3.

20
Turku Centre for Computer Science
Lemminkäisenkatu 14
FIN-20520 Turku
Finland

http://www.tucs.abo.fi/

University of Turku
• Department of Matemathical Sciences

Åbo Akademi University

• Department of Computer Science
• Institute for Advanced Management Systems Research

Turku School of Economics and Business Administration

• Institute of Information System Science