Implementing Project Management Processes for ERP Systems Mark Roman Ontario University Computing Conference May 17, 2004

Background June 2002 Banner implementation at Carleton was facing challenges Primarily project management issues Audit Internal External Strong technical and functional team members Subject matter expertise Strong will to succeed Care about the institution

User Scale Student: 450 administrative users and faculty advisors 23,500 web users Finance: 50 core users 200 budget system users 1,000 web reporting users Alumni 30 users Human resources 25 users Overall: 555 core users 23,500 external web users 1,000 internal web users

Data Scale Student Approximately 15 million records 370,000 students Alumni 90,000 alumni Finance 1.4 million transactions 25,000 cheques per year HR 4,000 employee payroll processed semi-monthly

Observations Success necessary because Cannot afford costs of unsuccessful or ineffective implementation ERP system needed to enable better management & control Current technology architecture no longer supported

Project Management Processes Installed Implemented from July 2002

New Project Management Processes Cost Management Transition Planning Reporting Strategy Dedicated Resource Program Technology Readiness Assessment Integrated Project Schedule Data Access Protocol New Project Management Process Changed Organization Structure New Communication Strategy Go Live Planning Re-Vamped Steering Committee Project Status Reporting Vendor Relationships Banner Information Center Weekly Management Review Risk Management Process Production Systems Review Culture Shift

Cost Management Financial review No prior expense review Reviewed all actuals to determine real project cost Restructured budget into meaningful, functional accounts Made budget easy to read/understand Built summary report of all actuals By cost types: total per vendor, salaries, consulting, etc. By sub-modules: Student, Finance, HR, Alumni, Infrastructure Developed forecast Completed to end of project Built operational budget for post go-live Regular reporting Report monthly on actuals against budget and forecast Review financial data monthly to identify variances and act if necessary

Integrated Project Schedule Changes Schedule (Gantt chart) developed for each module (Student, Finance, HR, Alumni, Enterprise) All modules put into an integrated plan Schedule review sessions with project manager for each module to update progress and date changes every 2 weeks Not interested in tracking history Results Critical path issues identified Resource allocation problems determined Radar screen for potential problems Translates into a PowerPoint Gantt chart for presentation to steering committee

Sample Steering Committee Summary Feb. 24 Jun’02 Jul’02 Aug’02 Sep’02 Oct’02 Nov’02 Dec’02 Jan’03 Feb’03 Mar’03 Apr’03 May’03 Jun’03 Jul’03 Aug’03 Sep’03 Oct’03 Nov’03 Dec’03 Student HR Alumni Finance Enterprise

Sample Steering Committee Student Detail Feb. 24 Jun’02 Jul’02 Aug’02 Sep’02 Oct’02 Nov’02 Dec’02 Jan’03 Feb’03 Mar’03 Apr’03 May’03 Jun’03 Jul’03 Aug’03 Sep’03 Oct’03 Nov’03 Dec’03 Infrastructure OUAC HSA EMAS Letter generation Transfer artic. DARS Interfaces e-Visions ESIS/UAR UGAFA

Changed Project Organization Issues Needed to match functional project management with technical project management Technical and functional had to be considered part of the same team Needed greater role definition for project management Results De-silo functional and technical teams Tear down the invisible managerial walls Removed barriers across sub-projects and with partners

Project Reporting Structure Student Finance Human Resources Alumni Functional Project Team Technical Project Team Functional Project Team Technical Project Team Functional Project Team Technical Project Team Alumni Support Team Manager, Student Functional Manager, Student Technical Manager, Finance Functional Manager, Finance Technical Manager, HR Functional Manager, HR Technical Manager, Alumni Support Project Admin. Banner Project Management Team Project Director Banner Steering Committee

Banner Information Center Single database for all status reports and issues All managers enter status reports here each week and update issue log Simple interface to an Access database Enables access to any status report written by any manager throughout the life of the project Shared access for anyone who needs access and any stakeholder

Project Status Reporting Weekly status of all modules formally documented Written reporting from each project manager Edited into weekly summary report and distributed to every stakeholder Simple focus on progress, issues, and next steps Encourage realistic reporting Truth trumps success Bullet list for quick scanning Results Awareness creates greater confidence in project No surprises No secrets

Weekly Management Review Project managers review accomplishments, issues, and plans Forum for: Discussing cross-module issues Creates shared awareness of status of all project activity Opportunity to question anything Debate on approach to any project activities Identify issues requiring escalation to steering committee Policy Funding Diplomatic support

Risk Management Process Formal risk analysis using the PMI (Project Management Institute) guidelines Helped us prepare for the unexpected and expected Forced us to think about future risk scenarios, so it also worked as a project planning tool

