7 mistakes to avoid when evaluating a build-your-own vs ready-made Collections Management System (CMS)
Over the last 30 years we’ve seen numerous institutions seek to save on costs by building their own CMS only to discover that the time, resources and cost of building and maintaining the CMS were seriously underestimated. The pattern is familiar to us: an institution invests untold hours and money in building a bespoke system only to come back to the market for an off-the-shelf system five or six years later when the bespoke system proves to be unfit for purpose or unsustainable.
Investing in technology can be a time intensive and expensive undertaking and the cost of making the wrong call can be significant. As a software vendor we might be seen to have a bias on this topic, nonetheless we would like to share some insights based on our experience to help institutions make an informed decision and avoid some of the pitfalls that have hurt others.
1. Comparing apples to oranges when it comes to investment
When investing in a build-your-own system the single biggest issue for institutions is failure to account for the hidden costs.
A vendor quote is presented in terms of cost; there is usually a cost associated with implementation, number of licences, training, hosting, data migration and ongoing maintenance, and so on. It’s all there in black and white. Those numbers can look daunting, but they are based on experience doing similar work and they include not only the technology but the skills, project management, advice and experience of the vendor getting you up and running. And, importantly, the vendor is required to deliver to the agreed quote.
In contrast, the costs of a build-your-own system are difficult to estimate and often hidden. The new CMS must be delivered by existing museum staff, or additional staff, and the cost is in terms of staff time. It is necessary to estimate how much time the project will require, and from which staff, and whether this can be achieved with existing resources. Unless the institution has experience with this sort of undertaking, any calculation is based on a best guess of what work might be involved and how long it will take.
It’s at this point that underestimation can occur, so let’s have a look at why that might be.
2. Museums have Collections specialists and IT specialists but few staff who are both
A CMS is a feature-rich system which needs to adhere to standards and meet a range of needs. When evaluating build-your-own vs ready-made solutions there are usually two main decision-making groups: Collections staff and IT staff. Collections staff are experts in their field and usually have a firm idea of what they want the solution to do. IT staff are specialists in the technology and usually have a good idea of how they can make the solution happen. Usually the two groups will have sat together and made estimates on how simple the build process should be to achieve the goals. However, each group typically understands only the main principles of the other’s speciality, not the detail. In terms of technology development, detail such as “we need these three fields to be mandatory” or “we need this field to link to that database” can mean a difference of weeks or even months in project timeframes.
Each department goes into the project feeling well-informed about what’s involved, but as soon as development work commences, the details start to unfold and the deadline for delivery moves further and further away, adding costs and resources at each step.
3. You’re paying to re-invent the wheel
Taking ourselves as an example, our systems are used by more than 3400 institutions and have developed over 30 years with input from thousands of users about how they would like the systems to function. From fields to reports to searching and linking, the vendor of a popular CMS will have invested time and money into servicing the needs of an existing customer base and have had decades of trial and error to shape the system.
When an institution opts to build its own CMS it effectively pays to re-do all that work, starting from scratch with a smaller resource and user base. Museums often underestimate just how much they have in common with other museums and archives. Most needs are in fact common across institutions and when you choose a commercial system developed for a range of customers, you benefit from the feedback, requests and experiences of many institutions rather than just your own.
4. It’s not a one-off project cost, it evolves over time
It’s easy to think of buying Collections Management software as a project that concludes when the CMS has been implemented. That’s just not the case. Implementing a CMS is just the beginning and as users start to use the system, they’ll quickly identify how their experience could be improved and suggest changes that will help them do their job more efficiently. Standards and priorities change and before long the institution will find itself needing functionality that hadn’t been envisaged.
A build-your-own estimate rarely accounts for this ongoing work, accounting only for the time to develop the features required in the original brief. By the time the work nears completion, requirements will often have shifted with the changing needs of departments, leading to further extension of the timeframe for delivery and adding to the time investment made by project teams. IT staff feel like they’re battling ever moving goalposts, while Collections staff see the timeframe for completion moving steadily away.
When you buy a solution from a vendor, not only will the system boast features that you may not have thought to specify at the outset, but it should include ongoing maintenance, support and upgrades, and updates – meaning that once your system is live, you have a pathway to continued progress without having to spend large amounts of in-house time on development.
5. IT departments can’t always prioritise the CMS over other projects
An internal IT department is usually responsible for a range of systems, many just as critical as the CMS. Other important projects or IT emergencies do come up, perhaps requiring the CMS to be de-prioritised in an effort to keep the whole institution running smoothly. If the CMS build project is running slower than anticipated, it’s not unusual for IT resources to be reassigned. It’s also possible that such things as support and maintenance haven’t been accounted for in IT resourcing calculations. This may result in additional hires needing to be made to keep projects on track, or an impact on the timeframe for implementation, each carrying an additional cost for the project team.
Implementation of CMS systems is a vendor’s business. A vendor works to a contract that requires them to resource the project appropriately within agreed costs and timeframes. They usually have a much larger base of experienced developers to call on and can pool resources from other departments and make hires to suit their project load without impacting your costs. When you choose a vendor solution, development resourcing is not your issue.
6. Projects are usually driven by an individual, and individuals can leave
Build-your-own projects are usually driven by one or two individuals with a vision of the development of the system. Whether they’re an IT or Collections lead, they usually have clear ideas about why they want a bespoke system and why it needs to be built in a specific way. They’re key drivers of the project and its central point of knowledge. Other staff will understand how to use the systems for their own purposes, but understanding the system as a whole system is typically limited to the project leader(s).
If the project leader should leave, it is often very difficult for others to understand how the whole thing hangs together. At this point, ongoing development often stalls and sometimes institutions find it easier to start over or end up going back to market.
When you buy from a vendor, the software is developed by a team, and knowledge is distributed and documented. If key staff leave your institution, system development doesn’t stall, knowledge of the system is retained and remains with the vendor with whom you have a Support contract.
7. You will need to invest in bespoke training and documentation
When a system is unique to an institution, it is necessary to have a plan for training existing staff, but also to train all new staff as no one coming into the institution will have experience of the system. Staff skill is critical in gaining any benefit from systems, and training and writing detailed documentation on how to use systems should be factored into costs from the outset.
When implementing a popular ready-made system not only can the vendor provide documentation and training, but it is more likely that new hires will have used the system before and can come into your institution with skills and experience that can help make better use of your software, rather than starting from scratch every time.
If you’re looking for more information about Collections Management software, we can help
If you’re exploring options for Collections Management software, we’d love to speak to you about your requirements. We can work with you to understand what you’re trying to achieve and give you an estimate of the timeframes and costs based on our experience with other customers. You can also read our advice on selecting the right vendor to work with for your CMS.
