Turku Centre for Computer ScienceTechnical Report No 33June 1996

ISBN 951-650-801-4ISSN 1239-1891

An Integrated Project ManagementInformation System

Fredrick von SchoultzÅbo Akademi University, Department of Computer ScienceLemminkäisenkatu 14, FIN-20520 Turku, Finlande-mail: fschoult@abo.fi

Uwe Malzahn, Ralf SchulzUniversität Leipzig, Institut für WirtschaftsinformatikMarscherstraße 31, 04109 Leipzig, Germanye-mail: schulz@wifa.uni-leipzig.de

AbstractIn industry, business has been organized and conducted in projects for a long time. Projectmanagement is regarded as one solution to the challenges of modern business world likeaccelerated product life cycles, customer-individual production and services, complexprocesses and high time and cost pressure.Although many project management tasks are supported by computer systems a lack ofintegration among the systems is obvious. There is a need of integration with respect tofunction 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 computersupport for a composed set of project management functions and uniform data access. Inaddition, 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 anda simulation tool for schedule analysis.

1

1. IntroductionIn industry, business has been organized and conducted in projects for a long time. Projectmanagement is regarded as one solution to the challenges of modern business world likeaccelerated product life cycles, customer-individual production and services, complexprocesses and high time and cost pressure.Professional project management embraces a whole set of managerial tasks. Essentialproject management functions are the management of scope, quality, time, cost, humanresources, contract, procurement and information. [PMI87] Existing computer systemssupport 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 supportsspecific tasks like risk assessment and cost estimation. The third group are general purposetools for text processing, charting, data administration etc.Although many project management tasks are supported by computer systems a lack ofintegration among the systems is obvious. There is a need of integration with respect tofunction 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 computersupport for a composed set of project management functions and uniform data access. Inaddition, 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 anda simulation tool for schedule analysis.The work presented has been done within The Intelligent Project Management SystemsResearch Group1 of the Department of Computer Science at Åbo Akademi University andInstitut 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 IPMSThe functional model of IPMS contains all main project management functions supportedby 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 threelayers. The users form the first layer the of the IPMS. The second layer comprises theapplications the users interact with, and the third layer the project database as well as thedata 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. TheFederation of Finnish Metal, Engineering and Electrotechnical Industries (FIMET) andTechnology Development Centre (TEKES) are responsible for the coordination of theprogramme. 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.

2

2.1. Short description of existing components

Specific functional softwareSpecific 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 componentis 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 breakdownstructure (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

9

data base

9.1

project managers

1subcon- tractors

2

plan builder

3

simulation tool

4

planning tool

5

reporting tool

6

communication and progress control tool

7

data base access tool

8

1-6

1-4

case base

9.2

1-32-7

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

8-9

1-7

1-5

1-2

specific function tools

SF

1-SF

SF-8

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

3

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 othercomponents.

Planning toolThe planning tool is used to refine and administrate the project plan. Project plans arestored in the database and are later updated as the project progresses. A project planincludes project structure and hierarchy, schedule and sequential relationships (flows)between tasks, resource assignment and workload and budget/cost. More details aboutproject 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 basicfunctionality. Software for project planning differs considerably in functionality and avail-ability for operating systems and hardware environments. One can roughly distinguish twomain 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 fromHoskyns 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 implementationstrategies for planning tools.

Reporting toolThe task of the reporting tool is to present data on output media. This function is tightlylinked 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)

4

• 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 canhandle all project-specific and non-specific report formats (s. component description) ishardly to be found. The solution will be a combination of the retrieval functions of thedatabase access tool, the project-specific report functions of the planning tool and thefunctions 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 togenerate project-specific diagrams. The software Graneda from Netronic constitutes anexception. It is a special tool for generating project-graphics.Reporting tools couple the functions of data retrieval, data manipulation and general datapresentation. If such a tool will be used it should be considered to choose a product thatcan also serve as database access tool (component 8).

Database access toolThe database access tool provides a common interface to the databases for all componentsof the second layer of the functional model. In addition, the database access tool is usedfor administration and maintenance of the data stock and retrieval and preprocessing ofreporting data. It should provide features for data retrieval, data modification and data gen-eration.

Relations among the componentsThe 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-machineinterface. 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 / casebaserepresent 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 componentsIn this chapter the three new components, a plan builder, a communication and progressmanagement tool and finally a simulation tool for project scheduling are presented.

5

3.1. Plan builder

Project plansTo come up with a project plan represents an essential part of project management. Aproject plan includes scope, time, budget, resources, risk, etc. Computer-based projectplans contain the following components:

