Knowledge Reuse in Configuration of Project Management Information Systems: A Change Management Case Study

Transcription

1 Knowledge Reuse in Configuration of Project Management Information Systems: A Change Management Case Study S. Bērziša and J. Grabis Riga Technical University, Faculty of Computer Science and Information Technology, Riga, Latvia berzisa@gmail.com, grabis@iti.rtu.lv Abstract Project management information system is one of main enablers of successful project management. The configuration of the project management information system should be adapted to needs and requirements of a particular project. However, project managers are not always aware of the most appropriate configuration. Adequate knowledge would help the project managers during definition of the configuration requirements. Therefore, an approach for the project management knowledge reuse during configuration of the project management information system is elaborated. This paper presents the case study of application of knowledge reuse in configuration of project change management module. The case study discusses both knowledge acquisition and knowledge utilization processes. I. INTRODUCTION Project management (PM) is knowledge-centric and experience-driven activity [1] supported by an appropriate project management information system (PMIS) [2]. Quality of PMIS affects PM and project success [3] as well as user acceptance and usage of PMIS [4]. Similarly as in the case of enterprise applications when best practices are used in systems configuration [5] [6], utilization of PM knowledge can greatly enhance quality of PMIS. Therefore, an approach for knowledge-based configuration of PMIS is developed in [7]. This approach uses principles of case-based reasoning (CBR) [8] and ensures collection and reuse of theoretical and empirical knowledge. CBR has found multiple applications in PM including project planning [1], [9], software development project effort estimation [10] and construction schedule generation and evaluation [11]. These applications focus on supporting execution of particular PM activities. This paper explores application of knowledge-based configuration and CBR to derive recommendations for setting-up the overall PM environment by configuring PMIS. This application can be perceived as application of CBR to derive best-practices for configuration of packaged software. CBR-based knowledge reuse is expected to assist selection of appropriate configuration of PMIS and to improve correspondence between PMIS s capabilities and PM requirements. A knowledge reuse case analyzed in this paper focuses on configuring the project change management (PCM) module of PMIS. Empirical data from real-life projects and data from several PM methodologies are used to derive PM and PCM knowledge. Paper is divided into five sections. Section 2 presents approach for the PM knowledge reuse. Knowledge acquisition and PMC knowledge content is summarized in Section 3. Section 4 describes case study of PCM configuration definition using accumulated knowledge. Conclusions and recommendations for future research are presented in Section 5. II. APPROACH FOR KNOWLEDGE REUSE The aim of knowledge reuse is to provide knowledge necessary for configuration of PMIS. It is assumed that PMIS is set-up for each new project. Configuration of PMIS is defined as either automated or manual setup of packaged software according to requirements of the particular project. The requirements are specified in a standardized manner as prescribed by XML schema for Configuration of Project Management information systems (XCPM) [12]. XCPM provides means for describing all data items, processes and knowledge areas relevant to the PM domain. The knowledge reuse process (Figure 1) is divided in two sub-processes: knowledge acquisition and knowledge utilization. Knowledge is classified as either theoretical (i.e., derived from PM methodologies) or empirical (i.e., derived from real-life projects). Each case (corresponding to either PM methodologies or real-life projects) is formally described using XCPM and is categorized according to a set of project characteristics (see Section III). The formalized and categorized cases are stored in the knowledge repository. A new case is initialized upon starting a new project. PMIS requirements are defined for the new project and the new case is categorized. Similar cases are searched in the repository by comparing their characteristics with those of the new case, and a list of similar cases is retrieved. Statistical analysis of the similar cases is performed, and a summary of results is displayed to a project manager. The project manager uses the summary and the requirements to prepare the configuration file in the format defined by XCPM. The configuration file is loaded into PMIS, and a fully functional PMIS is obtained. PMIS is configured taking into account previous experience and requirements of the current project. III. KNOWLEDGE ACQUISITION Both theoretical and empirical knowledge is stored in the PM knowledge repository. Theoretical knowledge is collected from standards, methodologies and best practices. This knowledge is

