Available online at www.sciencedirect.comwww.elsevier.com/locate/ijproman

International Journal of Project Management 27 (2009) 1930Towards a conceptual reference model for projectmanagement 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 2008Abstract

Project management information systems have changed considerably over the last decade. They no longer focus on scheduling andresource 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, andoperation 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 28commercial project management software systems. RefModPM has 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 systems1. Introduction

Project management information systems (PMIS) arewidely regarded as an important building block in todaysproject management [1]. The nature of these systems haschanged considerably during the last decade; they are, infact, still developing from single-user/single-project man-agement systems to complex, distributed, multi-functionalsystems that no longer only cover project planning [2].Information systems research has to date only partlyreflected this PMIS evolution. Typical fields of researchare (1) algorithms in respect of operation research prob-lems related to project management (e.g. [35]), (2) theassessment and comparison of commercial project manage-ment solutions and corresponding assessment frameworks(e.g. [68]), (3) the development of prototypes to test newkinds of functionality (e.g. [911]), and (4) research into0263-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.dethe usage of project management software systems (e.g.[1214]). Two specific problems are very rarely addressed:PMIS are become increasingly complex. Therefore, firstly,information system designers are facing a growing numberof business processes that have to be supported with pro-ject management software. Secondly, information systemusers have difficulties in setting up corresponding organiza-tional systems and selecting corresponding software prod-ucts. An expert survey by Meyer indicates that only inapproximately 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 beingexploited at all.

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

mailto:frederik.ahlemann@ebs.de

20 F. Ahlemann / International Journal of Project Management 27 (2009) 1930projects (RefModPM). The model can be used for thedesign of project management software, the set-up of thesurrounding organizational system, as well as for the defi-nition of software requirements that are essential to selecta commercial project management software system. Ref-ModPM covers both single-project management andmulti-project management. It is based on a single, uniforminformation system architecture called M-Model andmakes use of the Unified Modeling Language (UML) Ver-sion 2.

This paper is structured as follows: section two describesthe conceptual and terminological foundation of this articleand presents a review of existing approaches to referencemodelling in respect of PMIS. A brief description of theresearch design and the sources of the construction processare provided in section three. Section four outlines thearchitecture of the reference model, the M-Model. A moredetailed 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 sectionsix, examples that illustrate the models application aredescribed, followed by concluding remarks that summarizethe paper.

2. Foundation and related work

2.1. The role of information models in the development of

information systems

Information systems (IS) are socioeconomic systemsthat comprise software, hardware, and the surroundingorganizational 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 modelscan be distinguished:

1. Conceptual models help with documenting, analyzing,and understanding the requirements that an IS needsto meet. These models do not take any technical aspectsinto consideration and focus on the problem that needsto 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. Suchcomponents are not, however, analyzed in detail.

3. Implementation models depend on specific technologiesand are closely related to software programming.

In general, information models describe the static ordynamic aspects of information systems. Consequently,models are distinguished as those presenting informationstructures, 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 forthe programming of functionality.There are several graphical languages available for themodelling of IS. One of the most prominent and widelyused is the Unified Modeling Language (UML) [15].UML allows class diagrams to be used for data modellingand activity diagrams for process modelling.

The design and implementation of information systemsshould be regarded as a construction process and is a topicof design science that explores how researchers can con-struct high-quality artefacts that are good solutions topractical problems [16,17].

2.2. Reference models

There is no mutual understanding of the term referencemodel [18, pp. 8,19]. Generally, one can distinguishbetween 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 ofone 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 forsupporting the construction of other models [19, p. 491].The use of reference models is frequently based on theexpectation that they can

