I read some of the comments in this thread and thought I'd add something
from a developer/consultant's perspective. This is not ebase specific, and
they're just comments.
The primary issue for most non-profits I've done database work with hasn't
been with initial install, customization, or training, so much as knowledge
retention as staffers move on. Because of the limited amount of funds a
non-profit can throw at human resources, and because of heavy reliance on
interns and volunteers, employee turnover will often be higher at
non-profits than at for-profit ventures.
This produces a cost overrun in terms of continued reliance on consultants
(me) to provide training to new employees - and it can get more expensive
when the only one who knew how to restart the server, for example, moves on
and you have to call me up to figure out how to do it.
I've found that especially in older organizations, even large ones with 30+
employees, there's heavy resistance to hiring a dedicated technology
administrator on staff. While in budgetary terms I am cheaper (you might
spend 4K a year on me versus 30K), organizational efficiency suffers. I
find, when an organization finally brings me back to train new people, that
existing employees have had three month old problems and they didn't know
whom to address them to. In terms of hidden costs, you may not be able to
put a dollar figure on the inability of a user to print labels for two
months because she didn't know where the user manual was or that there even
was one - but it's expensive - especially in terms of meeting organizational
missions.
So there are two things you want to avoid because they're both costly:
1. calling me or someone like me
2. letting users drift away from that database you so expensively deployed
just because no one's around to get them through the little hurdles
Given this my recommendation for people who are considering the
implementation of a database system is to include in your plan a methodology
for knowledge retention that goes further than having the ebase manual on
the shelf and a consultant's phone number. Identify which core
functionalities are essential for your practice, assign an employee the task
of maintaining these functionalities. Write up working documents that
explain the role and duties of the employee in charge of the database (even
if that employee has other duties) so that when that employee moves on you
have an identifiable set of duties to pass on to a new employee and those
tasks don't get left undone for months.
It's critical that you *always always always* have someone who has primary
responsibility for the database. Leaving a database alone for three months
lets users - especially those users less computer savvy than you - turn from
it when they can't figure things out (and have no one to ask) and start
storing contacts in Outlook, Now Contact, Palm Desktop, Word Documents,
Filofaxes and stacks of business cards wrapped in rubber bands - all over
again. Someone should always have an "expert user hat" that they can slip
on when necessary.
This expert user hat chould have the following responsibilities, but it'll
depend on your organization:
1. user training
2. server maintenance (checking backups are written etc)
3. minor interface changes
4. data entry rule maintenance (ensuring users check for dupes etc)
5. primary contact for ebase consultant, hardware consultant
6. database advocacy (constantly steering users away from their excel
spreadsheets and toward ebase)
Colin
------------------
Reminder to each recipient: To change your list account preferences, go to
http://email.sparklist.com/scripts/lyris.pl?enter=support and enter the email address
you used to subscribe to the ebase support list:: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
---------------------------------------------------------------------
ebase - Relationship Management for Nonprofits, http://www.ebase.org
---------------------------------------------------------------------