2 Figure 1. Knowledge acquisition and utilization process described once and stored. One case (H i ) is created for each methodology or standard. Empirical knowledge is collected from previously completed projects. Each case describes the configuration of PMIS used for a given project. The case description (C j ) is added to the knowledge repository after it is used in configuration of PMIS. In the case of the PCM configuration, main information elements are work items, attributes of work items and workflows describing status changes of the work items. Views, reports, templates and other information also could be included in the PCM configuration knowledge. A. Theoretical Change Management Knowledge Theoretical knowledge about PCM has been acquired from methodologies and best practices. It has been collected from general and software development specific PM methodologies. PMBOK [2] defines five types of work items related to PCM: actions, change requests, defect, preventive actions and corrective actions. Requests for change, off-specifications, questions, actions and work packages are used in PRINCE2 [13]. SCRUM [14] defines product backlog items, sprint backlog items and bugs. Change requests, issues and actions are defined in [15]. From the area of software development, MSF [16] and RUP [17] and best practices described in [18] have been considered. MSF for Agile Software Development (MSF-ASD) [19] uses bugs, scenarios and tasks for PCM. MSF for CMMI Process Improvement (MSF-CMMI) [20] uses bugs, change requests, issues, requirements and tasks. Business cases, change requests, software requirements, tasks and activities are defined in RUP. Best IT practice described in [18] also defines change requests, issues and tasks. A specific kind of theoretical knowledge is default configurations provided by PM software packages. These configurations could be related with methodology, but not always. Three methodology related process templates are included in Visual Studio Team Foundation Server (VSTFS): MSF-ASD, MSF-CMMI and Visual Studio SCRUM (VS-SCRUM). VS-SCRUM uses product backlog items, bugs, tasks and sprints for PCM [21]. MSF-ASD defines the following types of work items: user stories, tasks, bugs and issues [22]. MSF-CMMI defines the following types of work items for PCM: requirements, tasks, bugs, change requests and issues [23]. Project task management tool JIRA [24], which is geared towards agile software development, uses the following default types of work items: bug, improvement, new feature, task and custom issue. B. Empirical Change Management Knowledge Empirical knowledge about PCM is derived from configurations used in real-life projects. Information about 37 information technology projects in Latvia is collected in the knowledge repository. Statistics about categorization of the empirical projects is summarized in Table I. IV. CASE STUDY An outsourcing software development project for the governmental institution has been chosen as a case for analyzing PCM configuration. The project is carried out by a large IT company. JIRA [24] is used as a project task and change management tool. Historically, various tools for PMC have been used in the development company, but gradually JIRA is being implemented in all projects. The company s own JIRA configuration usually is used for new projects. Originally, this configuration was developed for the internal project using SCRUM [14] methodology. Project managers can prepare their own project configurations, but most of them choose the simplest option of using the default JIRA configuration and having project specific PCM to adapt to it. This option was also used by the project manager of the reviewed case. Description of the case PCM configuration is shown on left side of Figure 2. Five work items or ticket types are included in the default PCM JIRA configuration.

