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

Towards a conceptual reference model for project
management information systems
Frederik Ahlemann
Information Systems 2, European Business School, International University, Schloss Reichartshausen, 65375 Oestrich-Winkel, Germany
Received 17 August 2007; received in revised form 17 January 2008; accepted 31 January 2008
Abstract
Project management information systems have changed considerably over the last decade. They no longer focus on scheduling and
resource management alone. Instead, they have become comprehensive systems that support the entire life-cycle of projects, project pro-
grams, and project portfolios. In this context, project-oriented organizations are facing a new challenge: the design, implementation, and
operation of project management information systems have become increasingly complex. Numerous processes have to be considered,
diverse stakeholder interests taken into account, and corresponding software systems selected. The reference information model (Ref-
Mod
PM
) presented in this article addresses this challenge and aims to accelerate the set-up of project information systems. RefMod
PM
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. RefMod
PM
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 systems
1. Introduction
Project management information systems (PMIS) are
widely regarded as an important building block in today’s
project management [1]. The nature of these systems has
changed considerably during the last decade; they are, in
fact, still developing from single-user/single-project man-
agement systems to complex, distributed, multi-functional
systems that no longer only cover project planning [2].
Information systems research has to date only partly

reflected this PMIS evolution. Typical fields of research
are (1) algorithms in respect of operation research prob-
lems related to project management (e.g. [3–5]), (2) the
assessment and comparison of commercial project manage-
ment solutions and corresponding assessment frameworks
(e.g. [6–8] ), (3) the development of prototypes to test new
kinds of functionality (e.g. [9–11]), and (4) research into
the usage of project management software systems (e.g.
[12–14]). Two specific problems are very rarely addressed:
PMIS are become increasingly complex. Therefore, firstly,
information system designers are faci ng a growing number
of business processes that have to be supported with pro-
ject management software. Secondly, information system
users have difficulties in setting up corresponding organiza-
tional systems and selecting corresponding software prod-
ucts. An expert survey by Meyer indicates that only in
approximately 20% of cases do organizations have infor-
mation systems in place that support multi-project pro-
gramme and portfolio management [13, p. 9]. In contrast,
approximately 99% of organizations use information sys-
tems for scheduling and time management [13, p. 13].
The potential of existing PMIS is clearly not being
exploited at all.
This article addresses these issues by presenting a refer-
ence information model for enterprise-wide project man-
agement that covers all project management processes
that are related to planning, controlling, and coordinating
0263-7863/$30.00 Ó 2008 Elsevier Ltd and IPMA. All rights reserved.
doi:10.1016/j.ijproman.2008.01.008
E-mail address:

www.elsevier.com/locate/ijproman
Available online at www.sciencedirect.com
International Journal of Project Management 27 (2009) 19–30
projects (RefMod
PM
). The model can be used for the
design of project management software, the set-up of the
surrounding organizational system, as well as for the defi-
nition of software requirements that are essential to select
a commercial project man agement software system. Ref-
Mod
PM
covers both single-project management and
multi-project management. It is based on a single, uniform
information system architecture called M-Model and
makes use of the Unified Modeling Language (UML) Ver-
sion 2.
This paper is structured as follows: section two describes
the conceptual and terminological foundation of this article
and presents a review of existing approaches to reference
modelling in respect of PMIS. A brief description of the
research design and the sources of the construction process
are provided in section three. Section four outlines the
architecture of the reference model, the M-Model. A more
detailed exemplary excerpt of the reference model is pre-
sented in section five, which is then compared to the mod-
elling approaches presented by other authors. In section
six, examples that illustrate the model’s application are
described, followed by concluding remarks that summarize
the paper.

2. Foundation and related work
2.1. The role of information model s in the development of
information systems
Information systems (IS) are socioeconomic systems
that c omprise software, hardware, and the surrounding
organizational system. Models play an important role dur-
ing the design and implementation of information systems.
Depending on the phase or level of IS design and imple-
mentation, three different types of such information models
can be distinguished:
1. Conceptual models help with documenting, analyzing,
and understanding the requirements that an IS needs
to meet. These models do not take any technical aspects
into consideration and focus on the problem that needs
to be solved or the processes that need to be supported.
2. Conversely, design models specify the general architec-
ture of the infor mation system by describing larger tech-
nical building blocks called components. Such
components are not, however, analyzed in detail.
3. Implem entation models depend on specific technologies
and are closely related to software programming.
In general, information models describe the static or
dynamic aspects of information systems. Consequently,
models are distinguished as those presenting information
structures, i.e. data structures (data models), and those pre-
senting information processes (process models). In a nut-
shell: data models lead to the design of databases,
whereas process models are generally used as a basis for
the programming of functionality.
There are several graphical languages available for the