Risk Management Process Perform risk assessment 1 - Risk management plan developed 2 - Risk assessment team assembled 3 - Risk generation process executed 4 - Risk list rationalized 5 - Risks ranked and prioritized 6 - Response plans written 7 - Risk review process established and running monthly Institutionalize ongoing risk assessment Ongoing risk reviews Execution of risk response plans if necessary Write Plan Assemble Team Generate Risks Rationalize List Rank Risks Write Responses Monitor & Control

Risk Management Process Step 5 - Ranked Risks Rationalized list distributed to risk team for review Voting by: Impact of the potential loss Probability of occurrence

Risk Management: “A” Risk List (Fall 2002)

Risk Management Process Response Plans Response plans written for each of the risks: Name Description Initiation Triggers Symptoms Options Avoidance Transference Mitigation Acceptance Action plan Secondary risks

Production systems review Alumni review initiated Alumni went live with 1/3 of software Review options to implement the rest of the software Stakeholders awareness

Attitude shift Positive, buoyant culture introduced Can-do, non-adversarial Go Live Morale Reality sets in Recognize progress Trough of Disillusionment Kickoff Time

Vendor Relationships Paid bills due Support services from affected vendors returned to acceptable levels Focused on developing personal relationships with vendors where possible With approximately 10 different vendors, maintaining positive relations was challenging but critical

Re-Vamped Steering Committee Focus on: Sharing information (“Open the kimono”) Education of issues (before resolving issues) Mutuality-of-interest problem solving Full disclosure of project status The good, the bad, and the scary If something goes wrong: What happened How did it happen What is the impact What action are we taking to fix it When will it be fixed Decision making body Enterprise-wide policy Escalated issues Voting

Re-Vamped Steering Committee ERP Project Management Meeting Purpose: To review progress, address issues, and take corrective action Frequency: Every week Attendees: Project managers Project director (chair) ERP Steering Committee Meeting Purpose: To resolve strategic issues and monitor project success measures Frequency: Every two weeks Attendees: VP Finance & Admin VP Academic Dean of Students Dean of Grad Studies AVP Enrollment AVP Alumni CIO Director HR Director Finance Project director (chair) Issue requests & status updates Issue resolution & direction

New Communications Strategy Consistent key messaging: Going live is not the end of the project, it is just the end of the beginning The “show me” year - demonstrate, don’t speculate Match expectations with reality No “rah-rah” messages Mandate to replace legacy system, not improve upon it Going live means a non-ERP team member has entered permanent data into the system

ERP Data Access Protocol Background External systems accessed legacy data through the back door Same external groups wanted to continue this practice with ERP Purpose of protocol Formalize process for facilitating data access through the front door To maintain the project’s schedule and budget (and manage scope changes) the external projects were asked to follow this protocol Scope control Data propagation restraint Principles Use central database instead of “edge” systems whenever possible Avoid duplicate functionality Need a standard approach to respond to external systems Data will be supplied if business case warrants New ERP changes will supercede any “edge” system

ERP Data Access Protocol Results 6 groups demanded data access to ERP to replace unapproved legacy screen scraping and/or report scraping data acquisition systems All were told yes, on the condition they complied with the data access protocol Only one made it to the steering committee and none were moved to production

Technology Readiness Assessment To prepare for every go-live Initiated evaluation for performance and capacity evaluation of infrastructure Evaluate demand and usage profile of key events like registration

Performance Upgrades Develop & Test Database Server SAN Workload offload & failover 1 X Sun 3800 50% increase Developers 50 Users All year round 6 CPU @ 750 Mhz/CPU Application Server 1 X Dell 8500 Administrators 555 Users All year round 8 CPU Production Database Server 1 X Sun 3800 8 CPU @ 1Ghz/CPU Web Server (Carleton Central) Students 8,000 Users/Summer 23,500 Users/Fall 4 X Sun Netra 186% increase 800% increase

Dedicated Technical Resource Program Introduced dedicated technical resources to specific functional problems Successful with degree auditing and graduate eligibility sub-projects Creates focus, limits flexibility Challenge was to limit legacy support work

Reporting Strategy Number of Users Complexity of Report Oracle PL/SQL Efficiency of processing needed Complex queries PowerPlay Executive dashboard tool good for analytical work Not useful for day-to-day reporting eVisions Customize Banner reports Specialised external, formal reports Impromptu “what if” decision support modeling High-end data manipulation Reports needing high presentation flexibility Access Quick development of ad hoc queries Low volume of data Oracle Production reporting Standardised, repeated reports Number of Users Complexity of Report

Transition Planning Planning for staff transition back to functional departments Who goes where and when do they go there? Get the functional folks out of project mode and back into the operational bloodstream of the university Best way to make the system work is to get the people who really know it re-established in their functional areas Resist temptation to make project structure permanent Most effective way to socialize the system into the organization

