10 Decisions You Will Face With Any Donor Data Migration Project

Full Transcript:

Steven Shattuck: Thanks for being here for today's webinar, "10

Decisions You Will Face with any Donor Data Migration

Project." My name is Steven Shattuck. I am the VP of

Marketing here at Bloomerang and I'll be moderating today's

discussion.

Before we begin, I just want to let everyone know that we are

recording this presentation and I'll be sending out the

recording later on this afternoon. So, if you have to leave

early, or you want to review the content with some members

of your team a little later on, just know that I will be

sending out that recording a little later on today as well

as the slides and you'll be receiving those.

We're doing something a little new on our Bloomerang webinar today.

We've got a poll up on the screen. So, if you have not

already answered that poll, please do. Just take a couple

of minutes and answer those three questions. When you do

that, you should see a little confirmation screen. We'll be

sharing the answers and the data of that poll a little

later on this afternoon.

So, while you're doing that poll, I want to go ahead and introduce my

guest today. He is Gary Carr. Hey, Gary, how are you doing?

Gary Carr: I am good.

Steven Shattuck: Good. And for those of you who don't know Gary, Gary

is the founder and president of Third Sector Labs and he's

got more than 20 years of experience delivering software

and data solutions to a wide variety of clients. Gary is

really focused on data. He's going to be talking about data

today. That's what Third Sector Labs does. They're

committed to making sense out of data for the nonprofit

industry. So, Gary, it's really good to have you here.

What's going to happen is Gary is going to run through his

presentation today and we're going to save a little bit of

time at the end for questions. So, as you're listening to

Gary, please feel free to send any questions our way via

the chat box there on our webinar screen. We'll both see

those. We'll try to answer just as many as possible during

the formal Q&A session.

If we can't get to all of the questions, Gary has agreed to answer

some of them online a little later on after the

presentation. So, don't be shy. Gary is a data expert. He

is here for you.

So, Gary, I think we can probably close the poll, I think. Have you

got enough answers?

Gary Carr: We've got a lot of good answers on the poll. I'm going to close

it.

Steven Shattuck: Cool.

Gary Carr: I'm going to see if we can share the results here.

Steven Shattuck: Yeah. I can see them.

Gary Carr: Great. So, I'm sorry?

Steven Shattuck: Pretty interesting results there.

Gary Carr: Across a number of our webinars, I know this is not scientific

for the folks that are with us today, but it does give us

some good insight into a number of different system,

technology and data-related issues when we participate in

the webinar or we're hosting a webinar. So, we tend to ask

the same questions over and again.

It's interesting here. We'll talk about the results a little bit as

we go through the presentation. But for the folks that are

with us today, the results that I'm seeing here are pretty

consistent with results that we have seen across other

events from other respondents.

I do want to say that on the second question, the number of

technology systems that people are using to execute their

campaigns, this is the highest response rate we've ever had

for just one or two systems. The majority of respondents

that we see in the past have been dealing with 3-5 and even

six or more systems.

So, for the folks that are joining us today, congratulations. You are

finding ways to make things easier with technology, not

necessarily more difficult. I think that's a good thing.

So, I'm going to stop sharing the results, Steve. Hopefully I'm going

to take us over to the presentation.

Steven Shattuck: Yeah. Gary. It's all you.

Gary Carr: Great. So, thanks again everyone for being with us today.

Thanks to Bloomerang for hosting this event, "10

Decisions..."

We've covered the poll, but we're going to have a short agenda here.

After we get through the general overview, we've got some

ground rules that we want to talk about related to data,

data systems, data migration and then we're going to take a

look at the process and the planning that you do around the

data migration and focus on the concept of donor data

migration. And then we'll jump to the 10 unavoidable

decisions and then look at the takeaways and the Q&A at the

end.

I appreciate your overview and giving my background. Third Sector

Labs, we provide a variety of data-related services. If you

visit our website, you can find more detail on them.

But basically, we're doing level one-type work, which is cleanings

and assessments. We'll take our client work to a second

level of complexity or a second level of involvement around

data management, migration and as we're talking about

today, enrichment.

And then we'll also handle some very sophisticated, we call them

level three services, level three problem solving. We'll do

some fairly sophisticated work around data warehousing,

mining and system integration.

So, when we wrote the topic for the webinar today, for the event,

there are actually some loaded words in here. "10

Decisions..." not making a decision is still a decision.

We're going to talk about that. You will face these. We

think these are pretty much unavoidable in any donor data

or CRM data migration.

Donor Data is an interesting concept. It is far more degradable if

you haven't thought about that or you haven't encountered

that in your day-to-day work, it's far more degradable than

many other types of data that you may deal with, for

example, outcome measurement data.

Donor data is degradable as our lives are. Something we want

everybody thinking about when you think about the word

migration, migration involves in movement and movement

involves risk. So, it's a loaded topic today.

Data confounds us. Why does data confound us? Why does it give us

reason to pause, reason to feel perplexed or sometimes even

