Towards a conceptual reference model for project management ...

Available online at www.sciencedirect.com

International Journal of Project Management 27 (2009) 19–30 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 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 management 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 problems related to project management (e.g. [3–5]), (2) the assessment and comparison of commercial project management 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

E-mail address: [email protected] 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. [12–14]). Two specific problems are very rarely addressed: PMIS are become increasingly complex. Therefore, firstly, information system designers are facing a growing number of business processes that have to be supported with project management software. Secondly, information system users have difficulties 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) 19–30

projects (RefModPM). The model can be used for the design of project management software, the set-up of the surrounding organizational system, as well as for the definition 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 Unified 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 five, which is then compared to the modelling approaches presented by other authors. In section six, examples that illustrate the model’s application are described, followed by concluding remarks that summarize the paper. 2. Foundation and related work 2.1. The role of information models in the development of information systems Information systems (IS) are socioeconomic systems that comprise software, hardware, and the surrounding organizational system. Models play an important role during the design and implementation of information systems. Depending on the phase or level of IS design and implementation, 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 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 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 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 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 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 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 frequently used as synonyms. In the following sections, we discuss all the variant forms as long as they meet the characteristics 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 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 first 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-


elling techniques are used to develop a project management domain model and a corresponding application system. The term ‘‘reference information model” was first used by Luiten et al. in 1993 when they combined their individual research activities on modelling in the architecture, engineering, and construction domain. The resulting unified domain model is called IRMA (Information Reference Model for AEC) [23]. Although not obvious at first sight, this model largely comprises project management activities and data

structures. It contains modelling results from Froese, as well as from other researchers such as, for example, Karstila et al. [24] and Luiten and Bakkeren [25]. Although IRMA has been revised several times [26], it has never been published in its entirety. It was, however, used as a basis for the design and implementation of a software system called StartPlan [27]. Schlagheck published a combined reference information model for process and project controlling [28] that focuses on single project management environments with particu-

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


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 Schu¨tte [29, p. 177]. The research comprised: (1) Problem definition. The research objective was defined and the problem domain specified as documented in the first section of this paper [29, p. 189,28, p. 79]. (2) Exploration and generation of hypotheses. The second phase consisted of three different activities: (2a) Construction of a reference model architecture. A conceptual information system architecture was developed that served as a frame of reference for the subsequent model construction [29, p. 207,28, p. 79]. This information system architecture is called the M-Model, and is 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/refinement 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, refine, 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 first 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 model’s 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 fu¨r 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 Wa¨denswil, Eidgeno¨ssische Forschungsanstalt fu¨r Obst-, Wein- und Gartenbau BASF AG Bayerische Hypo- und Vereinsbank AG Credit Suisse EADS Deutschland GmbH Henkel KGaA HighQIT for the financial Industry GmbH

Wa¨denswil, Switzerland

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

Ludwigshafen, Germany Munich, Germany Zurich, Switzerland Ulm, Germany Du¨sseldorf, 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 refined or redesigned if the interview results indicated that this was necessary (return to step (2d)). The process was then continued. Following an approach by


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 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 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) Refinement of the reference model. The experience gained in the above-mentioned projects was also used to refine the reference model. (4) Documentation. The documentation of the reference model contains a description of the construction process, the reference model itself, annotations of model elements, including theoretical and empirical evidences, and the 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 defined in RefModPM. The M-Model’s two different layers indicate this. 4.1. Project life-cycle Regardless of their individual objectives, projects undergo a series of phases that constitute the project 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, profitability, and strategic impact are analyzed so that a final 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 (financial, human, and other resources) are provided (Project Preparation). The project manager also refines the project plan (Detailed Planning). Execution: In this phase, the project idea is realized through the resources assigned to the project (Project Execution). Information regarding the project execution is collected and analyzed for controlling purposes (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


Termination: In the termination phase, the project results are submitted to the project sponsor (Internal Project Termination). In addition, the enterprise closes the project and endeavours to learn from the experiences (External Project Termination). These phases are reflected on the outline of the ‘‘M” (see Fig. 2) and are further sub-divided into process steps, as indicated. It is not obligatory for all projects to run through all process steps. Even if a project has completed a phase but lacks profitability and feasibility, or its strategic 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]:

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 necessary 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 foundation of the ‘‘M”) are important building blocks, since they deliver information that is required for planning and controlling purposes such as staff availability and/or financial transactions [38, p. 261, 281]. 4.4. Refinement 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 office/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 profiles, do benefit controlling.

