Towards a conceptual reference model for project management information systems

Transcription

1 Available online at International Journal of Management 27 (2009) Towards a conceptual reference model for project management information systems Frederik Ahlemann Information Systems 2, European Business School, International University, Schloss Reichartshausen, Oestrich-Winkel, Germany Received 7 August 2007; received in revised form 7 January 2008; accepted 3 January 2008 Abstract 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 (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 3 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 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. Introduction management information systems (PMIS) are widely regarded as an important building block in today s project management []. 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 () 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 ]), and (4) research into address: frederik.ahlemann@ebs.de the usage of project management software systems (e.g. [2 4]). 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 [3, p. 9]. In contrast, approximately 99% of organizations use information systems for scheduling and time management [3, p. 3]. 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 /$30.00 Ó 2008 Elsevier Ltd and IPMA. All rights reserved. doi:0.06/j.ijproman

2 20 F. Ahlemann / International Journal of Management 27 (2009) 9 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 definition of software requirements that are essential to select a commercial project management 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) 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.. 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:. 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) [5]. 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 [6,7] Reference models There is no mutual understanding of the term reference model [8, pp. 8,9]. 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 [9, p. 49]. 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 Previous project management reference models Approaches to the conceptual modelling of project management information systems have been published since the 980s. 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 [2]. 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-

3 F. Ahlemann / International Journal of Management 27 (2009) 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 993 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 Management Standards Analysis of 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 Order Fig.. The reference model construction process.

