Martin Smit 1 and Ingrid Pistorius 2. Abstract

Transcription

1 WORKING TOWARDS THE VISION OF "THE BEST SAP PLANT MAINTENANCE IMPLEMENTATION IN SOUTH AFRICA EVER" AND ACHIEVING SUCCESS THROUGH STAKEHOLDER PARTICIPATION AND BUY IN. Martin Smit 1 and Ingrid Pistorius 2 1 Eskom Generation, 2 Accenture Abstract Many IT implementations are unsuccessful in that projects are terminated before completion or they are completed late and exceeds the budget by far. In many instances the users are not satisfied with the system or they are not effectively using the system to its fullest potential. In very few instances are any real benefits measured and realised. Eskom Generation is in the process of implementing SAP R/3 Plant Maintenance (PM) version 3.1H at 10 power stations. The objective of this presentation will be to share the project management approach being followed and the lessons learnt to ensure successful implementation. The paper is a case study of a real-world implementation and the authors will present an objective account of the project with specific focus on the PMBOK knowledge areas (i.e. integration, scope, time, cost, quality/performance, human resources, communications, procurement, and risk management). 1 INTRODUCTION Effective plant maintenance is critical to the Eskom Vision of lowest cost electricity in the world and the Generation objective of world class technical performance (90:7:3). To achieve this vision and objective it is essential to have a world class Plant Maintenance (PM) system with embedded best practices. You also need an empowered workforce utilising the system to its fullest potential to maintain the Generation plant assets (book value of R24.044bn and annual maintenance cost of R1.642 for 2000). The current Plant Maintenance system Permac is at the end of its development life cycle and does not serve the needs of the power stations. Permac does not have the functionality of world class PM systems and is not integrated with the plant, financial and other systems. A detailed business case was compiled investigating the cost and associated benefits for different software products and implementation options for an integrated plant maintenance system. Approval was obtained from the Generation Executive Committee to install SAP PM at 10 power stations (9 fossil and 1 nuclear). 2 PROJECT OVERVIEW The project has been divided into three separate projects: 2.1 A detailed business case and approval project The business case and approval project started on 26 July 1999 and was completed on 25 August 2000 when contracts were signed with the successful implementation partners and software vendor. The objective of this part of the project was to make a recommendation considering 4 options: Paper presented at African Rhythm Project Management Conference April 2002, Johannesburg, South Africa Hosted by: Project Management Institute of South Africa (PMISA): ISBN Number:

2 Plant maintenance functionality integrated with the financial and commercial systems (i.e. SAP); Plant maintenance functionality integrated with the plant configuration management system (i.e. PiGo); Plant maintenance functionality using a best of breed system (i.e. Maximo); or Do nothing, keep the status quo (i.e. Permac and PiGo). The second part of the project objective was to obtain buy-in from all the relevant stakeholder forums, to obtain approval form the relevant management bodies, to obtain approval for the capital expenditure and to negotiate contracts with the recommended software and hardware vendors as well as the implementation partners. 2.2 Implementation project The project for the Implementation of the SAP PM system started on 04 September 2000 and is planned for completion in August The objective of this part of the project is to implement the SAP PM system at 10 power stations in the Generation Group (approximately 2500 users). Figure 1 shows the implementation phases of the project S ept ept Oct Nov Dec Jan Jan Feb Feb Mar Apr May Jun Jun Jul Jul Aug Aug S ept ept Oct Nov Dec Jan Jan Feb Feb Mar Apr May Jun Jun Jul Jul Aug Aug DESIGN PH A S E DELIVERY PH A S E PILO T : Tutuka GRO UP 1 D uvha, Lethabo, Matimba GRO UP 2 Hendrina, M ajuba, K end al GRO UP 3 Kriel, M atla KO EBERG Figure 1. Implementation phases of the project 2.3 Benefits realisation project This project is planned to start on 01 June 2002 with a planned finish date of 31 December The objective is to attain the maximum return on the SAP PM investment by facilitating actions across all 10 power stations in order to realise the benefits following the implementation of the SAP PM system in the Generation Group. 3 APPLICATION OF PMBOK KNOWLEDGE AREAS 3.1 Project Integration Management Project plan development One project plan was developed for the business case. For the implementation project, project plans are developed prior to the start of each of the phases. The Accenture Business Integration Methodology and historical information from other, similar Accenture system implementation projects are used as a basis to develop the integrated project plan. During all project phases, the