3 TABLE I. CHARACTERISTICS OF EMPIRICAL PROJECTS Characteristic Values and frequency (%) Project type: Outsourcing (49%) In-house (51%) Client: Government (41%) Private (51%) Commercial (8%) Project action: Development (49%) Improvement/maintenance (19%) Implementation (19%) Implementation/development (14%) Project product: Software (100%) Area: IT (100%) Complexity: Mono-discipline (86%) Multi-discipline (14%) Team size: <7 (76%) >=7 (24%) Budget (EUR): < (24%) (49%) (8%) (8%) > (11%) Duration: < 6 months (49%) 6 months year (35%) Year - 2 years (5%) > 2 years (11%) Project organization. structure: Project organization area: Management methodologies (one project can use more than one methodology): Project (65%) Matrix (27%) Functional (5%) Individual (3%) IT (68%) Government (11%) Other (21%) MSF (3%) PMBOK (3%) CMMI (8%) ITIL (11%) SCRUM (8%) ISO 9001:2008 (46%) RUP (3%) Other (11%) None (38%) PM life cycle: Waterfall (57%) Evolutionary (16%) Iterative (11%) Agile (11%) Spiral (3%) V-model (3%) Attributes (i.e., PMIS s data fields) of the work items and status workflows are identical for all work items. The objective of the case study is to use the knowledge repository to identify other alternative configurations of PMIS what could be better suited for the particular project judging by analogy with previously completed projects. PM knowledge reuse is organized in four phases as shown in the knowledge utilization lane in Figure 1. A new case is categorized according to the project characteristics in the first phase (Table II). Similar cases are searched according to equality between project characteristics although only a subset of characteristics is used to determine similarity (the subset is chosen by the project manager). In this case, the empirical cases are compared according to the following characteristics: action, product, methodology and PM life cycle. Similarity of the theoretical cases is evaluated only according to methodology and PM life cycle. Given that the methodology characteristic is not defined for the new case (Table II), this characteristic is ignored in search for similar cases. The search for similar cases results in ten similar empirical cases and eight relevant theoretical cases: PMBOK, PRINCE2, MSF-CMMI, RUP, the best practices [15] and [18], VSTFS MSF-CMMI and JIRA default configuration. In the third phase, the retrieved similar cases are analyzed and PMIS configuration suggestions for the project manager are generated. These suggestions are presented in three steps: 1) types of PCM work items types are established; 2) attributes for each type of work items are defined; and 3) a workflow for each type of work items is defined. A. Types of Work Item Types of work items have been identified from eighteen similar cases, and they observation frequency is calculated. As the result, the project manager gets information shown in Table III. The most frequently observed types of work items are change request (83%), task (67%), issue (56%) and bug (33%). These four types are included in the proposed PCM configuration. Change requests and issues are registered by the client, but tasks and bugs are used by the project team Project type: Client: TABLE II. CHARACTERISTICS OF THE NEW CASE Project action: Characteristic Project product: Area: Complexity: Value Outsourcing Government Development Software IT Multi-discipline Team size: >=7 Project budget: > Duration: Project organization structure: Organization work area: Year - 2 years Project Methodologies: - PM life cycle: TABLE III. LIST OF TYPES OF WORK ITEMS IT Waterfall Work item type Frequency (%) Change request 83% Task 67% Issue 56% Bug 33% Action 17% Question 17% New feature 17% Requirement 11% Improvement 11% Defect 6% Preventive action 6% Corrective action 6% Off-specification 6% Work package 6% Activity 6% Business Case 6% Software requirement 6%

