An Integrated Project Management Information System

Fredrick von Schoultz

bo Akademi University, Department of Computer Science Lemminkisenkatu 14, FIN-20520 Turku, Finland e-mail: fschoult@abo.

Uwe Malzahn, Ralf Schulz

Universitt Leipzig, Institut fr Wirtschaftsinformatik Marscherstrae 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 integrated 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 lling certain gaps in todays support environment: 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 management software are systems based on network planning. [Dwo92] They provide scheduling, cost and resource planning. Another group of project management software supports specic 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 integrated 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 lling certain gaps in todays support environment: 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 fr Wirtschaftsinformatik at Universitt Leipzig in cooperation with Wrtsil Diesel 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 implementation. 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 rst 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 rst, components which are quite common in existing project management systems are briey characterized, then some innovative components are introduced in section 3.

1. The Intelligent Project Management Systems Research Group at bo Akademi University participates within the SuperVision project in the Finnish national technology programme 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 Wrtsil Diesel Oy, Diesel Power Plants. 1

1 project managers 1-3 1-SF 1-4 1-5

2 1-2 1-7 1-6 2-7 subcontractors

SF specific function tools SF-8

3 plan builder 3-8

4 simulation tool 4-8

5 planning tool 5-8

6 reporting tool 6-8

7 communication and progress control tool 7-8

8 data base access tool 8-9 9

9.1 data base

9.2 case base

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

2.1. Short description of existing components

Specic functional software
Specic 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 specic functional software for the IPMS, this component is included for comprehensiveness. The use of specic functional software mainly precedes 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 specic functional software and the other components of the functional model is very unlikely and no recommendations for implemention of special functional software in the model are given. However, some specic functional software works

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 rene 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 (ows) 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 availability for operating systems and hardware environments. One can roughly distinguish two main groups of planning tools, single-user and multiple-user tools. The rst 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 les, inexible le 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 (todays standard) or mainframe (becomes obsolete) Rich functionality, several (optional) modules to add special functionality Storage of project data in relational data bases, exible 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 le 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 (ow) 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-specic and non-specic 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-specic report functions of the planning tool and the functions of a general-purpose graphical tool. Any software for project planning provides at least sufcient features to get out projectspecic reports like WBS or workload diagrams. Their shortcomings are limited capabilities to present data that is not included in the internal data model of the software, e. g. certain 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-specic 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 modication and data generation.

Relations among the components

The relations between the project managers (or subcontractors respectively) and the applications (1-SF, 1-3, 1-4, 1-5, 1-6, 1-7, 2-7) denote information ow in the man-machine interface. Relation 1-2 expresses direct communication among managers and subcontractors, 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 ows. There are several ways to implement these dataows, a short overview 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 nally a simulation tool for project scheduling are presented.

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 analysis, cost estimation, project monitoring, as well as a complete specication 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 projects activities with respect to time: The predecessor-successor relationships among the activities are specied 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 dene 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 generation. CBR is an approach of problem solving within AI that has recently attracted much attention [Aamo95],[Kolo93]. Its basic idea is to reuse specic knowledge from former problem 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 rst sight to dene a project represented by its corresponding project plan as a case. However, considering more elaborate aspects, certain parts of project plans can be dened 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]:

 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 projects 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 t the new project requirements. For example, a new appliance type of a power plant has to be considered. Validation: If an adapted solution is not sufcient, it has to be criticised till the new project plan shows a good quality. The actual course of the project has to be documented and evaluated, especially all variations from the project plan. Update: A nished 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 dene 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 Cost Time Structure

Descriptor Total budget Total duration Activity

Value 4 000 000 FIM 2 years build third oor

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 predened 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 adaptation, 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 consistency 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 signicantly 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 matching 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

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 discriminative feature between rst 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 classication and diagnostic problems. The functional requirements of the plan builder, as described in section 2.2.1., can be met. Extended options as conguration of project plans can hardly be realized without 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 rst 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. Alternately, the standard database interface to the Raima Data Manager is established. The relation 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 ve panels: Three panels (case, question and action panel) are used for dening 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 dene 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 Articial 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.

CBR Express User Interface

Case Base API CBR Express Kernel Raima Data Manager Data Integrator SQL Server

Oracle

Q+E

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 dene any executable le as an external browsers, e.g. ToolBook applications may show multimedia presentations, or Microsoft 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) ve 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 descriptors and initiate a further search in the case base. This may be repeated several times until the project manager nds 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.