modelling of IS. One of the most prominent and widely
used is the Unified Modeling Language (UML) [15].
UML allows class diagrams to be used for data modelling
and activity diagrams for process modelling.
The design and implementation of information systems
should be regarded as a construction process and is a topic
of design science that explores how researchers can con-
struct high-quality artefacts that are good solutions to
practical problems [16,17].
2.2. Reference models
There is no mutual understanding of the term ‘‘reference
model” [18, pp. 8,19]. Gen erally, one can distinguish
between approaches that regard models as direct repres en-
tations of reality and approaches that follow a constructiv-
ist paradigm. The latter regard a model as a construction of
one or various modellers. This paper is based on the above-
mentioned constructivist understanding of the term model.
In accordance with this and in keeping with Thomas, a ref-
erence model is defined as an ‘‘information model used for
supporting the construction of other models” [19, p. 491].
The use of reference models is frequently based on the
expectation that they can
 accelerate the development of information systems (a
time aspect),
 reduce the associated costs (a cost aspect),
 help to communicate innovative ideas and best practices
(a quality aspect), and
 reduce the risk of failure (a risk aspect) [20].
Although widely accepted in business informatics, the
term reference model is not always applied. The terms

‘‘standard model,” ‘‘framework” or ‘‘architecture” are fre-
quently used as synonyms. In the following sections, we
discuss all the variant forms as long as they meet the char-
acteristics of the definition presented above, are conceptual
by nature, and contain at least semi-formal information
models.
2.3. Previous project management reference models
Approaches to the conceptual modelling of project man-
agement information systems have been published since the
1980s. Raymond, for example, describes a data modelling
approach and illustrates it with an entity relationship
model consisting of 25 entity types that describe the core
data structures for single-project management [21]. This
data model is not, however, regarded as a normative arte-
fact or as a general recommendation for information sys-
tem designers.
One of the first reference information models for project
management in the architecture, engineering, and construc-
tion (AEC) industry was published by Froese, who called it
a ‘‘standard model” [22]. Proprietary object-oriented mod-
20 F. Ahlemann / International Journal of Project Management 27 (2009) 19–30
elling techniques are used to develop a project management
domain model and a corres ponding application system.
The term ‘‘reference information model” was first used by
Luiten et al. in 1993 when they combined their individual
research activities on modelling in the architecture, engineer-
ing, and construction domain. The resulting unified domain
model is called IRMA (Information Reference Model for
AEC) [23]. Although not obvious at first sight, this model
largely comprises project management activities and data

structures. It contains modelling results from Froese, as well
as from other researchers such as, for example, Karstila et al.
[24] and Luiten andBakkeren [25]. Although IRMA hasbeen
revised several times [26], it has never been published in its
entirety. It was, however, used as a basis for the design and
implementation of a software system called StartPlan [27].
Schlagheck published a combined reference information
model for process and project controlling [28] that focuses
on single project management environments with particu-
Validation
Practical Application
Documentation
Problem definition
Exploration and
generation of
hypotheses
Problem Definition
Literature Review / Analysis of Project
Management Standards
Analysis of Project Management
Software Systems
Construction of the Information
System Architecture (M-Model)
Construction / Refinement of the
Reference Model
Interviews with Domain Experts
Documentation
Refinement of
the Reference Model
Legend

Research Phase
Research Activity
Order
Fig. 1. The reference model construction process.
F. Ahlemann / International Journal of Project Management 27 (2009) 19–30 21
lar emphasis on general planning and controlling activities,
but has never been completed [28, pp. 193, 211].
3. The research and construction process
The reference model construction discussed in this arti-
cle was realized within a four-phase research process – con-
ducted between 2002 and 2007 (Fig. 1) – derived from a
process model for reference model constr uction by Schu
¨
tte
[29, p. 177]. The research compri sed:
(1) Problem definition. The research objective was
defined and the problem domain specified as documented
in the first section of this paper [29, p. 189,28, p. 79].
(2) Exploration and generation of hypotheses. The second
phase consisted of three different activities:
(2a) Construction of a reference model architecture.A
conceptual information system architecture was developed
that served as a frame of reference for the subsequent
model construction [29, p. 207,28, p. 79]. This information
system architecture is called the M-Model, and is docu-
mented in Section 4 of this article. The M-Model is the out-
come of an examination of existing research results and an
analysis of project management case studies documented in
the literature.
(2b) Analysis of project management software systems. A

