This document provides an overview of Ian Rowson's presentation on selecting and implementing a Museum Collections Management System (CMS). Some key points: - CMS projects involve significant time and resources, so it is important to minimize risks by following best practices. Rowson outlines seven "golden rules" to help with this. - Choosing a flexible, standards-compliant system is important to allow for future changes and data exchange. Homegrown databases often fail to meet long-term needs. - Ensuring you can export data in an open format is essential to avoid being locked into one system forever. Suppliers should demonstrate this capability. - Getting support from various departments and an experienced supplier can help navigate technical

1. adlib
Collections Databases: Making The System Work For You
Ian Rowson
My presentation today offers an overview of the process of purchasing a Museum Collections
Management System (CMS), and along the way I’m going to identify seven ‘golden rules’ to help
minimise the risks inherent in this process. Museums come in all shapes and sizes, of course, and so it’s
difficult to give a presentation which is completely relevant to all. So I’m trying to pitch this more
toward the smaller institution, on the assumption that large institutions should, in theory, have more
skills and experience available in-house to help them. Hopefully there will be something here that is
relevant to anybody considering a CMS project.
I’ve been involved in the world of museum CMS for about 12 years, from both the museum side as a
software purchaser and sometime software builder, and also from the software supplier perspective in
my current role as Manager of Adlib UK. In this time, I’ve seen many projects come and go.
I hope it’s fair to say most have had a positive outcome, not that I claim any particular credit for that.
CMS projects are, or at least should be, very much team efforts. Such projects involve resources, mainly
time and money, which are much too valuable to waste. But as is usual in life, it is the projects that hit
problems needing to be resolved that provided the greater learning experiences.
What I hope you will retain from this presentation is my list of golden rules of CMS projects.
I make no claim that this list is exhaustive, or for that matter unbiased, but if you keep at least these
points in mind, they should help you to avoid the worst dangers.
To begin, I want to talk about a bit of background. Why do we need a CMS in today’s museum?
Most museums have some kind of database, even if it’s just an Excel spreadsheet, to record details of
their collection. It is after all, a requirement of the Museum Accreditation Scheme to make a catalogue,
and a database offers an attractive way of doing this.
The classic justification is of course that museums contain a lot of information. By improving access to
information many of the processes of management of collections can become streamlined.
1

2. adlib
But a good CMS is about recording more that just collections data, such as object names, makers and
dimensions.
What about all the other information resources the museum may hold?:
• Files about objects, artists or makers, which could include archive material.
• Research resulting from exhibitions or academic study
• Published Material pertaining to collections or objects
• Interpretive texts
• Texts written for educational resources or web presentation.
• Digital Assets – Images, sound recordings, digitised video or film
• Information about objects gained from visitors
I’m sure you can think of many other examples.
If you don’t attempt to manage these resources and bring them under control, their purpose and
usefulness to the museum is severely diminished. A museum can gain much from making the
information it holds accessible to all the different staff who work within it in a consistent and
comprehensive fashion, let alone, of course, making information available outside the institution.
At the moment, in my opinion, good old-fashioned information management does not have the profile
it needs to have in our profession. Everyone’s attention seems to be focussed on more exciting topics,
such as the possibilities offered by social networking on the web. Blogs and podcasts are today’s hot
topics of discussion, and while I’m not arguing against doing those things, what I would ask is; what
happens to the information you may gather? If you don’t store and manage it properly, then it will be
lost, which to my mind rather renders the whole exercise pointless.
The principles of good information management should underpin any museum project using ICT, but
I’ve seen too many instances where a designers have been engaged to create a website, or a gallery
interactive, where the content is completely inaccessible to be repurposed or sometimes even edited, by
the museum in any way.
2