get confused? More traditionally, we thought about data and

science, we thought about it like the Sherlock Holmes

story. It was a capital mistake to theorize before you have

data. That's sort of a very traditional approach. You need

some data, you need some facts and then you make the

decisions.

And then along came the Information Age. We got the second quote,

which has been attributed to more people than I keep track

of. "Data is the new oil." Okay. That's interesting. That

means data is driving our Information Age. Okay. That makes

sense to me.

We started one-upping each

other and we came up with clever quotes, "Data isn't just

the new oil, but it's a whole new kind of resource."

I sort of associate quotes like that with tech guys like me trying to

take over industries and the world and claim that we've got

some sort of secret sauce knowledge that nobody else has,

so you better listen to us. I think it's a little bit of an

overstatement. I think data is like a new oil. It is

driving the Information Age. Let's make sure we figure out

how to keep data in its place. That takes us to the heart

of the problem.

I found this great quote from Joss Whedon. Josh is a screenwriter,

director. Some of you may follow his work. But he put up

this conundrum one time. I can't remember why he was being

interviewed. But he talked about the fact that he is

personally frustrated by the fact that we have institutions

like the NSA collecting gobs of data, collecting mega

amounts of data on us individually and how it is

disturbing. It makes us feel uncomfortable.

There's so much data out there. As he says, it freaks him out. Yet,

we are the generation that wants to put a GPS on our kids

so we always know where we are. Well, that's data. So, how

do we deal with this conundrum? How do we deal with this

conflict in how we approach technology and data?

And I think we sort of sum it up because we're feeling overwhelmed.

That's the challenge for so many clients that we talk to

and partners that we work with in the industry. Everybody

feels overwhelmed. Big data is big confusion.

It's not just what data do we need, but even more challenging is

sometimes the question what's the data that can ignore.

That sort of gets to the heart of today's presentation.

What donor data do we need and what data can we ignore? So,

that's the scene running in the background behind our

discussion today.

So, if you're here with us, you're here-wow, one, one, one, one,

we're going to call all these equal then. If you're here

because you're in the midst of a CRM migration or perhaps

you've got one coming up and you want to plan for it, you

may have some problems or some issues you're still

wrestling with.

But you've probably got a CRM data migration that is right around the

corner or has just left you around the corner and you're

trying to wrestle with that a little bit. I doubt many of

you are so inspired by data that you're here looking for a

job with Third Sector, but there could be a few.

What are the ground rules that we talked about? The ground rules, the

points that we're going to reference throughout this

presentation that are not negotiable, it's just sort of

recognizing that this is the way it is in the industry.

This is the way it is with data. Thanks for that comment,

Mark Port.

"Never tear down a bridge before you know why it was built. It may be

your only means of retreat." It's a very wise statement

that I think goes somewhere... it's definitely a ground

rule, if you will, that good, smart technologists live by.

You don't want to replace things. We don't want to tear

things down. We don't want to get rid of the old until we

have a good reason for it and we know what we're going to

be doing as we move forward.

So, ground rules for us today, the ground rules for a discussion

around donor data migration-first and foremost, all of your

donor relationships depend upon data, all of them data. So,

your data needs to be as complete as possible.

What does complete mean? Number two-complete is what you're going to

use. Think about that as we talk through our questions

today. What does that really mean? What do you really need?

How much data do you need? What does it need to look like?

What are you going to use? And then the flipside of that is

what are you not using? If you're not using it, why is it

still around?

Your shiny new CRM, your new donor database, that's your future, not

your past. This is a very important concept. We run into a

lot of challenges with clients that don't recognize that.

We are talking about your future, the success of your

future. We are not talking about the past. Reports are your

past. CRM is your future.

Not making a decision, number four, is still a decision. I cannot

stress that enough. When we talk about these ten decisions

that we're going to go through today, you've got to act on

them. If you just push them off, then the reality is you've

made a decision and it's going to be to your detriment.

Lastly, all data migrations start with an understanding of the

process. They require a plan. That's where we're going to

get stated with our next slide. What's the process and the

plan that we're talking about?

So, it's moving time. I've got a bunch of logos here representing

different donor management systems, different CRMs. I'm

sure that you've all run into any of these, if not most or

not all of these, from simple access in Excel spreadsheets

to very large "we can do it all" systems to newer systems

that have come on to the market that adjust some very

specific and important aspects of fundraising and donor

management. So, there are pros and cons for moving from

something to something. So, it's moving time.

What's the technical process? Well, I chuckled with somebody one time

talking about this because their view of what we do in a

data migration is that we take all the best stuff from the

old system and we shove it into the new system. That's kind

of what it's like, right? That's all you've got to do.

We're shoving it into a cloud because so many of the new systems are

software as a service, cloud-based access anywhere. So,

just get all of those zeroes and ones out of the old, cram

it into the new and we're good to go, right? That's all

we've got to do. Not exactly.

The technical process really looks more like this-six steps that we