3 interaction and dependency between the different teams on the project are two important factors to keep in mind to make the plan work effectively for everyone. Another challenging factor during project plan development is the fact that there are many organisations involved in the project each with their own methodologies and thinking. However, the project plan is not developed in isolation. Input from all organisations is sought throughout the planning process. Reports from MS Project are used to guide the project execution and project control. The Theory of Constraints (TOC) buffer management methodology is used where non-critical paths are protected by feeding buffers, and the critical path is protected by the project buffer Project plan execution The project plan is actively managed throughout all the project phases. Each team leader has the responsibility to update his/her part of the plan on a weekly basis, based on the team s progress for the week. The overall project progress is then summarised in an Excel-based graph, which indicates the project buffer penetration (TOC model), as well as the overall project and team progress. This is discussed in a weekly progress meeting, attended by all team leaders Overall change control The initial project plans for each project and each phase are approved by the Project Manager and saved as a baseline against which changes can be controlled. The project plans are updated weekly to indicate the progress. New changes are incorporated into a revised project baseline once the change requests are approved. 3.2 Project Scope Management Initiation The need for the project was initiated from within the business, not from Information Management. The Power Station Managers Forum who realised the need for replacing the plant maintenance system initiated the project. A Maintenance Manager with project management experience from one of the power stations was seconded to lead the project Scope planning A project scope statement was developed for each of the three projects and covered the following elements: Project statement of work with reference to the detailed specifications; Project objectives in terms of time, cost and performance; Key performance areas and quality criteria for each of the PMBOK knowledge areas; and Management plan that includes the project organisation, accountabilities, master plan and implementation methodology/approach. The scope statements were supported by the Steering Committee and authorised by the Project Sponsor Scope definition As scope definition is critical to project success. Detailed specifications were compiled during the business case for the following: Specification for Software Implementation; Specification for Software; and Specification for Hardware.

4 3.2.4 Scope verification The specifications were reviewed by some of the Power Station Managers, the Steering Committee and the Generation Tender Committee, the purpose being to ensure a detailed and accurate project scope accepted by the business that will result in few scope changes Scope change control It was decided to implement SAP PM Vanilla to keep the scope changes to a minimum. The only scope changes that were allowed was to ensure that the system works effectively to cater for specific business needs e.g. nuclear and cold reserve power stations. A detailed position paper is compiled for each scope change and is approved by the Steering Committee to ensure that the changes are beneficial. 3.3 Project Time Management Activity definition The Accenture Business Integration Methodology, project scope statement and historical information from similar Accenture projects are the main inputs for the activity definition. These activities are depicted in the overall project plan and performed to produce the various project deliverables Activity sequencing Based on the Accenture Business Integration Methodology, historical information and work experience, the dependencies between the different project activities are determined, and entered in Microsoft Project (the tool used for the project plan) Activity duration estimation Activity duration estimates are based on historical information, resource availability and resource capabilities, as well as expert judgement that is obtained from various stakeholders Schedule development MS Project is used to assist with the schedule development and resource levelling. Theory of Constraints (TOC) was adapted after assistance from the Goldratt Institute to assist with the compilation of the initial project schedules for the design and development phases of the implementation project Schedule control Few changes are made to the schedule activities, duration estimates and sequences other than adding new activities due to new scope changes. No schedule change control procedures are used other than the overall project plan revisions. 3.4 Project Cost Management Resource planning The Accenture Business Integration Methodology, historical information, the project scope statement and the resource pool available are the major inputs for determining what resources (people, equipment, etc) and what quantities of each are to be used to execute the project activities. The resource planning is not done in isolation by the management team. Being a relatively small project team, it is easy to obtain constant input from the team members regarding their preferences and career aspirations. This ensures that the team members are motivated and they accept the overall project plan.