3. adlib
So my first golden rule is: Avoid establishing ‘silos’ of unconnected data which are inaccessible and
therefore unusable for other purposes. When commissioning any software in the museum for whatever
function, the question you should ask is “How easily can we access the data in this system to use it in
other ways”?
The collections management system, which is designed specifically for the purpose of information
management, should be the natural home of all information resources in the museum.
Now I wish to address the main issues that may impact CMS projects. I suppose you could say, “But
what could go wrong?” After all, we’re not talking about rocket science here. We’re talking about
installing a computer system, running database software in a museum. Surely that’s not a problem?
Computers are easy now, even my kids can use them?
Well, it’s true that computers, or information technology, have become ubiquitous in society. Even at
home we are using things such as wireless broadband, that would have been unimaginable 20 years
ago. So obviously Information technology has become much more accessible, but computer systems
for professional use are still some way from being ‘consumer goods’ that you can just ‘fit and forget’.
In particular, there are some big issues which characterise Museum CMS projects which simply can’t be
overlooked.
Firstly, Museum information management requirements are quite complex. They can involve
different kinds of information resources (as I’ve highlighted). even object data can vary widely – for
example, a natural history specimen has very different information recording needs to a fine art
object, yet they often need to co-exist in the same database. If you take the view they can be in
separate databases, then already you’re on the way to creating silos – how do you search across
these databases? How do you create links between object records within different databases? How
do you ensure consistent vocabulary is used to describe them?
Secondly, Museums collect under the ethos that their objects are to be maintained ‘in perpetuity’.
To manage them effectively, that also means you need to retain the information about them ‘in
perpetuity’. Herein lies a challenge.
Computer systems used in a commercial environment have typical projected lifespan of about
4 years before they will be replaced. In fact, it could be argued that the whole ICT industry is
3

4. adlib
based on rapid change and obsolescence of its products. Horror stories about this have even
made it into the national press – which shows it must be true!
A notorious example of this was the BBC’s £2.5m Domesday project, which became obsolete
less than 20 years after it was created.
I’m sorry to say that this issue does not seem to have the profile it deserves within the museum
profession, and even some software vendors in the market today place little emphasis on this.
After all, what salesperson wants to raise the doubt in the customer’s mind of what happens to
their data, if and when they decide to stop using the expensive software they are just about to
invest in?
But it is a truth that, compared to the massive investment in staff time creating data resources,
the cost of any software application, (which after all, is only ever a temporary home for it) is
fairly insignificant. The pace of change is such that who knows what kind of computers systems
or software we will be using in ten or even twenty years time?
So I would argue that the most important criteria for software purchase today is to make sure
that it will allow us at some point in the future to extract our data without loss or huge expense.
However, it is by no means a given that all software applications will permit easy extraction of
data, and my company know this better than most, because we spend most of our waking
hours converting data from other systems into Adlib. That is why we pledge to all our
customers than you can and will be able to extract ALL your data from OUR software
applications as fully portable XML files.
So my second golden rule: make sure you can extract your data in a suitable format from any software
you purchase – in fact, ask to see this demonstrated to you if you have a software presentation.
I’m now going to talk a little about how to begin planning a project. This is a big subject, which is
rather beyond the scope of this presentation, but I can point your towards some good sources of advice,
such as Managing New Technology Projects in Museums and Galleries available from Collections Trust,
and the Museum Informatics Website publication Planning for Museum Automation. Both of these
publications, although a few years old now, have a lot of relevant material in them.
4

5. adlib
One thing you can be sure of: Projects will always expand to fit or exceed the time available!
An important factor to consider is that of confidence. As a member of museum staff, perhaps working
in the documentation or collections management dept., how often do you purchase a computer
system? Hopefully, no more than once perhaps, in any one organisation you may be working in.
Yet projects to purchase and install CMS typically require more than a passing level of technical
understanding. At very least, it is going to mean dealing with technical people, who quite often seem to
talk a different language to museum people.
At Adlib we recognise that this can lead to misunderstandings which can pose a risk to any project. We
seek to minimise these risks by employing people who are museum qualified and museum experienced
in our sales and consultancy roles. This means such staff can act as interpreters between our customers
and our technical people, the people who actually make things work.
This helps too, because sometimes museum staff are uncomfortable dealing with the ICT department
of their own organisation, be it a local authority or university, for example, let alone an external
company who are trying to sell you their product.
You are skating on thin ice if you are having to rely on a member of staff who has recently brought a
pc for the kids to do their homework on as being your expert in information systems procurement. But,
unfortunately, this is sometimes the case in a small museum.
So my third golden rule is: try to get some help. Don’t attempt to do it all on your own. Try to build a
project team that includes IT dept. people. If this is not possible, in any event, try to use a supplier that
can demonstrate good experience of and understanding of museum projects.
Having decided that some form of database system is required, and assembled a project team to
undertake the procurement of it, a next step is to consider how to proceed. There are two broad
possibilities:
If someone in the museum is quite IT literate, you might consider a DIY approach. A simple museum
database can be built with software such as Microsoft Access, which the museum may already own.
5