4 B. Attributes of Work Items Attributes or data fields should be defined for each of the selected types of work items. For the each work item the list of attributes is created by analyzing the attributes of work items in descriptions of the similar cases. In this case study change request is described in 15 cases, task - 12, issue - 10 and bug 6. The result of analysis is shown in Table IV. This table shows only attributes whose observation frequency is larger than 20% for at least one type of work items. The project manager gets this information separately for each type of work items as he/she specifies the configuration of PMIS. Attributes with different names might have identical semantic meaning. For example, a person submitting the TABLE IV. ATTRIBUTES OF WORK ITEMS Frequency (%) Change Issue Task Bug Attributes request Key/id 100% 100% 100% 100% Summary/Title 87% % 100% Type 0% 40% 100% 50% Status/State/Err status 100% 100% 100% 100% Priority 100% 100% 100% 100% Resolution 67% 100% 100% 50% Affects Version(s)/ 47% 50% 75% 67% Found in Fix Version(s)/ 67% 80% 100% 83% Iteration Component(s)/Area/ 60% 70% 92% 100% System/Block Labels(s)/Keywords 33% 30% 58% 50% Environment 33% 30% 58% 50% Description 100% 100% 100% 100% Assignee/Assigned 73% 100% 100% 100% to/addressed Reporter/Created 100% 100% 100% 100% by/author/initiator Due date 47% 60% 75% 50% Created/ Created date 100% 100% 100% 100% Updated/Change date 100% 80% 100% 83% Resolved/Resolved 53% 60% 83% 83% date Estimate 73% 50% 100% 67% Remaining 60% 30% 83% 67% Logged/Completed 47% 40% 62% 67% Comment 47% 40% 67% 67% Fix in build/ Fix/ 0% 0% 8% 50% Build(fix) Security level 7% 10% 33% 67% History 27% 40% 33% 100% Closed date 20% 40% 25% 50% Attachment 47% 70% 92% 100% Links 27% 40% 33% 83% Triangle 20% 30% 25% 19% Blocked 20% 0% 25% 19% Changed by 20% 30% 25% 19% Close by 20% 30% 25% 19% Escape 0% 30% 0% 0% Resolved by 20% 30% 8% 19% Impact assessment 33% 20% 0% 0% change request could be called as reporter, created by, author, initiator and so on. The synonym dictionary is used to identify semantically equal attributes. This dictionary allows users to list name with equal meanings and to use this list in summarizing attribute of the work item. The resulting lists of attributes are similar for all four types of work items with some minor deviations. For example, the impact assessment is only used in the change request. C. Workflows Workflows are also defined for each type of work items, but workflow comparison is not as simple as comparison of attributes because processes can be describe in different ways. However, in the PCM case, it is possible to analyze the statuses and transactions changing status value just like the attributes. Results of the workflow statuses analysis are shown in Table V. Different lists of the workflow statuses are used TABLE V. LIST OF WORKFLOW STATUSES Frequency (%) Change Issue Task Bug Workflow statuses request Active 20% 30% 25% 33% Agreed 27% 10% 8% 17% Approved 40% 20% 0% 0% Assigned 20% 20% 8% 0% Canceled 0% 0% 25% 33% Clarification 20% 20% 8% 17% Client testing 20% 0% 25% 17% Client testing done 20% 0% 25% 17% Closed 100% 100% 100% 100% Code review 0% 0% 8% 17% Delivered 20% 0% 25% 17% Deployment 20% 20% 17% 0% Duplicated 7% 0% 0% 0% Evolution 7% 10% 0% 0% Feedback 7% 10% 8% 0% In progress 13% 30% 42% 50% New 7% 10% 17% 0% On hold 27% 0% 25% 17% Open 47% 50% 33% 50% Production 20% 0% 25% 17% Proposed 20% 30% 25% 33% Ready for review 0% 0% 8% 17% Ready for testing 27% 10% 42% 33% Realize 47% 30% 33% 17% Registered 20% 0% 0% 17% Rejected 13% 10% 8% 0% Reopened 13% 30% 33% 33% Resolved 47% 60% 58% 83% Submitted 7% 0% 0% 17% Test failed 7% 0% 0% 0% Tested 27% 10% 33% 17% Testing 40% 30% 50% 50% Unassigned 7% 10% 8% 0% Verification 20% 0% 0% 0%

5 for the each type of work items, but all include the following statuses: open, testing, resolved and closed. Like with the list of attributes of work items, this information is shown separately about each type of work items when the project manager describes the workflow of a particular work item. Including only statuses with observation frequency more than 20%, the workflow for change request includes the following statuses: agreed, approved, closed, on hold, open, ready for testing, realize, resolved, tested and testing. If multiple similar statuses are suggested for inclusion in the workflow (e.g., agreed and approved ), the project manger needs to choose only one of these similar statuses. When workflow statuses have been chosen then information about the transactions between these statuses is collected in a similar manner. D. Proposed Configuration of PMIS The proposed knowledge based configuration of PMIS is created including all elements with observation frequency larger than 20%. The types of work items and the corresponding workflows are shown in Figure 2 and the attributes of work items are listed in Table IV. Comparison of the initial configuration with the proposed configuration shows that only two work items have been kept task and bug. Also two new types of work items have been added change request and issue. Most of the attributes of work items have not been changed. Majority of differences occur in compassion of workflows. A separate workflow has been established for each type of work items, and all four workflows obtained differ from the original workflow. The proposed configuration of PMIS is more suitable Figure 2. PCM configurations