• Work break-down structure (WBS): The project is decomposed into a hierarchyof activities. It serves as a basic documentation for project coordination, risk analy-sis, cost estimation, project monitoring, as well as a complete specification of theservices for the orderers. The WBS can be constructed according to the structure ofthe 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 projectand to control the progress of a running project. It contains a model of the project’sactivities with respect to time: The predecessor-successor relationships among theactivities 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 WBShierarchy.

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 reasoningWhen a new project has to be planned, the respective project manager has to create a basicor 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 inthe current situation. The plan builder is an IPMS component that aims to assist the projectmanager in this task. We suggest case-based reasoning (CBR) to support this process. Incomparison 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, thesolution of a previous problem is transferred to the new situation. This approach is basedupon 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 asolution. Further documentation of the solution or the way of solving the problem may beadded. In the context of creating a project plan, it seems to be natural at first sight to definea project represented by its corresponding project plan as a case. However, consideringmore elaborate aspects, certain parts of project plans can be defined as cases. We willassume 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 thefollowing basic steps [Alle94]:

6

• 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 thatmatch the current project’s description most. The project manager then either rejectsthe proposed project plans as they do not seem relevant enough to him, or he selectsone of them.

• Adaptation: The old project is used as a starting point for the planning of the newproject. 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 newproject 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 beused to create similar project plans.

Representation of project plans as casesIn order to carry out a comparison between a description of the current project and anyproject plan stored as a case in the case base (retrieval step, see above), it is necessary torepresent project plans as cases in an appropriate form. The most common way to do so isto define a case as a set of attribute-value pairs. Each attribute may or may not be used inthe comparison process, depending on which attributes are regarded as relevant in a givensituation. Those attributes that are regarded as relevant for the comparison process will bereferred to as descriptors in the following. Descriptors are strongly domain-dependent. Inthe context of project plans in general, there seem to be only three domain-independentcategories of descriptors. In the table below, an example is given for each category.

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 beeither one descriptor "activity" taking a list of activity names as its value, or severaldescriptors "activity 1", "activity 2" etc. each taking one value.Other domain-dependent descriptors have to be provided by the domain experts. As anexample, 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 plansThere are several ways to retrieve project plans which are similar to a current problemdescription.

Descriptor category Descriptor ValueCost Total budget 4 000 000 FIMTime Total duration 2 yearsStructure Activity build third floor

Table 1: Example of descriptors for project plans

7

One way is to specify a query for previous project plans appropriate as starting points inthe current planning problem, as in conventional database environments. The plan builderthen retrieves all cases matching the query exactly. This retrieval function is provided bythe 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 ofthe corresponding descriptor of every comparison case is computed using a local similaritymeasure. Aggregating the local similarities, an overall degree of similarity is calculated foreach case comparison using a global similarity measure [Alth95].Finally, a list of similar projects is presented to the project manager, ranked by degree ofglobal similarity. After browsing through the retrieved set of projects, it is up to the projectmanager to decide which project plan out of this set is suited to serve as the initial plan inhis current project to start with or whether there is a suited one at all.

Adaptation of project plansAdaptation 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 orwhat to pay attention to in the adaptation process.A part of the adaptation can be performed automatically using adaptation rules. A specialform of this approach is the use of parametrized adaptation rules representing quantitativerelations 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 hencebe thought of as future extensions for the plan builder.

Currently available softwareThere 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 toolsare also available for Unix platforms.

• Case representation: The standard representation of cases is a set of attribute-valuepairs which is realized in every tool. Boolean, numeric, symbolic and string datatypes are common, in addition some tools enable to construct symbol hierarchiesand ordering of symbol values. Extended features in case representation are theoption to build case hierarchies or nested case structures. Another feature, supportedby many advanced tools, is integration of arbitrary multimedia objects into cases.

• Case retrieval: There are two basic mechanisms to retrieve similar cases: Nearestneighbour matching (see section 2.2.1. for details) and inductive retrieval. The lattertechnique requires a learning phase in which general knowledge, usually in the formof a decision tree, is extracted from cases using machine learning algorithms. Thisgeneral 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 differin how far the user may parametrize the algorithms used. The tool ReMind from

8

Cognitive Systems Inc. additionally offers template retrieval, i.e. database queries asin SQL.

• Case adaptation: There are different facilities to perform automated adaptation ofretrieved 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 forindividual needs.