4 22 F. Ahlemann / International Journal of Management 27 (2009) 9 30 lar emphasis on general planning and controlling activities, but has never been completed [28, pp. 93, 2]. 3. The research and construction process Table Analyzed project management IS Product Acos Plus. Alpha Line AMS Realtime s Artemis Portfolio, and Resource Management Solution Cat4 eroom fx-project iplan Nucleus Our PC Projekt-Controlling-System Planview PPMS PQM Primavera P3e Insight Scheduler Explorer, WebTime Projekta Prolog Scheduler ProMOS PSIPENTA PM ressolution SureTrak Manager Teamcenter untermstrich Vertabase Pro v Company 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 Projektmanagement- Systeme GmbH PUS Prozess- und Systemtechnik GmbH Primavera Metafuse, Inc. Sciforma Corporation Exchange, Inc. BBL Software GmbH Meridian Systems Nesbit GSI Gesellschaft für Steuerungsund Informationssysteme mbh Scheuring Management AG Primavera EDS PLM Solutions untermstrich software GmbH Standpipe Studios Inc. MediaSolv.com Inc. Table 2 Interview partner companies for the reference model validation phase Company Location Agroscope FAW Wädenswil, Eidgenössische Wädenswil, Switzerland Forschungsanstalt für Obst-, Wein- und Gartenbau BASF AG Ludwigshafen, Germany Bayerische Hypo- und Vereinsbank AG Munich, Germany Credit Suisse Zurich, Switzerland EADS Deutschland GmbH Ulm, Germany Henkel KGaA Düsseldorf, Germany HighQ IT for the financial Industry GmbH Ottobrunn-Riemerling (Munich), Germany Infineon Technologies AG Munich, Germany Multi-national financial services company Zurich, Switzerland (anonymous) Softlab GmbH Hamburg, Germany T-Systems International GmbH Erfurt, Germany ThyssenKrupp Stahl AG Duisburg, Germany Vattenfall Europe Berlin, Germany The reference model construction discussed in this article was realized within a four-phase research process conducted between 2002 and 2007 (Fig. ) derived from a process model for reference model construction by Schütte [29, p. 77]. The research comprised: () Problem definition. The research objective was defined and the problem domain specified as documented in the first section of this paper [29, p. 89,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 ). 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,3]). (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, possible 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

5 F. Ahlemann / International Journal of Management 27 (2009) 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 M- model embraces all tasks related to the initiation, planning, execution, and termination of projects. It describes the process of enterprise-wide project management (project lifecycle) and explains the management 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.. 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 ( 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 ( Execution). Information regarding the project execution is collected and analyzed for controlling purposes ( Controlling). Information is then aggregated to obtain an overall view of the project situation (Portfolio Controlling). Top Management: Portfolios Strategy Definition Portfolio Planning Portfolio Controlling Office, Committees: s, Programs Idea Evaluation Preparation Controlling External Termination Manager: s Idea Generation Detailed Planning Execution Internal Termination Personnel and Financial Management Processes Data Structures Fig. 2. The M-Model.

6 24 F. Ahlemann / International Journal of Management 27 (2009) 9 30 Termination: In the termination phase, the project results are submitted to the project sponsor (Internal Termination). In addition, the enterprise closes the project and endeavours to learn from the experiences (External 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] Management levels Three different management levels are distinguished within the M-Model (cp. [34, p. 8,37, p. 29]: 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. 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 RefMod PM reference model M-Model element Contents Number of diagrams Idea generation Generate, classify, and screen project ideas. Idea evaluation Describe project ideas, assess their feasibility, and decide on their realization. Portfolio planning Perform the organizational budgeting, derive a project portfolio, and prioritize the projects. Preparation Set up the project, procure 2 external resources. planning Perform the detailed project planning, including scheduling, resource assignment, etc. execution Execute the project; manage the 5 project work, ensure the quality, record the resource usage, process the risks, hold team meetings. controlling Record and communicate the 4 project status, process change requests, hold steering committee meetings Portfolio controlling Check the budget spending and the project performance. Internal project termination External project termination Claim management, supplier assessment, team member assessment. Archive project documentation, update skill profiles, do benefit controlling. 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. 29]. Top management: The management board responsible for the entire project portfolio is represented by the upper third of the M-Model [4, p. 4] 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. 05]. 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. 26, 28] Refinement of the M-Model The reference model consists of 0 basic activity diagrams that correspond to the project life-cycle phases out- Table 4 Class diagrams in the RefMod PM reference model M-Model element Contents (recurring contents are not listed) Foundation s, work breakdown structures, lifecycle phases; primary and secondary organizational structures, roles, resources, resource types; scenarios, archives, baselines Financial management Accounts, transactions, currencies, cost centres, cost objects Strategic planning Strategic targets, organizational budgets, units Idea generation classification, project screening criteria Idea evaluation Milestones, resource needs, project cost calculations, project budgets, key performance indicators Portfolio planning Budgets, resource capacities, strategic project assessments, project portfolios preparation Resource calendars, resource assignments, decisions, reports, meetings, suppliers, contracts planning Quality assurance, precedence relationships, stakeholders, risks, risk measures execution Documents, quality approvals, quality measures, timesheets, meeting minutes controlling Status reports, change requests Portfolio controlling Budget spending reports Internal project Supplier assessments, staff termination assessments External project termination... Number of diagrams

7 F. Ahlemann / International Journal of Management 27 (2009) 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 8 activity diagrams (Table 3.), 8 class diagrams (Table 4.), 0 classes, 2 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 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 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 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.. Requirements During the research process, the following general requirements regarding the modelling of project master data, project structures, baselines, and scenarios were deduced:. s, work packages, and activities require a comprehensive 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 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. s 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 Reference model by Froese According to Froese, a 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 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 () 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.

8 26 F. Ahlemann / International Journal of Management 27 (2009) 9 30 «Orga, IT» PlanVersion -VersionNumber -CreationDate -Description -Editable PlanArchive Scenario Baseline Programme -BasePlan -AppovedPlan -ActualPlan -Child «Orga, IT» Initiative -ID -Name -Description -Comment -Objective -Activities -Conditions -Dependencies -StartDate -EndDate -LatestStartDate -EarliestStartDate -LatestEndDate -EarliestEndDate -Effort -Float -Duration -Risk -PostponedUntil -Priority -ResourcePlanningType -Mandatory 0.. -Parent «Orga, IT, Config» LifeCyclePhase -Name -Chargable Sub Phase WorkPackage Task..* «Orga, IT» InitiativeLifeCyclePhase -Date -Decision -Comment Fig. 3. master data in RefMod PM. 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 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 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). RefMod PM thus meets requirement. 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