6. adlib
This could seem a tempting possibility, particularly if budgets are tight, or you have a member of staff
who fancies themselves as a systems developer.
Alternatively, and assuming you have your own money printing equipment, you could employ a
contract software developer to build a system for you.
There are issues that you need to be aware of, however, if you consider going down the DIY route.
Firstly, the issue of time. To design and construct a database application takes time. Lots of it. Can you
spare the member of staff from their usual duties to do this? What other work will become neglected
while the project proceeds? It is amazing just how much time such a project can soak up.
Secondly, can you be sure of a good outcome? If a member of staff’s time is invested in this for weeks or
even months, what if they get out of their depth and can’t finish?
Thirdly, what always happens is your resident expert leaves to go to another job. If that happens, is
anyone else left who understands or is capable of maintaining the system?
At Adlib, we spend a lot of our time converting data from home-grown database projects that have
either hit one of the problems mentioned, or simply reached the point where the system simply cannot
offer functions that the museum needs.
Adlib software has been around since 1970’s which means that dozens of man-years (and woman-
years) has gone into defining and refining its functionality. This means it can do things that would be
impractical to develop in-house.
My belief, and I can speak from experience as someone who has in the past been a museum’s resident
Access developer, is that at best using software such as Access offers a solution which is only really
applicable if the requirement is basic, and budget is non-existent.
Should your project come into this category, I would instead recommend that you consider using Adlib
Museum Lite, our free basic catalogue software package which is available for download from our web
site. By using this, you could save yourself a lot of time and trouble. In the future, the data you enter
6

7. adlib
into to Museum Lite can always be transferred into more powerful software should the need arise. If
you buy one of our products, we will do this conversion for free.
The most common way of proceeding with a CMS project is to purchase a commercially made software
package for museum management, of which Adlib is one vendor of about a dozen currently operating
in the UK market.
So how can you go about choosing which one is right for you?
Well, firstly the processes of museum collections documentation are well defined by SPECTRUM
standard. So there is no real need to re-invent that particular wheel in trying to write a functional
software specification. It’s already there.
The Collections Trust administer a compliance programme, where software suppliers can have their
system validated against the SPECTRUM standard. Currently, the Collections Trust website lists 5
compliant systems, of which Adlib is one.
I would always recommend adherence to standards, for a variety of reasons, but not least because to do
so makes your data more easily ‘interoperable’, meaning you could more easily exchange it with
another institution if you so wish, or dare I say, when the time comes to more it from one Collections
Management System to another.
I spoke earlier on about the CMS being a natural home for museum data. Well, Spectrum defines
museum data clearly enough, but what about the other resources I mentioned earlier? You may have
archival or library data, or digital resources relating to your collections?
There are other standards that apply in these cases; for example, ISAD(G) for archival data, and AACR2
for library data. Dublin Core is often employed for Digital Asset metadata. You probably won’t be too
surprised to hear that Adlib follow these standards in the implementation of archival, library and
digital asset catalogue modules which may be integrated with the museum system to allow cross
searching, linkage of different material types and use of common terminology for cataloguing.
So my fourth golden rule is ‘Standards do matter’. They help to keep data ‘open’ for exchange and
movement, and sometimes it is even a requirement of grant giving bodies that they are adhered to.
7

8. adlib
Standards are all well and good, you may say, but what about my special requirement to do ‘X’? Our
collection is unique, and we have a long tradition of recording such and such information that is not
part of Spectrum?
This argument is sometimes used to win support for ‘home grown development’, that being that ‘no
commercially available package could ever meet our needs’.
While it is true that museum software systems by their nature have to be designed to support the
operation of a ‘generic’ museum, if such a place exists, the software package should also be flexible
enough to be configured to cope with any special requirements that may crop up in future, without
having to go down the route of bespoke software development. After all, who knows what is around
the corner?
To give an example, imagine you decide to embark on a project to use volunteers to enter the content
of several hundred mda cards onto your database. Processes such as this can be greatly simplified if you
can create your own screen layouts. Adlib comes delivered with a tool called Designer which you can
use to do exactly that. In fact you can do a lot more than that. You can also create new fields and
indexes, change screen texts and colours, in fact build yourself a whole new specific database if you
wish. We offer a range of training courses to customers who wish to learn how to do this kind of thing
themselves, or, of course, you can commission such work from us.
So my fifth golden rule is ‘flexibility is important’. No-one wants to be locked-in to working a certain
way, just because the software you’re using dictates that. How easy is it to change things?
Now, having decided to buy a standards compliant, flexible system, how else do you choose?
Well there a couple of factors you may want to take into consideration;
Firstly, you’re not just buying software. Inevitably, you are in fact buying into a long term relationship
with a supplier, of which the purchase of a system is only the initial step. I’m talking here about
ongoing software support.
8