have to get through. Those six steps are pretty standard

for any data migration. You're going to do analysis up

from. There are mappings across systems. There's data

extraction that's going to occur from the legacy system,

configuration of the new database that you're moving it

into. Create your import files and run your import. It's a

six-step process. That's it. Well, not exactly.

There's really a lot more going on. There are a lot of additional

steps that are going to occur that you may or may not be

aware of as your consultant or your expert or your vendor

representative is taking you through the data migration

process. There are some really important steps that need to

be scheduled around things like data cleaning, parsing

data. There are multiple rounds of testing that are going

to be run. Your consultant, you're going to need to run

test files, re-run test files. You're going to be

reconfiguring your database.

When you're fully ready to import, step number six, you'll notice how

many additional boxes there are around number six because

you're going to test, you're going to re-test, you're going

to re-import, you're going to clean, you may well re-import

again after that. And when you get done at the end of the

process, then you're going to start thinking about what

your archives need to look like, what happens to all the

data you couldn't move over.

So, a six-step process really starts to look like about a 14 or 15-

step process. It could get longer than that depending upon

the number of steps that we have to repeat. I bring this up

because this what I want you to be prepared for as you're

thinking about an engagement or you're addressing or

planning that next donor data migration, what are you going

to encounter? How simple does the work seem versus how much

work really needs to get done?

Creating a plan is really something that your experts, your

consultants or your vendor representatives should be doing.

But I bring this up because you guys, with the

responsibilities that you have for your own organizations,

you can take steps to be better prepared.

The checklist that I put on our website, any plan starts with a good

checklist. You've got data migration steps that you need to

think about in the planning process and then you've got

steps that also, on the right-hand side-the image is a

little grainy and I apologize for that-but you also have

steps that are going to be occurring during the process.

The steps may or may not occur in the same order every time you run

through a plan, every time your expert is taking you

through the plan or doing the work. The steps are all going

to be there, perhaps moved around a little bit.

The important point here is you've got something available to you so

that you're not at the mercy of database experts that are

doing the move for you. You feel like you have a little bit

of power, a little bit more knowledge and better

preparation as you start going through the process.

So, we've talked about the ground rules. We've talked about the

importance of understanding the process, understanding the

plan and what are those unavoidable decisions that we're

going to run into. Let's start with the biggie-do we need a

data governance policy? By the way, what in the world is

data governance?

I'm a little self-serving here. I hope that's okay. I'm pulling a

page off of our website. We have a donor data management

dictionary with a bunch of terms that you may or may not be

familiar with or you may wonder what does that really mean.

So, data governance is simply having a set of rules or policies that

are going to tell you how you're going to manage and

maintain data quality with the assets in your organization.

So, you're talking about standards that are going to impact

compliance with third-party standards. You have regulatory

issues that you need to deal with.

What about backup and security, frequency of updates, numbers of

certain data fields that you want to keep, versions of data

fields, historical versioning of your data-there's a whole

series of data policies or standards that can be thought of

as data governance. There's no one right answer for

everybody.

These policies are going to vary from organization to organization.

What's important is that you know that you need them. So,

the answer to the question is do you really need to have

data governance policies or standards in place behavior you

start that data migration? The answer is yes.

The reason for that is because without that set of rules or

standards, doing this is going to have so many questions

that you can't answer. You're just going to interrupt the

process, interrupt the data migration and going to return

again and again to get those questions answered. You're

going to be revisiting data governance.

Your governance policies or your standards should generally cover

these areas of specialization. The purpose-what defines a

complete record? What are the processes? So, then you're

going to have to run processes, such as how do you gather,

how you input your data, how frequently do you clean it?

You're going to have storage policies. You're going to have that

second point under the storage is really important at some

point-when does a prospect stop being a prospect and just

become bad data?

You're also going to have storage policies around things like how

many instances of addresses or email addresses you keep.

How many versions of records? And then security-what are

your security policies?

Depending upon the organization, you may have third-party compliance

issues. You may have system integration issues that you

need to address in your data governance. But again, you

want to have this decision made, these standards in place

before you start your data migration. That doesn't mean

there won't be exceptions to the rule, there will be. But

let's make sure we've got some rules.

Number two-how many years of donor data do we actually migrate?

This is a great question. I have heard this question so many times.

I've been on a number of other webinars related to CRMs and

donor migration and this question inevitably comes up-how

many years of donor data do we really need?

Well, the wrong answer here is that you need to bring it all. That's

the data hoarder in all of us. We just can't let go of

something. We think we might need it. We're afraid to let

go of something that might be really important.

The correct answer-ask yourself when was the last time you actually

logged into your CRM and studied donors or their gifts or

any other related data that was more than three years old.

The odds are that doesn't happen very often. You may look

at trend reports. You may look at historical reports

.As I mentioned before, data is

degradable. People's lives change.

So, the rule of thumb that we share with our clients is start with

three years. Three years is a good amount of data to

migrate out of your old system and fit into your new

