Transcript Implementing Project Management Processes for ERP Systems Mark Roman Ontario University Computing Conference

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
Changed
Organization
Structure
New
Communication
Strategy
New
Project
Management
Process
Go Live
Planning
Re-Vamped
Steering
Committee
Project
Status
Reporting
Banner
Information
Center
Vendor
Relationships
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
Student
HR
Alumni
Finance
Enterprise
Dec’03
Nov’03
Oct’03
Sep’03
Aug’03
Jul’03
Jun’03
May’03
Apr’03
Mar’03
Feb’03
Jan’03
Dec’02
Nov’02
Oct’02
Sep’02
Aug’02
Jul’02
Jun’02
Sample Steering Committee Summary
Feb. 24
Sample Steering Committee Student Detail
Infrastructure
OUAC
HSA
EMAS
Letter generation
Transfer artic.
DARS
Interfaces
e-Visions
ESIS/UAR
UGAFA
Dec’03
Nov’03
Oct’03
Sep’03
Aug’03
Jul’03
Jun’03
May’03
Apr’03
Mar’03
Feb’03
Jan’03
Dec’02
Nov’02
Oct’02
Sep’02
Aug’02
Jul’02
Jun’02
Feb. 24
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
Finance
Student
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
Banner Project Management
Team
Project
Admin.
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
Degree of impact
Financial estimate
Low
Medium
High
Very High
Less than $250,000
$250,000 to $1,000,000
$1,000,000 to $3,000,000
$3,000,000 and over
Numerical
value
1
5
16
32
• Probability of occurrence
Degree of
probability
Low
Medium
High
Very High
Probability estimate
1– 25% (unlikely)
26–50% (possible)
51–75% (more likely than not)
75-100% (quite probable)
Numerical
value
1
2
3
4
Risk Management: “A” Risk List (Fall 2002)
#
Description
Impact
Probabilty
Score
Grade
1 Synchronization of HR and Finance
may put payroll at risk.
26.7
2.0
53.4
A
2 Fully developed plans do not exist
for post-GoLive management of
Banner.
15.9
3.3
52.1
A
3 Formal disaster recovery or
continuity plans do not exist for the
business or IT components of
Banner.
24.3
2.1
52.0
A
4 We may not be able to maintain
and sustain the right people in
right places on the project.
16.0
3.1
50.3
A
5 The university is not ready to
socialize Banner into its culture.
10.6
2.9
30.7
A
6 Security may be breached.
10.9
1.7
18.6
A
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
Kickoff
Recognize
progress
Trough of
Disillusionment
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
ERP Steering
Committee Meeting
Purpose:
Purpose:
• To review progress,
address issues, and take
corrective action
Issue requests &
status updates
• To resolve strategic issues
and monitor project
success measures
Frequency:
Frequency:
Attendees:
Attendees:
• Every week
• Project managers
• Project director (chair)
• Every two weeks
Issue resolution
& direction
•
•
•
•
•
•
•
•
•
•
VP Finance & Admin
VP Academic
Dean of Students
Dean of Grad Studies
AVP Enrollment
AVP Alumni
CIO
Director HR
Director Finance
Project director (chair)
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
1 X Sun 3800
Workload
offload &
failover
50%
increase
6 CPU @
750 Mhz/CPU
Developers
50 Users
Application Server
All year round
1 X Dell 8500
8 CPU
Administrators
555 Users
Production
Database Server
All year round
1 X Sun 3800
8 CPU @
1Ghz/CPU
186%
increase
800%
increase
Web Server
(Carleton Central)
Students
4 X Sun Netra
8,000 Users/Summer
23,500 Users/Fall
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











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
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
Project Benefit
Zone
Productivity
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
Risk
Low
Medium
High
High
Priority

