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: frederik.ahlemann@ebs.de 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 [...]... 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. .. 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:... [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... 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, Bjork BC, Cooper G, Junge R, Karstila K, et al... 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... 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 F Ahlemann / International Journal of Project Management 27 (2009) 19–30 [5] Hartmann S A self-adapting genetic algorithm for project scheduling...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 RefModPM 6.1 Software specification and selection As RefModPM is a conceptual reference model for PMIS, it will be especially useful... 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, Schutte R Handelsinformationssysteme... 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... 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, Bjork BC, Hannus M A conceptual framework for ¨ design and construction information In: Proceedings 1st international symposium . Towards a conceptual reference model for project management information systems Frederik Ahlemann Information Systems 2, European Business. 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