Further criteria having an impact on tool selection are robustness, performance of caseretrieval, and ease of integration with existing software environment.Commercial tools available today are widely restricted to classification and diagnosticproblems. 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 ExpressAs an example, we describe how a solution based on the tool CBR Express from InferenceCorp. from a technical point of view can look like. This tool is mainly used for applicationdevelopment in the area of help-desk and call-center applications. There are quite a lot ofsuccessful running applications in industry and commerce. The tool can be characterizedas a first generation tool since it supports only a simple adaptation technique and limitedforms of case representation and retrieval. Because of its robustness, good performanceand existing interfaces with many relational databases, it can be appropriately used forapplications that do not require sophisticated case adaptation or inductive learning andretrieval techniques.Project data may be stored in relational data bases. There is a data base interface (“dataintegrator”) which enables access to Oracle 6.0 or 7.0, Microsoft SQL Server 4.2, SybaseSQL 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 AsymetrixCorp. It consists of five panels: Three panels (case, question and action panel) areused for defining and editing cases and its components, they are password-protectedand accessible for case base administrator only. Two panels (search and trackingpanel) serve to define the current problem and to initiate case base searches. Theinterface can be customized using ToolBook or any other GUI builder.

• The case retrieval is performed by the CBR Express Kernel which is a run-timemodule of ART-IM, Inference Corp. ís Artificial Intelligence development tool. TheCBR Express Kernel operates as a server to the interface, carrying out case basesearches when it is activated by a user request. A set of retrieved cases is returned tothe interface for display.

9

Cases in CBR Express consist of three parts:

• a textual description, summarizing the essential aspects of the case in a sentence orshort 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 astandard feature, plain text of arbitrary length can be written to give explanation for therespective question or action. Alternately, external browsers may be invoked to presentinformation 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 builderThe project manager inputs an initial verbal description to express the most importantaspects of the current project. The plan builder then retrieves a set of (by default) five casesfrom the case base which match the description most. The descriptors of all retrieved casesare 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 untilthe project manager finds an appropriate initial project plan. In the plan builder, the actionof every retrieved case serves as a link to more detailed information for the respectiveproject plan.

CBR Express User Interface

CBR Express Kernel

Index File Case Base Database

Case Base API

Data IntegratorRaima Data

ManagerQ+E

SQL Server

Oracle

Figure 2. CBR Express architecture

10

3.2. Communication and progress control toolCommunication 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 madein the different activities of the project. Traditionally reporting has been done using con-ventional communication techniques such as mail, phone and facsimile. The progress ofthe project has then been estimated by the project manager based on the reports received. Itis possible that up to a week may pass between the completion of an activity and theupdate 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 andactual 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 baseon the work done within the SuperVision project [Ekl94], [Mör93], [Nyl95].

FunctionalityThe main function to be performed by the communication and progress management toolis to offer a fast and convenient media for the different parties involved to communicateover. The communication and progress management tool can be based on a client serverarchitecture with a central relational database server. Both server-client and client-clientcommunication has to be possible. Messages and files can be exchanged between theusers. An overview of the is shown in Figure 3. Another important function of the tool is tooffer automatic reminders to involved parties if an activity is running late. Perhaps themost important advantage of using a communication and progress control tool is that theproject database more accurately will reflect the current status of the project.

CheckpointsTraditional progress control requires the project manager to make an estimate of how faran activity has progressed based on knowledge of the project. This knowledge is obtainedthrough 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 needsto estimate how much of the activity is completed at a certain point in time in order to be

Project manager

Sub supplier

Communication and progress management tool

Daemon

Client

Database

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

11

able to see if the project is on schedule. The need for the project manager to estimate howmuch of an activity is completed can be eliminated by introducing of checkpoints withinan 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 injectorassembled. Each checkpoint has a percentage which indicates approximately how much ofan activity is finished when the checkpoint is reached. Checking if an activity is late isdone by calculating a date for each checkpoint using the percentage and the start- finishdate 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 thelast checkpoint should be 100.

Progress controlProgress management is the main functionality of the tool. It involves three differentphases.

• Checkpoint definition• Checkpoint confirmation• Checkpoint approval

In order for the system to be aware of an activity, which is assumed to already be present inthe 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 ispossible to define a set of default checkpoints. These can be used as a base when definingcheckpoints.Checkpoint confirmation is done by the responsible person. He is only able to see theactivities 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 forconfirming a checkpoint. Because the project manager is conceivably involved in severalprojects he has the added possibility of specifying a view of the projects. A view mayspecify 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 persondescribes the current state of the project. For each activity there is an icon whose functionis similar to that of a traffic light. If the activity is on schedule the light is green otherwiseit is red. This makes it easy for the users to get a quick overview of the activities in theproject.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 tothe project manager, the person responsible for the activity, to both of them or then noreminders can be sent.Automatic reminders can be generated by a daemon process running on the server. Thedaemon periodically checks the state of the projects in the project database. If it finds a lateactivity 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 foreach reminder level. He can also set the message generation frequency.