comprehensive analysis of 28 commer cial project manage-
ment software applications was used to generate hypo the-
ses on project management processes and organizational
and data structures (Table 1). In the sense of reverse engi-
neering, these products’ database schemas, documentation,
and software functionality were investigated to gain knowl-
edge regarding the software vendors’ understanding of pro-
ject management information systems.
(2c) Literature review/analysis of PM standards. Further
research conducted by other authors and project manage-
ment institutions, for example, concerning critical success
factors in project management or project management
organization, was also taken into consideration (e.g.
[30,31]).
(2d) Construction/refinement of the reference model. The
initial construction of the reference model was based on the
knowledge obtained from the analysis of project manage-
ment software systems and the literature review.
(3) Validation. The objective of this phase was to vali-
date, refine, and stabilize the initial reference model
construction.
(3a) Interviews with domain experts. A series of inter-
views were conducted with experts in project management
and project information systems with the objective of gath-
ering further empirical evidence for the reference model in
order to validate it (Table 2). This formative evaluation
was executed by means of guided interviews [32, p. 227],
basically consisting of two parts. In the first part, the
domain experts’ knowledge and experience were deter-
mined. In the second part, the experts were confronted with

the reference model and asked to provide detailed feedback
on the model’s strengths and weaknesses. Thereafter, pos-
sible improvements were discussed. The reference model
would then be refined or redesi gned if the interview results
indicated that this was necessary (return to step (2d)). The
process was then continued. Following an approach by
Table 1
Analyzed project management IS
Product Company
Acos Plus.1 ACOS Projektmanagement GmbH
Alpha Project Line HISC AG Projektmanagement
AMS Realtime Projects Advanced Management Solutions
Artemis Portfolio, Project and
Resource Management Solution
Artemis International Solutions
Corporation
Cat4 Cataligent Projekt GmbH
eRoom eRoom Technology, Inc.
fx-project FeRox Management Consulting
GmbH
iPlan Integrated Strategic Information
Systems Pvt. Ltd.
Nucleus ESNA Limited
OurProject ACME Interactive
PC – Projekt-Controlling-System EFK GmbH
Planview PlanView United States
PPMS PLANTA Projektmanagement-
Systeme GmbH
PQM PUS Prozess- und Systemtechnik
GmbH

Primavera P3e Primavera
Project Insight Metafuse, Inc.
Project Scheduler Sciforma Corporation
ProjectExplorer, WebTime ProjectExchange, Inc.
Projekta BBL Software GmbH
Prolog Scheduler Meridian Project Systems
ProMOS Nesbit
PSIPENTA PM GSI Gesellschaft fu
¨
r Steuerungs-
und Informationssysteme mbH
resSolution Scheuring Project Management AG
SureTrak Project Manager Primavera
Teamcenter Project EDS PLM Solutions
untermStrich untermStrich software GmbH
Vertabase Pro Standpipe Studios Inc.
vProject MediaSolv.com Inc.
Table 2
Interview partner companies for the reference model validation phase
Company Location
Agroscope FAW Wa
¨
denswil, Eidgeno
¨
ssische
Forschungsanstalt fu
¨
r Obst-, Wein- und
Gartenbau
Wa

¨
denswil, Switzerland
BASF AG Ludwigshafen, Germany
Bayerische Hypo- und Vereinsbank AG Munich, Germany
Credit Suisse Zurich, Switzerland
EADS Deutschland GmbH Ulm, Germany
Henkel KGaA Du
¨
sseldorf, Germany
HighQ
IT
for the financial Industry GmbH Ottobrunn-Riemerling
(Munich), Germany
Infineon Technologies AG Munich, Germany
Multi-national financial services company
(anonymous)
Zurich, Switzerland
Softlab GmbH Hamburg, Germany
T-Systems International GmbH Erfurt, Germany
ThyssenKrupp Stahl AG Duisburg, Germany
Vattenfall Europe Berlin, Germany
22 F. Ahlemann / International Journal of Project Management 27 (2009) 19–30
Lincoln and Guba [33, p. 234], this cyclic process was ter-
minated when insights gained from preceding interview dis-
cussions no longer enhanced the reference model. It was
then concluded that the domain experts had reached con-
sensus on the reference model’s propositions. The selection
of domain experts followed both the chain sampling and
theoretical sampling approaches [32, p. 237]. Although
they were identified by means of chain sampling, the inter-

view topic was determined by means of the M-Model and
theoretical sampling since not all aspects of enterprise-wide
project management can be discussed in a single interview.
(3b) Practical application. The validation of the refer-
ence model was not only achieved through the interviews
with domain experts, but it was also validated in respect
of application projects (see Section 6).
(3c) Refinement of the reference model. The experience
gained in the above-mentioned projects was also used to
refine the reference model.
(4) Documentation. The documentation of the reference
model contains a description of the construction process,
the reference model itself, annotations of model elements,
including theo retical 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 (proj ect life-
cycle) and explains the managem ent levels involved. For
each element of the M-Model, process and data models
are defined in RefMod
PM
. The M-Model’s two different
layers indicate this.
4.1. Project life-cycle
Regardless of their individual objectives, projects
undergo a series of phases that constitute the project life-