3.2. Communication and progress control tool

Communication plays a vital role in most managerial tasks. It is also of uttermost importance 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 conventional 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 communication 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 existing partial solutions. The concepts of a communication an progress control tool are base on the work done within the SuperVision project [Ekl94], [Mr93], [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 les 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 reect the current status of the project.
Communication and progress management tool

Project manager

Daemon Database

Client Sub supplier

Figure 3. The data ow 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 methods. 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 checkpoints 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 nished 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- nish date of the activity. When a work related to a checkpoint is done the responsible person conrms it. However, the checkpoint is not considered as reached until it has been approved by the project manager. An activity is nished 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 denition Checkpoint conrmation 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 dened and a responsible person added to it. This is done by the project manager when setting up a new project. In addition to the percentage each checkpoint is also given a descriptive name. For each type of activity it is possible to dene a set of default checkpoints. These can be used as a base when dening checkpoints. Checkpoint conrmation is done by the responsible person. He is only able to see the activities for which he is responsible. When a checkpoint is conrmed a message is automatically 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 conrming 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 trafc 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 nds 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, message 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 automatically bring up a screen showing the referenced activity. Document transfer allows users to exchange les between each other. Because it is not uncommon that both the sender and receiver of a le are not logged in simultaneously the server is used for intermediate storage. When a user sends a le it is rst transferred to the server and then a message is sent to the receiver. The user that received the message can retrieve the le from the server to his client computer. After the le 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 participants 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 establish 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 database. 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 implemented within the SuperVision project at bo Akademi University [Mr93], [Nyl95]. A detailed descrption of the implementation1 can be found in [Kar95]. ProgressView is currently beeing used by Wrtsil Diesel Oy. A short description of the prototype is given below. The rst thing to be done when starting to use ProgressView in a new project is to dene the users involved. All users are given a group and a domain. The group denes 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 com1. 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 dened before adding users that are to belong to this domain. The next step is for the project manager to dene the checkpoints for the activities in the project, see Figure 4. Even though the project manager enters the checkpoints into the system the denition 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 - dene checkpoint. When the users and checkpoints are entered the system is functioning. The system can then be used for the parities to communicate over. Conrmations 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 les 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 information 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 efcient 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 dened as a continuous non-negative random variable of a known probability density function. Experience shows that it is unrealistic to require persons in charge to express activity durations as probability density functions. PERT (Program Evaluation and Review Technique [Mod70]) overcomes this difculty 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 tted 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 PERTs 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 xed ones. The earliest and latest time for an event become the earliest expected time and the latest allowable time. These values can be calculated as in CPM (Critical Path Method) using the expected durations instead of the constant 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 random variables. Letting the activity durations be random variables gives the paths p 1, p2, ..., pn a probability of being the critical path. Since the durations are independent random variables there are an innite 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 selfcontained. 14

B 0.2 A 0.6 Start C 0.2 D 0.2 End

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 frequencies. 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 nished. Therefore the simulation models 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 renement is desirable.

Simulation net models

Simulation nets are extended Petri nets specially designed for simulation. Simulation nets were introduced by Trn in 1981 [Trn81]. 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 collected. 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 lter which accepts mpx-les as input an generates a number of les needed for the simulation and compiling statistics. The les generated are the simulation net model, a template le specifying what kind of statistics is to be collected during the simulation and a le containing information about how to map the statis15

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 daemon 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 execution, 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 separated from the simulation engine it is possible to tailor it to meet the needs of the application 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 simulation runs has to be performed. The possibility to execute the model in parallel on several 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 simulation, 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 modication 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 components that do not have this capability (e.g. PM-software MS-Project) the database access tool has to generate les that can be used as input for these components. It is necessary to harmonise the database structure with the requirements of the components using direct database access. Conicts 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 conict. For the tools communication through les the import and export functions are used to exchange data with the database through the database access tool. The les exported by the components of this type (les in some format like dBASE IV, MPX, ODBS) are interpreted and the content is inserted into the database by the database access tool. To enable dataow in the opposite direction the database access tool generates les 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 ow of project management functions supported by IPMS during the project life cycle. In the concept phase, where goals and feasibility of the project are determined, 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 activities. The plan builder helps the project planner to look for a plan that is similar to the current 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 supports communication between the project manager and the team members or subcontractors. 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 typical activities1. Concept

Gather data Identify need Establish: goals, feasibility, stake holders, risk level, strategy, potential team Estimate resources Identify alternatives Present proposals Obtain approval for next phase

Main activities with IPMS

Supporting activities with IPMS

External links to IPMS

Specific functional tools (SF) Estimate costs Assess risks etc.

Similar cases from the case base

Specific project data

Project description

Development

Appoint key team members Conduct studies Develop scope baseline: end product(s), quality standards, resources, activities Establish: master plan, budget, WBS, procedures Assess risks Confirm justification Present project brief Obtain approval to proceed

Plan builder (3) Generate plan

Basic project plan

Planning tool (5) Define plan

Simulation tool (4) Analyze and refine plan

Reporting tool (6)

Implementation

Set up: organization, communications Motivate team Detail technical requirements Establish: work packages, information control system Procure goods and services Execute work packages Direct/Monitor/forecast/control: scope, quality, time, cost Resolve problems

Final project plan

Report project status

Comm & progr ctl tool (7) Communicate with providers and monitor project progress

Simulation tool (4) Planning tool (5) Analyze status and change plan

Termination
Finalize products Review and accept Transfer product responsibility Evaluate project Document results Reassign project team

Data on plans and course of the project

Supporting documentation

Plan builder (3) Store new case in the case base

New case

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 Conference on Case-Based Reasoning (ICCBR-95). Springer-Verlag, Berlin 1995. Bradley Allen, Case-Based Reasoning: Business Applications, Communications of the ACM, Vol. 37, No. 3, pp. 40-42. Klaus-Dieter Althoff, Eric Auriol, Ralph Barletta, Michel Manago, A Review of Industrial Case-Based Reasoning Tools, AI Intelligence, Oxford 1995. Adedeji B. Badiru, STARC 2.0: An Improved PERT Network Simulation Tool, Computers ind. Engng, Vol 20, No 3, 389-400 Ken Currie, Brian Drabble, Knowledge-based planning systems: a tour, International Journal of Project Management, Nr. 3, August 1992, p. 131137 S. Dworatscheck, Marktspiegel Projektmanagement-Software, TV Rheinland, Kln 1992 Patrik Eklund et al.., InterVision - A Communication and Decision Support System for Distrebuted Project Management, Deliverable for the PRODEAL Programme, bo Akademi University, 1994 O. A. Hosny, An Intelligent Decission Support System for Construction Planning and Scheduling, University of Missouri - Rolla, 1992 Johan Karlsson, ProgressView - ett klient/server-baserat projektuppfljningssystem, Master Thesis, Department of Computer Science, bo Akademi University, 1995, 61 pp Janet L. Kolodner, Case-Based Reasoning, Morgan Kaufmann Publishers; San Mateo, CA, 1993. Kenneth Mrk, Kommunikationsstd inom projektstyrning, Master Thesis, Department of Computer Science, bo Akademin University, 1993, 64 pp Joseph J. Moder and Cecil R. Phillips, Project Management with CPM and PERT, Van Nostrand Reinhold Ltd., 360 pp Kenneth Nylund, Stdsystem fr datorbaserad projektadministration, Master Thesis, Department of Computer Science, bo Akademi University, 1995, 61 pp Anastasia Pagnoni, Project Engineering; Computer-Oriented Planning and Operational Decision Making, Springer-Verlag, 239 pp, ISBN 0-38752475-4 Project Management Institute: Project Management Body of Knowledge (PMBOK), PMI, Drexel Hill, 1987 Fredrick von Schoultz and Aimo Trn, SimNet, A Tool for Simulation with Application to Project Network Analysis, Proc. SIMS94, Stockholm, 1994, 144-149.

[Alle94] [Alth95]

[Bad91] [Cur92]

[Dwo92] [Ekl94]

[Hos92] [Kar95]

[Kolo93] [Mr93] [Mod70] [Nyl95]

[Pag90]

[PMI87] [vSch94]

19

[vSch96]

[Trn81] [Wats94]

Fredrick von Schoultz, Simulating Project Progress, Turku Centre of Computer Science, Technical Reports, No. XX, June 1996, ISBN 951-650-8006, 11 pp Aimo Trn, Simulation Graphs: A General Tool for Modelling Simulation Designs, SIMULATION 37:6, 187-194 Ian Watson, Farhi Marir, Case-Based Reasoning: A Review, The Knowledge Engineering Review, Vol. 9, No. 3.

20

Turku Centre for Computer Science Lemminkisenkatu 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