Tài liệu Towards a conceptual reference model for project management information systems ppt

Towards a conceptual reference model for projectmanagement information systems Frederik Ahlemann Information Systems 2, European Business School, International University, Schloss Reicha

Towards a conceptual reference model for project

management information systems

Frederik Ahlemann Information Systems 2, European Business School, International University, Schloss Reichartshausen, 65375 Oestrich-Winkel, Germany

Received 17 August 2007; received in revised form 17 January 2008; accepted 31 January 2008

Abstract

Project management information systems have changed considerably over the last decade They no longer focus on scheduling and resource management alone Instead, they have become comprehensive systems that support the entire life-cycle of projects, project pro-grams, and project portfolios In this context, project-oriented organizations are facing a new challenge: the design, implementation, and operation of project management information systems have become increasingly complex Numerous processes have to be considered, diverse stakeholder interests taken into account, and corresponding software systems selected The reference information model (Ref-ModPM) presented in this article addresses this challenge and aims to accelerate the set-up of project information systems RefModPM was developed with the help of 13 domain experts from German and Swiss enterprises Furthermore, it is based on an analysis of 28 commercial project management software systems RefModPMhas already been applied in several projects and is the basis of the forth-coming German DIN norm for a standardized project management data model

Ó 2008 Elsevier Ltd and IPMA All rights reserved

Keywords: Information technology; Processes; Procedures; Managing information systems

1 Introduction

Project management information systems (PMIS) are

widely regarded as an important building block in today’s

project management [1] The nature of these systems has

changed considerably during the last decade; they are, in

fact, still developing from single-user/single-project

man-agement systems to complex, distributed, multi-functional

systems that no longer only cover project planning [2]

Information systems research has to date only partly

reflected this PMIS evolution Typical fields of research

are (1) algorithms in respect of operation research

prob-lems related to project management (e.g [3–5]), (2) the

assessment and comparison of commercial project

manage-ment solutions and corresponding assessmanage-ment frameworks

(e.g.[6–8]), (3) the development of prototypes to test new

kinds of functionality (e.g [9–11]), and (4) research into

the usage of project management software systems (e.g

[12–14]) Two specific problems are very rarely addressed: PMIS are become increasingly complex Therefore, firstly, information system designers are facing a growing number

of business processes that have to be supported with pro-ject management software Secondly, information system users have difficulties in setting up corresponding organiza-tional systems and selecting corresponding software prod-ucts An expert survey by Meyer indicates that only in approximately 20% of cases do organizations have infor-mation systems in place that support multi-project pro-gramme and portfolio management[13, p 9] In contrast, approximately 99% of organizations use information sys-tems for scheduling and time management [13, p 13] The potential of existing PMIS is clearly not being exploited at all

This article addresses these issues by presenting a refer-ence information model for enterprise-wide project man-agement that covers all project manman-agement processes that are related to planning, controlling, and coordinating

0263-7863/$30.00 Ó 2008 Elsevier Ltd and IPMA All rights reserved.

doi:10.1016/j.ijproman.2008.01.008

E-mail address: frederik.ahlemann@ebs.de

www.elsevier.com/locate/ijproman International Journal of Project Management 27 (2009) 19–30

projects (RefModPM) The model can be used for the

design of project management software, the set-up of the

surrounding organizational system, as well as for the

defi-nition of software requirements that are essential to select

a commercial project management software system

Ref-ModPM covers both single-project management and

multi-project management It is based on a single, uniform

information system architecture called M-Model and

makes use of the Unified Modeling Language (UML)

Ver-sion 2

This paper is structured as follows: section two describes

the conceptual and terminological foundation of this article

and presents a review of existing approaches to reference

modelling in respect of PMIS A brief description of the

research design and the sources of the construction process

are provided in section three Section four outlines the

architecture of the reference model, the M-Model A more

detailed exemplary excerpt of the reference model is

pre-sented in section five, which is then compared to the

mod-elling approaches presented by other authors In section

six, examples that illustrate the model’s application are