system. Beyond that, justify any older data. Justify it

with specific use cases, not because you're afraid of

losing your data.

You're sort of putting the burden on yourself to defend why you would

want to bring in that fourth or fifth year of data. What

are you going to do with it? How is it going to help you?

How is going to make your organization better or make your

fundraising more successful? So, start with three and

justify anything else.

That's two down, eight to go. Big question number three-what do we do

about our lapsed donors? Do we import them too?

Lapsed donors are treated a little bit differently organization to

organization. But generally, it's someone that used to give

to you but has not given in the past two or three years.

Most organizations that we've worked with, if someone just

hasn't given in one year, they've kind of lost them out of

the cycle, they don't really treat them as a loss or a

lapsed donor, someone that's been lost and has to come

back. But once you get a couple of years out, you've got

old data.

So, here's what I want to tell you. Here's what I want to share with

everybody. Those lapsed donors are not a data problem. It's

a communication problem. It's a fundraising problem. I

think it's really important to understand the difference.

We're not trying to solve a data problem here. So, the

correct answer is it depends.

What do you do with your lapsed donors? Option A is that you segment

your lapsed donors upon import. You identify them with a

code. You identify them as lapsed.

The purpose would be if you're using a new system-I'll put a plug in

here for Bloomerang because I really do like how Bloomerang

addresses donor retention and is going to help an

organization get at the lapsed donor problem-if you've got

a new system and you've purchased that system because you

want to take advantage of those retention-based features,

than by all means you're going to want to segment and bring

those lapsed donors into your new system.

You need a strategy. You're going to need to send out two, three,

four communications, schedule it over a period of a number

of months. You're coming up with new messaging to target

those donors. Whatever you've been doing before hasn't

worked.

You've got this group. In a database of 30,000 donors, you've got

10,000 that are lapsed. You're going to make sure that you

can segment them, go after them with new messaging and

anyone that's responding is going to stay in that CRM. But

you're going to purge the people that don't respond.

They're lapsed. They're lost.

The other option would be you don't import your lapsed donors. So,

again, this kind of gets back to your data governance too.

You set your standard. You're not going to bring over

people who have not given to you in the last three years.

But you may be able to identify those lapsed donors in your old

system and maybe you can use that old system to manage that

targeted outreach. If that's the case, before you're

bringing them in, you're going to use that old system to

run that same targeted program that I talked about just a

moment ago.

The advantage here is that you're not looking at a bunch of old data,

a bunch of bad data, which then you will have to purge once

you go through that campaign.

So, it depends upon the tools you've got. It depends upon the reason

you selected your new CRM. It depends upon how aggressively

you're going to go after those lapsed donors in some sort

of mini-campaign to identify them and get them reengaged.

But what we're trying to avoid here is bringing over a

bunch of old lost data that won't do you any good going

forward.

Number four-what about that data that we can't or we don't import?

There's going to be the chance we don't import. So, the wrong answer

is keep trying. We have gotten this message more than once

from a client that we were working with. "We've got to get

it all in there. It's got to fit. It fit in our old system.

It's not necessarily fitting in the new one. Why not? We

need all the data."

That's the wrong approach. I think you guys have figured that out

because I've been repeating myself on this point

throughout. We're talking the future, not the past.

Archives are for the past. There are simple technologies

that you can use to archive data that is not going to over

to your new system.

So, for example, let's say you're leaving Raiser's Edge and you're

coming into Neon or Bloomerang or Pacific CRM. You're

coming from the old. You're bringing it into the new. You

don't necessarily need to retain your old archive data

within your old system.

That can also be problematic. Nobody wants to go back and fire up

Raiser's Edge a year later because there was some data they

didn't think they needed but then it turns out they did.

You don't want to go to an old computer, fire up an old

system and then try to figure out what you need.

Instead, what you do is at the end of your data migration process,

whatever data that did not come across, you can have that

data put into an archive format that you can easily access

in the future should you need it. It's a great peace of

mind. You can go back to it. Odds are you won't, but maybe

you will within three months or so, but not long after

that. Hopefully the decisions around archiving in terms of

what data is not coming across, hopefully that's being

driven by those data governance policies that we talked

about.

Number five-this is a great question. We see this a lot. That's ad

hoc text fields. Those ad hoc text fields are storing a lot

of notes, a lot of data. What do you do about them? Why do

you have them?

Older CRM systems, older databases had far fewer data fields than

they do now. The systems had less flexibility. So, in the

little case on the slides-this is an exaggeration, I know-

I've got a four-field database and I've got a whole bunch

of data slammed into the notes field. This little four-

field example is the exaggeration, but all the data that

you're seeing in those notes, we've seen that times ten in

notes fields. So, what do we do about them?

So, you've got these ad hoc text fields. We know they were needed in

the old system. In the new system, hopefully you don't need

it. You're not going to need a lot of these ad hoc text

fields. Hopefully your new system-one of the reasons you're

choosing that new system is because of the breadth of data