cycle. At a high level of abstraction, this life-cycle can be
divided into the following phases [34, p. 6,35, p. 49]:
 Initiation: In the initiation phase, project ideas are gen-
erated, collected, recorded, and examined (Idea Gene ra-
tion). Their feasibility, profitability, and strategic impact
are analyzed so that a final decision can be made regard-
ing their implementation (Idea Evaluation). This phase
ends with a formal go/no-go decision made by the man-
agement team (Portfolio Planning).
 Planning: In this phase, the project idea is translated into
a project plan and the necessary resources (financial,
human, and other resources) are provided (Project Prep-
aration). The project manager also refines the project
plan (Detailed Planning).
 Execution: In this phase, the project idea is realized
through the resources assigned to the project (Project
Execution). Information regarding the project executi on
is collected and analyzed for controlling purposes (Pro-
ject Controlling) . Information is then aggregated to
obtain an overall view of the project situation (Portfolio
Controlling).
Data Structures
Processes
Top Management:
Portfolios
Strategy Definition
Personnel and Financial Management
Project
Manager:
Projects

Project
Office,
Committees:
Projects,
Programs
Idea
Generation
Idea
Evaluation
Portfolio
Planning
Portfolio
Controlling
Project
Preparation
Project
Execution
Detailed
Planning
Project
Controlling
External
Project
Termination
Internal
Project
Termination
Fig. 2. The M-Model.
F. Ahlemann / International Journal of Project Management 27 (2009) 19–30 23
 Termination: In the termination phase, the project