described, followed by concluding remarks that summarize

the paper

2 Foundation and related work

2.1 The role of information models in the development of

information systems

Information systems (IS) are socioeconomic systems

that comprise software, hardware, and the surrounding

organizational system Models play an important role

dur-ing the design and implementation of information systems

Depending on the phase or level of IS design and

imple-mentation, three different types of such information models

can be distinguished:

1 Conceptual models help with documenting, analyzing,

and understanding the requirements that an IS needs

to meet These models do not take any technical aspects

into consideration and focus on the problem that needs

to be solved or the processes that need to be supported

2 Conversely, design models specify the general

architec-ture of the information system by describing larger

tech-nical building blocks called components Such

components are not, however, analyzed in detail

3 Implementation models depend on specific technologies

and are closely related to software programming

In general, information models describe the static or

dynamic aspects of information systems Consequently,

models are distinguished as those presenting information

structures, i.e data structures (data models), and those

pre-senting information processes (process models) In a

nut-shell: data models lead to the design of databases,

whereas process models are generally used as a basis for

the programming of functionality

There are several graphical languages available for the modelling of IS One of the most prominent and widely used is the Unified Modeling Language (UML) [15] UML allows class diagrams to be used for data modelling and activity diagrams for process modelling

The design and implementation of information systems should be regarded as a construction process and is a topic

of design science that explores how researchers can con-struct high-quality artefacts that are good solutions to practical problems[16,17]

2.2 Reference models There is no mutual understanding of the term ‘‘reference model” [18, pp 8,19] Generally, one can distinguish between approaches that regard models as direct represen-tations of reality and approaches that follow a constructiv-ist paradigm The latter regard a model as a construction of one or various modellers This paper is based on the above-mentioned constructivist understanding of the term model

In accordance with this and in keeping with Thomas, a ref-erence model is defined as an ‘‘information model used for supporting the construction of other models”[19, p 491] The use of reference models is frequently based on the expectation that they can

 accelerate the development of information systems (a time aspect),

 reduce the associated costs (a cost aspect),

 help to communicate innovative ideas and best practices (a quality aspect), and

 reduce the risk of failure (a risk aspect)[20]

Although widely accepted in business informatics, the term reference model is not always applied The terms

‘‘standard model,” ‘‘framework” or ‘‘architecture” are fre-quently used as synonyms In the following sections, we discuss all the variant forms as long as they meet the char-acteristics of the definition presented above, are conceptual

by nature, and contain at least semi-formal information models

2.3 Previous project management reference models Approaches to the conceptual modelling of project man-agement information systems have been published since the 1980s Raymond, for example, describes a data modelling approach and illustrates it with an entity relationship model consisting of 25 entity types that describe the core data structures for single-project management [21] This data model is not, however, regarded as a normative arte-fact or as a general recommendation for information sys-tem designers

One of the first reference information models for project management in the architecture, engineering, and construc-tion (AEC) industry was published by Froese, who called it

a ‘‘standard model”[22] Proprietary object-oriented

mod-elling techniques are used to develop a project management

domain model and a corresponding application system

The term ‘‘reference information model” was first used by

Luiten et al in 1993 when they combined their individual

research activities on modelling in the architecture,

engineer-ing, and construction domain The resulting unified domain

model is called IRMA (Information Reference Model for

AEC)[23] Although not obvious at first sight, this model

largely comprises project management activities and data

structures It contains modelling results from Froese, as well

as from other researchers such as, for example, Karstila et al

[24]and Luiten and Bakkeren[25] Although IRMA has been revised several times[26], it has never been published in its entirety It was, however, used as a basis for the design and implementation of a software system called StartPlan[27] Schlagheck published a combined reference information model for process and project controlling[28]that focuses

on single project management environments with

particu-Validation

Practical Application

Documentation

Problem definition

Exploration and generation of hypotheses

Problem Definition

Literature Review / Analysis of Project Management Standards

Analysis of Project Management Software Systems

Construction of the Information System Architecture (M-Model)