9. adlib
Software is something that is continually being upgraded and bugs fixed. It’s a bit like when you buy a
car, you need to have it regularly serviced to keep it running sweetly, but more complicated than that,
because when you update software, you usually also get new features added to it, but these new
features may also bring new bugs along with them, and so the process goes on, it is just a fact of life.
So you need to be sure that the software supplier is capable of delivering an appropriate level of after-
sales support, sometimes termed a ‘service level agreement’ and this you can typically judge by:
1) the scale of the organisation: do they have technical people in the UK who are available when you
need them on the phone, or do you have to wait until they have woken up, because their office is on
the other side of the world?
2) talk to people who are currently using the system, and get feedback from them about the after sales
service provided. Any supplier worth their salt will provide names of similar institutions using their
products that you can contact.
Learn about the supplier by gathering information. Obviously events such as the Museum and Heritage
show provide an ideal format for this, because all of the major suppliers are here for you to talk to and
collect sales literature from.
However, although sales literature is useful, it is only the ‘gloss paintwork’. What you need to do is
scratch through the surface, ideally by getting hold of a demonstration copy of the software so you can
give it a thorough trial run, and take a read through the user manuals.
At Adlib, we have a very open policy which means that demonstration copies of our software and all
our manuals are freely available for download from our website. If you find that a potential supplier is
cagey about letting you have access to this kind of information, then I think you really have to question
why that is so?
So my sixth golden rule is; select a supplier who is able to provide a professional level of service if you
encounter a problem, or should I say ‘when’. No-one likes to be waiting around for time-zones to
change before they can talk to the helpdesk, or for a call back from someone who is not really
technically qualified to be doing software support work.
9

10. adlib
So far, so good. But things may get more complicated if you have to begin a competitive tender
process, which many organisations require for projects that have a budget that exceeds a given
amount.
By it’s very nature, creating a tender document does require a certain amount of re-invention of wheels
– both on the part of the prospective purchaser, in that functional and service level specifications need
to be written, and prospective suppliers, who have to respond to them.
My comment about tender documents is, if you have to use them, make sure you allow enough time
for the process to work properly. You’ll need sufficient time to create the documents, and suppliers
need to be given a realistic length of time to respond to them properly. You’ll also need time to
adequately evaluate and compare the responses.
I’m not going to say any more about tenders, because if you need to use them, the chances are there
will be a procurement department within your organisation who will guide and advise you on this.
Having selected a supplier, its time to discuss project implementation – in other words, see about
getting it all installed and working. This is where the fun really begins!
If you have data to be migrated to the new system, make sure you allow enough time and money to
complete this properly. I think it’s fairly safe to say that the success of most projects stands or falls on
the data conversion.
This is why we have evolved a three stage process, which I’m going to explain because I’ve found that
many people coming into this for the first time seem to think it is a trivial exercise. Far from it. It cannot
be rushed, and don’t let anyone tell you that it can.
Firstly, we create a mapping document which outlines for every field of data in the old system,
where it will end up in the new one. This is then discussed and signed off by the customer.
Secondly, we transfer the data according to the rules defined in the mapping document, and
provide it to the customer for checking as a test installation. This gives the opportunity to make
changes if anything has not worked out quite right.
10

11. adlib
Thirdly, we request a final copy of the data, and transfer it to the new ‘live’ system. This means
that there is plenty of opportunity for checking and correcting any errors before the final switch
over, and that ‘downtime’ is kept to a minimum.
The delivery of the test system also provides an opportunity to test and prove that the technical
infrastructure for the new system is all ok before it goes live.
So my seventh golden rule is; don’t try to rush project implementation, especially any data conversion.
Build in plenty of staff time for data checking, because once you’ve fully switched over to a new system
for data entry, it can be very difficult, if not impossible, to re-run the data conversion again.
My final word on the subject is, keep in contact with your supplier. Join the user group. Participate in
any discussion list. Let them know what you think about their products, what features are good, and
what you think needs changing. The relationship between the software supplier and the customer
should ideally be one of mutual benefit.
References:
Perkins, John.(1993) Planning for Museum Automation Student Workbook, Pittsburgh: Archives &
Museum Informatics,. Available online at http://www.archimuse.com/publishing/automation.html
Stiff, Matthew (2001) Managing New Technology Projects in Museums & Galleries, Cambridge, MDA
11