results are submitted to the project sponsor (Internal
Project Termination). In addition, the enterprise closes
the project and endeavours to learn from the experiences
(External Project Termination).
These phases are reflected on the outline of the ‘‘M” (see
Fig. 2) and are further sub-divided into process steps, as
indicated. It is not obligatory for all projects to run
through all process steps. Even if a project has completed
a phase but lacks profitabi lity and feasibility, or its strate-
gic positioning is inappropriate, it could still be terminated
immediately [36, p. 545].
4.2. Management levels
Three different management levels are distinguished
within the M-Model (cp. [34, p. 8,37, p. 29]:
 Project manager: At the operational project manage-
ment level, the project manager is responsible for the
planning and execution of a single project . This level is
represented by the lower third of the M-Model.
 Project office/committees: This management level com-
prises all permanent or temporary organizational ele-
ments that are responsible for multi-project
coordination and planning and controlling activities
that affect all projects, for example, the project office
and committees [38, p. 96,39, p. 386, 40, p. 129].
 Top management: The management board responsible
for the entire project portfolio is represented by the
upper third of the M-Model [41, p. 4].
4.3. Strategy definition, personnel, and financial systems
The strategy definition (the ‘‘roof” of the ‘‘M”) is a nec-
essary input for portfolio planning, since it requires a

clearly defined business strategy [35, p. 105]. On the other
hand, the personnel and the financial system (the founda-
tion of the ‘‘M”) are important building blocks, since they
deliver information that is required for planning and con-
trolling purposes such as staff availability and/or financial
transactions [38, p. 261, 281].
4.4. Refinement of the M-Model
The reference model consists of 10 basic activity dia-
grams that correspond to the project life-cycle phases out-
Table 3
Activity diagrams that are part of the RefMod
PM
reference model
M-Model element Contents Number of
diagrams
Idea generation Generate, classify, and screen
project ideas.
1
Idea evaluation Describe project ideas, assess
their feasibility, and decide on
their realization.
1
Portfolio planning Perform the organizational
budgeting, derive a project
portfolio, and prioritize the
projects.
1
Project Preparation Set up the project, procure
external resources.
2

Project planning Perform the detailed project
planning, including scheduling,
resource assignment, etc.
1
Project execution Execute the project; manage the
project work, ensure the
quality, record the resource
usage, process the risks, hold
team meetings.
5
Project controlling Record and communicate the
project status, process change
requests, hold steering
committee meetings
4
Portfolio controlling Check the budget spending and
the project performance.
1
Internal project
termination
Claim management, supplier
assessment, team member
assessment.
1
External project
termination
Archive project documentation,
update skill profiles, do benefit
controlling.
1

Table 4
Class diagrams in the RefMod
PM
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
3
Financial management Accounts, transactions,
currencies, cost centres, cost
objects
1
Strategic planning Strategic targets,
organizational budgets, units
1
Idea generation Project classification, project
screening criteria
1
Idea evaluation Milestones, resource needs,
project cost calculations,
project budgets, key
performance indicators
2

Portfolio planning Budgets, resource capacities,
strategic project assessments,
project portfolios
1
Project preparation Resource calendars, resource
assignments, decisions, reports,
meetings, suppliers, contracts
2
Project planning Quality assurance, precedence
relationships, stakeholders,
risks, risk measures
1
Project execution Documents, quality approvals,
quality measures, timesheets,
meeting minutes
2
Project controlling Status reports, change requests 1
Portfolio controlling Budget spending reports 1
Internal project
termination
Supplier assessments, staff
assessments
1
External project
termination
1
24 F. Ahlemann / International Journal of Project Management 27 (2009) 19–30
lined in the scope of the M-Model. Each of these activity
diagrams has an assigned class diagram that describes the
data structures required to run the process. Some activity

diagrams are further refined, providing more detailed pro-
cess descriptions. In addition to this, the reference model
contains class diagrams that indicate the interfaces to per-
sonnel and financial systems, as well as to the strategic
planning process. These diagrams moreover specify the
data required from those related systems. Furthermore,
some of the fundamental data structures – specifically orga-
nizational structures, basic resou rce data, and elemental
classes that describe the structure of projects – that are used
throughout the project life-cycle are also presented in sep-
arate class diagrams. Altogether, the refer ence model com-
prises 18 activity diagrams (Table 3.), 18 class diagrams
(Table 4.), 101 classes, 112 methods, and 245 attributes.
The level of detail is adequate for organizational model-
ling, but requires further refinement for software design
and implementation.
5. An exemplary excerpt: modelling of programs, projects,
and work breakdown structures
Owing to its size, it is not possible to present RefMod
PM
in its entirety. Instead, this section contains an excerpt from
the RefMod
PM
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 Schlag-

heck, as both have corresponding model elements in their
reference model. Other project management areas are not
referred to in this section. For an easier comparison, all three
reference models have been drawn using the same modelling
language (UML 2). Moreover, the relevant model elements
are concentrated in a single diagram. In the textual descrip-
tion, class names are provided in brackets.
In the following sections, general requirements for the
modelling of project master data gathered from literature
and reverse engineering are discussed (see Section 3).
Thereafter, an explanation is provided on how Froese
and Schlagheck model the domain. Finally, the RefMod
PM
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. Project s, work packages, and activities require a com-
prehensive set of attributes that allows the project to
be fully described, planned, and controlled.
2. The work breakdown structure may have any number of
levels.
3. All project managem ent methods (e.g., risk, quality,
resource, and cost management methods) must be appli-
cable to any level of the work breakdown structure, the
project itself, and project programs.
4. It must be possible to save any number of project base-

lines for management and controlling purposes.
5. There should be at least three specific plan versions of
any project: (a) the original plan approved by manage-
ment, (b) the current plan containing all changes result-
ing from approved change requests, and (c) the actual
data.
6. Scenarios must ‘‘behave ” like a normal project plan.
Any project management method should be applicable
to a scenario.
7. Project s must be clear ly assigned to a life-cycle phase or
project status. There must be clarity regarding the phase
in which a project is at a specific point in time, as well as
when this status changes.
8. For the purpose of multi project management, it must
be possible to present projects in a hierarchical system.
5.2. Reference model by Froese
According to Froese, a project (Project) is characterized
by a project number, a construction plan, contracts, a facil-
ity, a locat ion, and participants (Fig. 4).
The construction plan (ConstructionPlan) itself consists
of several activities (Activity) that can form an activity net-
work and have attributes for storing the resul ts of a sched-
uling process. Each activity has an assigned activity
category (ActivityCategory) that ‘‘represents the category
of construction effort that involves the application of a par-
ticular action to a specific set of component categories
using a method and, typically, a set of resources.” [22, p.
87] The time, resource, and cost management are entirely
based on activities.
Evidently, Froese’s model is not able to meet the

requirements described above. One fundamental limitation
of his model is that it does not support work breakdown
structures. Moreover, it only ‘‘knows ” planning data;
actual data or even scenari os are not supported.
5.3. Reference model by Schlagheck
Schlagheck follows a completely different approach to
Froese when it comes to model project structures (Fig. 5).
According to Schlagheck, projects (Project) are arranged
in a hierarchy and are characterized by an objective and a
status. Each project has exactly one project plan. A work
breakdown structure (WorkBreakdownStructure) is a spe-
cial project plan and consists of WBS elements (WBSEle-
ment) that also form a hierarchy. A WBS element can
either be a sub-project, a task, a work package or an
activity.
F. Ahlemann / International Journal of Project Management 27 (2009) 19–30 25
Schlagheck’s model is clearly more advanced than Fro-
ese’s. It allows work breakdown structures with an unlim-
ited number of levels to be set up. Consequently,
Schlagheck is at least able to meet requirement 2.
5.4. RefMod
PM
RefMod
PM
tries to meet the requirements outlined
above by introducing a very fundamental data structure
called Initiative (Fig. 3). An initiative is a generalization
of any form of action that has a defined start and end date
and is unde rtaken to reach a goal. Therefore, an initiative
may be a program, a project, a sub-project, a pro ject phase,

a work package, an activity or a task (indicated by the
inheritance relationship between these classes). By using a
generic data structure for these different types of objects,
project management methods from, for example, risk,
quality, resource or cost management can be implemented
to be applicable to all of them by employing the class Ini-
tiative (requirement 3). Initiatives are characterized by a
relatively large set of attributes covering scope, time, and
risk management (other functional areas of project man-
agement like resource or cost management are covered by
other data structures). RefMod
PM
thus meets requ irement
1.
By means of a reflexive association, initiatives form a
hierarchy that can be used to (a) set up a work breakdown
structure, (b) create programs by subsuming several pro-
jects, or (c) arrange projects in a multi project management
environment, for example, in the form of an organizational
structure (requirements 2, 8).
A life-cycle phase (LifeCyclePhase) divides an initia-
tive’s lifetime into several standardized time spans. The
beginning or ending of such a time span can be recorded
-ID
-Name
-Description
-Comment
-Objective
-Activities
-Conditions

-Dependencies
-StartDate
-EndDate
-LatestStartDate
-EarliestStartDate
-LatestEndDate
-EarliestEndDate
-Effort
-Float
-Duration
-Risk
-PostponedUntil
-Priority
-ResourcePlanningType
-Mandatory
«Orga, IT»
Initiative
-Parent0 1
-Child
0 *
-Name
-Chargable
«Orga, IT, Config»
LifeCyclePhase
1
0 *
«Orga»
Programme
«Orga»
Project

«Orga»
SubProject
«Orga»
WorkPackage
«Orga»
Task
-VersionNumber
-CreationDate
-Description
-Editable
«Orga, IT»
PlanVersion
0 1
-AppovedPlan
0 *
0 1
-ActualPlan
0 *
0 1
-BasePlan
0 *
«Orga»Scenario
«Orga»PlanArchive
-Date
-Decision
-Comment
«Orga, IT»
InitiativeLifeCyclePhase
1 *
1

1
0 *
«Orga»
Phase
1
0 *
«Orga»
Baseline
Fig. 3. Project master data in RefMod
PM
.
26 F. Ahlemann / International Journal of Project Management 27 (2009) 19–30
-ProjectNumber
ProjectSpecificObject
-Contracts
-Facility
-Location
-Particiapants
Project
-DefaultConstructionMethod
-DurationUnits
ConstructionPlan
1
1
-Components
-EarlyFinish
-EarlyStart
-LateFinish
-LateStart
-Duration

-TotalFloat
Activity
1
*
-Action
-ComponentCategories
-Method
-PartOf
-QuantityFormula

ActivityCategory
1
*
-Successo
r
*
-Predecessor *
Fig. 4. Project master data according to Froese.
-Objective
-Status
Project
-Hierarchy 0 1
0 *
-ResponsiblePerson
ProjectPlan
1
1
WorkBreakdownStructure
WorkBreakdownStructurePlanning
-Description

WBSElement
11 *
-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) 19–30 27
in respect of each initiative (InitiativeLifeCyclePhase).
Consequently, the overall initiative life-cycle is transparent
(requirement 7). This data structure pattern can be used to
implement different life-cycle models and enables software
systems developed with RefMod
PM
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 pro-
ject management, like time, cost, risk, or resource data (not
shown in the excerpt) and is usually created by copying the
actual project plan. Plan versioning can be used to create