1

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 classification, 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, staff assessments ...

3

1

Financial management

1

Strategic planning Idea generation

2

Idea evaluation

1 Portfolio planning 5 Project preparation

4

Project planning

Project execution 1 1

1

Project controlling Portfolio controlling Internal project termination External project termination

1

1 1 2

1

2

1

2

1 1 1 1


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 process descriptions. In addition to this, the reference model contains class diagrams that indicate the interfaces to personnel 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 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 refinement for software design and implementation. 5. An exemplary excerpt: modelling of programs, projects, and work breakdown structures Owing to its size, it is not possible to present RefModPM in its entirety. Instead, this section contains an excerpt from the 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 specific 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 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 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 effort that involves the application of a particular action to a specific set of component categories using a method and, typically, a set of resources.” [22, p. 87] The time, resource, and cost management are entirely based on activities. Evidently, Froese’s model is not able to meet the requirements described above. One fundamental limitation of his model is that it does not support work breakdown structures. Moreover, it only ‘‘knows” planning data; actual data or even scenarios are not supported. 5.3. Reference model by Schlagheck Schlagheck follows a completely different approach to Froese when it comes to model project structures (Fig. 5). According to Schlagheck, projects (Project) are arranged in a hierarchy and are characterized by an objective and a status. Each project has exactly one project plan. A work breakdown structure (WorkBreakdownStructure) is a 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) 19–30 «Orga» Baseline

«Orga»PlanArchive

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

«Orga»Scenario «Orga» Programme

1

0..1

0..1

0..1

0..*

0..*

«Orga» Project

-ActualPlan

0..*

-AppovedPlan

0..*

-BasePlan

1

«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

Schlagheck’s model is clearly more advanced than Froese’s. 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 defined start and end date and is undertaken to reach a goal. Therefore, an initiative may be a program, a project, a sub-project, a project phase, a work package, an activity or a task (indicated by the inheritance relationship between these classes). By using a generic data structure for these different types of objects, project management methods from, for example, risk,

.

quality, resource or cost management can be implemented to be applicable to all of them by employing the class 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 reflexive 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 initiative’s lifetime into several standardized time spans. The beginning or ending of such a time span can be recorded


27

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

Project -Contracts -Facility -Location -Particiapants

1

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

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


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 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 infinite number of plan versions (requirement 4), RefModPM allows three specific plan versions to be assigned to each initiative (requirement 5). Apart from meeting empirically gathered requirements, our model also impacts the efficiency of software development. During the practical application of the model, we discovered that the Initiative and PlanVersion data structures 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 software 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 compared to the approaches of present-day PM software systems that usually apply different 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 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 termination phase, has been designed to serve both single and multi project management purposes, and covers all functional areas of PMI’s 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.


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 specification 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 off the shelf package. RefModPM 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 procedure 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 project. This leads to a high-level scope definition that allows the class and activity diagrams to be selected that need to be taken into consideration. 2. Modify the activity diagrams to truly fit individual company needs. The reference model’s process descriptions are sometimes 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 development, 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 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 model’s application can accelerate 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 RefModPM is not limited to the specification 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 specified 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 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’ 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 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 official 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. Wu¨rzburg: 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):1365–84. [4] Chang CK, Christensen MJ, Zhang T. Genetic algorithms for project management. Ann Software Eng 2001;11(1):107–39.

30


[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¨V ware – Kriterienkatalog und Leistungsprofile. Ko¨ln: Verlag TU 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 Leistungsprofile, Verfahren der Bewertung und Auswahl sowie Nutzungsorganisation 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 of the 2006 ACM symposium 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. Wirtschaftsinformatik 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 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 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 Prozessund 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 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, Ku¨hn F, Wollmann P, editors. Multiprojektmanagement Strategische und operative Steuerung von Projektportfolios. Frankfurt: Allgemeine Buch; 2002. p. 2–36. [38] Burghardt M. Projektmanagement: Leitfaden fu¨r die Planung, ¨ berwachung und Steuerung von Entwicklungsprojekten. Erlangen: U Publicis MCD; 2002. [39] Schulte-Zurhausen M. Organisation. Mu¨nchen: Vahlen; 1999. [40] Alter R. Integriertes Projektcontrolling. Gießen: Verlag der Ferberschen 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. Projektmanagement 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.