Available online at www.sciencedirect.

com

International Journal of Project Management 27 (2009) 1930

www.elsevier.com/locate/ijproman

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 programs, 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 (RefModPM) 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. RefModPM has already been applied in several projects and is the basis of the forthcoming 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 todays
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 management systems to complex, distributed, multi-functional
systems that no longer only cover project planning [2].
Information systems research has to date only partly
reected this PMIS evolution. Typical elds of research
are (1) algorithms in respect of operation research problems related to project management (e.g. [35]), (2) the
assessment and comparison of commercial project management solutions and corresponding assessment frameworks
(e.g. [68]), (3) the development of prototypes to test new
kinds of functionality (e.g. [911]), and (4) research into

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

0263-7863/$30.00 2008 Elsevier Ltd and IPMA. All rights reserved.
doi:10.1016/j.ijproman.2008.01.008

the usage of project management software systems (e.g.

[1214]). Two specic problems are very rarely addressed:
PMIS are become increasingly complex. Therefore, rstly,
information system designers are facing a growing number
of business processes that have to be supported with project management software. Secondly, information system
users have diculties in setting up corresponding organizational systems and selecting corresponding software products. An expert survey by Meyer indicates that only in
approximately 20% of cases do organizations have information systems in place that support multi-project programme and portfolio management [13, p. 9]. In contrast,
approximately 99% of organizations use information systems 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 reference information model for enterprise-wide project management that covers all project management processes
that are related to planning, controlling, and coordinating

20

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

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 denition of software requirements that are essential to select
a commercial project management software system. RefModPM 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 Unied Modeling Language (UML) Version 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 presented in section ve, which is then compared to the modelling approaches presented by other authors. In section
six, examples that illustrate the models 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 during the design and implementation of information systems.
Depending on the phase or level of IS design and implementation, three dierent 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 architecture of the information system by describing larger technical building blocks called components. Such
components are not, however, analyzed in detail.
3. Implementation models depend on specic 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 presenting information processes (process models). In a nutshell: 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 Unied 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 construct 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 representations of reality and approaches that follow a constructivist paradigm. The latter regard a model as a construction of
one or various modellers. This paper is based on the abovementioned constructivist understanding of the term model.
In accordance with this and in keeping with Thomas, a reference model is dened 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 frequently used as synonyms. In the following sections, we
discuss all the variant forms as long as they meet the characteristics of the denition 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 management 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 artefact or as a general recommendation for information system designers.
One of the rst reference information models for project
management in the architecture, engineering, and construction (AEC) industry was published by Froese, who called it
a standard model [22]. Proprietary object-oriented mod-

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

elling techniques are used to develop a project management

domain model and a corresponding application system.
The term reference information model was rst used by
Luiten et al. in 1993 when they combined their individual
research activities on modelling in the architecture, engineering, and construction domain. The resulting unied domain
model is called IRMA (Information Reference Model for
AEC) [23]. Although not obvious at rst 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-

Problem definition

Problem Definition

Exploration and
generation of
hypotheses

Construction of the Information

System Architecture (M-Model)

Literature Review / Analysis of Project

Management Standards

Analysis of Project Management

Software Systems

Construction / Refinement of the

Reference Model

Validation

Interviews with Domain Experts

Practical Application

Refinement of
the Reference Model

Documentation

Documentation

Legend
Research Activity
Research Phase

21

Order

Fig. 1. The reference model construction process.

22

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

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 article was realized within a four-phase research process conducted between 2002 and 2007 (Fig. 1) derived from a
process model for reference model construction by Schutte
[29, p. 177]. The research comprised:
(1) Problem denition. The research objective was
dened and the problem domain specied as documented
in the rst section of this paper [29, p. 189,28, p. 79].
(2) Exploration and generation of hypotheses. The second
phase consisted of three dierent 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 documented in Section 4 of this article. The M-Model is the outcome 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 management software applications was used to generate hypotheses on project management processes and organizational
and data structures (Table 1). In the sense of reverse engineering, these products database schemas, documentation,
and software functionality were investigated to gain knowledge regarding the software vendors understanding of project management information systems.
(2c) Literature review/analysis of PM standards. Further
research conducted by other authors and project management 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/renement of the reference model. The
initial construction of the reference model was based on the
knowledge obtained from the analysis of project management software systems and the literature review.
(3) Validation. The objective of this phase was to validate, rene, and stabilize the initial reference model
construction.
(3a) Interviews with domain experts. A series of interviews were conducted with experts in project management
and project information systems with the objective of gathering 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 rst part, the
domain experts knowledge and experience were determined. In the second part, the experts were confronted with
the reference model and asked to provide detailed feedback
on the models strengths and weaknesses. Thereafter, pos-