accelerate the development of information systems (atime 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, theterm reference model is not always applied. The termsstandard model, framework or architecture are fre-quently used as synonyms. In the following sections, wediscuss all the variant forms as long as they meet the char-acteristics of the definition presented above, are conceptualby nature, and contain at least semi-formal informationmodels.

2.3. Previous project management reference models

Approaches to the conceptual modelling of project man-agement information systems have been published since the1980s. Raymond, for example, describes a data modellingapproach and illustrates it with an entity relationshipmodel consisting of 25 entity types that describe the coredata structures for single-project management [21]. Thisdata 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 projectmanagement in the architecture, engineering, and construc-tion (AEC) industry was published by Froese, who called ita standard model [22]. Proprietary object-oriented mod-

F. Ahlemann / International Journal of Project Management 27 (2009) 1930 21elling techniques are used to develop a project managementdomain model and a corresponding application system.

The term reference information modelwas first used byLuiten et al. in 1993 when they combined their individualresearch activities onmodelling in the architecture, engineer-ing, and construction domain. The resulting unified domainmodel is called IRMA (Information Reference Model forAEC) [23]. Although not obvious at first sight, this modellargely comprises project management activities and dataValidation

Practical Appl

Documentation

Problem definition

Exploration and generation of hypotheses

Problem Def

Literature Review / Analysis of Project Management Standards

Construction of theSystem Architectur

Construction / RefinReference M

Interviews with Dom

Documenta

Refinementhe Reference

Legend

Research Phase

Fig. 1. The reference modestructures. It contains modelling results from Froese, as wellas from other researchers such as, for example, Karstila et al.[24] andLuiten andBakkeren [25].Although IRMAhas beenrevised several times [26], it has never been published in itsentirety. It was, however, used as a basis for the design andimplementation of a software system called StartPlan [27].

Schlagheck published a combined reference informationmodel for process and project controlling [28] that focuseson single project management environments with particu-ication

inition

Analysis of Project Management Software Systems

Information e (M-Model)

ement of the odel

ain Experts

tion

t of Model

Research Activity

Order

l construction process.

Table 1Analyzed project management IS

Product Company

Acos Plus.1 ACOS Projektmanagement GmbHAlpha Project Line HISC AG ProjektmanagementAMS Realtime Projects Advanced Management SolutionsArtemis Portfolio, Project and

Resource Management SolutionArtemis International SolutionsCorporation

Cat4 Cataligent Projekt GmbHeRoom eRoom Technology, Inc.fx-project FeRox Management Consulting

GmbHiPlan Integrated Strategic Information

Systems Pvt. Ltd.Nucleus ESNA LimitedOurProject ACME InteractivePC Projekt-Controlling-System EFK GmbHPlanview PlanView United StatesPPMS PLANTA Projektmanagement-

Systeme GmbHPQM PUS Prozess- und Systemtechnik

GmbHPrimavera P3e PrimaveraProject Insight Metafuse, Inc.Project Scheduler Sciforma CorporationProjectExplorer, WebTime ProjectExchange, Inc.Projekta BBL Software GmbHProlog Scheduler Meridian Project SystemsProMOS NesbitPSIPENTA PM GSI Gesellschaft fur Steuerungs-

und Informationssysteme mbHresSolution Scheuring Project Management AGSureTrak Project Manager PrimaveraTeamcenter Project EDS PLM SolutionsuntermStrich untermStrich software GmbHVertabase Pro Standpipe Studios Inc.vProject MediaSolv.com Inc.

Table 2Interview partner companies for the reference model validation phase

Company Location

Agroscope FAW Wadenswil, EidgenossischeForschungsanstalt fur Obst-, Wein- undGartenbau

Wadenswil, Switzerland

BASF AG Ludwigshafen, GermanyBayerische Hypo- und Vereinsbank AG Munich, GermanyCredit Suisse Zurich, SwitzerlandEADS Deutschland GmbH Ulm, GermanyHenkel KGaA Dusseldorf, GermanyHighQIT for the financial Industry GmbH Ottobrunn-Riemerling

(Munich), GermanyInfineon Technologies AG Munich, GermanyMulti-national financial services company

(anonymous)Zurich, Switzerland

Softlab GmbH Hamburg, GermanyT-Systems International GmbH Erfurt, GermanyThyssenKrupp Stahl AG Duisburg, GermanyVattenfall Europe Berlin, Germany

22 F. Ahlemann / International Journal of Project Management 27 (2009) 1930lar 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 aprocess model for reference model construction by Schutte[29, p. 177]. The research comprised:

(1) Problem definition. The research objective wasdefined and the problem domain specified as documentedin the first section of this paper [29, p. 189,28, p. 79].

(2) Exploration and generation of hypotheses. The secondphase consisted of three different activities:

(2a) Construction of a reference model architecture. Aconceptual information system architecture was developedthat served as a frame of reference for the subsequentmodel construction [29, p. 207,28, p. 79]. This informationsystem architecture is called the M-Model, and is docu-mented in Section 4 of this article. The M-Model is the out-come of an examination of existing research results and ananalysis of project management case studies documented inthe literature.

(2b) Analysis of project management software systems. Acomprehensive analysis of 28 commercial project manage-ment software applications was used to generate hypothe-ses on project management processes and organizationaland 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. Furtherresearch conducted by other authors and project manage-ment institutions, for example, concerning critical successfactors in project management or project managementorganization, was also taken into consideration (e.g.[30,31]).

(2d) Construction/refinement of the reference model. Theinitial construction of the reference model was based on theknowledge 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 modelconstruction.

(3a) Interviews with domain experts. A series of inter-views were conducted with experts in project managementand project information systems with the objective of gath-ering further empirical evidence for the reference model inorder to validate it (Table 2). This formative evaluationwas executed by means of guided interviews [32, p. 227],basically consisting of two parts. In the first part, thedomain experts knowledge and experience were deter-mined. In the second part, the experts were confronted withthe reference model and asked to provide detailed feedbackon the models strengths and weaknesses. Thereafter, pos-sible improvements were discussed. The reference modelwould then be refined or redesigned if the interview resultsindicated that this was necessary (return to step (2d)). Theprocess was then continued. Following an approach by

F. Ahlemann / International Journal of Project Management 27 (2009) 1930 23Lincoln 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 wasthen concluded that the domain experts had reached con-sensus on the reference models propositions. The selectionof domain experts followed both the chain sampling andtheoretical sampling approaches [32, p. 237]. Althoughthey were identified by means of chain sampling, the inter-view topic was determined by means of the M-Model andtheoretical sampling since not all aspects of enterprise-wideproject management can be discussed in a single interview.

(3b) Practical application. The validation of the refer-ence model was not only achieved through the interviewswith domain experts, but it was also validated in respectof application projects (see Section 6).

(3c) Refinement of the reference model. The experiencegained in the above-mentioned projects was also used torefine the reference model.

(4) Documentation. The documentation of the referencemodel 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-Top Management:Portfolios

Strategy Def

Personnel and Financ

ProjectManager:Projects

ProjectOffice,Committees:Projects,Programs

IdeaGeneration

IdeaEvaluation

PortfolioPlanning

ProjectPreparation

PEx

DetailedPlanning

Fig. 2. The Mcycle) and explains the management levels involved. Foreach element of the M-Model, process and data modelsare defined in RefModPM. The M-Models two differentlayers indicate this.

