Road to CA

Today is the start of Cohort F! And what better way to celebrate than with cake?

Stop by Murray Hall after 1 pm today, when we'll have a cake available to mark the official beginning of our Colleague Advancement implementation. While you're there, Todd can show you the reams and reams of paper we've gone through so far during the LBPM person-matching preprocess.

CA or Bust!

Datatel recommends that we run through the conversion process three times before we do our live conversion - and we're just about ready to start our first conversion test!

Up to this point things have gone smoothly. We've had very few errors when running the pre-processes, unlike many other schools we've heard from. Todd and her crew have been able to clear up the few errors we did encounter, so we're heading into the first conversion test in really good shape.

This weekend we'll be re-creating our conversion environment so that it can be updated with all the work we've done with the translation tables. Assuming all goes well with that, we'll run our first conversion processes - Person and Corporation Demographics - on Monday.

Wish us luck!

Over the weekend Pete created a new clone of production for our conversion environment and this morning we ran our first test conversions. We were very pleased with the low number of errors we got at the validation stage. At this point we've completed M1, M2, and M3 conversions, all related to funds and recognition, and we've run L1 and L2, Person and Corp conversions, in validation mode. We ran L2 in Test Update mode, and just got two errors. That number may change when we have more of our Corps mapped to Colleague records.

After Thanksgiving we'll run L1 in Test Update mode and then we'll really have a better idea where we stand.

Todd and her team deserve a lot of credit for the low number of errors we've seen so far. The work everyone has done over the years to keep the data on Benefactor so clean is really paying off!

We've had a very busy time over here in CA Conversion world lately! Here's the short version of what we've been up to:

• Contribuiton Management at Datatel in VA went very well. Todd learned that several delivered reports will replace custom reports currently used in Benefactor. I liked hearing that!


• Anita Lynn from Datatel spent two days on campus helping us work out best practices for constituent and contribution management, and then create Allegheny-specific documentation for these areas. While she was here she also requested a meeting with the Business Office, so that we could begin to discuss with them some of the changes that CA will bring.


• We're working through the alphabet soup of conversions. The official first test conversion started with L1, and we are aiming to complete N4 very soon. In most cases we are still receiving relatively low numbers of errors - and in some cases no errors. Our N2 (Employment) conversion has produced the highest number of significant errors and we're currently examining those closely to determine how best to resolve them.

We are still aiming for a live conversion window of July 15 - August 15, 2009. So far, nothing in our first test conversion indicates we'll have any trouble meeting that goal.

I've often thought that I've missed my calling. I should have been a Quality Analyst for software companies. If there's a bug in software, I always find it....whether I'm looking for it or not!

During our N1 (Other Addresses) and N2 (Employment) conversions we noticed that the conversion process had created duplicate addresses in a certain situation. We were able to offer Datatel a scenario where everything was set up properly on Benefactor, but where we ended up with the same address being created twice in Colleague. They have acknowledged that this is a bug - one they discovered a few weeks before we brought it to their attention - and that a fix for it is coming in the January CA software update.

That's good news. It means we can ignore the 5000+ address ambiguities we got with the N1 and N2 conversions - at least for now. In the second conversion test we'll probably still get some address ambiguities, but we'll deal with those then.

Otherwise the conversions are still going well, with small numbers of errors. We're getting very good at sifting through the reports and figuring out what needs to be done to make an error go away. And we're starting to keep notes on each type of error we get and how we handle it - which should save time when we run the second conversion.

We are nearly finished with our first test conversion. Things have gone pretty smoothly, with most conversions giving a manageable number of errors.

Todd and her team have been fixing these errors as we go along. Once that work is complete we'll start with fresh copies of our cleaned up Benefactor and Colleague data and move on to the second test. That should go more quickly, as we expect to see even fewer errors this time around.

One big feature we'll gain in the conversion to CA is Rules. Rules let you use criteria to determine whether or not a certain action will apply. For instance, you can set a rule to determine whether a pledge should post to the GL. During our Constituent and Contribution training we've seen a number of places where rules can apply. I know we'll see even more in our Communications Management training next month.

Just last week Todd and I experimented with CA rules for the first time. We developed, and then refined, a rule that would post a pledge to the GL if it wasn't a current year Annual Fund pledge. The rule would cause a Y or N to default into the "Post to GL" box on the new pledge screen, but would not overwrite a manually entered value in that box. Perfect!

This weekend we are officially closing the door on Conversion Test #1!

