5 Tips For Keeping your Database Healthy Post Launch
By: Larry Bednar, CRM Consultant
The configuration is complete, the developer dust has settled, and your organization has a brand new database that you can’t wait to take for a spin. As we all know, with great power comes great responsibility, and the maintenance of your database’s health and functionality now rests solely in your hands. Here are five tips for protecting your investment, maintaining the performance of your new platform, and keeping your users upbeat and onboard post-launch.
1. Place system usage guidelines and documentation in a readily available location
Make sure all users are aware of these materials and their location. You can double-check this process by sending an email with the location of the process/policy linked in-line.
2. Grant new users adequate time for familiarizing themselves with features and best practices before requiring them to complete tasks within the database
Have an on-staff trainer that has adequate time to bring new users into a good usage pattern. Going over the system visually, verbally, and then in a guided hands-on training helps reinforce new concepts and patterns. This can’t be learned overnight, and rushing the process will only lead to mistakes. Users working in a system with inadequate training often develop improvisational practices instead of using database features that are already specifically designed for the same need.
3. Rely on a small number of system administrators
Salesforce recommends these ratios of users to administrators:
1 – 30 users < 1 full-time administrator
31 – 74 users 1+ full-time administrator
75 – 149 users 1 senior administrator; 1 junior administrator
140 – 499 users 1 business analyst, 2–4 administrators
500 – 750 users 1–2 business analysts, 2–4 administrators
> 750 users Depends on a variety of factors
This ensures that an application of consistent system standards are realized.
4. Use one field for one purpose, and choose field/table/object names that are evocative of the data held in the field. Similarly, avoid using more than one field to store similar types of information, especially if those fields are in different database locations
Names that reflect their content are more resilient over time. Eliminate guesswork by naming fields clearly and specifically. Keep the next generation of users in mind and make it as easy as possible for them to match future data to the current usage. This shields databases from the following mistakes that occur when the proper use is not clear or is not enforced:
Users may re-purpose fields that are actually designed for other purposes (Administrators may create new fields to store data that is already provided for in parts of the system they are unfamiliar with)
Users may use existing fields they are familiar with for additional ‘secret’ purposes that are not obvious by reference to field names (If this field value starts with an 'x', that means 'do not mail')
Naming has a big impact on long-term ease of use, and can reduce these number of mixups. Here are some specific data types that are prone to this particular problem:
Email address fields: Do not place website addresses, social media account names, or multiple values in these fields. Reports that are used for instance to provide email addresses for mailing will not work properly if these fields contain anything other than a single email address and nothing else.
Phone address fields: Do not place multiple values or notes about usage in these fields. No values like "503-232-1111 (joe work, 9AM-6PM)".
Website address fields: Use only for website addresses, not for Twitter/Facebook account names, etc.
"Profession", "Occupation", "Title" fields: Make sure your users have a clear understanding of the differences between these fields and a good understanding of what information should go in each. Be sure to monitor these types of fields for proper uses. Do not put multiple values, notes or remarks, or different types of data in these fields.
5. Never believe an assurance that a rough-edged improvisation will only be used for a short period of time
If you think you’re incorporating a quick fix that you’ll quit using and clean up after this project or that campaign, you’d better think again. Almost every revision made to a database ends up living in that system for a long time, so think about the long-term impacts. Even a minor change can have substantial and long lasting impacts.
A Cautionary Tale
Once poor data storage is established within a system, users often develop an immovable belief that the system is junk. This sentiment becomes very strong as everyone on staff reinforces the mindset whenever they come up against reports that no longer work, data errors, or confusing fields. Sometimes this emotional mindset is so entrenched that users cannot be convinced that the current system is perfectly adequate for their needs. Even if a consulting firm comes in to help train users or offer tech support, the bias against the system as a whole will overshadow any effort to remedy the situation.
I've several times been hired by groups with this mindset, and went on to discover that their database functions well, and initially provided well-designed alternatives to poor data storage. The organization’s data storage and usage practices corrupted the system and confused the users. Once again, this stems from:
Poor user training
Misplaced or "forgotten" system documentation
Users who are in a rush to get work done before receiving proper training and/or before reviewing available system documentation thoroughly.
Do your best to avoid internal errors that will make you lose faith in your new database. Once poor practices have been established, transitioning to better systems might require costly data transformations, even if the same database will be used after the correction.
The Good News
I've had several clients who use their database systems successfully for long periods of time, and it’s not by accident. By following these principles, organizations can employ the time and energy of their staff to serve their core mission rather than on repeated system transitions. It can be done!
Do you have questions about maintaining your new database, or worry that you might not be utilizing best practices for database maintenance in your organization?