5 3.4.2 Cost estimating Cost estimating involved developing an approximation of the costs of the resources needed to complete the project activities after consideration was given to various costing alternatives. Cost estimates were compiled from information obtained from the potential software and hardware vendors and implementation partners Cost budgeting The cost baseline was derived from the cost estimates and included the following: External cost (including escalation) for contracts to procure software licences, buy/hire hardware and implementation partner resources; Internal cost (including escalation) for own resources and general project expenses; Cost of cover and IDC (interest during construction); and Project contingency of 4%. Execution Release Approval (ERA) for the project was obtained for the final cost baseline from the Eskom Capital Investment Committee Cost control The cost baseline is changed following approval of the scope and cost changes by the project Steering Committee. The total cost for scope changes are monitored against the project contingency. It was decided to have a formal cost management plan. Cost is monitored during the weekly progress meetings by comparing the estimate at completion with the budget (ERA value). See figure Project Quality Management Quality planning The Quality Plan is the major output of this activity. The Quality Plan aims to ensure that the defined quality objectives are met and stakeholders and sponsors expectations are fulfilled or even exceeded Quality assurance Various processes and tools are used to evaluate the overall project performance on a regular basis to ensure that the project would satisfy the quality standards. One of these is the Client Quality Management Assessment (CQMA). An Accenture on a regular basis does this assessment. The objective of such an assessment is to monitor the overall satisfaction of the various stakeholders of the project as well as to monitor the overall quality processes and suggesting improvements. Eskom Corporate Audit is closely involved with the project. They review project deliverables, monitor solution testing (including user tests) and are present during the final conversion of data into the live system. The system testing process is used to ensure that the solution fulfils the requirements of all stakeholders. It includes different tests for each Power Station, namely unit testing, string testing, system testing, user acceptance testing and dress rehearsal testing. Each of these tests is conducted by different stakeholders, which include project team members and end users Quality control The weekly progress meeting is used as the forum to manage the Quality Plan. During this meeting, the list of project deliverables is reviewed and sign-off dates are recorded.

6 Project management team members, team leaders, site representatives and end users sign off the project deliverables. This records the satisfaction and approval of the various stakeholders with the solution and the overall project. Each project phase is concluded with a Phase Closeout Report. This report is a summary of all the activities and deliverables (with references) that are executed and completed during that phase. The Steering Committee approves and signs-off this report which formally concludes each project phase. 3.6 Project Human Resource Management Organisational planning Journey and Change Mgt Quality Assurance Steering Committee Project Management FSC Project Administration Support Systems Integration Data Preparation Solution Prep Human Performance & Site Preparation Solution Support Software Factory Data Purification Solution Confirmation Site Readiness Training Material Update & Support User Profiles Environment Management (incl Project infrastructure) Production Architecture & Infrastructure Conversion Testing Configuration Solution Testing Training Coordination Figure 2. Project Team Organisation Figure 2 illustrates the project team organisation and reporting relationships. The project team consists of 5 teams, namely the project management team, the systems integration team, the data preparation team, the solution preparation team and the human performance & site preparation team. The Steering Committee plays an overseeing role. They provide overall leadership, guidance and approval of the project. During monthly Steering Committee meetings, the project management team gives status feedback, highlights issues and risks and obtains their input and approval as and when necessary. During rollout/implementation phases, the project team is split in two, due to the fact that some team members have to be at the Power Station sites. The one major challenge that the team is faced with then, is to maintain good communication channels between the central and site based teams. Figure 3 below illustrates the team organisation during Rollout phases:

7 Change Mgmt Data Purif & Conversion Project Mgmt Solution Preparation Interfaces Solution/ Integration FSC Central Change Mgmt Rollout Mgmt Site PS 1 PS 2 PS 3 Roles & Profiles Training Training Logistics Technical Environm Dress Rehearsal Outages Figure 3. Project team organisation during rollout phases Staff acquisition Each organisation involved in the project has its own policies & procedures with regards to staff acquisition. The project team organisation plan (figure 3 above), staffing pool description and recruitment policies are the major inputs to this process. Eskom resources are seconded to the project Team development This is the activity of developing individual and group skills to enhance the overall project performance. In the beginning of the project the team formulated the project vision of being the best SAP PM implementation in South Africa ever. The vision serves as a psychological contract between the organisation, the team members and the project manager. The project vision is constantly communicated to all stakeholders in various forums. The team also attended detailed SAP PM training to help them understand the system that they are working with. Successes are celebrated after key milestones have been achieved, e.g. through activities such as team sport events, social dinners, etc. Much attention is also given to do regular knowledge transfer sessions. This entails that an expert in a subject/area spends time to transfer his/her knowledge to other team members. Individual growth and motivation is a natural result of this effort. Performance contracts are negotiated with each team member to include project objectives as well as individual performance objectives. Team members are provided with regular performance feedback. This leads to clear performance improvements. 3.7 Project Communications Management Communications planning The main objective of communication is to give the right information to the right people, at the right time, in the right format. There are also other reasons for communicating with the project stakeholders (i.e. users, Steering Committee members, Power Station Representatives, etc.). The objectives of communication are to:

8 Ensure consistent messages across all stakeholder groups; Inform, involve and educate all stakeholders whose commitment is required, on the changing maintenance processes and technology (SAP); Address concerns and fears of the people impacted by the SAP PM implementation, thereby beginning and sustaining the acceptance process by promoting buy-in from stakeholders; Ensure that all stakeholder groups know how and when they will be affected by the implementation of the SAP PM; and Create realistic expectations through open and honest communication. All of these objectives are taken into account when the project communication plan is developed for each phase. The communication plan is a matrix that indicates exactly which message is sent to which audience group, when and which communication channel is used. The matrix is a living document that is updated regularly, due to the fact that additional communication needs may arise during the project/phase, audience groups may change, etc Information distribution The cascading model below is the basis of how project information is made available to the various stakeholders: F e e d b a c k M2K+ Communications Coordinators PSMs, PSRs & PS Communication Practitioners Project Champions S p o n s o r s h i p O w n e r s h i p Project Sponsors This body empowers the M2K+ project team to implement SAP PM; They also follow the implementation process & intervenes if necessary All M2K+ End Users Figure 4. Cascading model of communication Figure 4 illustrates the general flow of messages to the stakeholders. Each stakeholder group is responsible to ensure that messages are communicated to the stakeholders on the level below. Power Station Representatives (PSR s) were identified and formally appointed at each Power Station to ensure that the power stations actively participate in the SAP PM system implementation. These individuals co-ordinate all the actions for their power stations to ensure that the requirements of their station are met. They are also responsible for the data purification effort at their power station. All project communication is directed to the PSR. He/she is then responsible to disseminate the information to the right individuals on site. The project sponsors are the Steering Committee members and functional owners. This body empowers the project team to implement SAP PM. They follow the implementation process closely and intervene when necessary.