9 F. Ahlemann / International Journal of Management 27 (2009) SpecificObject -Number -Contracts -Facility -Location -Particiapants ActivityCategory -Action -ComponentCategories -Method -PartOf -QuantityFormula -... ConstructionPlan -DefaultConstructionMethod -DurationUnits * * Activity -Components -EarlyFinish -EarlyStart -LateFinish -LateStart -Duration -TotalFloat -Successor * Fig. 4. master data according to Froese. -Predecessor * -Hierarchy 0.. Plan -Objective -ResponsiblePerson -Status WorkBreakdownStructure WorkBreakdownStructurePlanning..* WBSElement -Description -Hierarchy 0.. Sub Task -Hierarchy 0.. WorkPackage Activity Fig. 5. Work breakdown structure according to Schlageheck.

10 28 F. Ahlemann / International Journal of Management 27 (2009) 9 30 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 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), RefMod PM 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 Conclusions The discussion of the model excerpt indicates that Ref- Mod PM goes beyond the scope of previous reference models. 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 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 RefMod PM compared to existing reference information models for project management Froese (992) Schlagheck (2000) RefMod PM Domain Characteristics lifecycle phases Planning Planning, execution Initiation, planning, execution, termination Management levels, 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 Modeling language(s) SOL (Proprietary) UML 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 Management Body of Knowledge (PMBOK) [PMI04, 9]. c A prototype has been developed, although it is unclear whether this prototype has been evaluated.