Table 1
Analyzed project management IS
Product

Company

Acos Plus.1
Alpha Project Line
AMS Realtime Projects
Artemis Portfolio, Project and
Resource Management Solution
Cat4
eRoom
fx-project

ACOS Projektmanagement GmbH

HISC AG Projektmanagement
Advanced Management Solutions
Artemis International Solutions
Corporation
Cataligent Projekt GmbH
eRoom Technology, Inc.
FeRox Management Consulting
GmbH
Integrated Strategic Information
Systems Pvt. Ltd.
ESNA Limited
ACME Interactive
EFK GmbH
PlanView United States
PLANTA ProjektmanagementSysteme GmbH
PUS Prozess- und Systemtechnik
GmbH
Primavera
Metafuse, Inc.
Sciforma Corporation
ProjectExchange, Inc.
BBL Software GmbH
Meridian Project Systems
Nesbit
GSI Gesellschaft fur Steuerungsund Informationssysteme mbH
Scheuring Project Management AG
Primavera
EDS PLM Solutions
untermStrich software GmbH
Standpipe Studios Inc.
MediaSolv.com Inc.

iPlan
Nucleus
OurProject
PC Projekt-Controlling-System
Planview
PPMS
PQM
Primavera P3e
Project Insight
Project Scheduler
ProjectExplorer, WebTime
Projekta
Prolog Scheduler
ProMOS
PSIPENTA PM
resSolution
SureTrak Project Manager
Teamcenter Project
untermStrich
Vertabase Pro
vProject

Table 2
Interview partner companies for the reference model validation phase
Company

Location

Agroscope FAW Wadenswil, Eidgenossische

Forschungsanstalt fur Obst-, Wein- und
Gartenbau
BASF AG
Bayerische Hypo- und Vereinsbank AG
Credit Suisse
EADS Deutschland GmbH
Henkel KGaA
HighQIT for the nancial Industry GmbH

Wadenswil, Switzerland

Inneon Technologies AG
Multi-national nancial services company
(anonymous)
Softlab GmbH
T-Systems International GmbH
ThyssenKrupp Stahl AG
Vattenfall Europe

Ludwigshafen, Germany
Munich, Germany
Zurich, Switzerland
Ulm, Germany
Dusseldorf, Germany
Ottobrunn-Riemerling
(Munich), Germany
Munich, Germany
Zurich, Switzerland
Hamburg, Germany
Erfurt, Germany
Duisburg, Germany
Berlin, Germany

sible improvements were discussed. The reference model

would then be rened or redesigned if the interview results
indicated that this was necessary (return to step (2d)). The
process was then continued. Following an approach by

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

Lincoln and Guba [33, p. 234], this cyclic process was terminated when insights gained from preceding interview discussions no longer enhanced the reference model. It was
then concluded that the domain experts had reached consensus on the reference models propositions. The selection
of domain experts followed both the chain sampling and
theoretical sampling approaches [32, p. 237]. Although
they were identied by means of chain sampling, the interview 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 reference model was not only achieved through the interviews
with domain experts, but it was also validated in respect
of application projects (see Section 6).
(3c) Renement of the reference model. The experience
gained in the above-mentioned projects was also used to
rene 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 documentation of the interview results.
4. The architecture of the reference model: the M-Model
The reference model is based on a single, uniform conceptual architecture called the M-Model (Fig. 2). The Mmodel embraces all tasks related to the initiation, planning,
execution, and termination of projects. It describes the process 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 dened in RefModPM. The M-Models two dierent
layers indicate this.
4.1. Project life-cycle
Regardless of their individual objectives, projects
undergo a series of phases that constitute the project lifecycle. 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 generated, collected, recorded, and examined (Idea Generation). Their feasibility, protability, and strategic impact
are analyzed so that a nal decision can be made regarding their implementation (Idea Evaluation). This phase
ends with a formal go/no-go decision made by the management team (Portfolio Planning).
 Planning: In this phase, the project idea is translated into