6 for the reviewed waterfall project than the original configuration, because it has been created using knowledge from the waterfall project cases. It could be considered as a draft configuration, which is refined by the project manager according to project requirements and needs before actually loading it into PMIS. V. CONCLUSIONS This paper presents application of PM knowledge during configuration of PMIS. This approach includes the knowledge acquisition and utilization processes. The case of configuring PCM module of PMIS is used to demonstrate application of the approach. The result of the PCM case analysis is the configuration of PMIS that includes four types of work items, their attributes and also different workflows for the each type of work items. This configuration has been created by including all suggestions with observation frequency more than 20%. The final configuration to be loaded into PMIS is manually refined by the project manager who can choose to accept or reject these suggestions as well as to add additional information. This way knowledge about previously completed projects and PM methodologies complements needs and requirements of a particular project to develop an appropriate configuration of PMIS. Two problems of knowledge reuse have been identified in the case study. The first problem is that different names are used for semantically equivalent work items, attributes or statuses. Without analyzing and merging of these synonym names, the result of statistical analysis would be incorrect. The synonym dictionary is used as a solution of this problem. The second problem is related to analyzing workflow data. The description of PM workflows is not standardized and therefore simple comparison and analysis of their data is impossible. In the PCM case, the workflows are defined using only statuses and transactions, and, therefore, frequency data can be used. However, this approach would not yield sufficient result in case of sequential workflows. Identification of workflow similarity is one of the main topics for future research. Evaluation of efficiency of configurations obtained as the result of knowledge reuse is another important issue to be addressed. ACKNOWLEDGMENT This work has been supported by the European Social Fund within the project Support for the implementation of doctoral studies at Riga Technical University. REFERENCES [1] H.-L. Yang and C.-S. Wang, Recommender system for software project planning one application of revised CBR algorithm, Expert Systems with Applications, vol. 36, pp July [2] Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition, Project Management Institute, [3] L. Raymond and F. Bergeron, Project management information systems: An empirical study of their impact on project managers and project success, International Journal of Project Management, vol. 26, pp , February [4] A.S.B. Ali, F.T. Anbari, and W.H. Money, Impact of organizational and project factors on acceptance and usage of project management software and perceived project success Project Management Journal, vol. 39, pp. 5 33, June [5] Y. Li, X.W. Liao, and H.Z. Lei, A knowledge management system for ERP implementation, Systems Research and Behavioral Science, vol. 168, pp , March [6] R. Vandaie, The role of organizational knowledge management in successful ERP implementation projects, Knowledge-Based Systems, vol. 21, pp , December [7] S. Bērziša and J. Grabis, A framework for knowledge-based configuration of project management information systems,, Information Technologies Proceedings of the International Conference on Information and Software Technologies, R. Butleris and R. Butkiene, eds., Kaunas: Kaunas University of Technology, 2011, pp [8] A. Aamodt and E. Plaza, Case-based reasoning: Foundational issues, methodological variations, and system approaches, AI communications, vol. 7, pp , March [9] J. Lee and N. Lee, Least modification principle for case-based reasoning: a software project planning experience, Expert Systems with Applications, vol. 30, pp , Febuary [10] R.J. Aarts, A CBR architecture for project knowledge management, Advences in Case-Based Reasoning, Smyth, P, eds., 1998, pp [11] E. Mikulakova, M. Konig, E. Tauscher, and K. Beucke, Knowledge-based schedule generation and evaluation, Advanced Engineering Informatics, vol. 24, pp , November [12] S. Bērziša, XML-based Specification of the Project Management Domain and Its Application, Databases and Information Systems VI. Volume 224 Frontiers in Artificial Intelligence and Applications, J. Barzdins and M. Kirikova, eds., Amsterdam: IOS Press, 2011, pp [13] B. Hedeman, G.V.V. Heemst, and H. Fredriksz, Project Management Based on PRINCE2 (Best Practice), Van Haren Publishing, [14] K. Schwaber, Agile Project Management with Scrum, Microsoft Press, [15] J. Charvat, Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects, Wiley, 2003 [16] M.S.V. Turner, Microsoft Solutions Framework Essentials: Building Successful Technology Solutions, Microsoft Press, [17] R.D. Gibbs, Project Management with the IBM(R) Rational Unified Process(R): Lessons From The Trenches, IBM Press, [18] K. Bainey, Integrated It Project Management: A Model-Centric Approach, Artech House Publishers, [19] Microsoft, MSF for Agile Software Development Process Guidance F3EA426-C2B BA0F-35A021D85234&displaylang=en, [20] Microsoft, MSF for CMMI Process Improvement, 0B578F1-B7A4-459F-A783-04BC82CB2359, [21] MSDN, Visual studio SCRUM [22] MSDN, MSF for Agile Software Development [23] MSDN, MSF for CMMI Process Improvement, [24] Atlassian,