12

CommunicationThe 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 ofreceived messages, read as well as unread, is presented to every user when he logs in to thesystem. 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 notuncommon that both the sender and receiver of a file are not logged in simultaneously theserver is used for intermediate storage. When a user sends a file it is first transferred to theserver and then a message is sent to the receiver. The user that received the message canretrieve the file from the server to his client computer. After the file has been retrieved bythe receiver it is deleted from the server.Talk is an interactive on-line communication between two users where the text typed byone 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 talksession he chooses a recipient from a list of logged in users and a talk request is sent to therecipients computer. The talk request causes a window to be popped up on the recipientscomputer 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 ofproblematic activities. This eliminates the possibility of the project manager not noticingproblematic activities. Without this support the problematic activities might drown in thestream of information.If all changes in the projects status are updated using the system it is possible to have thesystem 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 orearly, it could affect his reliability rating.

ProgressViewA communication and progress management tool called ProgressView has been imple-mented within the SuperVision project at Åbo Akademi University [Mör93], [Nyl95]. Adetailed 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 givenbelow.The first thing to be done when starting to use ProgressView in a new project is to definethe users involved. All users are given a group and a domain. The group defines the accesslevel for the user and the domain the company or division the user belongs to. Users thathave 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 SystemsResearch Group at Åbo Akademi University for developing and implementing largeparts of the system.

13

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 theproject, 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. Atthis point the project manager usually also sets the reminder level. The project managerwould certainly want a reminder to draw his attention to a late activity. He might also wanta reminder to be sent to the responsible person in order to get an explanation for the delay.

When the users and checkpoints are entered the system is functioning. The system canthen be used for the parities to communicate over. Confirmations of reached checkpointsare sent by the responsible persons to the project manager for him to approve. Besides thisthe tool can also be used for other kinds off communication. Messages and files such asdocuments 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 theprojects he is responsible for. Late activities are indicated with a red icon and activities thatare on schedule are indicated with a green icon. By clicking on an activity in the list he canbring up the information about the checkpoints within that activity. The user of the systemcan 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 divisionthat the person is working for.The project manager has the possibility to generate reports about the activities. He choosesa certain project or domain to include in the report. The reports can be imported to e.g. aspread sheet program for further processing.

Figure 4. Snapshot of ProgressView - define checkpoint.

14

3.3. Simulation tool1

If the duration of each activity is a known constant value there are efficient schedulingalgorithms for computing the completion date of the project. Often there are situationswhere the duration of an activity is not know exactly. To explicitly take this uncertaintyinto 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 durationsare independent beta distributed variables and requires for each of them only three, usuallyeasily 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 theachieved results. But PERT´s easiness is more apparent than real: it rests upon strongassumptions whose acceptability always requires careful checking. Improper use of PERTis not rare, and generally leads to deceptive results. [Pag90]

Scheduling and Critical PathScheduling planning and the critical path concept are also affected when introducingexpected activity durations instead of fixed ones. The earliest and latest time for an eventbecome 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 ofan expected project completion time. The critical path and the expected completion timecan be determined as follows.Let p1, p2, ..., pn be paths from the source to the sink of the project and let d1, d2, ..., dn bethe sum of the random durations of the activities in the respective paths. The critical pathwill be the path with the longest duration. The expected project duration will therefore bemax(d1, d2, ..., dn).However this method can produce fallacious results if used incorrectly. This is due to thefact 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 p1, p2, ..., pn a probabil-ity of being the critical path. Since the durations are independent random variables thereare an infinite number of possible executions of the project plan. In every execution at leastone of the paths has the longest execution time, i.e. is the critical path. This implies that thepath with the maximal expected execution time is not always the path with the highestprobability of being critical. It might also be that the path with the highest probability ofbeing 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 thecritical path are as follows. Path AB had the longest duration in 20% of the cases, AC in20% 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.

15

0.6 belonging to the critical path. However A does not belong to the path E which has thehighest probability of being the critical path. [Pag90]This indicates that the notion of the critical path might not always be the best indicator ofcriticality. Instead of monitoring and controlling more closely the activities with anexpected delay of zero it would be of interest to monitor the activities with the highestprobability of belonging to the critical path. This probability is estimated by means of fre-quencies. Using some probabilistic simulation technique these frequencies can beobtained.In order to assure that the obtained results are as correct as possible the simulation shouldonly 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 buildingoften is tedious work some degree of automation in the model refinement is desirable.