baselines at certain points in time (PlanArchive). However,
plan versions can also be used as a starting point for sce-
nario planning (Scenario, requirement 6). Since the plan
versioning concept is based on the Initiative class, it is pos-
sible to use this kind of functionality for entire projects or
even project portfolios on any level of the WBS. Although
a user can create an infinite number of plan versions
(requirement 4), RefM od
PM
allows three specific plan ver-
sions to be assigned to each initiative (requirement 5).
Apart from meet ing empirically gathered requirements,
our model also impacts the efficiency of software develop-
ment. During the practical application of the model, we
discovered that the Initiative and PlanVersion data struc-
tures can significantly reduce development efforts when
properly implemented. Software manufacturers state that
they can now combine software features that previously
had to be developed separately. This reduces costs and
development time as, for example, carefully implemented
plan version functionality almost automatically yields the
largest part of a full-featured scenario management. In
addition, the Initiative data structure allows the same soft-
ware functionality to be used for risk, quality, time and
resource management on both the work package, project
and portfolio levels. This is a significant benefit when com-
pared to the approaches of present-day PM software sys-
tems that usually apply differen t data structures for work
packages, projects and portfolios.
5.5. Conclusions

The discussion of the model excerpt indicates that Ref-
Mod
PM
goes beyond the scope of previous reference mod-
els. This is not surprising, since RefMod
PM
uses some ideas
from previous work and extends it according to additional
requirements. Table 5. demonstrates the extent to which
RefMod
PM
represents significant research progress in the
field of PMIS reference models, since it
 has a significantly wider scope, covering not only project