fields that you have available to you and the flexibility

with creating a new data field that you might need that you

hadn't thought about yesterday.

You're going to save that text data. You're going to save it and

you're going to parse it later. Not now. Why do I say that?

The parsing process is the process of taking one data field

and splitting it up into two, three, four, five different

data fields. It often requires some data analysis. It

requires its own round of testing. It's something that you

will want to do after your data migration, typically.

The reason for that is it's its own project. Data parsing is its own

project. You may very well have, for example, a quote from

a consultant or a vendor to manage your data migration in

40 hours, 80 hours, 120 hours, whatever the quote is. That

quote all may be based on somebody completely missing the

fact that you've got these fields that are going to need to

be parsed and the work on parsing those fields can take up

half as much of the time that it takes for the full data

migration. It's not necessarily easy work.

So, what we're doing is we're going in as the data guy and we are

looking at those fields that need to be parsed. We're

interpreting the data that is in those fields. We are going

to export it into some additional tool. Sometimes we don't.

Excel actually has parsing capabilities in it if you didn't

know that. It's a very good tool for some very simple

parsing exercises.

So, basically, we're going to have to get that information data, get

it into the tools, run through the parsing and then we're

going to have to do another mapping. So, we're going to

have to take that data that you see in one field, map it to

three, four, five, six new fields. Then there's a whole

import process and testing process that goes around that.

So, that's why I say that parsing exercise better decide-do

that work after you get through your full data migration.

So, your result of the parse-in our four-field database example, now

we've got like ten different fields. We broke everything

apart. This is one of the ground rules I talked about

earlier if you remember. Complete. It's what you will use.

You're looking at this data, you see all this stuff stuck

into the notes field, it looks like we're going to use

everything in my example. So, a complete record now in the

new database looks like a complete database form of what we

are using. We know we will use all of this information.

Okay. Five down, five to go. Number six-when do we clean our data? Do

we do it before the data migration? Do we do it after the

data migration? Great question.

When was the last time that you cleaned your donor data? This was one

of our questions in a poll that we've done many times. We

didn't run it earlier in the poll today. But basically,

most folks don't know when it was cleaned. About a third of

them will tell us that the data has been cleaned within the

last three months and then the rest of it is just a guess.

It's long-term.

So, the answer about when you actually want to go in and clean is

really going to depend. The rule of thumb is you're going

to clean your data before you actually migrate into the new

system. You want to bring only the data across that you're

going to use. You want to bring it across in the cleanest

and easiest to manage format. You don't want to bring

problems over. You want to bring good data over.

So, what that means, if you look at the right-hand side of this

slide, what that means is we've applied our data

governance, we've done our normalization, we've de-duped

the data, we've parsed a bunch of data and after the

import, some of the data management tasks we have might be

appending the data to enrich it and add fields. After the

import, it might be to parse. But the rule of thumb is we

want to get the cleaning done up front.

However, there are going to be exceptions. I'll give you an example.

We worked with a client where the CRM database-it was a

Raiser's Edge database-co-linked with records across

multiple organizations that all had a parent organization

sitting up above them. The challenge we had was uncertainty

around record ownership. So, there were records that were

shared. There were records where we were going to have to

do additional work to figure out who owns what.

So, working with the client-we didn't make this decision on our own-

but working with the client we made the decision that we

were going to bring all of the data across. Once we got

this new database, we were going to use some of the

database tools to then help us clean that data, remove-the

customer had a little bit of a sense of urgency where they

needed to get out of the old system and get into the new.

So they were going to have a resource dedicated to purging

the records that they determined were in disposable in this

database anymore.

So, we established some guidelines. We got the data moved. The data

that came across-we did not move anything that was

corrupted. We did do duplication. But we brought a larger

mass of data across knowing that there was cleaning and

purging that still needed to occur after that engagement

was completed. We did it with the customer's knowledge and

planning where everybody was prepared to handle it that

way. That's a little bit of an exception, but it happened.

So, part of the planning process is really making sure that

everybody understands what has to be accomplished.

Now, this question comes up a lot. It often generates a sense of

stress in a data migration project. You are two, three,

four months into your migration project and you just figure

out that there's data that won't translate into the new

CRM. You thought it would. You expected that fields X, Y

and Z were all going to come across and populate correctly

and it's not happening. It's not working. Have you made the

wrong CRM choice? Is your data far worse than anybody

thought it was? What do you do now?

Well, you might feel a sense of panic because we've spent so much

time and effort on this engagement getting us to this

point. But we don't want you to panic. This is not

uncommon. This occurs more often than you would think. It

typically is going to occur after we get through not only

the analysis and the mapping that we've created, but we've

actually configured that CRM and we've started to run

processes, we've started to run test files to bring data

over and how that data is populating in the new system.

So, for example, we might be looking at a donor record on the right-

hand side and we start to see that the individual who's

represented there-we're doing our testing and we can see

only half have come across or we're missing employment

information or-I don't know, I'm picking stuff out, but