a project plan and the necessary resources (nancial,
human, and other resources) are provided (Project Preparation). The project manager also renes 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 (Project Controlling). Information is then aggregated to
obtain an overall view of the project situation (Portfolio
Controlling).

Top Management:
Portfolios
Strategy Definition

Portfolio
Planning

Project
Office,
Committees:
Projects,
Programs

Project
Manager:
Projects

Idea
Evaluation

Idea
Generation

Portfolio
Controlling

Project
Preparation

Detailed
Planning

23

Project
Controlling

Project
Execution

External
Project
Termination

Internal
Project
Termination

Personnel and Financial Management

Processes
Data Structures

Fig. 2. The M-Model.

24

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

 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 reected 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 protability and feasibility, or its strategic positioning is inappropriate, it could still be terminated
immediately [36, p. 545].
4.2. Management levels
Three dierent management levels are distinguished
within the M-Model (cp. [34, p. 8,37, p. 29]:

coordination and planning and controlling activities

that aect all projects, for example, the project oce
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 denition, personnel, and nancial systems
The strategy denition (the roof of the M) is a necessary input for portfolio planning, since it requires a
clearly dened business strategy [35, p. 105]. On the other
hand, the personnel and the nancial system (the foundation of the M) are important building blocks, since they
deliver information that is required for planning and controlling purposes such as sta availability and/or nancial
transactions [38, p. 261, 281].
4.4. Renement of the M-Model

 Project manager: At the operational project management 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 oce/committees: This management level comprises all permanent or temporary organizational elements that are responsible for multi-project
Table 3
Activity diagrams that are part of the RefModPM reference model
M-Model element

Contents

Number of
diagrams

Idea generation

Generate, classify, and screen

project ideas.
Describe project ideas, assess
their feasibility, and decide on
their realization.
Perform the organizational
budgeting, derive a project
portfolio, and prioritize the
projects.
Set up the project, procure
external resources.
Perform the detailed project
planning, including scheduling,
resource assignment, etc.
Execute the project; manage the
project work, ensure the
quality, record the resource
usage, process the risks, hold
team meetings.
Record and communicate the
project status, process change
requests, hold steering
committee meetings
Check the budget spending and
the project performance.
Claim management, supplier
assessment, team member
assessment.
Archive project documentation,
update skill proles, do benet
controlling.

Idea evaluation

Portfolio planning

Project Preparation
Project planning

Project execution

Project controlling

Portfolio controlling
Internal project
termination
External project
termination

The reference model consists of 10 basic activity diagrams that correspond to the project life-cycle phases outTable 4
Class diagrams in the RefModPM reference model
M-Model element

Contents (recurring contents

are not listed)

Number of
diagrams

Foundation

Projects, work breakdown

structures, lifecycle phases;
primary and secondary
organizational structures, roles,
resources, resource types;
scenarios, archives, baselines
Accounts, transactions,
currencies, cost centres, cost
objects
Strategic targets,
organizational budgets, units
Project classication, project
screening criteria
Milestones, resource needs,
project cost calculations,
project budgets, key
performance indicators
Budgets, resource capacities,
strategic project assessments,
project portfolios
Resource calendars, resource
assignments, decisions, reports,
meetings, suppliers, contracts
Quality assurance, precedence
relationships, stakeholders,
risks, risk measures
Documents, quality approvals,
quality measures, timesheets,
meeting minutes
Status reports, change requests
Budget spending reports
Supplier assessments, sta
assessments
...

Financial management

Strategic planning
Idea generation

Idea evaluation

1
Portfolio planning
5
Project preparation

Project planning

Project execution
1
1

Project controlling
Portfolio controlling
Internal project
termination
External project
termination

1
1
2

1
1
1
1

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

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 rened, providing more detailed process descriptions. In addition to this, the reference model
contains class diagrams that indicate the interfaces to personnel and nancial 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 specically organizational 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 separate class diagrams. Altogether, the reference model comprises 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 modelling, but requires further renement 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 RefModPM reference 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 Schlagheck, 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 description, 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 comprehensive set of attributes that allows the project to
be fully described, planned, and controlled.

25

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 applicable 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 baselines for management and controlling purposes.
5. There should be at least three specic plan versions of
any project: (a) the original plan approved by management, (b) the current plan containing all changes resulting 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 specic 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 facility, a location, and participants (Fig. 4).
The construction plan (ConstructionPlan) itself consists
of several activities (Activity) that can form an activity network and have attributes for storing the results of a scheduling process. Each activity has an assigned activity
category (ActivityCategory) that represents the category
of construction eort that involves the application of a particular action to a specic 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, Froeses 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 dierent 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 special project plan and consists of WBS elements (WBSElement) that also form a hierarchy. A WBS element can
either be a sub-project, a task, a work package or an
activity.

26

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

Orga
Baseline

OrgaPlanArchive

Orga, IT
PlanVersion
-VersionNumber
-CreationDate
-Description
-Editable

OrgaScenario
Orga
Programme

0..1

0..1

0..1

0..*

0..*

Orga
Project

-ActualPlan

0..*

-AppovedPlan

0..*

-BasePlan

Orga
SubProject

Orga, IT
Initiative

-Child

0..*

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

0..1

-Parent

Orga
Phase

Orga
WorkPackage

Orga
Task

Orga, IT, Config

LifeCyclePhase
-Name
-Chargable
1
1

0..*
1..*

Orga, IT
InitiativeLifeCyclePhase
-Date
-Decision
-Comment

0..*
PM

Fig. 3. Project master data in RefMod

Schlaghecks model is clearly more advanced than Froeses. It allows work breakdown structures with an unlimited 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 dened 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 dierent 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 Initiative (requirement 3). Initiatives are characterized by a
relatively large set of attributes covering scope, time, and
risk management (other functional areas of project management like resource or cost management are covered by
other data structures). RefModPM thus meets requirement
1.
By means of a reexive association, initiatives form a
hierarchy that can be used to (a) set up a work breakdown
structure, (b) create programs by subsuming several projects, 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 initiatives lifetime into several standardized time spans. The
beginning or ending of such a time span can be recorded

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

27

ProjectSpecificObject
-ProjectNumber
ActivityCategory
-Action
-ComponentCategories
-Method
-PartOf
-QuantityFormula
-...

Project
-Contracts
-Facility
-Location
-Particiapants

1
ConstructionPlan
-DefaultConstructionMethod
-DurationUnits
1
Activity
-Components
-EarlyFinish
-EarlyStart
-LateFinish
-LateStart
-Duration
-TotalFloat

1
*
*

-Successor

-Predecessor

Fig. 4. Project master data according to Froese.

-Hierarchy

0..1

Project
0..*

ProjectPlan

-Objective
-Status

-ResponsiblePerson
1

WorkBreakdownStructure

0..*
-Hierarchy
WorkBreakdownStructurePlanning

WBSElement
-Description
1

0..1

1..*

SubProject

-Hierarchy

Task

0..1
0..*

WorkPackage

Activity

Fig. 5. Work breakdown structure according to Schlageheck.

28

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

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 dierent life-cycle models and enables software
systems developed with RefModPM to 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 project 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 scenario planning (Scenario, requirement 6). Since the plan
versioning concept is based on the Initiative class, it is possible 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 innite number of plan versions
(requirement 4), RefModPM allows three specic plan versions to be assigned to each initiative (requirement 5).
Apart from meeting empirically gathered requirements,
our model also impacts the eciency of software development. During the practical application of the model, we
discovered that the Initiative and PlanVersion data structures can signicantly reduce development eorts 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 software functionality to be used for risk, quality, time and
resource management on both the work package, project
and portfolio levels. This is a signicant benet when compared to the approaches of present-day PM software systems that usually apply dierent data structures for work
packages, projects and portfolios.
5.5. Conclusions
The discussion of the model excerpt indicates that RefModPM goes beyond the scope of previous reference models. This is not surprising, since RefModPM uses some ideas
from previous work and extends it according to additional
requirements. Table 5. demonstrates the extent to which
RefModPM represents signicant research progress in the
eld of PMIS reference models, since it
 has a signicantly wider scope, covering not only project
planning and execution, but also the initiation and termination phase,
 has been designed to serve both single and multi project
management purposes, and
 covers all functional areas of PMIs PMBOK.

Table 5
RefModPM compared to existing reference information models for project management

Domain Characteristics
Project lifecycle phases
Management levels
Supported industries
Coveredb
Integration management
Scope management
Time management
Cost management
Quality management
Human resource management
Communications management
Risk management
Procurement management
(Semi-)Formal models available for
Data structures
Organizational structures
Processes
Other characteristics
Number of classes/object types
Modeling language(s)
Research methodology
Model evaluation
Documentation of design and evaluation methods
Communication of research
a
b
c

Froese (1992)

Schlagheck (2000)

RefModPM

Planning
Project
Construction industry

Planning, execution
Project
Any

Initiation, planning, execution, termination

Project, program, portfolio
Any

No
Yes
Yes
Yes
No
No
No
No
Yes

No
Yes
Yes
Yes
Yes
No
No
No
No

Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes

Yes
Yes
Noa

Yes
No
Yes

Yes
Yes
Yes

36
SOL (Proprietary)

20
UML 1

101
UML 2

Yesc
No
Yes

No
No
Yes

Yes
Yes
Yes

Processes are only modeled implicitly, representing process steps (activities) in the data model.
According to the nine knowledge areas of the Project Management Body of Knowledge (PMBOK) [PMI04, 9].
A prototype has been developed, although it is unclear whether this prototype has been evaluated.

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

 Moreover, the research methodology underlying the

model construction and evaluation is presented. The
complete reference model has been made available to
the public in book form.
6. Application of RefModPM
6.1. Software specication and selection
As RefModPM is a conceptual reference model for PMIS,
it will be especially useful in cases where organizations strive
to introduce a new project management software by either
developing one or by rolling out a commercial o the shelf
package. RefModPM can rst of all be used as a foundation
for the software specication and design. Secondly, it can
serve as a basis for dening requirements that commercial
software needs to meet. In both cases, the following procedure is recommended to fully benet from the knowledge
contained in the reference model:
1. Dene the process steps and layers from the M-Model
that are relevant to the project. This leads to a high-level
scope denition that allows the class and activity diagrams to be selected that need to be taken into
consideration.
2. Modify the activity diagrams to truly t individual company needs. The reference models process descriptions
are sometimes too detailed, whilst other times they
may require further renement.
3. Adapt the class diagrams in accordance with the activity
diagrams. Here, data structures that are no longer
referred to by any process steps are deleted. Additionally,
it might become necessary to rene the data structure to
accommodate more detailed process descriptions.
4. Specify requirements: With regard to software development, the resulting company-specic model can be used
to provide more detailed software specications, for
example, for the development of use cases or user stories.
When commercial software needs to be selected, the process and data descriptions are translated into a list of
requirements. Practical experience has shown that, as a
rule of thumb, one process step can be transformed into
one requirement. In action research projects, we have
learned that the reference models application can accelerate requirements engineering and software selection
projects signicantly. Subject matter experts estimate
that it can reduce eorts by 3050%.
6.2. Other application examples
The application of RefModPM is not limited to the specication and introduction of PM software. The following
cases illustrate its wide applicability:
1. It was used to develop a new project initiation and portfolio management process for a multinational high-tech

29

company headquarters in Switzerland. Within a one-day

workshop, the cornerstones of this process were specied by using the reference model as a template.
2. The reference model was used as the basis for a new
DIN (German Institute for Standardization) project
management data model standard. A working group
of the German Association of Project Management
(GPM), consisting of 15 project management software
vendors, consulting rms, and project management
experts from diverse companies, developed a
comprehensive XML schema for project management data exchange within six months by using RefModPM [42,43]. DIN will publish the data model
during 2008.
3. The result of this work has also been used in several software development projects such as by PLANTA, one of
the leading German project management software vendors [44, p. 4]. Another vendor is currently developing
a completely new software system based on RefModPM.
4. The reference model is currently being used for the construction of a comprehensive project management ontology that forms the basis of endeavours in the areas of
Enterprise Application Integration (EAI) and Knowledge Management [45].
7. Summary
This paper has introduced RefModPM, a new conceptual
information system reference model for project and project
portfolio management. RefModPM tries to overcome existing reference models deciencies by covering more aspects
of project management and oering data structures and
processes that have been validated empirically and have
proven to be stable, exible, and accepted by subject matter
experts. The development of the rst version of RefModPM
took approximately 1.5 man-years to complete. We are
currently working on an extended second version of RefModPM that is scheduled to be completed during 2008.
Several software manufacturers that develop new products or product versions are currently using RefModPM.
The adoption of RefModPM is also promoted through
the second, English language edition of a German language
book, which should be available in 2008. The new ocial
German industry norm based on RefModPM should result
in additional distribution.
References
[1] White D, Fortune K. Current practice in project management an
empirical 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-andbound algorithm for resource-constrained project scheduling with
generalised precedence constraints. Manage Sci 2000;46(10):136584.
[4] Chang CK, Christensen MJ, Zhang T. Genetic algorithms for project
management. 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 scheduling

under resource constraints. Naval Res Logist 2002;49(5):43348.
[6] Dworatschek S, Hayek A. Marktspiegel Projekt-Management SoftV
ware Kriterienkatalog und Leistungsprole. Koln: Verlag TU
Rheinland; 1992.
[7] Rabl W, Fiedler S. Projektmanagement-Software: Marktubersicht
und Entwicklungstrends. In: Gareis R, editor. Projekte & EDV.
Wien: Service-Fachverlag; 1994. p. 3754.
[8] Kolisch R, Hempel K. Experimentelle Evaluation der methodischen
Fundierung von Projektmanagementsoftware. Kiel; 1995.
[9] Kurbel K. Groupware extension for a software project management
system. Int J Project Manage 1994;12(4):2229.
[10] Schulz R, Malzahn U, von Schoultz F. An integrated project
management information system. Leipzig; 1996.
[11] Ehlers P. Integriertes Projekt- und Prozemanagement auf Basis
innovativer Informations- und Kommunikationstechnologien: Das
GroupProject-System. Aachen: Shaker; 1997.
[12] Hayek A. Projektmanagement-Software: Anforderungen und Leistungsprole, Verfahren der Bewertung und Auswahl sowie Nutzungsorganisation von Projekt-Software. Koln: Verlag TuV Rheinland; 1993.
[13] Meyer MM. Stand und Trend von Softwareunterstutzung fur
Projektmanagement-Aufgaben Zwischenbericht zu den Ergebnissen
einer Befragung von Projektmanagement-Experten. Bremen; 2005.
[14] Meyer MM. Softwareunterstutzung fur das Projektmanagement.
Bremen: Universitat Bremen; 2007.
[15] Object Management G. Unied modelling language: superstructure.
Verson 2.0. Object Management Group; 2005.
[16] Winter R, Schelp J. Reference modeling and method construction: a
design science perspective. In: Proceedings of the 2006 ACM symposium
on applied computing, Dijon, France. ACM Press; 2006. p. 15612.
[17] Hevner AR, March ST, Park J, Ram S. Design science in information
systems research. MIS Quart 2004;28(1):75105.
[18] Fettke P, Loos P. Referenzmodellierungsforschung. Wirtschaftsinformatik 2004;46(5):33140.
[19] Thomas O. Understanding the term reference model in information
systems research: history, literature analysis and explanation. LNCS
2006;3812:48496.
[20] Becker J, Schutte R. Handelsinformationssysteme. Landsberg-Lech:
Verlag moderne Industrie; 1996.
[21] Raymond L. Information systems design for project management: a
data modeling approach. Project Manage J 1987;18(4):949.
[22] Froese T. Integrated computer-aided project management through
standard object-oriented models. Center for Integrated Facility
Engineering: Stanford; 1992.
[23] Luiten G, Froese T, Bjork BC, Cooper G, Junge R, Karstila K, et al.
An information reference model for architecture, engineering and
construction. In: Mathur K, Betts M, Tham K, editors. The
proceedings of the rst international conference on the management
of information technology for construction. World Scientic; 1993.
[24] Karstila K, Bjork BC, Hannus M. A conceptual framework for
design and construction information. In: Proceedings 1st international symposium on building systems automation integration.
Madison: Wisconsin; 1991 [02.06.1991].
[25] Luiten GT, Bakkeren WJC. A layered modelling methodology
applied to the building and construction industry. In: Workshop on
models for computer integrated construction. VTT; 1992.

[26] Froese T. Developments to the IRMA model of AEC. In: Khozeimeh

K, editor. Computing in civil engineering proceedings of the rst
congress held in conjunction with A/E/C systems94. American
Society of Civil Engineers; 1994. p. 77885.
[27] Froese T, Yu QK. StartPlan: producing schedule templates using
IRMA. In: Khozeimeh K, editor. Computing in civil engineering
proceedings of the rst congress held in conjunction with A/E/C
Systems 94. American Society of Civil Engineers; 1994. p. 6370.
[28] Schlagheck B. Objektorientierte Referenzmodelle fur das Prozessund
Projektcontrolling:
Grundlagen

Konstruktion

Anwendungsmoglichkeiten. Wiesbaden: Gabler; 2000.

[29] Schutte R. Grundsatze ordnungsmassiger Referenzmodellierung:
Konstruktion kongurations- und anpassungsorientierter Modelle.
Wiesbaden: Gabler; 1998.
[30] Lechler T. Erfolgsfaktoren des Projektmanagements. Frankfurt AM
et al., editor. Lang; 1997.
[31] Cooke-Davies T. The real success factors on projects. Int J Project
Manage 2002;20(3):18595.
[32] Patton MQ. Qualitative research and evaluation methods. Thousand
Oaks: Sage; 2002.
[33] Lincoln YS, Guba EG. Naturalistic inquiry. Beverly Hills, California:
Sage; 1985.
[34] Morris PWG. Managing project interfaces key points for
project success. In: Cleland DI, King WR, editors. Project management handbook. New York: Van Nostrand Reinhold company;
1983.
[35] Cleland DI, Ireland LR. Project management. Strategic design and
implementation. London: McGraw-Hill; 2002.
[36] Meredith JR, Mantel SJ. Project management a managerial
approach. New York: Wiley; 2000.
[37] Wollmann P. Multiprojektmanagement im Kontext der strategischen
Planung. In: Hirzel M, Kuhn F, Wollmann P, editors. Multiprojektmanagement Strategische und operative Steuerung von Projektportfolios. Frankfurt: Allgemeine Buch; 2002. p. 236.
[38] Burghardt M. Projektmanagement: Leitfaden fur die Planung,
berwachung und Steuerung von Entwicklungsprojekten. Erlangen:
U
Publicis MCD; 2002.
[39] Schulte-Zurhausen M. Organisation. Munchen: Vahlen; 1999.
[40] Alter R. Integriertes Projektcontrolling. Gieen: Verlag der Ferberschen Universitatsbuchhandlung; 1991.
[41] Gareis R. Programme and project portfolio management: new
competencies of project-oriented organizations. In: Presentation at
the PMI symposium, Houston; 2000.
[42] Obels M, Roeschlein R, Staiger M, von Schneyder W, Wagner R,
Waschek G. Die neue Projektmanagement-Norm. Projektmanagement Aktuell 2006;17(2):414.
[43] Angermeier G. Genormtes Datenmodell fur Projektmanagement:
Katalysator fur eine projektorientierte Wirtschaft? Projekt Magazin
2005(6).
[44] Matthes G. Unterlage zum 9. PLANTA-Anwenderforum, 1719. Mai
2006. Karlsruhe: Planta; 2006.
[45] Abels S, Ahlemann F, Hahn A, Hausmann K, Strickmann J.
PROMONT a project management ontology as a reference for
virtual project organizations. Lect Notes Comput Sci 2006(4277):
81323.