[jburkett]

We are implementing and building Raiser's Edge for the use of 12 different departments. What are your best strategies for bringing in all of the departments?

Initially, in our first phase, we will start with users and databases in three departments but after that I'm debating how to bring in the rest to Raiser's Edge during the next phase. Some organizations do it one department at a time. For each department I'll need to manage data clean-up/ import and training users while managing and administering to the newbies from phase one. Any other successful options?

The databases from different departments have some duplicate data (who doesn't). So it may be easiest to bring in departments which have the most similar data to the phase 1 folks. Each department is also a little different and has a different level of use of Raiser's Edge. Thoughts?

[RobertWild]

First thought is: Good luck, and may God have mercy on your soul.

Second thought: Prioritise the databases. And then some. How you do this is largely up to your userbase, however I'd probably start with the largest/most complex, and move through the list. Generally you will run into 1 main problem with this - either the departments want to merge in, in which case everyone will think that their system is #1 priority, or else nobody will want in, in which case you will have significant problems even getting decent specs.

Probably the biggest piece of advice, having done something similar for less departments - is to a) find out what each and every flag is for in each and every system that you are about to fold into RE (you may be able to combine different flags from different departments into the one attribute table for instance), and b) map everything out before anything is imported.

It will save a bucketload of time later on.

You will have problems with duplications. Everyone does. Even with CEO's records, where one department mails to the office, the other mails to the home, and of course, neither record is flagged as a CEO.

Maintain working backups of each database you are about to fold into RE for a while after integration. There's always that one little flag somewhere nobody told you about that has turned out to be mission-critical to the organsiation.

Invest in a good stress reliever. It pays off later.

[EduardoG]

We're currently undergoing a very similar task, but we're using the same database for all involved, with pretty strict security settings for each new group of people. Probably the most important thing we've done is begun creating defaults for pretty much everybody who'll be using RE, meaning that it is as simple as loading the correct default to get what you're trying to do.

We're also using actions every time a user wants to delete a record or change important aspects of the records, as we can't always trust they understand what we want to keep and why.

Hope this helps! Good luck.

[paulmorriss]

Procedures.
Procedures.
Procedures.

It keeps data entry the same across departments.

[DavidZ]

I would also say that it is better to avoid duplicates before they get into RE rather than trying to fix them once they are in RE.

The ID lookup utility helps with this process.

David

[nisaac]

Speaking from the user perspective, rolling out an application to varied groups of people is daunting. In my opinion first there has to be a gathering of information/work flow. Understanding how each department currently completes their daily tasks will help map out the workflow for each department. Creating a security model will help you understand what rights different people will have and what training they will need.

I don't know the size of your organization. In our organization, we were able to limit the number of people who would be changing data initially. From there, we were able to "hand out" security rights depending on job responsibilities. We are tight handed with rights.

My best tool is the champion. For each department, it helps if you can have a champion or early adopter. This person helps formulate the workflow, understands the data at the department level, works with the database first and acts as a resource for the department.

It's an exciting project. Good luck!