Construction / Refinement of the Reference Model

Interviews with Domain Experts

Documentation

Refinement of the Reference Model

Legend

Research Phase

Research Activity

Order

Fig 1 The reference model construction process.

lar emphasis on general planning and controlling activities,

but has never been completed[28, pp 193, 211]

3 The research and construction process

The reference model construction discussed in this

arti-cle was realized within a four-phase research process –

con-ducted between 2002 and 2007 (Fig 1) – derived from a

process model for reference model construction by Schu¨tte

[29, p 177] The research comprised:

(1) Problem definition The research objective was

defined and the problem domain specified as documented

in the first section of this paper[29, p 189,28, p 79]

(2) Exploration and generation of hypotheses The second

phase consisted of three different activities:

(2a) Construction of a reference model architecture A

conceptual information system architecture was developed

that served as a frame of reference for the subsequent

model construction[29, p 207,28, p 79] This information

system architecture is called the M-Model, and is

docu-mented in Section4of this article The M-Model is the

out-come of an examination of existing research results and an

analysis of project management case studies documented in

the literature

(2b) Analysis of project management software systems A

comprehensive analysis of 28 commercial project

manage-ment software applications was used to generate

hypothe-ses on project management proceshypothe-ses and organizational

and data structures (Table 1) In the sense of reverse

engi-neering, these products’ database schemas, documentation,

and software functionality were investigated to gain

knowl-edge regarding the software vendors’ understanding of

pro-ject management information systems

(2c) Literature review/analysis of PM standards Further

research conducted by other authors and project

manage-ment institutions, for example, concerning critical success

factors in project management or project management

organization, was also taken into consideration (e.g

[30,31])

(2d) Construction/refinement of the reference model The

initial construction of the reference model was based on the

knowledge obtained from the analysis of project

manage-ment software systems and the literature review

(3) Validation The objective of this phase was to

vali-date, refine, and stabilize the initial reference model

construction

(3a) Interviews with domain experts A series of

inter-views were conducted with experts in project management

and project information systems with the objective of

gath-ering further empirical evidence for the reference model in

order to validate it (Table 2) This formative evaluation

was executed by means of guided interviews [32, p 227],

basically consisting of two parts In the first part, the

domain experts’ knowledge and experience were

deter-mined In the second part, the experts were confronted with

the reference model and asked to provide detailed feedback

on the model’s strengths and weaknesses Thereafter,

pos-sible improvements were discussed The reference model would then be refined or redesigned if the interview results indicated that this was necessary (return to step (2d)) The process was then continued Following an approach by

Table 1 Analyzed project management IS

Artemis Portfolio, Project and Resource Management Solution

Artemis International Solutions Corporation

GmbH

Systems Pvt Ltd.

PC – Projekt-Controlling-System EFK GmbH

Projektmanagement-Systeme GmbH

GmbH

ProjectExplorer, WebTime ProjectExchange, Inc.

Steuerungs-und Informationssysteme mbH

Table 2 Interview partner companies for the reference model validation phase

Agroscope FAW Wa¨denswil, Eidgeno¨ssische Forschungsanstalt fu¨r Obst-, Wein- und Gartenbau

Wa¨denswil, Switzerland

Bayerische Hypo- und Vereinsbank AG Munich, Germany

HighQITfor the financial Industry GmbH Ottobrunn-Riemerling

(Munich), Germany

Multi-national financial services company (anonymous)

Zurich, Switzerland

Lincoln and Guba[33, p 234], this cyclic process was

ter-minated when insights gained from preceding interview

dis-cussions no longer enhanced the reference model It was

then concluded that the domain experts had reached

con-sensus on the reference model’s propositions The selection

of domain experts followed both the chain sampling and

theoretical sampling approaches [32, p 237] Although

they were identified by means of chain sampling, the

inter-view topic was determined by means of the M-Model and

theoretical sampling since not all aspects of enterprise-wide

project management can be discussed in a single interview

(3b) Practical application The validation of the