Medium
Low
Athletic eRegistration
Decommission of CP6
Internal Summary Reporting
Automate Portfolio Requirements
Class Scheduling
Disk Storage Space on “W” Drives
Interface Purchase Requisitions from Maximo
Electronic Gradebook
Interface Library and Accounts Receivable
Interface Campus Card with OC Transpo
Fixed Assets and Capital Budgeting
Investment Management
Remote Cheque Requisition
OUAC Upgrades
Accept Payment for Tuition over the Web
Automated Average Calculation for 105 Applicants
Direct Deposit for Student Refunds
Enhancing Student Service over the Web
Transfer Articulation in DARS
Automated Equivalency and Load into DARS
Document Imaging for FAST Reporting
Direct Deposit for Travel Expenses
Document Finance Processes
Remote Access
eCommerce (e.g. application fees)
Remote PO Requisitions
Intranet for Banner Finance andFinance
Test Environment for Millennium
Registration Enhancements
Electronically Import OSAP Data
Automated Travel Expense Claims
Admissions through Web and eCommerce
Receiving EDI Transcripts
Document Management + Imaging
Workflow
Offline Database & Query Facility
Banner Parking Management
Archiving Solutions
Connect Single Sign-on
User Friendly JV Form
Force Password Change
System to Support Paul Menton Centre
Benchmark Other Institutions
Link Web Audit to Course Calendar & Registration
Banner Web for Alumni Research & Implement
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
Revisions
Project
Flow
Needs
Develop
Project
Charter
Plan
Project
Implement
Plan
Shutdown
Project
Document
Document
Progress
Final Product
Maintain
Asset
Support Work
Approval
Steering
Committee
Role
Review
Charter
Not Needed
Reject
Control
Mechanisms
Portfolio assessment
• Priorities
• Risk
• Strategic fit
Approval
Review
Plan
Not Sufficient
Reject
Approval
Monitor
Status
Not Successful
Cancel
Status reporting
Fiscal budget
Risk plan
Scope
Resource plan
Schedule
Quality plan
Communication plan
Vendor management
Review
Deliverable
s
Not Accepted
Continue
Execution
Accepted
Benefit
Realization
New Project
Work
Initiate
Next Phase
Base budget
Support resources
Benefit measures
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 Evaluation Criteria
9/22/2003
Generic model
Banner Steering Committee
Support for Teaching and Learning
Strategy: Strengthen teaching & learning support
Grow EDC:
orientation
and
instruction
in
pedagogy
Improve
Library:
access to
info and
resources
Reward
achievement in
instruction,
pedagogical research
Emphasize
teaching
achievements for
tenure/
promos
Criteria
Grad Studies
Expenses
Strategy: Enhance university’s activity & profile in grad studies & research
Increase
student
volume &
improve
student
quality
Use grad
funding to
improve
student
quality
Grow
external
funds for
research,
infrastructure, awards
Define
strategic
research
areas
Assist in
development of
student
recruitment
plans
Grow
international character
of research
work &
partners
Grow
circulation
& use of
research
results
Undergrad Studies
New
Project
Positive
transition
from high
school to
university
Establish
first year
coordinator
in SASC
Appoint first
year
coordinator
in FASS
Implement
academic
advising
plan
Integrate
Campus
Life &
Career
Services
into SASC
Strategy: Continually improve the quality of the student body
Increase
co-ops and
placements
Set
appropriate
enrolment
targets in
programs &
faculties
Raise high
school
entrance
averages
relative to
province
Increase
proportion
of high
achieving
students
Set
appropriate
targets for
international students
Review
articulation
agreements
Continue
university
retention
committee
Monitor
impact of
new rules
on retention
& update
Implement
clear &
uniformly
applicable
rules
Correct
courses
with high
no-credit
rates
Support
mission of
CIE
Faculty and Staff
Strategy: Recruit and retain highest quality staff
Congenial,
supportive,
equitable
work
environment
Multi-year
schedule
for hiring
faculty and
staff
Passed
Project
Promote
collaboration with
employee
groups
Advancement
Strategy: Strengthen university’s position regionally, nationally, and internationally
Develop
integrated
plan for all
Advancement units
Develop
diverse and
equitable
institutional
image
Velocity
Deliver products & services
faster
Capacity
Handle more work with
same resources
Satisfaction
Improve customer service
and satisfaction
NPV
Positive net present value
of costs & benefits
Decisioning
Improves ability to make
more collaborative and
timely decisions
Leverage
Maximize use of existing
assets
MarketShare
Risk
Community
Strategy: Foster identification & attachment to Carleton
Promote
community
of learning
Develop
universitywide events
Promote
diversity
and civility
Develop
university
organized
culture
events on
campus
Infrastructure and Financial Management
Strategy: Improve the physical plant and campus infrastructure
Refine and
develop
Campus
Master
Plan
Improve
physical
appearance
&
cleanliness
of campus
Create
comfortable
spaces
Continue
install and
upgrade of
campus
network
Address
deferred
maintenance
backlog
Continue to
implement
new admin
system
Strategy: Maintain financial viability of the university
Improve
and modify
global
budgeting
system
Reduce
accumulated deficit
Maximize
external
funding of
projects
Description
Lower the cost to operate
the university.
Strategy: Improve retention and graduation rates
Hurdle 2:
How well does the project meet the university’s goals?
Strategy: Enhance the student university experience
Hurdle 1:
Does the project meet the university’s goals?

Grow volume profitably
Lower risks of running the
university
Innovation
Increase innovation &
improve learning
processes.
Mandated
Non-negotiable operational
requirement or legislative
demand.
Yes/No
Project Planning – Change Request or Project?
Low priority and less
than 20 days and low
impact and not complex
No additional
resources required
Resources
available
Schedule
request by
project office
Resources not
available
Review
request by
project office
Approval
High priority, or more
than 20 days, or high
impact, or complex
Submit new
request by
functional
area
Review of
project
charter by
steering
Rejection
Approval
Approval
Additional resources
required
Review of
project
charter by
steering
Review of
charter by
budget
committee
Rejection
Rejection
Start work
by team
Hold request
Develop
project plan
Cancel
project or
revise
charter
Develop
project plan
Cancel
project or
revise
charter
Cancel
project or
revise
charter
Project Planning

Project plan
– Standard requirement
– PMI based
– Scaleable
Cost Comparison

ERP implementations at other institutions
ERP Implementation Costs - Summary
$250.0
$240.0
$230.0
$220.0
$210.0
$200.0
$190.0
$180.0
$170.0
$160.0
$150.0
$140.0
$130.0
$120.0
$110.0
$100.0
$90.0
$80.0
$70.0
$60.0
$50.0
$40.0
$30.0
$20.0
$10.0
$0.0
College
Carleton
University
University A
University B
University C
University D
Wayne State
University of
Illinois
ERP Implementation Costs - Detail
Institution
College - Banner
Implementati
on Cost
($ Million)
$9.5
Modules Included in Cost
Student, Finance, HR
Carleton University - Banner
$11.9
Student, Finance, HR, Alumni
University A - Banner
$11.9
Student
University B - Peoplesoft
$20.0
Student, Finance
University C - Banner
$26.0
Student, Finance, HR, Alumni
University D - Peoplesoft
$30.0
Student, Finance, HR, Alumni
Wayne State - Banner
$45.0
Student, Finance, HR. Alumni
$250.0
Student, Finance, HR, Alumni
University of Illinois - Banner
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