Implementing Project Management Processes for ERP Systems - PowerPoint PPT Presentation

Loading...

PPT – Implementing Project Management Processes for ERP Systems PowerPoint presentation | free to download - id: 3bb448-YmNiN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Implementing Project Management Processes for ERP Systems

Description:

Implementing Project Management Processes for ERP Systems Mark Roman Ontario University Computing Conference May 17, 2004 Background June 2002 Banner implementation ... – PowerPoint PPT presentation

Number of Views:1486
Avg rating:3.0/5.0
Slides: 55
Provided by: cronusUwi
Learn more at: http://cronus.uwindsor.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Implementing Project Management Processes for ERP Systems


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
Technology Readiness Assessment
Dedicated Resource Program
Reporting Strategy
Transition Planning
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
Risk Management Process
Weekly Management Review
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
  • 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

10
Sample Steering Committee Summary
Feb. 24
Jul02
Jan03
Oct02
Jun02
Aug02
Sep02
Nov02
Dec02
Feb03
Mar03
Apr03
May03
Jun03
Jul03
Aug03
Sep03
Oct03
Nov03
Dec03
Student HR Alumni Finance Enterprise
11
Sample Steering Committee Student Detail
Feb. 24
Jul02
Jan03
Oct02
Jun02
Aug02
Sep02
Nov02
Dec02
Feb03
Mar03
Apr03
May03
Jun03
Jul03
Aug03
Sep03
Oct03
Nov03
Dec03
Infrastructure OUAC HSA EMAS Letter
generation Transfer artic. DARS Interfaces e-Visio
ns 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
Alumni
Human Resources
Finance
Student
Functional Project Team
Functional Project Team
Functional Project Team
Alumni Support Team
Technical Project Team
Technical Project Team
Technical Project Team
Manager, Student Functional
Manager, Finance Functional
Manager, HR Functional
Manager, Alumni Support
Manager, Student Technical
Manager, Finance Technical
Manager, HR Technical
Project Admin.
Banner Project Management Team
Project Director
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
  • 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
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

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, dont 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 projects 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 _at_ 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 _at_ 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
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

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

51
ERP Implementation Costs - Summary
52
ERP Implementation Costs - Detail
53
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.

54
Questions
About PowerShow.com