refer-ence model was not only achieved through the interviews

with domain experts, but it was also validated in respect

of application projects (see Section6)

(3c) Refinement of the reference model The experience

gained in the above-mentioned projects was also used to

refine the reference model

(4) Documentation The documentation of the reference

model contains a description of the construction process,

the reference model itself, annotations of model elements,

including theoretical and empirical evidences, and the

doc-umentation of the interview results

4 The architecture of the reference model: the M-Model

The reference model is based on a single, uniform

con-ceptual architecture called the M-Model (Fig 2) The

M-model embraces all tasks related to the initiation, planning,

execution, and termination of projects It describes the

pro-cess of enterprise-wide project management (project

life-cycle) and explains the management levels involved For each element of the M-Model, process and data models are defined in RefModPM The M-Model’s two different layers indicate this

4.1 Project life-cycle Regardless of their individual objectives, projects undergo a series of phases that constitute the project life-cycle At a high level of abstraction, this life-cycle can be divided into the following phases [34, p 6,35, p 49]:

 Initiation: In the initiation phase, project ideas are gen-erated, collected, recorded, and examined (Idea Genera-tion) Their feasibility, profitability, and strategic impact are analyzed so that a final decision can be made regard-ing their implementation (Idea Evaluation) This phase ends with a formal go/no-go decision made by the man-agement team (Portfolio Planning)

 Planning: In this phase, the project idea is translated into

a project plan and the necessary resources (financial, human, and other resources) are provided (Project Prep-aration) The project manager also refines the project plan (Detailed Planning)

 Execution: In this phase, the project idea is realized through the resources assigned to the project (Project Execution) Information regarding the project execution

is collected and analyzed for controlling purposes (Pro-ject Controlling) Information is then aggregated to obtain an overall view of the project situation (Portfolio Controlling)

Data Structures Processes

Top Management:

Portfolios

Strategy Definition

Personnel and Financial Management

Project Manager:

Projects

Project Office, Committees:

Projects, Programs

Idea Generation

Idea Evaluation

Portfolio Planning

Portfolio Controlling

Project Preparation

Project Execution Detailed

Planning

Project Controlling

External Project Termination

Internal Project Termination

Fig 2 The M-Model.

 Termination: In the termination phase, the project

results are submitted to the project sponsor (Internal

Project Termination) In addition, the enterprise closes

the project and endeavours to learn from the experiences

(External Project Termination)

These phases are reflected on the outline of the ‘‘M” (see

Fig 2) and are further sub-divided into process steps, as

indicated It is not obligatory for all projects to run

through all process steps Even if a project has completed

a phase but lacks profitability and feasibility, or its

strate-gic positioning is inappropriate, it could still be terminated

immediately[36, p 545]

4.2 Management levels

Three different management levels are distinguished