We ran the last of our conversions 17 days ago, and since then have been running post-conversion processes and evaluating the data that converted over. In doing so we have found some areas that need more work - like duplicate addresses - and some areas where we need to tweak our conversion settings - like recognition history. We've also found a few possible bugs and have passed that information along to Datatel. (I really do find more than my share of software bugs - or maybe they find me!)

In the past week we've refreshed the data in bentest and prepared bentest for the second conversion - running pre-processes, setting up L1 groups, etc.

This weekend we are going to wipe the slate clean and create a fresh clone of production for our second conversion environment. We've been doing cleanup in production and benlive as we've worked through the first conversion, and so expect to find many fewer errors this time around.

For those of you who are curious, our first conversion test took 3 days, 20 hours, 22 minutes and 57 seconds to run all of the conversion validations, test updates, and updates. We expect the second conversion to go more quickly, because we don't expect to be running the validation stage multiple times as we did first time around. Our goal is to fly through conversion #2 and then keep this environment around for training and testing. Wish us luck!

Okay, so I know I never told you we had started the second conversion. It's been a busy month.

But here we are, with the second conversion nearly complete! It started out more slowly than we had hoped, with a whole lot of address ambiguities at L1 - far more than we got in the first conversion, despite the huge number of duplicate addresses we had removed from Colleague prior to the clone of the conversion environment.

Once we got a handle on the address problems the rest went fairly smoothly. The exception is N2 - Employment - and we are waiting to hear from Rachna about why we have over 6000 start/end date errors when we didn't get these in the first conversion.

After much discussion, a final date for conversion has been set. We will begin at 5 pm Thursday August 6th and be up and running by 8 am Tuesday August 11th.

Benefactor will go down at noon Thursday August 6th, so that we can run the pre-processes that need to be run before starting the conversions.

The following weekend will be a backup weekend, though we don't expect we'll need to use it.

With the second conversion completed, it's a good time to grab a breath and consider our next steps. Here are some of the things on our short-term to-do list.

• Fix errors found in the second conversion. We don't have too much to do here. Most conversions had a small number of errors and we were able to fix them as we went along. Exceptions are N4 (relations) and L1 (address ambiguities). These will take a little more time to fix, but we'd like them done before Conversion 3.
• Work on Report Writing. Todd and I started this towards the end of the first conversion, but then had to put this aside when we wiped out the first conversion environment, leaving us no data for testing our reports. Now that we have data in CA again, we are back at work on this. Our goal is to have at least a few tricky reports and computed columns identified before our pre-DUG Advanced Computed Columns workshop.
• Plan for Conversions 3 and 4. That's right, we expect 4 conversions. The third will start as soon as we have the errors identified in conversion 2 fixed, and the fourth will be about a month before our live date. The third will be to verify that we have fixed all the errors, and the fourth will be to simulate the live conversion - only during the week instead of on a weekend!

We've been very busy since our last few posts. Here's some of what we've been up to:

• Conferences and Training
Todd, Matt and I - along with 8 others from Allegheny - attended DUG 2009 in the DC area earlier this month. Just ahead of that, Todd and I took the Advanced Computed Columns class at Datatel. Both were well worth the time and effort. We got to trade war stories with other converting clients, and picked up a computed column trick or two that could come in handy. A high point of DUG was finally meeting Rachna, our conversion consultant!

• More Training and Consulting
Last week we had two full days of Communications Management on campus, with Amy Houy from Datatel. It was a very productive session, though Amy left us with lots of homework - computed columns and hard copy documents to create. She gave us a spreadsheet with all the details of what we need for each document, which is very helpful. Two days after that we had our Acitivies and Events webinar. Todd was pleased to see that it's very similar to what she's been using in Benefactor, only better.

• Data Cleanup
While we didn't encounter many errors to be fixed in the second conversion, we did find a need for some data cleanup, especially addresses. Our computed columns for fixing address ambiguities worked to get our records converted, but didn't always give us the end results we wanted. We identified some records that could be easily cleaned up and have been working on that for a while.

• Testing the Second Conversion
Todd has been simultaneously working on reports for CA and testing the second conversion by comparing report results from CA to those from Benefactor. She's been very happy to see the financial reports matching to the penny in most cases! In the few instances where they don't match she can trace the issue to a handful of transactions that didn't convert - but will convert next time around.

With data cleanup progressing nicely, we've picked a date to begin our third conversion test. We will start on May 6 and hope to be finished in a week or so.

Our number one goal for conversion 3 is to bring every bit of Benefactor data over. "No record left behind" is our new motto! This means that any errors encountered will need to be fixed in bentest as well as in benlive, and possibly also in production and the conversion environment. We don't expect to receive many errors, but if we do this could slow us down some.

