1 / 54

Implementing Project Management Processes for ERP Systems

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

cooper-kirk
Download Presentation

Implementing Project Management Processes for ERP Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing Project ManagementProcesses for ERP Systems Mark Roman Ontario University Computing Conference May 17, 2004

  2. 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

  3. 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

  4. 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

  5. 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

  6. Project Management Processes Installed Implemented from July 2002

  7. 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

  8. 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

  9. Integrated Project Schedule • 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 • 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

  10. Sample Steering Committee Summary Feb. 24 Jul’02 Jan’03 Oct’02 Aug’02 Sep’02 Jun’02 Nov’02 Dec’02 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

  11. Sample Steering Committee Student Detail Feb. 24 Jul’02 Jan’03 Oct’02 Aug’02 Sep’02 Jun’02 Nov’02 Dec’02 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

  12. 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

  13. 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. Project Director Banner Project Management Team Banner Steering Committee

  14. 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

  15. 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

  16. 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

  17. 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

  18. Risk Management Process Write Plan • 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 Assemble Team Generate Risks Rationalize List Rank Risks Write Responses Monitor & Control

  19. 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

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

  21. 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

  22. 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

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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

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

  34. 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

  35. 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

  36. 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

  37. 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

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

  39. Project Portfolio Planning Post go-live planning process

  40. 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?

  41. 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

  42. 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

  43. 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

  44. 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

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

  46. 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

  47. 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?

  48. 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

  49. Project Planning • Project plan • Standard requirement • PMI based • Scaleable

  50. Cost Comparison ERP implementations at other institutions

More Related