within the M-Model (cp.[34, p 8,37, p 29]:

 Project manager: At the operational project

manage-ment level, the project manager is responsible for the

planning and execution of a single project This level is

represented by the lower third of the M-Model

 Project office/committees: This management level

com-prises all permanent or temporary organizational

ele-ments that are responsible for multi-project

coordination and planning and controlling activities that affect all projects, for example, the project office and committees [38, p 96,39, p 386, 40, p 129]

 Top management: The management board responsible for the entire project portfolio is represented by the upper third of the M-Model [41, p 4]

4.3 Strategy definition, personnel, and financial systems The strategy definition (the ‘‘roof” of the ‘‘M”) is a nec-essary input for portfolio planning, since it requires a clearly defined business strategy[35, p 105] On the other hand, the personnel and the financial system (the founda-tion of the ‘‘M”) are important building blocks, since they deliver information that is required for planning and con-trolling purposes such as staff availability and/or financial transactions[38, p 261, 281]

4.4 Refinement of the M-Model The reference model consists of 10 basic activity dia-grams that correspond to the project life-cycle phases

out-Table 3

Activity diagrams that are part of the RefMod PM reference model

diagrams Idea generation Generate, classify, and screen

project ideas.

1 Idea evaluation Describe project ideas, assess

their feasibility, and decide on their realization.

1

Portfolio planning Perform the organizational

budgeting, derive a project portfolio, and prioritize the projects.

1

Project Preparation Set up the project, procure

external resources.

2 Project planning Perform the detailed project

planning, including scheduling, resource assignment, etc.

1

Project execution Execute the project; manage the

project work, ensure the quality, record the resource usage, process the risks, hold team meetings.

5

Project controlling Record and communicate the

project status, process change requests, hold steering committee meetings

4

Portfolio controlling Check the budget spending and

the project performance.

1 Internal project

termination

Claim management, supplier assessment, team member assessment.

1

External project

termination

Archive project documentation, update skill profiles, do benefit controlling.

1

Table 4 Class diagrams in the RefModPMreference model M-Model element Contents (recurring contents

are not listed)

Number of diagrams

structures, lifecycle phases;

primary and secondary organizational structures, roles, resources, resource types;

scenarios, archives, baselines

3

Financial management Accounts, transactions,

currencies, cost centres, cost objects

1

Strategic planning Strategic targets,

organizational budgets, units

1 Idea generation Project classification, project

screening criteria

1 Idea evaluation Milestones, resource needs,

project cost calculations, project budgets, key performance indicators

2

Portfolio planning Budgets, resource capacities,

strategic project assessments, project portfolios

1

Project preparation Resource calendars, resource

assignments, decisions, reports, meetings, suppliers, contracts

2

Project planning Quality assurance, precedence

relationships, stakeholders, risks, risk measures

1

Project execution Documents, quality approvals,

quality measures, timesheets, meeting minutes

2

Project controlling Status reports, change requests 1

Internal project termination

Supplier assessments, staff assessments

1 External project

termination

lined in the scope of the M-Model Each of these activity

diagrams has an assigned class diagram that describes the

data structures required to run the process Some activity

diagrams are further refined, providing more detailed

pro-cess descriptions In addition to this, the reference model

contains class diagrams that indicate the interfaces to

per-sonnel and financial systems, as well as to the strategic

planning process These diagrams moreover specify the

data required from those related systems Furthermore,

some of the fundamental data structures – specifically

orga-nizational structures, basic resource data, and elemental

classes that describe the structure of projects – that are used

throughout the project life-cycle are also presented in

sep-arate class diagrams Altogether, the reference model

com-prises 18 activity diagrams (Table 3.), 18 class diagrams

(Table 4.), 101 classes, 112 methods, and 245 attributes

The level of detail is adequate for organizational

model-ling, but requires further refinement for software design

and implementation

5 An exemplary excerpt: modelling of programs, projects,

and work breakdown structures

Owing to its size, it is not possible to present RefModPM

in its entirety Instead, this section contains an excerpt from

the RefModPMreference model, which has been chosen as it

is relatively easy to understand and is fundamental to the

rest of the reference model It consists of a class diagram that

covers project master data, the work breakdown structure,

and the assignment of projects to project programs The

excerpt is about baselines and scenario management It

can actually be compared to the work of Froese and

Schlag-heck, as both have corresponding model elements in their

reference model Other project management areas are not

referred to in this section For an easier comparison, all three

reference models have been drawn using the same modelling

language (UML 2) Moreover, the relevant model elements

are concentrated in a single diagram In the textual

descrip-tion, class names are provided in brackets

In the following sections, general requirements for the

modelling of project master data gathered from literature

and reverse engineering are discussed (see Section 3)

Thereafter, an explanation is provided on how Froese

and Schlagheck model the domain Finally, the RefModPM

excerpt is introduced and compared to the work of Froese

and Schlagheck to substantiate its maturity in respect of

previous reference models

5.1 Requirements

During the research process, the following general

requirements regarding the modelling of project master data,

project structures, baselines, and scenarios were deduced:

1 Projects, work packages, and activities require a

com-prehensive set of attributes that allows the project to

be fully described, planned, and controlled

2 The work breakdown structure may have any number of levels

3 All project management methods (e.g., risk, quality, resource, and cost management methods) must be appli-cable to any level of the work breakdown structure, the project itself, and project programs

4 It must be possible to save any number of project base-lines for management and controlling purposes

5 There should be at least three specific plan versions of any project: (a) the original plan approved by manage-ment, (b) the current plan containing all changes result-ing from approved change requests, and (c) the actual data

6 Scenarios must ‘‘behave” like a normal project plan Any project management method should be applicable

to a scenario

7 Projects must be clearly assigned to a life-cycle phase or project status There must be clarity regarding the phase

in which a project is at a specific point in time, as well as when this status changes

8 For the purpose of multi project management, it must

be possible to present projects in a hierarchical system

5.2 Reference model by Froese According to Froese, a project (Project) is characterized

by a project number, a construction plan, contracts, a facil-ity, a location, and participants (Fig 4)

The construction plan (ConstructionPlan) itself consists

of several activities (Activity) that can form an activity net-work and have attributes for storing the results of a sched-uling process Each activity has an assigned activity category (ActivityCategory) that ‘‘represents the category

of construction effort that involves the application of a par-ticular action to a specific set of component categories using a method and, typically, a set of resources.” [22, p 87] The time, resource, and cost management are entirely based on activities

Evidently, Froese’s model is not able to meet the requirements described above One fundamental limitation

of his model is that it does not support work breakdown structures Moreover, it only ‘‘knows” planning data; actual data or even scenarios are not supported

5.3 Reference model by Schlagheck Schlagheck follows a completely different approach to Froese when it comes to model project structures (Fig 5) According to Schlagheck, projects (Project) are arranged

in a hierarchy and are characterized by an objective and a status Each project has exactly one project plan A work breakdown structure (WorkBreakdownStructure) is a spe-cial project plan and consists of WBS elements (WBSEle-ment) that also form a hierarchy A WBS element can either be a sub-project, a task, a work package or an activity

Schlagheck’s model is clearly more advanced than

Fro-ese’s It allows work breakdown structures with an

unlim-ited number of levels to be set up Consequently,

Schlagheck is at least able to meet requirement 2

5.4 RefModPM

RefModPM tries to meet the requirements outlined

above by introducing a very fundamental data structure

called Initiative (Fig 3) An initiative is a generalization

of any form of action that has a defined start and end date

and is undertaken to reach a goal Therefore, an initiative

may be a program, a project, a sub-project, a project phase,

a work package, an activity or a task (indicated by the

inheritance relationship between these classes) By using a

generic data structure for these different types of objects,

project management methods from, for example, risk,

quality, resource or cost management can be implemented

to be applicable to all of them by employing the class Ini-tiative (requirement 3) IniIni-tiatives are characterized by a relatively large set of attributes covering scope, time, and risk management (other functional areas of project man-agement like resource or cost manman-agement are covered by other data structures) RefModPMthus meets requirement 1

By means of a reflexive association, initiatives form a hierarchy that can be used to (a) set up a work breakdown structure, (b) create programs by subsuming several pro-jects, or (c) arrange projects in a multi project management environment, for example, in the form of an organizational structure (requirements 2, 8)

A life-cycle phase (LifeCyclePhase) divides an initia-tive’s lifetime into several standardized time spans The beginning or ending of such a time span can be recorded

-ID -Name -Description -Comment -Objective -Activities -Conditions -Dependencies -StartDate -EndDate -LatestStartDate -EarliestStartDate -LatestEndDate -EarliestEndDate -Effort -Float -Duration -Risk -PostponedUntil -Priority -ResourcePlanningType -Mandatory

«Orga, IT»

Initiative

-Parent 0 1

-Child

0 *

-Name -Chargable

«Orga, IT, Config»

LifeCyclePhase

1

0 *

«Orga»

Programme

«Orga»

Project

«Orga»

SubProject

«Orga»

WorkPackage

«Orga»

Task

-VersionNumber -CreationDate -Description -Editable

«Orga, IT»

PlanVersion

0 1

0 *

0 1

0 *

0 1

0 *

«Orga»Scenario

«Orga»PlanArchive

-Date -Decision -Comment

«Orga, IT»

InitiativeLifeCyclePhase

1 *

1

1

0 *

«Orga»

Phase

1

0 *

«Orga»

Baseline

Fig 3 Project master data in RefModPM.

ProjectSpecificObject

-Contracts

-Facility

-Location

-Particiapants

Project

-DefaultConstructionMethod -DurationUnits

ConstructionPlan

1

1

-Components -EarlyFinish -EarlyStart -LateFinish -LateStart -Duration -TotalFloat

Activity

1

*

-Action -ComponentCategories -Method

-PartOf -QuantityFormula -

ActivityCategory

1

*

-Successor

*

-Predecessor * Fig 4 Project master data according to Froese.

-Objective

-Status

Project

-Hierarchy 0 1

ProjectPlan

WorkBreakdownStructure

WorkBreakdownStructurePlanning

-Description

WBSElement

1 1 *

-Hierarchy

0 1 0 *

SubProject

Task

WorkPackage

Activity

-Hierarchy

0 1 0 *

Fig 5 Work breakdown structure according to Schlageheck.

in respect of each initiative (InitiativeLifeCyclePhase).

Consequently, the overall initiative life-cycle is transparent

(requirement 7) This data structure pattern can be used to

implement different life-cycle models and enables software

systems developed with RefModPMto enforce a compliant

project execution Consequently, a system can ensure that

all necessary approval steps are carried out before a project

actually begins

Each project plan can be archived as often as necessary

by means of a plan version (PlanVersion) A plan version is

a complete set of planning data covering all aspects of

pro-ject management, like time, cost, risk, or resource data (not

shown in the excerpt) and is usually created by copying the

actual project plan Plan versioning can be used to create

baselines at certain points in time (PlanArchive) However,

plan versions can also be used as a starting point for

sce-nario planning (Scesce-nario, requirement 6) Since the plan

versioning concept is based on the Initiative class, it is

pos-sible to use this kind of functionality for entire projects or

even project portfolios on any level of the WBS Although

a user can create an infinite number of plan versions

(requirement 4), RefModPMallows three specific plan

ver-sions to be assigned to each initiative (requirement 5)

Apart from meeting empirically gathered requirements,

our model also impacts the efficiency of software

develop-ment During the practical application of the model, we

discovered that the Initiative and PlanVersion data

struc-tures can significantly reduce development efforts when

properly implemented Software manufacturers state that

they can now combine software features that previously had to be developed separately This reduces costs and development time as, for example, carefully implemented plan version functionality almost automatically yields the largest part of a full-featured scenario management In addition, the Initiative data structure allows the same soft-ware functionality to be used for risk, quality, time and resource management on both the work package, project and portfolio levels This is a significant benefit when com-pared to the approaches of present-day PM software sys-tems that usually apply different data structures for work packages, projects and portfolios

5.5 Conclusions The discussion of the model excerpt indicates that Ref-ModPMgoes beyond the scope of previous reference mod-els This is not surprising, since RefModPMuses some ideas from previous work and extends it according to additional requirements Table 5 demonstrates the extent to which RefModPM represents significant research progress in the field of PMIS reference models, since it

 has a significantly wider scope, covering not only project planning and execution, but also the initiation and ter-mination phase,

 has been designed to serve both single and multi project management purposes, and

 covers all functional areas of PMI’s PMBOK

Table 5

RefModPMcompared to existing reference information models for project management

Domain Characteristics

Covered b

(Semi-)Formal models available for

Other characteristics

Research methodology

a Processes are only modeled implicitly, representing process steps (activities) in the data model.

b According to the nine knowledge areas of the Project Management Body of Knowledge (PMBOK) [PMI04, 9].

c A prototype has been developed, although it is unclear whether this prototype has been evaluated.