Choosing a new database

©Dale Jennings Associates December 2012
Getting a New Database
A primer for charities
These slides are a non-technical overview about what getting a new database involves. They
are intended to start charity leaders thinking practically and realistically and are NOT sufficient
to use as a workbook or checklist. The slides are adapted from our one day training course
with exercises removed.

One Day Course Content
(not all of it in this slide set)
• The non-technical essentials about
databases
– Why not spread sheets?
– The database ecosystem – what else
your database needs in order to thrive
– The different types of database: CRMs,
client management systems, donor
management, etc.
– The money saving myths
– Your responsibilities
– Who needs to do what
– What a vendor can and really can’t do
for you
– Leading by example when technology
isn’t your thing
• How to define your requirements
– What do you / should you collect and
count?
– Core processes & long term habits
– The essential hidden extras
– Developing key selection criteria
• Important considerations
– Open source or commercial software?
– Which versions of Microsoft Windows
and Office?
– Will it run on your computers?
– Should you go to the cloud?
– Going mobile
– Links to social media
– Security and privacy
– What you can expect to pay
• Course Exercises (for your situation)
using templates you can keep
– Identifying stakeholders and relevant
mapping for your situation
– What do you need to count?
– Do you have technical constraints?
– Capability building
– Q&A
– Identifying next steps

The problem with spread sheets
(that a database can reduce or avoid entirely)
• Security
– Files can be copied and deleted easily; even
accidentally
– Multiple copies and the versions
– Tendency for spread sheet to become the “personal
property” of individual staff members
• Manual processes
– Staff must cut, paste and operate on data in a way that
must introduce errors
– Easy to overwrite cells with no warning or indication it
happened
– Limited data validation capability
– Time spent “checking” data is correct or complete.
– Someone must remember to update tracking; no
automatic updates
– Handcrafted reports
• No audit trail or alerts
– Who did what? When?
– How long has a status been current?
– Limited historical view
– No automatic indication of overdue events

Your “Database Ecosystem”
(at home OR in “the cloud”)
Internet
SOFTWARE
Personal
Devices
Processes
Data
Reports
People
Security
Governance
Servers
Storage

EVERY Database does much the Same Thing
What do your people, clients etc. collect?
Why do you need it?
What will you do with it?
STORE
PROTECT
ORGANISE
PROCESS
Data IN
Information
OUT

Database = Organisation’s Kitchen
GROCERIES
client details,
case notes, etc.
MEALS
reports,
trends, invoices
KITCHEN
database

Database Variations
• Specialist databases “dress up”
the basics.
• Search types
– Indexed: by fields
– Semantic: match language
(Google)
NB: Basic technology should
thrive in your ecosystem

Money Saving Myths
(finding your balance point)
Potential Reductions Potential additions
• Extra tasks needed to
support database
– user administration
– data and process alignment
• Increased IT costs
• Less people/effort needed
to do day to day work
– May do more with same
– Or do same with less
• Reduce or remove
“checking” and sig off
activities.

Responsibilities
• You always retain
responsibility for
– Legal compliance
– Performance management
– Defining operational
requirements
– Managing the data in your
systems
– Ensuring systems are fit for
purpose
– Training system users
– Business continuity planning
and provision

Vendors CANNOT
• Choose a technology
they don’t sell
• Recommend someone
else’s product
• Be more expert in your
work than you are
• Mange the project to
your priorities
• Manage your staff &
volunteers

Leading Technology Change By Example
(when technology isn’t your thing)
• Be Genuine
• Get training, coaching or
mentoring
• Accept and plan for the
cost
• Get expert advice at
critical stages / tasks
– Defining requirements
– Reviewing proposals
– Testing
– Initial alignment

Role of IT
Cost
Of
IT
Supports
basic comms
and data
AND
Supports
critical
business
PROCESSES
AND
Supports
critical
business
DECSIONS
AND
IT is part of
the product
or service
AND
IT is the
product or
service
$
$6%
?
3%
A Thought about Budgets

Process for Successful New Databases
(Easy huh?)
Understand what you want and why you want it
Know what it is worth
Understand the challenges
Try before you buy What will it really cost?
Do we have the resources?
How will fill the gaps?
 Design for usability: make the system do the
work not your staff.
 Manage the project tightly BUT allow enough
alignment, testing and training time.

Developing from scratch
• DON’T do it !
– Unless there really is no alternative OR
– You have lots and lots of spare money
• There are literally thousands of CRM’s, project
tools etc. “off the shelf”. See
http://www.getapp.com/
• There are specialist databases for social services,
health and community etc.

How the customer
described it.
How the project
leader understood it.
How the analyst
designed it.
How the
programmer wrote it
How the consultant
reported it
How the developer
documented it
How the technician
installed it.
How the accountant
billed it
How the supplier
supported it
What the Customer
REALLY needed

What do you want?
1.To meet strategic goals
2.Operational needs
3. Eco-system constraints
4. Financial constraints
5. Time scales
6. Digital Literacy

Database Requirements: Perspectives
• Client(s) Journey
• Stakeholders
– in the client journey
– On their own journeys
• Compliance & Funder
needs
• Appropriate Technology
• Dataflow
Read this story in the notes.

