1. 1/7/2017 Footer 1
Implementing CMR, What We Learned
From Our Project
PRESENTED BY KATE BUTLER, WENDY JACCARD, JULIE
VARGO
2. 1/7/2017 Footer 2
• Presenter Intro/Backgrounds/Overview of The Ohio State University
• Implementing BBEC at OSU
- Overview of the Project
- Customization Management
- Project Environment Management
- Training
- Implementation
• Supporting BBEC at OSU
- Overview of Production Support
- Patches and Upgrades
- Support / Phase 2 Environment Management
- On Going Training
• Questions?
AGENDA
4. 1/7/2017 Footer 4
• Kate Butler, Enterprise Solutions Consultant, Blackbaud
- Kate.butler@blackbaud.com
• Wendy Jaccard, Principal Consultant, Blackbaud
- Wendy.jaccard@blackbaud.com
• Julie Vargo, Director of Application Development, The Ohio State
University
- Vargo.64@osu.edu
WHO ARE WE?
5. 1/7/2017 Footer 5
• $364,822,055 Raised in Fiscal year 2012
• 498,038 of living alumni
• 1,394,264 Individuals, 192,377 Organizations, and 266,261 Groups in
BBEC
• 444,004 of Gift processed Fiscal Year 2012
- 900 Average # of Gifts per Week
• 900 System Users
THE OHIO STATE UNIVERSITY
7. 1/7/2017 Footer 7
• Project Goals
- Short Term – Replace Mainframe Technology
- Long Term - To have a system that is flexible enough to facilitate and
improve the University's ability to raise money, steward our donors, cultivate
friends, and honor our alumni.
• Initial Scope
- Replace 5 custom built applications
- Eliminate the need for “outside” databases
PROJECT OVERVIEW
8. 1/7/2017 Footer 8
• Project Time Line
- A little over 2 years from when the decision was made to go with BBEC
- We ended up pushing 6 weeks from our original go-live date
PROJECT OVERVIEW
9. 1/7/2017 Footer 9
• Project Team
- Project Steering Committee
• Representatives from Foundation, Business Units, and University IT
• Duties – Oversees project from high level, reviews escalated risks/issues,
makes recommendations to help ensure projects success
- Project Leadership Team
• Project Business Sponsor, Director of Application Development, Director
of Infrastructure, and Key Functional Leads
• Duties – Day to Day oversight of the project, reviews risks/issues, and
provides the overall project direction and guidance.
PROJECT OVERVIEW
10. 1/7/2017 Footer 10
• Project Team
- Project Infrastructure Team
• Individuals that are responsible for the system Hardware, Networks and
Level One Help Desk
• Project FTEs
– 1.5 FTE Hardware/Network
– 2.5 FTE Level One Help Desk
PROJECT OVERVIEW
11. 1/7/2017 Footer 11
• Project Team
- Project Application Development Team
• Individuals that are responsible for the system administration and
customizations
• Project FTEs
– 1 Project Manager (OSU)
– 1 Engagement Manger (Blackbaud)
– 1.5 Functional Consultants (Blackbaud)
– 3 Business Analyst (OSU)
– 1.5 Technical Lead (OSU/Blackbaud)
– 5.5 Technical Developers ( 4 OSU - 1.5 Blackbaud)
– 1.5 Core Trainers
PROJECT OVERVIEW
12. 1/7/2017 Footer 12
• Project Team
- Project Functional Team
• Team consists of representatives from each business area (BIO,
Revenue, Events, etc.)
• Functional Lead (FL), Conversion Lead (CL), Subject Matter Experts
(SME)
• Provides expertise on overall business requirements and process for their
area.
• Performs Conversion Validation and System Testing
• Team had over 60 members
PROJECT OVERVIEW
14. 1/7/2017 Footer 14
• The Good
- Project Functional Team - Had the right experts involved
- Technical Teams Limited Workload on Legacy System
- A True Team was built with OSU and Blackbaud Employees
- Clear Scope and Hard Deadline
PROJECT OVERVIEW
15. 1/7/2017 Footer 15
• The Bad/Ugly
- Overworked Project Functional Team
- Testing Challenges
• Inexperienced Testers and Testing Lead
• Found it difficult to test from end to end
• Hard to get management to understand being at the mercy of a Vendor
PROJECT OVERVIEW
16. 1/7/2017 Footer 16
• OSU ended up with around 90 customization with varying degrees of
complexity
• We used a “sort-of” agile approach to development
- 30 day development cycles
- Daily 15 min. sprint status meetings
• OSU managed the development work
• Required Blackbaud technical resources to be on-site if possible 50%
of their time.
CUSTOMIZATION MANAGEMENT
17. 1/7/2017 Footer 17
• OSU is “self-hosted”
• Project Environments
- Sandbox
• Used to for timings on patches, test to make sure bug was due to out-of-
box code not something OSU
• No customizations
• Sample Database
- Design
• Used for Functional Consultants to “try-out” settings and configuration
• Limited Access
• No customizations
• Sample Database
ENVIRONMENT MANAGEMENT
18. 1/7/2017 Footer 18
• Project Environments (cont.)
- Configuration
• Used to set-up configuration for production
• Technical Staff wrote custom scripts to move from configuration to other
environments.
• Customizations
• No data
• Limited Access
- Conversion
• Used to convert OSU data into
• Customizations
• Converted data
• Limited Access
ENVIRONMENT MANAGEMENT
19. 1/7/2017 Footer 19
• Project Environments (cont.)
- Conversion Validation
• Used to validate data conversion
• Customizations
• Copy of Conversion Database
• Open to all project team members
- TFS (Team Foundation Server)
• Used for our customization source save
• No data
• Limited Access (developers only)
ENVIRONMENT MANAGEMENT
20. 1/7/2017 Footer 20
• Project Environments (cont.)
- Test
• Used by Developers for Testing
• Customizations
• Copy of Conversion Database
• Open to all project team members
- Stage
• Used by project team members for Testing
• Customizations
• Copy of Conversion Database
• Open to all project team members
ENVIRONMENT MANAGEMENT
21. 1/7/2017 Footer 21
• Project Environments (cont.)
- Training
• Used for end user Training
• Customizations
• Copy of Conversion Database
• Open to all project team members, but with their production security
applied
- Production
• The “Real Thing”
ENVIRONMENT MANAGEMENT
22. 1/7/2017 Footer 22
- The Good
• Daily Sprint meetings were priceless
• New to Agile – but worked well (small chunks of work with well-defined
end or goal dates.)
• Teamwork between OSU and Blackbaud Professional Services
CUSTOMIZATION/ENVIRONMENT MANAGEMENT
23. 1/7/2017 Footer 23
- The Bad/Ugly
• Environment Management was time consuming
• OSU and Blackbaud did not have firm grasp on data and configuration
movement through the different environments. (GUIDs are yucky)
• Multiple versions/releases of BBEC (2.5 to 2.9)
CUSTOMIZATION/ENVIRONMENT MANAGEMENT
24. 1/7/2017 Footer 24
• Train the Trainer Mythology
• Onsite Staffing & Support
TRAINING
25. 1/7/2017 Footer 25
• The Good
- Feel this was the smoothest “area” of our project
- Collaboration on training documentation was excellent
- Business Area Leaders taking on some of the training worked well
- Trainers involved early in design process
- Applying security model during training
- Utilizing helpdesk
TRAINING
26. 1/7/2017 Footer 26
• The Bad/Ugly
- Query Training
- Time Commitment for Users
- Lack of hands on time
- Teach by Process
TRAINING
27. 1/7/2017 Footer 27
• We performed a rolling implementation
IMPLEMENTATION
Date Task
8/17 Last Day to Accept Checks
8/18-8/19 Finish Processing /Balance Aug
8/20 Provide Copy / IT Shut down / Begin Conversion
8/21 – 8/24 Running Conversion
8/25 IT Day
8/26-8/29 Production Conversion Validation
8/30 Released to BIO and GP Processing
9/1 Released to Prospect Management, Planned Giving
9/6 Released to Stewardship, Events, and Recognition Clubs
9/7 Release to BIO/ Rev View Only
28. 1/7/2017 Footer 28
• BBIS
- March of 2012
• Email
• Our College of Business Profile, Alumni Directory, and Events
IMPLEMENTATION
29. 1/7/2017 Footer 29
• The Good
- Users were well trained
- OSU Level 1 and Level 2 Support was prepared for go-live
- We chose to implement during a “slow” time
- Blackbaud’s Professional Services Support was excellent
IMPLEMENTATION
30. 1/7/2017 Footer 30
• The Bad/Ugly
- Load Balancer
- Performance
- User understanding the difference between bug fixing for a vendor
application compared to a custom application
IMPLEMENTATION
32. 1/7/2017 Footer 32
• Production Support Only Mode for 6 months
• Majority of issues were with
- Performance
- Two-Way Sync with our Alumni Association
- Batch
– Things not working exactly as expected
PRODUCTIONS SUPPORT OVERVIEW
33. 1/7/2017 Footer 33
• Keys to Production Support
- Establish a Strong Support Team
• Functional Lead for each area stays intact, 10% to 25% of their job will be
focused on system support tasks.
• Well-rounded/knowledgeable Technical Analyst
• Help Desk/Level 1 familiar with the system.
- Defined yet fluid support process
• Internal help desk system
• Limited resources to handle communication to Blackbaud
PRODUCTIONS SUPPORT OVERVIEW
34. 1/7/2017 Footer 34
• Key Production Support Roles
- Functional Leads
• Acts as the point of contact for their respective business area
• Approves Security Access for users
• Helps to direct and participate in the developing and performing of testing
bug fixes both customizations and Blackbaud.
• Provides consultative support to users on questions of functional areas
processes and procedures.
• Aids in prioritization of system issues
• Aids planning of the vendor fix/patches
PRODUCTION SUPPORT OVERVIEW
35. 1/7/2017 Footer 35
• Key Production Support Roles
- Technical / Business Analyst
• Level two support for TAS issues.
• Responsible for monitoring Technical Analyst Group assigned incidents.
• Try to problem solve given issue.
• Act as a Configuration Gatekeeper
• Adds/Updates Configuration that is outside of customizations.
• Create and Update Application Security Roles/Users
• Aid in Job Scheduling and Monitoring
• Aid in testing bug fixes both customizations and Blackbaud patches.
• File issues with Blackbaud TAM
PRODUCTION SUPPORT OVERVIEW
36. 1/7/2017 Footer 36
• Key Production Support Roles
- Help Desk
• Level one support for TAS issues.
• Responsible for initiating the majority of support incident tickets.
• Try to problem-solve issue with the using issue documents and
researching existing tickets.
• Aids in the creation of common TAS issue documents
• Responsible for creation of new users in AD
PRODUCTION SUPPORT OVERVIEW
WSJ2
39. 1/7/2017 Footer 38
• Patch Process
- OSU using the ”patch when needed” methodology
- Rolled out 5 rounds of patches since go-live
- Patch is first put into our Sandbox environment to establish timing, then put
in our Test and Stage Environments
- Functional Leads/ Technical Analyst / Developers are all responsible for
testing
• OSU patch testing is semi-structured, goal for 2013 to establish better
testing process
- Goal is to have patch process completed in a two week time period.
PATCHES
40. 1/7/2017 Footer 39
• OSU is in the middle of project to upgrade (2.9 to 2.94)
• Treating it as a project (Phase 2)
• Part of the project is also to bring our Alumni Association and Arts
Center into the BBEC fold.
• Timeline – 1 year and 2 months
• Have discovered upgrading an environment with your own production
data is better done sooner than later.
UPGRADES
41. 1/7/2017 Footer 40
• OSU has two environment paths
- Production Support Path
- Phase 2/ Upgrade Path
SUPPORT AND PHASE 2 ENVIRONMENT MANAGEMENT
Production Support(2.9) Phase 2/Upgrade (2.94)
Sandbox Sandbox
TFS TFS
Test Test
Stage Stage
Design
Conversion & Conversion Validation
Training
(only one environment, upgrading one month prior to production upgrade)
Production
42. 1/7/2017 Footer 41
• Keeping Customizations in Sync between the two paths is a
challenge.
• Environment Management has become a full-time job.
SUPPORT AND PHASE 2 ENVIRONMENT MANAGEMENT