9 The feedback loops are an essential part of the model. Each stakeholder group is responsible to communicate any feedback (e.g. questions, issues, etc.) to the level above, or directly to the project communication co-ordinators. The feedback is tracked in order to customised future messages Performance reporting The project team leaders compile a weekly status report. These status reports and the project Key Performance Indicators (KPI s) are reviewed at the weekly progress meeting. The Project Manager compiles a bi-weekly status feedback report to the Project Sponsor on all aspects as per the project knowledge areas. See figures 5, 6 and 7 for examples of the key performance Indicators (KPI s). On a monthly basis a performance report presentation is made to the Steering Committee. Group 2 Roll Out Phase Contractual go-live finish date: 2002/03/31 Planned go-live finish date: 2002/03/25 Expected go-live finish date: 2002/03/25 Planned support finish date: 2001/04/25 Project buffer: 4 days Project buffer consumption: 0 days Figure 5. KPI for time management Data Purification Group 3 Target as at 04 Mar 02: 90% (Completion target date is 15 Apr 02) Progress (measured Matla: 86.75% based on data loaded into Kriel: 90.02% the purification tool) Koeberg: 91.19% Figure 6. Data purification progress ACTUAL TO DATE BUDGET (ERA ESTIMATE IN RAND VALUE) IN RAND COMPLETION RAND Accenture Arivia.kom FSC Generation Expenses Infrastructure Hardware Software IDC TOTAL Figure 7. Total project cost as at 08 Mar 02 (escalation and scope changes included) AT IN Administrative closure On completion of each of the projects/phases the documentation for each deliverable is signed-off and filed. A sign-off document for each project/phase with reference to the key documents is compiled and signed off by the Steering Committee. After sign-off by the Steering Committee the project file with documentation is presented to Corporate Audit for review. 3.8 Project Risk Management Risk management planning It was decided to follow a team based risk assessment process. Although the initial process to identify, assess, quantify and compile a response plan for the risks takes some time, it is simple and very effective Risk identification For each of the project deliverables the question is asked what can go wrong. Team members then brainstorm the possible risks than can impact each deliverable.

10 3.8.3 Risk assessment In order to understand each risk the reason for each risk is identified and documented Risk quantification The impact and probability of each risk on scales of 1 to 10 is established (1-3 is low, 4-7 is medium and 8-10 is high). A risk rating is then calculated by multiplying the impact of the risk by the probability Risk response planning Countermeasures for all risks with an unacceptable risk rating as established by the project sponsor are mitigated. In the case of the SAP PM project it was all the risks with a risk rating > Risk monitoring and control The risks, reasons for the risks, impacts, probability, risk ratings and countermeasures are documented in a risk response plan spreadsheet. Bi-weekly risk control meetings are held to identify and review the risks as well as monitor the execution of countermeasures for the risks with a risk rating > 40. See figure 8 for an example of the risk response plan. Risks Impact Probability Reasons for Risks Countermeasures Risk Rating Comments Data not converted in time 8 7 Limited time for conversions to production due to halfyear month end and volume of Koeberg data. Koeberg users not trained 7 7 Koeberg will be busy with an outage during user training. High number of users to be trained. Figure 8. Example of risk response plan Detailed planning to 56 complete work in time available. Meeting held with Koeberg to discuss impacts. Start training earlier and train critical mass. 49 Many users will be trained after the outage. In order to ensure that risks are not overseen a standing agenda item has been added to the two weekly management meetings and weekly project progress meeting to identify any new risks. 3.9 Project Procurement Management Procurement planning A specialist in the disciplines of contract and procurement was involved early during the business case. Approval was also obtained from the relevant procurement and tender committees regarding the procurement strategy before starting with the procurement process. It was also decided to go out on tender and to compile the business case from the tender information received. The NEC Professional Services Contract was used for the procurement of implementation partner services with different main options to be negotiated during each phase of the project e.g. target or termed contracts Solicitation planning Due to the complexity of the decision a decision model was developed to facilitate commitment to the decision in the selection of the software and the implementation partner. The decision model in Figure 11 was agreed with the Steering Committee and Power Station Managers.