Database Perspectives: Data flow
Whatever dominates your cash flow should
dominate your data flow
• What are you paid to do?
• This may NOT be the same as your mission
• What do you spend most of your time, energy, and
resources doing?
• Fee for service contracts tend to dictate minimum
system requirements
NB: Your mission may require more
(e.g. collecting research data)

Database Perspectives: Your workload
• There will be a lot of work for your organisation
– 40% working out your requirements
– 5% (or less) talking to software sales people
– 20% “try before you” buy evaluation of preferred
solution
– 25% aligning system in detail once selected
– 10% training and supporting staff through
deployment

What is
Database
Alignment?
• Any database must be set up for you use
– Configure colours, logo and field names to match your
jargon
– Load in data set variables
– Establish alerts and/or dashboard: e.g. how many
assessments are due/overdue today? This week?
– Set up workflow to force process: e.g. record cannot be
saved without DoB entered
– Design and set up reports
• Evaluating a system means trying all of the above!

Preparing your Requirements #1
Map stakeholder journeys
• Give “exemplar” stakeholders names
– Easier for your team to talk about “Chris” than it is about a
“typical client”.
– Can have more than one profile if relevant
• For each stakeholder
– What is their journey through your core processes?
• What are their objectives?
• Are they willing travellers?
– Where do they touch other stakeholders?
– Where do they provide information?
• What is recorded and how/where will it be used?
– Where do they make decisions?
– Where are decisions made about them?
– Where is information about them but not from them provided?
• What is recorded and how will it be used?

Preparing Requirements #2
What do you have to
account for?
• Make sure the database
records the same “units” as
you need for invoices or
funder reports
• If the database counts
something different you are
setting up to fail!
• For example: counting time
spent with clients
– actual hours and minutes OR
– one hour slots regardless of
actual time spent OR
– number of sessions OR
– all X or X approved sessions OR
– ???.

Preparing your Requirements #3
Define your critical datasets
A dataset is a set of values that can be used to categorise a
data record.
• It will be a search variable when selecting data for reports
• It can be a drop down list for data entry.
• They should be centrally managed and consistantly used
• May be defined my someone else – e.g. Government
ministry ethnicity categories.
• A record may
– Use only one on the set to the exclusion of others: e.g. child or
adult
– Use more than one simultaneously: e.g. hobbies
You have to define the rules
• The new database must be able to enforce them.

• Open source or commercial software?
• “Off the shelf” or custom built?
• Which versions of Microsoft Windows and
Office?
• Will it run on your computers?
• Should you go to the cloud?
• Going mobile
• Links to social media
• Security and privacy
• What you can expect to pay
Questions to answer AFTER requirements prepared:
(It doesn’t matter being an OK answer IF you can justify it)

Development Methods
Probably best to use an AGILE(ish) methods not SDLC:
• especially if you are not developing from scratch
• AGILE (ish) methods
– is a cycle of prototype a function, try it, fix & refine it then add another
function
– Involves more staff and volunteers
– Shows progress fast
– Is easy to test
– Supports ecosystem testing
• SDLC = software development lifecycle
– Scopes everything first
– More specialist intensive
– Less staff involvement
– Slower
– Harder to test
– More expensive to fix mistakes

Avoid mistakes: Try before You Buy
(it’s a BIG decision!)
• Many suppliers offer a 30 day free trail.
• Software as a service allows you to sign up
for a short timeframe
• Is invaluable to
– Ensure a “good fit”
– Spot resource gaps
– Identify necessary extras
– Try out supplier service
– Involve the team

Specifically: WHAT to try before you buy
• Does it work in your environment?
– Do you need new computers or a software upgrade?
– Can you network go fast enough?
• Would it need changes?
• Questions where the answer should be “YES”
– Does the database count what you need it too?
– Can it follow your stakeholder journeys?
– Can you configure it yourselves with training? (e.g.
changing field names, adding logo, adding to data sets)
– Can you generate the reports you need?
(without dumping data to spread sheets)

Project Timescales
IDEA
Define
Requirements
Select
Design
&Plan
Develop Deploy
TIME
RealImagined

Time
Cost
Project Benefits
POTENTIAL
BENIFITS
IDEAL RANGE
If you need to change
the project plan make
sure you keep the
benefits.

Check Reality at Every Stage
• What is a requirement;
what is a habit?
• Are you counting what you
have to account for?
• What must be audited?
• Do we still get the benefits
we want?
• NB: Don’t force a fit!

Good Luck!
• Contact Dale Jennings Associates if you need help at
hazel@dalejennings.co.nz or 021 0234 9095
– Our first 90minute consultation is free and without
obligation
• Check us out by going to our website or “Google” our
Principal Hazel Jennings for more information.
• We are MSD capability mentors listed in the MSD
Family Services Directory.
• We are independent of all IT vendors:
– We don’t sell or take commission on software, r hardware
or telecoms or anything else

Choosing a new database

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Choosing a new database

Similar to Choosing a new database (20)

Recently uploaded

Recently uploaded (20)

Choosing a new database