planning and execution, but also the initiation and ter-
mination phase,
 has been designed to serve both single and multi project
management purposes, and
 covers all functional areas of PMI’s PMBOK.
Table 5
RefMod
PM
compared to existing reference information models for project management
Froese (1992) Schlagheck (2000) RefMod
PM
Domain Characteristics
Project lifecycle phases Planning Planning, execution Initiation, planning, execution, termination
Management levels Project Project Project, program, portfolio
Supported industries Construction industry Any Any
Covered

b
Integration management No No Yes
Scope management Yes Yes Yes
Time management Yes Yes Yes
Cost management Yes Yes Yes
Quality management No Yes Yes
Human resource management No No Yes
Communications management No No Yes
Risk management No No Yes
Procurement management Yes No Yes
(Semi-)Formal models available for
Data structures Yes Yes Yes
Organizational structures Yes No Yes
Processes No
a
Yes Yes
Other characteristics
Number of classes/object types 36 20 101
Modeling language(s) SOL (Proprietary) UML 1 UML 2
Research methodology
Model evaluation Yes
c
No Yes
Documentation of design and evaluation methods No No Yes
Communication of research Yes Yes Yes
a
Processes are only modeled implicitly, representing process steps (activities) in the data model.
b
According to the nine knowledge areas of the Project Management Body of Knowledge (PMBOK) [PMI04, 9].
c

A prototype has been developed, although it is unclear whether this prototype has been evaluated.
28 F. Ahlemann / International Journal of Project Management 27 (2009) 19–30
 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 RefMod
PM
6.1. Software specification and selection
As RefMod
PM
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 off the shelf
package. RefMod
PM
can first of all be used as a foundation
for the software specification and design. Secondly, it can
serve as a basis for defining requirements that commercial
software needs to meet. In both cases, the following proce-
dure is recommended to fully benefit from the knowledge
contained in the reference model:
1. Define the process steps and layers from the M-Model
that are relevant to the proje ct. This leads to a high-level
scope definition that allows the class and activity dia-
grams to be selected that need to be taken into
consideration.
2. Modif y the activity diagrams to truly fit individual com-
pany needs. The reference model’s process descriptions

are somet imes too detailed, whilst other times they
may require further refinement.
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 refine the data structure to
accommodate more detailed process descriptions.
4. Specify requirements: With regard to software develop-
ment, the resulting company-specific model can be used
to provide more detailed software specifications, for
example, 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 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 model’s application can accel-
erate requirements engineering and software selection
projects significantly. Subject matter experts estimate
that it can reduce efforts by 30–50%.
6.2. Other application examples
The application of RefMod
PM
is not limited to the spec-
ification and introduction of PM software. The foll owing
cases illustrate its wide applicability:
1. It was used to develop a new project initiation and port-
folio management process for a multinational high-tech
company headquarters in Switzerland. Within a one-day
workshop, 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 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 firms, and project management
experts from diverse companies, developed a
comprehensive XML schema for project manage-
ment data exchange within six months by using Ref-
Mod
PM
[42,43]. DIN will publish the data model
during 2008.
3. The result of this work has also been used in several soft-
ware development projects such as by PLANTA, one of
the leading German project management software ven-
dors [44, p. 4]. Another vendor is currently developing
a completely new software system based on RefMod
PM
.
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 of
Enterprise Application Integration (EAI) and Knowl-
edge Management [45].
7. Summary
This paper has introduced RefMod
PM
, a new conceptual

information system reference model for project and project
portfolio management. RefMod
PM
tries to overcome exist-
ing reference models’ deficiencies by covering more aspects
of project management and offering data structures and
processes that have been validated empirically and have
proven to be stable, flexible, and accepted by subject matter
experts. The development of the first version of RefMod
PM
took approximately 1.5 man-years to complete. We are
currently working on an extended second version of Ref-
Mod
PM
that is scheduled to be completed during 2008.
Several software manufacturers that develop new prod-
ucts or product versions are currently using RefMod
PM
.
The adoption of RefMod
PM
is also promoted through
the second, English language edition of a German language
book, which should be available in 2008. The new official
German industry norm based on RefMod
PM
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. Wu
¨
rzburg: BARC;
2006.
[3] Dorndorf U, Pesch E, Phan-Huy T. Time-oriented branch-and-
bound algorithm for resource-constrained project scheduling with
generalised precedence constraints. Manage Sci 2000;46(10):1365–84.
[4] Chang CK, Christensen MJ, Zhang T. Genetic algorithms for project
management. Ann Software Eng 2001;11(1):107–39.
F. Ahlemann / International Journal of Project Management 27 (2009) 19–30 29
[5] Hartmann S. A self-adapting genetic algorithm for project scheduling
under resource constraints. Naval Res Logist 2002;49(5):433–48.
[6] Dworatschek S, Hayek A. Marktspiegel Projekt-Management Soft-
ware – Kriterienkatalog und Leistungsprofile. Ko
¨
ln: Verlag TU
¨
V
Rheinland; 1992.
[7] Rabl W, Fiedler S. Projektmanagement-Software: Marktu
¨
bersicht
und Entwicklungstrends. In: Gareis R, editor. Projekte & EDV.
Wien: Service-Fachverlag; 1994. p. 37–54.
[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):222–9.

