bbcon2012 WhatweLearnedFinal

1/7/2017 Footer 1

Implementing CMR, What We Learned From Our Project

PRESENTED BY KATE BUTLER, WENDY JACCARD, JULIE

VARGO

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

1/7/2017 Footer 3

INTRODUCTION /BACKGROUNDS/ OSU OVERVIEW

1/7/2017 Footer 4

• Kate Butler, Enterprise Solutions Consultant, Blackbaud

- [email protected]

• Wendy Jaccard, Principal Consultant, Blackbaud

- [email protected]

• Julie Vargo, Director of Application Development, The Ohio State University

- [email protected]

WHO ARE WE?

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

1/7/2017 Footer 6

IMPLEMENTING BBEC AT OSU

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

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

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

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

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

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

1/7/2017 Footer 13

• Project Team

PROJECT OVERVIEW

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

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

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

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

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


1/7/2017 Footer 19


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


1/7/2017 Footer 20


- Test

• Used by Developers for Testing

• Customizations



- Stage

• Used by project team members for Testing

• Customizations




1/7/2017 Footer 21


- Training

• Used for end user Training

• Customizations


• Open to all project team members, but with their production security

applied

- Production

• The “Real Thing”


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

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

1/7/2017 Footer 24

• Train the Trainer Mythology

• Onsite Staffing & Support

TRAINING

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

1/7/2017 Footer 26

• The Bad/Ugly

- Query Training

- Time Commitment for Users

- Lack of hands on time

- Teach by Process

TRAINING

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

1/7/2017 Footer 28

• BBIS

- March of 2012

• Email

• Our College of Business Profile, Alumni Directory, and Events

IMPLEMENTATION

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

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

1/7/2017 Footer 31

SUPPORTING BBEC AT OSU

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

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

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

1/7/2017 Footer 35


- 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


1/7/2017 Footer 36


- 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


WSJ2

Slide 36

WSJ2 Not sure I understand this.

WendyJa, 9/18/2012

1/7/2017 Footer 37


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

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

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

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

1/7/2017 Footer 42

• Lab Sessions

• Workshops

• Keep Environment Clean

ON-GOING TRAINING

1/7/2017 Footer 43

QUESTIONS?

1/7/2017 Footer 44

#BBCON TWEET YOUR TRACK:

#bbcrm

Documents

bbcon2012 WhatweLearnedFinal