Simulation net modelsSimulation nets are extended Petri nets specially designed for simulation. Simulation netswere 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 canbe 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

DSimnexA prototype of the simulation tool has been implemented. The prototype consists of amodel 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 anumber of files needed for the simulation and compiling statistics. The files generated arethe 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-

Start

A0.6

E0.4

B0.2

C0.2

D0.2

End

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

16

tics back onto the project. The simulation tool used at this point is at this point DSimnex, ageneral purpose simulation tool developed at Åbo Akademi University. DSimnex consistsof 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 resultsfrom the run and report these to the control tool. The control tool is in charge of the modelconstruction, 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 controltool to be implemented e.g. as an add-on module for some project planning tool. There is aclear advantage of having the possibility to use other machines to run the simulation onsince 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 isnearly proportional to the number of computers available for the parallel execution.Another positive consequence is a better utilisation of available computer resources.

When the simulation is performed the results are processed and mapped back to theproject. 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. Theoutput can be altered to work as virtually any tool one wants to use to display the results(spread sheets, word processors).

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

Figure 6. Snapshot of DSimnex.

17

tion of the data stock and retrieval and preprocessing of reporting data. It should providefeatures 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, asseveral planning tools have (e.g. the PM-software PSDI Project/2 Series X), this featurecan 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 accesstool 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 arisedue to the requirements of the different components using direct database access. It can benecessary to use the other form of data exchange for one of the components in order toresolve such a conflict.For the tools communication through files the import and export functions are used toexchange data with the database through the database access tool. The files exported bythe 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 enabledataflow in the opposite direction the database access tool generates files that can beimported into the components.

5. Project management process using IPMSFrom a more technical perspective we return to the management tasks supported by IPMSand look at the whole picture of the project management process. Unlike management inan on-going enterprise, project management is management of change. The kind and effortof managerial activities as well as the type of computer based tools to support them varyduring the course of a project.Figure 7 shows the flow of project management functions supported by IPMS during theproject 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 estimationand risk analysis.In the development phase the project plan has to be established. The basic plan of IPMScontains 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 theplanning 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, ithas to be replanned using the simulation tool and the planning tool. A terminated project isstored in the case base with the plan builder to save documented “experiences” for laterreuse. The reporting tool supports the extraction and visual representation of project datathrough all phases from the development of the project to the project termination.

18

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

Analyze andrefine plan

Report projectstatus

Similar cases fromthe case base

Define plan

Final project plan

Communicate withproviders and monitor

project progress

Data on plans andcourse of the

project

Store new case in the casebase

New case

Basic project plan

Supportingdocumentation

Projectdescription

Generate plan

Plan builder (3)

Planning tool (5) Simulation tool (4) Reportingtool (6)

Comm & progr ctl tool (7)

Plan builder (3)

Planning tool (5)

and change planAnalyze status

Simulation tool (4)

Estimate costs

Specific functional tools(SF)

Assess risks etc.

Specificproject data

Project phases andtypical activities1.

Main activities withIPMS

Supporting activities withIPMS

External links toIPMS

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

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

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

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

Figure 7. IPMS project management process.

19

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,AReview of Industrial Case-Based Reasoning Tools, AI Intelligence, Oxford1995.

[Bad91] Adedeji B. Badiru,STARC 2.0: An Improved PERT Network SimulationTool, 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 SupportSystem for Distrebuted Project Management, Deliverable for the PRO-DEAL Programme, Åbo Akademi University, 1994

[Hos92] O. A. Hosny,An Intelligent Decission Support System for ConstructionPlanning and Scheduling, University of Missouri - Rolla, 1992

[Kar95] Johan Karlsson,ProgressView - ett klient/server-baserat projektuppföljn-ingssystem, Master Thesis, Department of Computer Science, ÅboAkademi 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 andPERT, 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 andOperational 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 withApplication to Project Network Analysis, Proc. SIMS´94, Stockholm, 1994,144-149.

20

[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 SimulationDesigns, SIMULATION 37:6, 187-194

[Wats94] Ian Watson, Farhi Marir,Case-Based Reasoning: A Review, The Knowl-edge Engineering Review, Vol. 9, No. 3.

Turku Centre for Computer ScienceLemminkäisenkatu 14FIN-20520 TurkuFinland

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