11 F. Ahlemann / International Journal of Management 27 (2009) 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.. 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 procedure is recommended to fully benefit from the knowledge contained in the reference model:. 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% Other application examples The application of RefMod PM is not limited to the specification and introduction of PM software. The following cases illustrate its wide applicability:. It was used to develop a new project initiation and portfolio management process for a multinational high-tech 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 Management (GPM), consisting of 5 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 Ref- Mod PM [42,43]. DIN will publish the data model during 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 RefMod PM. 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 RefMod PM, a new conceptual information system reference model for project and project portfolio management. RefMod PM 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 RefMod PM took approximately.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 Several software manufacturers that develop new products 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 The new official German industry norm based on RefMod PM should result in additional distribution. References [] White D, Fortune K. Current practice in project management an empirical study. Int J Manage 2002;20():7. [2] Ahlemann F, Backhaus K. management software systems requirements, selection processes and products. Würzburg: BARC; [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(0): [4] Chang CK, Christensen MJ, Zhang T. Genetic algorithms for project management. Ann Software Eng 200;():07 39.

12 30 F. Ahlemann / International Journal of Management 27 (2009) 9 30 [5] Hartmann S. A self-adapting genetic algorithm for project scheduling under resource constraints. Naval Res Logist 2002;49(5): [6] Dworatschek S, Hayek A. Marktspiegel Projekt-Management Software Kriterienkatalog und Leistungsprofile. Köln: Verlag TÜV Rheinland; 992. [7] Rabl W, Fiedler S. Projektmanagement-Software: Marktübersicht und Entwicklungstrends. In: Gareis R, editor. Projekte & EDV. Wien: Service-Fachverlag; 994. p [8] Kolisch R, Hempel K. Experimentelle Evaluation der methodischen Fundierung von Projektmanagementsoftware. Kiel; 995. [9] Kurbel K. Groupware extension for a software project management system. Int J Manage 994;2(4): [0] Schulz R, Malzahn U, von Schoultz F. An integrated project management information system. Leipzig; 996. [] Ehlers P. Integriertes Projekt- und Prozeßmanagement auf Basis innovativer Informations- und Kommunikationstechnologien: Das Group-System. Aachen: Shaker; 997. [2] Hayek A. Projektmanagement-Software: Anforderungen und Leistungsprofile, Verfahren der Bewertung und Auswahl sowie Nutzungsorganisation von Projekt-Software. Köln: Verlag TüV Rheinland; 993. [3] Meyer MM. Stand und Trend von Softwareunterstützung für Projektmanagement-Aufgaben Zwischenbericht zu den Ergebnissen einer Befragung von Projektmanagement-Experten. Bremen; [4] Meyer MM. Softwareunterstützung für das Projektmanagement. Bremen: Universität Bremen; [5] Object Management G. Unified modelling language: superstructure. Verson 2.0. Object Management Group; [6] 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; p [7] Hevner AR, March ST, Park J, Ram S. Design science in information systems research. MIS Quart 2004;28(): [8] Fettke P, Loos P. Referenzmodellierungsforschung. Wirtschaftsinformatik 2004;46(5): [9] Thomas O. Understanding the term reference model in information systems research: history, literature analysis and explanation. LNCS 2006;382: [20] Becker J, Schütte R. Handelsinformationssysteme. Landsberg-Lech: Verlag moderne Industrie; 996. [2] Raymond L. Information systems design for project management: a data modeling approach. Manage J 987;8(4):94 9. [22] Froese T. Integrated computer-aided project management through standard object-oriented models. Center for Integrated Facility Engineering: Stanford; 992. [23] Luiten G, Froese T, Bjö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; 993. [24] Karstila K, Björk BC, Hannus M. A conceptual framework for design and construction information. In: Proceedings st international symposium on building systems automation integration. Madison: Wisconsin; 99 [ ]. [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; 992. [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; 994. p [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; 994. p [28] Schlagheck B. Objektorientierte Referenzmodelle für das Prozessund Projektcontrolling: Grundlagen Konstruktion Anwendungsmöglichkeiten. Wiesbaden: Gabler; [29] Schütte R. Grundsätze ordnungsmässiger Referenzmodellierung: Konstruktion konfigurations- und anpassungsorientierter Modelle. Wiesbaden: Gabler; 998. [30] Lechler T. Erfolgsfaktoren des Projektmanagements. Frankfurt AM et al., editor. Lang; 997. [3] Cooke-Davies T. The real success factors on projects. Int J Manage 2002;20(3): [32] Patton MQ. Qualitative research and evaluation methods. Thousand Oaks: Sage; [33] Lincoln YS, Guba EG. Naturalistic inquiry. Beverly Hills, California: Sage; 985. [34] Morris PWG. Managing project interfaces key points for project success. In: Cleland DI, King WR, editors. management handbook. New York: Van Nostrand Reinhold company; 983. [35] Cleland DI, Ireland LR. management. Strategic design and implementation. London: McGraw-Hill; [36] Meredith JR, Mantel SJ. management a managerial approach. New York: Wiley; [37] Wollmann P. Multiprojektmanagement im Kontext der strategischen Planung. In: Hirzel M, Kühn F, Wollmann P, editors. Multiprojektmanagement Strategische und operative Steuerung von Projektportfolios. Frankfurt: Allgemeine Buch; p [38] Burghardt M. Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten. Erlangen: Publicis MCD; [39] Schulte-Zurhausen M. Organisation. München: Vahlen; 999. [40] Alter R. Integriertes Projektcontrolling. Gießen: Verlag der Ferberschen Universitätsbuchhandlung; 99. [4] Gareis R. Programme and project portfolio management: new competencies of project-oriented organizations. In: Presentation at the PMI symposium, Houston; [42] Obels M, Roeschlein R, Staiger M, von Schneyder W, Wagner R, Waschek G. Die neue Projektmanagement-Norm. Projektmanagement Aktuell 2006;7(2):4 4. [43] Angermeier G. Genormtes Datenmodell für Projektmanagement: Katalysator für eine projektorientierte Wirtschaft? Projekt Magazin 2005(6). [44] Matthes G. Unterlage zum 9. PLANTA-Anwenderforum, 7 9. Mai Karlsruhe: Planta; [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):