11 EVALUATION CRITERIA WEIGHT Software (SW): Evaluation workshop 15% SW vendor profile 8% Implementation partner profile 17% Cost/benefit (NPV) 35% Strategic: Non quantifiable benefits 5% Eskom future direction 5% IT support 5% SMME/BEE policy: SW vendor 2% Implementation partner 8% TOTAL 100% Figure 11. Decision model Evaluation criteria were developed to rate and score the proposals Solicitation The software vendors submitted the names of accredited implementation partners for their products. An enquiry was issued to all potential software and implementation partners during a site meeting where the scope, specifications, contract documents and conditions, etc. were discussed. Proposals were submitted at the time of tender closing Source selection Representatives from each power station participated in the evaluations of the software functionality. The evaluation of the competency and company information of the implementation partner and software vendors was more subjective and was rated by Senior Managers as identified by the Steering Committee. Following the evaluations the decision model was populated and a score calculated. Internal and external auditors verified the results of the evaluations. Following the approval of the business case contracts were negotiated with the successful software vendor and implementation partners Contract administration During the start of the implementation project all the project team members underwent training on the NEC contracts. This afforded all to understand the rules of the game and has reaped a lot of benefits, as there are few contract issues Contract close out Contract close out will follow after the completion of the implementation project. 4 KEY LESSONS LEARNT AND CONCLUSIONS 4.1 Project Integration Management The application of the PMBOK principles work, also for very complex IT projects; Facilitation skills is an essential part of the project managers toolkit; During the start of the implementation project the project team attended a two-day project management course The TOC Way. A key lessons is: It is not important to complete each task in time, it is essential to complete the project in time.

12 4.2 Project Scope Management Need came from the business who initiated the project which implies that there was business commitment The scope statement is the foundation and guide of all project activities/happenings. It is therefor critical that it is supported by the Steering Committee and authorised by the Project Sponsor. Involve all the stakeholders during the initial scope definition and verification. It is the first step to obtain buy in for the new system. 4.3 Project Time Management The TOC principle is applied. Buffer consumption is used to monitor and evaluate project progress. 4.4 Project Quality Management A Client Quality Management Assessment (CQMA) process added value to the project by having an experienced external person broadening the visions, challenging thinking and providing creative ideas and guidance for resolving complex project problems, as well as to ensure that there are no key issues and risks overlooked. 4.5 Project Human Resource Management A project team vision (created by the project team) serves as a psychological commitment and motivates the project team to achieve success. Correct project KPI s ensure project success: It is the primary method of accounting for the results of actions being taken within the project; It is the primary source of feedback to the project sponsors and project team members alike; It has a huge influence on the actions that project team members choose to take since they do more of what has a positive impact on their measurements; Empowerment (alignment between responsibility and authority) of the project manager, team leaders and members is a necessary condition for an effective project organisation: Apply simple, effective techniques to remove obstacles preventing empowerment; Communication, i.e. give clear instructions; and Team work (synergy). 4.6 Project Communications Management Communication is directly proportional to project success, the more successful your communication is the more successful your project will be; Build stakeholders buy-in and commitment by involving them in the activities of the project that will impact them, e.g. process design, solution testing and training delivery; Involve site change management specialists and give them the responsibility to execute site interventions, as they are familiar with the site culture and the users typical reactions to change and are able to customise interventions to assist users to go through all phases of transformation; and Ensure integration between communication and change management efforts. 4.7 Project Risk Management The project team members that participate in the process enjoy the team based risk assessment approach. The identification, assessment, quantification and response planning has been entrenched in the thinking of the project team members when looking at risks.

13 4.8 Project Procurement Management Obtain approval for the procurement strategy before starting with the procurement process Seek the support from specialists in the disciplines of contract and procurement and involve them early in the process as a member of the project team. Involve all the sites with the evaluation of the software functionality. It is the commitment to the decision that counts. References 1. A Guide to the project management Body of Knowledge Edition. Exposure Draft. 2. William R Duncan. Scoping out a Scope Statement. PM Network December Peg Thomas. Creating a Shared Vision with a Project Team. PM Network January Martin Smith Martin Smit is a Project Manager and is working for Eskom Generation. He has National Diplomas in Civil and Mechanical Engineering and Datametrics. He also has a Mechanical Engineers Certificate of Competency. He has been a PMP since 1992 and also is a Professional Technologist (Engineering). He is a member of a number of Institutes and has been a Member of the Project Management Institute (USA) since He held various management positions in construction, project and maintenance management.