we're definitely missing information that we know should be

there. So, the new CRM either is not accepting or not

interpreting correctly the data that's coming across.

So, what do you do? You stop what you're doing. You stop the imports.

You've got to go back and you've got to start identifying

your gaps and the mistakes that are being made. So, a

project timeline may very well get interrupted at this

point. You may be in months of a process that was supposed

to only take three or four months and now you're going to

have to probably take a couple of weeks to work through

this process that's going to require a remapping. It's

going to be tedious. Nobody is going to want to do that.

You're going to have to go back and investigate your new CRM. Odds

are it's the right CRM. You don't want to change your

decision about the CRM. You just need to go look at the

database and see what kind of fields are missing, are not

configured correctly or are not accepting or interpreting

data correctly-all fixable. But this is going to take a

little bit of time. Then you're going to create new test

files. You're going to rerun your test files. Hopefully you

get through your problem in one or two iterations and then

you can begin your import process again.

But you've got to be open minded in this problem. You want your

consultant to be asking you, "Why is this problem

occurring?" This old data that we're having trouble, we

thought it would fit. We thought it would work. We thought

the new system was going to interpret it correctly but it's

not.

What's the real problem here? Is it that we do need to work on the

CRM a little more and we need to remap or are we trying to

accommodate old data? Do we really have old data in here

that really shouldn't be in the system and we've been

trying to jam it in for accommodation because the customer

kept saying they really needed it and so we tried and we

tried but it's just not working?

The CRM represents your future, right? That's your ground rule. So,

be honest and open minded when you run into this problem.

Ask yourself why this might be happening. It does occur.

It's not the end of the world. It doesn't mean that you've

made a wrong CRM decision. But you need to work the problem

and when you're working the problem, you just need to be

open with yourself.

So, number eight-this kind of gets back to an earlier question, but

it does come up enough that I thought I would break it

apart and talk about it on its own. We can't agree. We have

been trying to work through this process. Early in the

process we can't agree on what data we should keep. We

can't agree on what data we should be purging. The

communication team says this. The fundraising team says

this. The major gift people say this. Can we just bring it

over, all of it, and then decide later?

And the answer is no. Not making a decision is making a decision. To

put off that issue may very well create more problems than

you realize when you're going through the migration

process. So, if you're stuck on some standard and you're

stuck on some data governance policy or you have two

different parts of the organization that are wrestling over

what data needs to come across, you need to stop and work

through that problem. It's important.

You always can have an archive. The archive is always your piece of

mind. That's an important reminder. But you want to be

moving forward, taking control of your data, taking control

of your process and you want agreement, organizational

agreement on that data that's coming over. It's very

important.

So, if I've gotten all the blood out of that turnip, number nine-so,

we're coming up on our last two questions. Number nine-once

the migration is completed, who is responsible for data

quality?

Now, we asked about this question at the beginning of the event. It

was one of our poll questions. If you recall, as the

responses were coming in, roughly 20 percent of you have a

database manager or technology person or department that is

responsible for data quality. 45 percent of you rely upon

a consultant and then it was one or two percent

were relying on a consultant and the rest of you were not

sure.

So, the right answer is that they're all good answers. We can have

someone from a tech team or a DBA. We can use marketing or

communication or fundraising or consultants. Any of them

will work. They're all good choices.

What's important here-and organizational structures are different,

organizational sizes are different-what's important here,

though, is that you've got to have accountability,

budgeting and time management or scheduling or you're not

going to succeed.

Data quality is very different than just knowing how many records you

have, preparing 50,000 records for an email or a direct

mail campaign, thinking about your communication channels,

your multimedia communication channels and how do you reach

what segments of your marketplace, what are your trends,

what is your historical giving-data quality goes beyond

that.

So, there's a very simple-I guess I could have made this a ground

rule, maybe I will next time-there's a very simple rule of

thumb here. If your data is not getting better, it's

getting worse.

I get folks objecting to this in my talks about why am I saying that.

The data is in our system. It's zeroes and ones. It's all

sitting in there and nobody's touching it. Nobody's

changing it. So, it's got to at least be status quo, right?

Well, no. Data degrades. Donor data degrades faster than any other

type of data that an organization or a company deals with.

Donor data is basically consumer data. There are a lot of

reasons why your data can be degrading. Trust me. This is

going on. We're all on the webinar together. We're here.

Your data is degrading even now. Why?

Well, some of the reasons relate to your organization-your lack of

data entry standards or unskilled data entry workers, maybe

too many volunteers, maybe untrained people. There are

basic common mistakes. There are any number of reasons that

records can get fragmented. But your organization is acting

on your data.

Your technology is acting upon your data. You may have duplicate or

disparate systems. You may have records stored in more than

one place that are in conflict with each other. With

technology, systems are going to go through upgrades;

upgrades do not just happen magically and do not just

complete themselves 100 percent accurately.

There may be inside your organizations multiple systems that are

integrated in processing and sharing data. And then we live