4.1. Project life-cycle

Regardless of their individual objectives, projectsundergo a series of phases that constitute the project life-cycle. At a high level of abstraction, this life-cycle can bedivided 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 impactare analyzed so that a final decision can be made regard-ing their implementation (Idea Evaluation). This phaseends with a formal go/no-go decision made by the man-agement team (Portfolio Planning). Planning: In this phase, the project idea is translated intoa project plan and the necessary resources (financial,human, and other resources) are provided (Project Prep-aration). The project manager also refines the projectplan (Detailed Planning). Execution: In this phase, the project idea is realizedthrough the resources assigned to the project (ProjectExecution). Information regarding the project executionis collected and analyzed for controlling purposes (Pro-ject Controlling). Information is then aggregated toobtain an overall view of the project situation (PortfolioControlling).Data Structures

Processes

inition

ial Management

PortfolioControlling

rojectecution

ProjectControlling

ExternalProject

Termination

InternalProject

Termination

-Model.

Table 4Class diagrams in the RefModPM reference model

M-Model element Contents (recurring contents Number of

24 F. Ahlemann / International Journal of Project Management 27 (2009) 1930 Termination: In the termination phase, the projectresults are submitted to the project sponsor (InternalProject Termination). In addition, the enterprise closesthe project and endeavours to learn from the experiences(External Project Termination).

These phases are reflected on the outline of the M (seeFig. 2) and are further sub-divided into process steps, asindicated. It is not obligatory for all projects to runthrough all process steps. Even if a project has completeda phase but lacks profitability and feasibility, or its strate-gic positioning is inappropriate, it could still be terminatedimmediately [36, p. 545].

4.2. Management levels

Three different management levels are distinguishedwithin 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 theplanning and execution of a single project. This level isrepresented 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-projectTable 3Activity diagrams that are part of the RefModPM reference model

M-Model element Contents Number ofdiagrams

Idea generation Generate, classify, and screenproject ideas.

1

Idea evaluation Describe project ideas, assesstheir feasibility, and decide ontheir realization.

1

Portfolio planning Perform the organizationalbudgeting, derive a projectportfolio, and prioritize theprojects.

1

Project Preparation Set up the project, procureexternal resources.

2

Project planning Perform the detailed projectplanning, including scheduling,resource assignment, etc.

1

Project execution Execute the project; manage theproject work, ensure thequality, record the resourceusage, process the risks, holdteam meetings.

5

Project controlling Record and communicate theproject status, process changerequests, hold steeringcommittee meetings

4

Portfolio controlling Check the budget spending andthe project performance.

1

Internal projecttermination

Claim management, supplierassessment, team memberassessment.

1

External projecttermination

Archive project documentation,update skill profiles, do benefitcontrolling.

1

coordination and planning and controlling activitiesthat affect all projects, for example, the project officeand committees [38, p. 96,39, p. 386, 40, p. 129]. Top management: The management board responsiblefor the entire project portfolio is represented by theupper 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 aclearly defined business strategy [35, p. 105]. On the otherhand, the personnel and the financial system (the founda-tion of the M) are important building blocks, since theydeliver information that is required for planning and con-trolling purposes such as staff availability and/or financialtransactions [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-are not listed) diagrams

Foundation Projects, work breakdownstructures, lifecycle phases;primary and secondaryorganizational structures, roles,resources, resource types;scenarios, archives, baselines

3

Financial management Accounts, transactions,currencies, cost centres, costobjects

1

Strategic planning Strategic targets,organizational budgets, units

1

Idea generation Project classification, projectscreening criteria

1

Idea evaluation Milestones, resource needs,project cost calculations,project budgets, keyperformance indicators

2

Portfolio planning Budgets, resource capacities,strategic project assessments,project portfolios

1

Project preparation Resource calendars, resourceassignments, decisions, reports,meetings, suppliers, contracts

2

Project planning Quality assurance, precedencerelationships, stakeholders,risks, risk measures

1

Project execution Documents, quality approvals,quality measures, timesheets,meeting minutes

2

Project controlling Status reports, change requests 1Portfolio controlling Budget spending reports 1Internal project

terminationSupplier assessments, staffassessments

1

External projecttermination

. . . 1

F. Ahlemann / International Journal of Project Management 27 (2009) 1930 25lined in the scope of the M-Model. Each of these activitydiagrams has an assigned class diagram that describes thedata structures required to run the process. Some activitydiagrams are further refined, providing more detailed pro-cess descriptions. In addition to this, the reference modelcontains class diagrams that indicate the interfaces to per-sonnel and financial systems, as well as to the strategicplanning process. These diagrams moreover specify thedata required from those related systems. Furthermore,some of the fundamental data structures specifically orga-nizational structures, basic resource data, and elementalclasses that describe the structure of projects that are usedthroughout 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 designand 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 fromthe RefModPM reference model, which has been chosen as itis relatively easy to understand and is fundamental to therest of the reference model. It consists of a class diagram thatcovers project master data, the work breakdown structure,and the assignment of projects to project programs. Theexcerpt is about baselines and scenario management. Itcan actually be compared to the work of Froese and Schlag-heck, as both have corresponding model elements in theirreference model. Other project management areas are notreferred to in this section. For an easier comparison, all threereference models have been drawn using the same modellinglanguage (UML 2). Moreover, the relevant model elementsare concentrated in a single diagram. In the textual descrip-tion, class names are provided in brackets.

In the following sections, general requirements for themodelling of project master data gathered from literatureand reverse engineering are discussed (see Section 3).Thereafter, an explanation is provided on how Froeseand Schlagheck model the domain. Finally, the RefModPM

excerpt is introduced and compared to the work of Froeseand Schlagheck to substantiate its maturity in respect ofprevious reference models.

5.1. Requirements

During the research process, the following generalrequirements regarding themodelling of projectmaster 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 tobe fully described, planned, and controlled.2. The work breakdown structure may have any number oflevels.

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, theproject 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 ofany 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 actualdata.

6. Scenarios must behave like a normal project plan.Any project management method should be applicableto a scenario.

7. Projects must be clearly assigned to a life-cycle phase orproject status. There must be clarity regarding the phasein which a project is at a specific point in time, as well aswhen this status changes.

8. For the purpose of multi project management, it mustbe possible to present projects in a hierarchical system.

5.2. Reference model by Froese

According to Froese, a project (Project) is characterizedby a project number, a construction plan, contracts, a facil-ity, a location, and participants (Fig. 4).

The construction plan (ConstructionPlan) itself consistsof 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 activitycategory (ActivityCategory) that represents the categoryof construction effort that involves the application of a par-ticular action to a specific set of component categoriesusing a method and, typically, a set of resources. [22, p.87] The time, resource, and cost management are entirelybased on activities.

Evidently, Froeses model is not able to meet therequirements described above. One fundamental limitationof his model is that it does not support work breakdownstructures. 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 toFroese when it comes to model project structures (Fig. 5).According to Schlagheck, projects (Project) are arrangedin a hierarchy and are characterized by an objective and astatus. Each project has exactly one project plan. A workbreakdown structure (WorkBreakdownStructure) is a spe-cial project plan and consists of WBS elements (WBSEle-ment) that also form a hierarchy. A WBS element caneither be a sub-project, a task, a work package or anactivity.

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

Orga, ITInitiative

-Parent0..1

-Child

0..*

-Name-Chargable

Orga, IT, ConfigLifeCyclePhase

1

0..*

OrgaProgramme

OrgaProject

OrgaSubProject

OrgaWorkPackage

OrgaTask

-VersionNumber-CreationDate-Description-Editable

Orga, ITPlanVersion

0..1

-App

oved

Plan

0..*

0..1

-Act

ualP

lan

0..*

0..1

-Bas

ePla

n

0..*

OrgaScenario

OrgaPlanArchive

-Date-Decision-Comment

Orga, ITInitiativeLifeCyclePhase

1..*

1

1

0..*

OrgaPhase

1

0..*

OrgaBaseline

Fig. 3. Project master data in RefModPM.

26 F. Ahlemann / International Journal of Project Management 27 (2009) 1930Schlaghecks model is clearly more advanced than Fro-eses. 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 outlinedabove by introducing a very fundamental data structurecalled Initiative (Fig. 3). An initiative is a generalizationof any form of action that has a defined start and end dateand is undertaken to reach a goal. Therefore, an initiativemay be a program, a project, a sub-project, a project phase,a work package, an activity or a task (indicated by theinheritance relationship between these classes). By using ageneric data structure for these different types of objects,project management methods from, for example, risk,quality, resource or cost management can be implementedto be applicable to all of them by employing the class Ini-tiative (requirement 3). Initiatives are characterized by arelatively large set of attributes covering scope, time, andrisk management (other functional areas of project man-agement like resource or cost management are covered byother data structures). RefModPM thus meets requirement1.

By means of a reflexive association, initiatives form ahierarchy that can be used to (a) set up a work breakdownstructure, (b) create programs by subsuming several pro-jects, or (c) arrange projects in a multi project managementenvironment, for example, in the form of an organizationalstructure (requirements 2, 8).

A life-cycle phase (LifeCyclePhase) divides an initia-tives lifetime into several standardized time spans. Thebeginning or ending of such a time span can be recorded

-ProjectNumberProjectSpecificObject

-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

0..* -ResponsiblePersonProjectPlan

1 1

WorkBreakdownStructure

WorkBreakdownStructurePlanning-DescriptionWBSElement

1 1..*

-Hierarchy

0..1

0..*

SubProject

Task

WorkPackage

Activity

-Hierarchy

0..1

0..*

Fig. 5. Work breakdown structure according to Schlageheck.

F. Ahlemann / International Journal of Project Management 27 (2009) 1930 27

28 F. Ahlemann / International Journal of Project Management 27 (2009) 1930in respect of each initiative (InitiativeLifeCyclePhase).Consequently, the overall initiative life-cycle is transparent(requirement 7). This data structure pattern can be used toimplement different life-cycle models and enables softwaresystems developed with RefModPM to enforce a compliantproject execution. Consequently, a system can ensure thatall necessary approval steps are carried out before a projectactually begins.

Each project plan can be archived as often as necessaryby means of a plan version (PlanVersion). A plan version isa complete set of planning data covering all aspects of pro-ject management, like time, cost, risk, or resource data (notshown in the excerpt) and is usually created by copying theactual project plan. Plan versioning can be used to createbaselines at certain points in time (PlanArchive). However,plan versions can also be used as a starting point for sce-nario planning (Scenario, requirement 6). Since the planversioning concept is based on the Initiative class, it is pos-sible to use this kind of functionality for entire projects oreven project portfolios on any level of the WBS. Althougha user can create an infinite number of plan versions(requirement 4), RefModPM allows 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, wediscovered that the Initiative and PlanVersion data struc-tures can significantly reduce development efforts whenproperly implemented. Software manufacturers state thatTable 5RefModPM compared to existing reference information models for project ma

Froese (1992)

Domain Characteristics

Project lifecycle phases PlanningManagement levels ProjectSupported industries Construction industryCoveredb

Integration management NoScope management YesTime management YesCost management YesQuality management NoHuman resource management NoCommunications management NoRisk management NoProcurement management Yes(Semi-)Formal models available forData structures YesOrganizational structures YesProcesses Noa

Other characteristics

Number of classes/object types 36Modeling language(s) SOL (Proprietary)Research methodology

Model evaluation Yesc

Documentation of design and evaluation methods NoCommunication of research Yes

a Processes are only modeled implicitly, representing process steps (activitiesb According to the nine knowledge areas of the Project Management Bodyc A prototype has been developed, although it is unclear whether this protothey can now combine software features that previouslyhad to be developed separately. This reduces costs anddevelopment time as, for example, carefully implementedplan version functionality almost automatically yields thelargest part of a full-featured scenario management. Inaddition, the Initiative data structure allows the same soft-ware functionality to be used for risk, quality, time andresource management on both the work package, projectand 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 workpackages, projects and portfolios.

5.5. Conclusions

The discussion of the model excerpt indicates that Ref-ModPM goes beyond the scope of previous reference mod-els. This is not surprising, since RefModPM uses some ideasfrom previous work and extends it according to additionalrequirements. Table 5. demonstrates the extent to whichRefModPM represents significant research progress in thefield of PMIS reference models, since it

has a significantly wider scope, covering not only projectplanning and execution, but also the initiation and ter-mination phase, has been designed to serve both single and multi projectmanagement purposes, and covers all functional areas of PMIs PMBOK.nagement

Schlagheck (2000) RefModPM

Planning, execution Initiation, planning, execution, terminationProject Project, program, portfolioAny Any

No YesYes YesYes YesYes YesYes YesNo YesNo YesNo YesNo Yes

Yes YesNo YesYes Yes

20 101UML 1 UML 2

No YesNo YesYes Yes

) in the data model.of Knowledge (PMBOK) [PMI04, 9].type has been evaluated.

F. Ahlemann / International Journal of Project Management 27 (2009) 1930 29 Moreover, the research methodology underlying themodel construction and evaluation is presented. Thecomplete reference model has been made available tothe public in book form.6. Application of RefModPM

6.1. Software specification and selection

As RefModPM is a conceptual reference model for PMIS,it will be especially useful in cases where organizations striveto introduce a new project management software by eitherdeveloping one or by rolling out a commercial off the shelfpackage. RefModPM can first of all be used as a foundationfor the software specification and design. Secondly, it canserve as a basis for defining requirements that commercialsoftware needs to meet. In both cases, the following proce-dure is recommended to fully benefit from the knowledgecontained in the reference model:

1. Define the process steps and layers from the M-Modelthat are relevant to the project. This leads to a high-levelscope definition that allows the class and activity dia-grams to be selected that need to be taken intoconsideration.

2. Modify the activity diagrams to truly fit individual com-pany needs. The reference models process descriptionsare sometimes too detailed, whilst other times theymay require further refinement.

3. Adapt the class diagrams in accordance with the activitydiagrams. Here, data structures that are no longerreferred to by any process steps are deleted. Additionally,it might become necessary to refine the data structure toaccommodate more detailed process descriptions.

4. Specify requirements: With regard to software develop-ment, the resulting company-specific model can be usedto provide more detailed software specifications, forexample, for the development of use cases or user stories.When commercial software needs to be selected, the pro-cess and data descriptions are translated into a list ofrequirements. Practical experience has shown that, as arule of thumb, one process step can be transformed intoone requirement. In action research projects, we havelearned that the reference models application can accel-erate requirements engineering and software selectionprojects significantly. Subject matter experts estimatethat it can reduce efforts by 3050%.6.2. Other application examples

The application of RefModPM is not limited to the spec-ification and introduction of PM software. The followingcases illustrate its wide applicability:

1. It was used to develop a new project initiation and port-folio management process for a multinational high-techcompany headquarters in Switzerland. Within a one-dayworkshop, the cornerstones of this process were speci-fied by using the reference model as a template.

2. The reference model was used as the basis for a newDIN (German Institute for Standardization) projectmanagement data model standard. A working groupof the German Association of Project Management(GPM), consisting of 15 project management softwarevendors, consulting firms, and project managementexperts from diverse companies, developed acomprehensive XML schema for project manage-ment data exchange within six months by using Ref-ModPM [42,43]. DIN will publish the data modelduring 2008.

3. The result of this work has also been used in several soft-ware development projects such as by PLANTA, one ofthe leading German project management software ven-dors [44, p. 4]. Another vendor is currently developinga completely new software system based on RefModPM.

4. The reference model is currently being used for the con-struction of a comprehensive project management ontol-ogy that forms the basis of endeavours in the areas ofEnterprise Application Integration (EAI) and Knowl-edge Management [45].7. Summary

This paper has introduced RefModPM, a new conceptualinformation system reference model for project and projectportfolio management. RefModPM tries to overcome exist-ing reference models deficiencies by covering more aspectsof project management and offering data structures andprocesses that have been validated empirically and haveproven to be stable, flexible, and accepted by subject matterexperts. The development of the first version of RefModPM

took approximately 1.5 man-years to complete. We arecurrently working on an extended second version of Ref-ModPM that is scheduled to be completed during 2008.

Several software manufacturers that develop new prod-ucts or product versions are currently using RefModPM.The adoption of RefModPM is also promoted throughthe second, English language edition of a German languagebook, which should be available in 2008. The new officialGerman industry norm based on RefModPM should resultin additional distribution.

References

[1] White D, Fortune K. Current practice in project management anempirical study. Int J Project Manage 2002;20(1):7.

[2] Ahlemann F, Backhaus K. Project management software systems requirements, selection processes and products. Wurzburg: BARC;2006.

[3] Dorndorf U, Pesch E, Phan-Huy T. Time-oriented branch-and-bound algorithm for resource-constrained project scheduling withgeneralised precedence constraints. Manage Sci 2000;46(10):136584.

[4] Chang CK, Christensen MJ, Zhang T. Genetic algorithms for projectmanagement. Ann Software Eng 2001;11(1):10739.

30 F. Ahlemann / International Journal of Project Management 27 (2009) 1930[5] Hartmann S. A self-adapting genetic algorithm for project schedulingunder resource constraints. Naval Res Logist 2002;49(5):43348.

[6] Dworatschek S, Hayek A. Marktspiegel Projekt-Management Soft-ware Kriterienkatalog und Leistungsprofile. Koln: Verlag TUVRheinland; 1992.

[7] Rabl W, Fiedler S. Projektmanagement-Software: Marktubersichtund Entwicklungstrends. In: Gareis R, editor. Projekte & EDV.Wien: Service-Fachverlag; 1994. p. 3754.

[8] Kolisch R, Hempel K. Experimentelle Evaluation der methodischenFundierung von Projektmanagementsoftware. Kiel; 1995.

[9] Kurbel K. Groupware extension for a software project managementsystem. Int J Project Manage 1994;12(4):2229.

[10] Schulz R, Malzahn U, von Schoultz F. An integrated projectmanagement information system. Leipzig; 1996.

[11] Ehlers P. Integriertes Projekt- und Prozemanagement auf Basisinnovativer Informations- und Kommunikationstechnologien: DasGroupProject-System. Aachen: Shaker; 1997.

[12] Hayek A. Projektmanagement-Software: Anforderungen und Leis-tungsprofile, Verfahren der Bewertung und Auswahl sowie Nutzungs-organisation vonProjekt-Software.Koln:VerlagTuVRheinland; 1993.

[13] Meyer MM. Stand und Trend von Softwareunterstutzung furProjektmanagement-Aufgaben Zwischenbericht zu den Ergebnisseneiner Befragung von Projektmanagement-Experten. Bremen; 2005.

[14] Meyer MM. Softwareunterstutzung fur das Projektmanagement.Bremen: Universitat Bremen; 2007.

[15] Object Management G. Unified modelling language: superstructure.Verson 2.0. Object Management Group; 2005.

[16] Winter R, Schelp J. Reference modeling and method construction: adesign science perspective. In:Proceedingsof the 2006ACMsymposiumon applied computing, Dijon, France. ACM Press; 2006. p. 15612.

[17] Hevner AR, March ST, Park J, Ram S. Design science in informationsystems research. MIS Quart 2004;28(1):75105.

[18] Fettke P, Loos P. Referenzmodellierungsforschung. Wirtschaftsin-formatik 2004;46(5):33140.

[19] Thomas O. Understanding the term reference model in informationsystems research: history, literature analysis and explanation. LNCS2006;3812:48496.

[20] Becker J, Schutte R. Handelsinformationssysteme. Landsberg-Lech:Verlag moderne Industrie; 1996.

[21] Raymond L. Information systems design for project management: adata modeling approach. Project Manage J 1987;18(4):949.

[22] Froese T. Integrated computer-aided project management throughstandard object-oriented models. Center for Integrated FacilityEngineering: Stanford; 1992.

[23] Luiten G, Froese T, Bjork BC, Cooper G, Junge R, Karstila K, et al.An information reference model for architecture, engineering andconstruction. In: Mathur K, Betts M, Tham K, editors. Theproceedings of the first international conference on the managementof information technology for construction. World Scientific; 1993.

[24] Karstila K, Bjork BC, Hannus M. A conceptual framework fordesign and construction information. In: Proceedings 1st interna-tional symposium on building systems automation integration.Madison: Wisconsin; 1991 [02.06.1991].

[25] Luiten GT, Bakkeren WJC. A layered modelling methodologyapplied to the building and construction industry. In: Workshop onmodels for computer integrated construction. VTT; 1992.[26] Froese T. Developments to the IRMA model of AEC. In: KhozeimehK, editor. Computing in civil engineering proceedings of the firstcongress held in conjunction with A/E/C systems94. AmericanSociety of Civil Engineers; 1994. p. 77885.

[27] Froese T, Yu QK. StartPlan: producing schedule templates usingIRMA. In: Khozeimeh K, editor. Computing in civil engineering proceedings of the first congress held in conjunction with A/E/CSystems 94. American Society of Civil Engineers; 1994. p. 6370.

[28] Schlagheck B. Objektorientierte Referenzmodelle fur das Prozess-und Projektcontrolling: Grundlagen Konstruktion Anwendungsmoglichkeiten. Wiesbaden: Gabler; 2000.

[29] Schutte R. Grundsatze ordnungsmassiger Referenzmodellierung:Konstruktion konfigurations- und anpassungsorientierter Modelle.Wiesbaden: Gabler; 1998.

[30] Lechler T. Erfolgsfaktoren des Projektmanagements. Frankfurt AMet al., editor. Lang; 1997.

[31] Cooke-Davies T. The real success factors on projects. Int J ProjectManage 2002;20(3):18595.

[32] Patton MQ. Qualitative research and evaluation methods. ThousandOaks: Sage; 2002.

[33] Lincoln YS, Guba EG. Naturalistic inquiry. Beverly Hills, California:Sage; 1985.

[34] Morris PWG. Managing project interfaces key points forproject success. In: Cleland DI, King WR, editors. Project manage-ment handbook. New York: Van Nostrand Reinhold company;1983.

[35] Cleland DI, Ireland LR. Project management. Strategic design andimplementation. London: McGraw-Hill; 2002.

[36] Meredith JR, Mantel SJ. Project management a managerialapproach. New York: Wiley; 2000.

[37] Wollmann P. Multiprojektmanagement im Kontext der strategischenPlanung. In: Hirzel M, Kuhn F, Wollmann P, editors. Multiprojekt-management Strategische und operative Steuerung von Projektport-folios. Frankfurt: Allgemeine Buch; 2002. p. 236.

[38] Burghardt M. Projektmanagement: Leitfaden fur die Planung,Uberwachung und Steuerung von Entwicklungsprojekten. Erlangen:Publicis MCD; 2002.

[39] Schulte-Zurhausen M. Organisation. Munchen: Vahlen; 1999.[40] Alter R. Integriertes Projektcontrolling. Gieen: Verlag der Ferbers-

chen Universitatsbuchhandlung; 1991.[41] Gareis R. Programme and project portfolio management: new

competencies of project-oriented organizations. In: Presentation atthe PMI symposium, Houston; 2000.

[42] Obels M, Roeschlein R, Staiger M, von Schneyder W, Wagner R,Waschek G. Die neue Projektmanagement-Norm. Projektmanage-ment Aktuell 2006;17(2):414.

[43] Angermeier G. Genormtes Datenmodell fur Projektmanagement:Katalysator fur eine projektorientierte Wirtschaft? Projekt Magazin2005(6).

[44] Matthes G. Unterlage zum 9. PLANTA-Anwenderforum, 1719. Mai2006. Karlsruhe: Planta; 2006.

[45] Abels S, Ahlemann F, Hahn A, Hausmann K, Strickmann J.PROMONT a project management ontology as a reference forvirtual project organizations. Lect Notes Comput Sci 2006(4277):81323.

Towards a conceptual reference model for project management information systemsIntroductionFoundation and related workThe role of information models in the development of information systemsReference modelsPrevious project management reference models

The research and construction processThe architecture of the reference model: the M-ModelProject life-cycleManagement levelsStrategy definition, personnel, and financial systemsRefinement of the M-Model

An exemplary excerpt: modelling of programs, projects, and work breakdown structuresRequirementsReference model by FroeseReference model by SchlagheckRefModPMConclusions

Application of RefModPMSoftware specification and selectionOther application examples

SummaryReferences