[10] Schulz R, Malzahn U, von Schoultz F. An integrated project
management information system. Leipzig; 1996.
[11] Ehlers P. Integriertes Projekt- und Prozeßmanagement auf Basis
innovativer Informations- und Kommunikationstechnologien: Das
GroupProject-System. Aachen: Shaker; 1997.
[12] Hayek A. Projektmanagement-Software: Anforderungen und Leis-
tungsprofile, Verfahren der Bewertung und Auswahl sowie Nutzungs-
organisation von Projekt-Software. Ko
¨
ln: Verlag Tu
¨
V Rheinland; 1993.
[13] Meyer MM. Stand und Trend von Softwareunterstu
¨
tzung fu
¨
r
Projektmanagement-Aufgaben – Zwischenbericht zu den Ergebnissen
einer Befragung von Projektmanagement-Experten. Bremen; 2005.
[14] Meyer MM. Softwareunterstu
¨
tzung fu
¨
r das Projektmanagement.
Bremen: Universita
¨
t 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: a

design science perspective. In:Proceedings ofthe2006 ACMsymposium
on applied computing, Dijon, France. ACM Press; 2006. p. 1561–2.
[17] Hevner AR, March ST, Park J, Ram S. Design science in information
systems research. MIS Quart 2004;28(1):75–105.
[18] Fettke P, Loos P. Referenzmodellierungsforschung. Wirtschaftsin-
formatik 2004;46(5):331–40.
[19] Thomas O. Understanding the term reference model in information
systems research: history, literature analysis and explanation. LNCS
2006;3812:484–96.
[20] Becker J, Schu
¨
tte 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):94–9.
[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, Bjo
¨
rk 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 first international conference on the management
of information technology for construction. World Scientific; 1993.
[24] Karstila K, Bjo
¨
rk BC, Hannus M. A conceptual framework for
design 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 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 first
congress held in conjunction with A/E/C systems’94. American
Society of Civil Engineers; 1994. p. 778–85.
[27] Froese T, Yu QK. StartPlan: producing schedule templates using
IRMA. In: Khozeimeh K, editor. Computing in civil engineering –
proceedings of the first congress held in conjunction with A/E/C
Systems ’94. American Society of Civil Engineers; 1994. p. 63–70.
[28] Schlagheck B. Objektorientierte Referenzmodelle fu
¨
r das Prozess-
und Projektcontrolling: Grundlagen – Konstruktion –
Anwendungsmo
¨
glichkeiten. Wiesbaden: Gabler; 2000.
[29] Schu
¨
tte R. Grundsa
¨
tze ordnungsma
¨
ssiger Referenzmodellierung:
Konstruktion konfigurations- 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):185–95.
[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 manage-
ment 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, Ku
¨
hn F, Wollmann P, editors. Multiprojekt-
management Strategische und operative Steuerung von Projektport-
folios. Frankfurt: Allgemeine Buch; 2002. p. 2–36.
[38] Burghardt M. Projektmanagement: Leitfaden fu
¨
r die Planung,
U
¨
berwachung und Steuerung von Entwicklungsprojekten. Erlangen:
Publicis MCD; 2002.
[39] Schulte-Zurhausen M. Organisation. Mu

¨
nchen: Vahlen; 1999.
[40] Alter R. Integriertes Projektcontrolling. Gießen: Verlag der Ferbers-
chen Universita
¨
tsbuchhandlung; 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. Projektmanage-
ment Aktuell 2006;17(2):41–4.
[43] Angermeier G. Genormtes Datenmodell fu
¨
r Projektmanagement:
Katalysator fu
¨
r eine projektorientierte Wirtschaft? Projekt Magazin
2005(6).
[44] Matthes G. Unterlage zum 9. PLANTA-Anwenderforum, 17–19. 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):
813–23.
30 F. Ahlemann / International Journal of Project Management 27 (2009) 19–30