in the age of big data, right? There's just the sheer

volume of data that is challenging us.

And then there's cause number three, which is probably the single

biggest reason why consumer or donor data degrades-it's us.

It's our lives. It's the fact that we change addresses. We

change jobs. We have all sorts of family events. We change

our communication. We force anyone who's trying to keep up

with us to stay in touch with us, to understand who we are.

If I'm in your donor database and you put me in there five years ago

and that record hasn't been worked on and updated and

upgraded, my life is different today than it was five years

ago. If you don't know that about me, you may be losing me

as a donor, or you at least run the risk of losing me as a

donor.

So, keep this in mind. Your data degrades. Your donor data is

degrading faster than any other data you've got in your

system-faster than your accounting, faster than your

outcome measurement, your financial data. There's a lot of

different data running around in your organization. But

your donor data is kind of falling apart naturally. Even if

an organization is not negatively impacting it, even if

your technology is spot on, at a bare minimum, you've got

us as your problem. It's the fact that our lives change.

So, when it comes to maintaining that big three, it's what really

matters. Accountability-you've got to have somebody

responsible; clear lines of responsibility for maintaining

your data quality. Budget-if you don't have a budget in

your organization for maintaining your data quality, you're

going to be at a disadvantage. And then schedule-this is a

challenge that I run into with lots of organizations.

Yeah. I know. The "Big Three" up top is no more. It's very

referential, though, isn't it? Some people look at

Roosevelt, Stalin and Churchill and they may or may not

recognize everybody right away. Chrysler is actually owned

by a foreign company. But these are the big three. I

started to put up ABC, NBC and CBS, but I figured no.

Anyway. Sorry. Thanks, Lauren.

Schedule-very often we don't understand the importance of separating

our data management schedule from our fundraising, our

communication schedule. We may have three or four or ten

different communication deadlines throughout the course of

a year. That may cause you from time to time to say, "Oh my

gosh, we had all of these returned envelopes or we've got

all of these emails that are being bounced and it looks

like they're turning into spam, what do we do?"

"Well, go get the junior, the new guy. I think he knows something

about computers. Get him and have him take a look at it and

see if he can clean up some of these old records or look at

these bad addresses. Go find somebody who can validate

postal addresses for us. Maybe we need to go append our

data."

Whatever the action is, the action is created reactively. The action

to improve the quality of your data is being driven by

something else. That something else is a communication

deadline, fundraising deadline or, even worse,

that's gettinginto your organization as a result

of bad data.

You've got to put your data up for schedule. You've got to think

about how frequently you want to update it, upgrade it,

clean it and keep it fresh and current so that the

fundraising and the marketing team can access it any time

they want. They're not waiting on somebody to reactively

clean up the problem. Really, really important.

Number ten-do we need a data consultant? Can we just rely on our new

vendor to get that work done? Can we do it with an in-house

resource?

So, this is kind of a self-serving part of the presentation, I know.

I believe you do need a data consultant. That's part of why

I'm in this business. You may have in-house staffing that

can do this work if they've got the time and that's great.

But you need somebody who can do more than just upload a file into a

new CRM system. You've got to have trained resources that

know how to extract the legacy data. That's easier in some

systems, more difficult in others.

There's cleaning and organization and purging that needs to occur.

You need to actually create import files for the new CRM.

Getting extraction files out of your old system-that

doesn't mean that data is ready to go into the new. There's

a lot of work that has to happen on that system. Even once

you've completed your migration, you still have archives

and other issues that need to be addressed.

So, remember that technical process that I showed you earlier and I

was talking about how six steps really look like 14 or 15?

Well, in this case, I've put up these big red circles to

point out that you have a resource assigned to perform

those additional tasks.

It's important to plan for it. Your CRM vendor-and I can't speak for

all of them-odds are that your CRM vendor wants to receive

a clean data file, they want to import that clean file and

get their work done as quickly as possible.

If we go back, odds are the CRM vendor does not want to be cleaning

and parsing, does not want to extract data out of that old

Raiser's Edge or Access database or Gift Pro or some of the

others than can be really difficult to work with. Odds are

they may not want to create the import file. They want data

brought to them so that they can run the import.

And then once you're done with that data migration, that vendor

resource is not going to be there to help you do things

like manage your archive files and make sure that you have

everything buttoned up at the end of the process that you

really need.

So, data migration require a plan. That's your ground rule reminder.

You really want to make sure that you know who is

performing all of these tasks before you're done.

So, what's the outcome? What do we want? What's the desired outcome

of making these decisions? You're going to run into them.

What do we want to get? What do we want to accomplish?

Well, hopefully, we are future-focused and we're ready to go once we

have completed our data migration and our new CRM is up and

running. Hopefully, our data is clean. We are no longer

wasting money. Many per-record systems-

if you're sitting there with an extra 10,000 data records

that are not really used or they're bad or they haven't

gotten around to cleaning them up, you're paying for it.

No wasted time due to bad data clogging up systems. I can't tell you