Our second goal is to bring the demographic data over properly. Some of the addresses - particularly the N1 (Other Addresses) - came over in conversion 2, but not the way we had planned. This was due to our solution for address ambiguities. We've been studying the converted data and re-evaluating our method of dealing with address ambiguities at L1, N1, and N2. Combined with this work and the data cleanup we've been doing we expect both fewer address ambiguities and better results from our computed columns in the third conversion.

And our final goal is to develop a plan for running the live conversion. We won't run it as a mimic of the live conversion - that is, we won't be doing it over a weekend on a quiet system, working through nights - but we will try to determine the best way to split up the conversions for maximum efficiency.

Everything is in place to begin Conversion #3 on Wednesday. Over the weekend Pete created a new conversion environment, leaving the conversion 2 environment around so that we can continue testing, training, and report writing there. Also over the weekend, we refreshed the data in bentest.

Today all the pre-processes were completed - doing any file manipulations we've learned are needed to get some old records to convert, creating all the BENCA files in the new bentest, and setting up the L1 groups.

While we aren't running this conversion as a mimic of live, we are using it to help us figure out timings and division of labor for the fourth - and thus, live - conversion. Todd is going to move her computer into my office for this run to reduce the time we spend wearing out the carpet between our offices and aid communication. If you happen to pass by Murray 105 in the next week or so, don't be surprised to see Todd and I feverishly running conversions with a stopwatch running in the background!

Conversion 3 was completed in 4 working days, plus about a half day to run post-conversion processes. We had expected it to take about a week, so it looks like we are right on track.

Our goal for this conversion was to convert all valid data, and that goal was met. We were somewhat surprised by the number of errors that we encountered along the way - some errors that we had seen before but hadn't been fixed, but most new errors since the last conversion two months ago. We fixed these errors as we were converting, in order to meet our goal of leaving no data behind, which slowed us down a bit.

For the July test conversion and also the August live conversion, we plan to run a mini-conversion a week or two ahead of conversion, in order to find these errors and get them fixed when we aren't under pressure to get the conversion completely quickly.

Our computed columns for solving address ambiguities worked well in this conversion. For N1 (Other addresses) the modification to the computed columns that would map former addresses to former addresses and current to current worked better than expected. We were able to resolve all but 115 addresses at N1 with this technique.

We've completed three conversions and all of our Datatel-led training. So what's left to do in the 2-1/2 months between now and live conversion? Plenty! Here are some of the things we're working on now, or about to start.

• Reporting. Datatel delivers many good custom reports in CA, which we will be using. Todd has been identifying the reports we will still need to write, and prioritizing these. Our goal is to have the drop-dead reports ready to go on August 11th, and work on reports that aren't needed until later in the year after conversion is completed.
• Writing Computed Columns. To support these reports, many computed columns need to be written. Todd already has a start on that, but there's lots more to be done.
• Communications. We are beginning to create the documents needed for communications - receipts, acknowledgements, etc. A list was created of what we needed when Amy Huoy from Datatel was here last month, but the documents themselves still need to be created.
• Security. Security classes need to be defined and set up so that end users can access the parts of CA they need.
• Reviewing the Converted Data. We have reviewed much of the data that was brought over to CA in the test conversions. But we need the people who work with the data every day to get in there and take a look, too. If there are problems, they are the ones most likely to find them. Once found, we can address the issue before the next conversion, to avoid problems in the final product.
• End User Training. We are using the second conversion environment for training and testing. Some of this has begun, with more on the horizon.
• Data Cleanup. This is an ongoing process. While we have a good handle on dealing with address ambiguities, we'd rather not encounter them at all. While it may not be realistic to think we can eliminate all of them, we are using quiet moments to do as much clean up as we can. Every little bit helps!

We are making good progress on our to-do list highlighted in our last post. Todd and I are whipping through the computed columns and subroutines needed for reports and downloads, while Matt is working on creating and testing the documents needed for acknowledgments, receipts, etc. In "quiet" moments, we're all working on data cleanup and testing the converted data.

Last week I took a break from computed columns to run a mini-conversion. I focused on just the conversions which still reported a number of errors in conversion 3, and on making sure we had solutions for all of those errors.

This should put us in good shape for conversion 4, which begins June 29th and is going to be our mimic of live conversion. Todd and I will be working through the night to get everything converted properly in the equivalent of a long weekend. We'll let you know how that goes!

This week Todd and I are running our mimic of live conversion. Beginning on noon Monday we will run the pre-processes, the conversions, and the post-processes in the same time frame we will be running the live conversion. For those interested, our plan for this week is attached.

Wish us luck!

Conversion 4 Plan