Go-Live Preparation Identify what technical processes and infrastructure preparation must be done to enable the ERP go-live Integration testing Plan integration testing using all functional modules Implement database instance for integration testing Include all vendor modules Move to production checklist What are all the steps needed to move each module into production? Pre-planning Legacy checklist ERP checklist Help desk checklist Support checklist Contingency plan Implementation checklist

Go-Live Preparation Support readiness Help desk process Tri-level workflow model Production operations readiness Coverage during standard and non-standard hours Ensure sufficient operations depth Infrastructure readiness Performance demands Capacity evaluation Upgrade where necessary Implementation schedule Timeline for production usage of each functional module going live

Go-Live Preparation Contingency planning Performance and capacity failures in infrastructure Inability to move to production at right time Production disaster recovery Communication Ongoing documentation and communicating of implementation actions and their rationale Consulting support Create insurance policy by requesting on-site support from all vendors

Project Go Live Experiences Productivity Project Benefit Zone Productivity Baseline Project Shock Zone Go Live Date Time

Project Portfolio Planning Post go-live planning process

Project Planning – Overview of Process Primary ERP go-lives complete Need to plan next steps for all production modules Separate planning sessions held with each live functional area Purpose: identify “all the other work we have to do” (not “Phase 2”) Needed to capture workload What are ongoing support requirements? What projects are outstanding?

Project Planning – Results of Planning Sessions Project Portfolio document developed Ongoing maintenance and support requirements Three types of projects identified Current Projects already in progress Most started before May go-live Expected Projects previously identified, but not started Debate: were these part of original project scope New New project ideas ERP linkages Some projects closely tied to ERP Others only loosely related

Project Planning – Results of Planning Sessions Over 130 projects identified Each project profiled by: Name Owner Brief description Start/finish dates Priority (low/medium/high) Size (small/medium/large) Risk (low/medium/high) Benefits Value Basic information to begin project planning process Enough data to: Uniquely identify each project Categorize each project Preliminary ranking of projects Not enough to information to approve/reject Emerging workload demand profile

Project Planning – Risk/Priorities For each class of project (current, expected, new): Plot risk and priority to begin sorting process High priority / Low risk first prize Low priority / high risk cancel Useful in helping to sort out key projects and start prioritization

Project Planning – Challenges Need a process to evaluate & manage projects throughout their life Where to allocate resources Schedule projects and dependencies Evolutionary Experience will morph the process, but need a starting point Role of steering committee Process should transcend ERP Workload estimation Why do we need this process? Cost control Evolution of project management processes established Ownership distinction: the steering committee owns the project Functional separation of controls

Project Life Cycle Initiation Planning Execution Closure Asset Maintenance Project Flow Implement Plan Revisions Progress Develop Project Charter Document Needs Plan Project Document Shutdown Project Final Product Maintain Asset Initiate Next Phase New Project Work Support Work Benefit Realization Reject Approval Not Needed Review Charter Reject Not Sufficient Review Plan Approval Cancel Not Successful Monitor Status Approval Steering Committee Role Continue Execution Not Accepted Accepted Review Deliverables Control Mechanisms Status reporting Fiscal budget Risk plan Scope Resource plan Schedule Quality plan Communication plan Vendor management Base budget Support resources Benefit measures Portfolio assessment Priorities Risk Strategic fit Issue log Change control

Project Planning – Project Charter Project charter required for any project not yet started Purpose of project charter Business case to justify the project Document project parameters Guide project development Acquire formal authorization to proceed to the next step in the project Authorize the use of resources to develop detailed project plan Sufficient information to help the steering committee make their decision Generally brief: 2 to 3 pages

Project Planning – Project Evaluation Criteria Two project hurdles: Does the project meet any of the institution’s strategic goals? If yes, how well does it meet those goals?

Project Planning – Change Request or Project? Resources available Start work by team Low priority and less than 20 days and low impact and not complex Schedule request by project office Hold request No additional resources required Resources not available Review request by project office Develop project plan Approval Review of project charter by steering High priority, or more than 20 days, or high impact, or complex Cancel project or revise charter Submit new request by functional area Rejection Develop project plan Approval Review of charter by budget committee Approval Cancel project or revise charter Review of project charter by steering Rejection Additional resources required Cancel project or revise charter Rejection

Project Planning Project plan Standard requirement PMI based Scaleable

ERP implementations at other institutions Cost Comparison ERP implementations at other institutions

ERP Implementation Costs - Summary

ERP Implementation Costs - Detail

Project Rules (with apologies to Einstein) If we knew what it was we were doing, it would not be called a project, would it? The most incomprehensible thing about projects is that they are comprehensible. Anyone who has never made a mistake on a project has never tried anything new. Try not to deliver a successful project but rather try to deliver a valuable project. You do not really understand a project issue unless you can explain it to your grandmother. Sometimes one pays most for the project solutions one gets for nothing.

Questions