how many times we've talked to a client where they've said,

"Yeah, our system has 50,000 records. But what we really do

is we run an export and then we trim out about 22,000 that

we know are bad and then we study it looking for bad fields

and then we cut those out and then we have a file that we

can work with where we can go run our campaign." You're

wasting a lot of time.

At the end of the day, you want to improve your relationships and

improve your fundraising results. And you've got to

remember, even with that brand new CRM, garbage in is

garbage out.

So, I hope we've hit some takeaways today and accomplished some

things that we've set out to accomplish with you. I want to

make sure that everyone understands the CRM migration

process. We want to make sure that we've identified those

key things along the way that you're going to run into so

that you're prepared.

We want you to understand what your options are and how to make those

touch decisions. It doesn't mean that everybody on the call

is going to make the same decisions tomorrow as a result of

this presentation, but hopefully you're all feeling better

prepared to make those decisions and you have a greater

sense of control over that next data migration process.

Steve, this is where we're starting to wrap up here right here at the

end. But this is what we do. We run data basics like

assessments and hygiene and management. We do the migration

and integration, security work and we can handle some of

the advanced tasks around warehousing and mining and

details integration. So, we're here to help. This is what

we do. We're the geeks that enjoy this type of work.

I really want to thank everybody here for extending your time. It's

very much appreciated. I want to thank Bloomerang for

hosting this event. It's great to be here on the Bloomerang

channel and have an opportunity to chat about this.

Steve, I think we've got some questions. I'm going to turn it over to

you and thanks.

Steven Shattuck: Yeah. Thanks, Gary. That was a lot of great

information. Thanks to everyone who was following along and

chatting away with us and sharing links. I always

appreciate that.

We've probably got maybe three or four minutes for questions. It

looks like we've got one here from Marylee. Gary, Marylee

is wondering, "In addition to moving data, should we also

plan on moving processes?" It seems like a donor migration

project is a good time to reevaluate all of your processes

in general, don't you think?

Gary Carr: I do. I think that's a great question. I think it sort of ties

into the data governance. Data governance will lead you to

some process questions. I think the next time I do this

webinar, I'm actually going to bring that up because I

think those are very much related. So, yeah, take time in

the planning steps of your data migration to ask those

questions and see if you can get leadership on board to

address changing some of those processes.

Steven Shattuck: Cool. And it looks like somebody was about to type,

but while we're waiting for some more questions, I just

want to let everyone know that we do these webinars once a

week. We do them every Thursday. We've got some cool

webinars coming up. They're always free. They're always

educational.

One week from today, actually, we're going to be talking about silent

auction items at your next fundraising event. We've got an

expert on auctions who is going to be sharing some of her

tips.

So, check that out. Check out our webinar page. There are lots of

webinars scheduled through the fall. You can look at all

the different topics and maybe find something that you're

interested in there and do register for those.

So, Gary, it looks like we're probably actually about out of time and

I want to give you time at the end to talk about how folks

can get in touch with you. I know that maybe some people

might have questions and you said you'd be willing to

answer them via email. So, how can people get in touch with

you?

Gary Carr: Sure. My email is on the screen there. It's

GCarr@ThirdSectorLabs.com. Please feel free to shoot me an

email. If folks want to call me, my phone number is

(571)242-2313. Go ahead.

Steven Shattuck: Do reach out. Third Sector does really great work.

They've also got a great blog that you can check out. I

think you guys have a newsletter too. So, I would

definitely check out those things if you're interested in

more data tips.

Gary Carr: We do. I appreciate you mentioning that, Steve. We do run a

pretty active blog. Also, if you follow us on Twitter,

we'll toss interesting observations and tips for the day,

things like that will come out of our Twitter account. In

our blogs and our Twitter account, one of the things that

we're trying to do is to bring best practices-make people

aware of best practices from the commercial world that we

think need to be part of data management best practices in

the nonprofit world.

So, you will see us straddle that fence and talk about, "This is

what's happening in the commercial world, we need to think

about doing this more or differently in the nonprofit

world." So, I appreciate that and helping me to plug those.

Thank you.

Steven Shattuck: Yeah. It is really good content. Gary actually

writes for our blog occasionally too. So, if you check out

the Bloomerang blog, you might see some articles from Gary

there as well.

Well, it's about 2:00. I want to leave it there. I don't want to keep

anyone any longer, especially if they haven't eaten lunch.

So, Gary, thanks so much for being here for about an hour

or so and sharing all your knowledge.

Gary Carr: I appreciate it. Steve, will be sending out the presentation to

everybody?

Steven Shattuck: Yeah. I'm going to send out the recording and the

slides here in probably about an hour or so. That's usually

about how long it takes to upload it to YouTube. So,

everyone look for an email from me later on this afternoon.

We'll share all this good information with you. Do check

out our upcoming webinars. We hope to see you next week or

sometime soon. So, have a great rest of your day and a good

weekend if we don't talk to you. Bye now.