This tipsheet was developed by Elisa Kosarin, CVA, a Volunteer Engagement Specialist at TwentyHats, and Abbey Earich, Lead Volunteer Coordinator for the Smithsonian Office of Visitor Services (OVS). It is based on Abbey’s experience selecting and serving as project lead for a new Smithsonian-wide VMS system implemented in 2018.

Finding the right VMS matters when you’re tracking volunteers, coordinating with development, and (ideally) measuring your program’s impact. It’s the difference between spending minutes entering data and running reports from one source or taking hours to manipulate a spreadsheet for relevant information.

But the process of choosing one can be complicated, as there is no one-size-fits-all system for museums. There are a lot of choices out there, and the best one for your organization will depend on your size and budget.

How do you select the right VMS?

Get diverse input from the start.

Assemble a committee to advise on the search. If you are replacing an existing system, the committee should include users of that old system. It should also include people from all departments and those that might have a stake in the outcome. Having such a diverse committee can make a big difference in addressing everyone’s needs.

Do the research.

Assign one person as the project lead. With so many options available, the committee should meet frequently so the project lead can understand the range of needs and identify the best options. The process could take up to a year depending on your museum’s needs. It can be challenging to find a vendor to meet all of your priorities in one system.

Getting at least three bids before making a final selection is a good practice. Each provider can give a demonstration to the committee to help inform the final choice.

Get wide-ranging input as you customize.

One way to do this is to create a pan-institution implementation team tasked with customizing the product to allow for wide ranging input.

Again, meet frequently to examine every aspect of the volunteer journey to identify your system’s needs. Creating a giant flow chart to map out the volunteer journey—from how a volunteer learns about an opportunity, to what the application form needs to include, to how to track volunteer hours—can be helpful to visualize the process.

Come to consensus.

Choices concerning the VMS system should never be made unilaterally. “On every decision, we’ve had to agree,” Abbey states. “We’ve had to figure out what would work for everybody, knowing that every opinion counts.”

Create a change control team (CCT) post-launch to meet quarterly and discuss requests and recommend changes to the system. As with the selection team, these meetings should be consensus-driven.

System changes should be made by majority vote, allowing for budget considerations. If a proposed change requires additional funds, you’ll most likely need to take that to the department or museum director, depending on your staff structure. Otherwise, give your team the agency to make changes that become global for all users.

Take plenty of time to test. And then test some more.

Once the system is developed, the next step is extensive testing.

Testing remains an important aspect as the database evolves and changes are made. Anytime an update occurs in the system, conduct extensive testing on the sites to ensure tools work correctly. Generally, tests find a few errors in the system and the team makes tweaks before moving changes to the live site with actual users. Abbey also works closely with her IT security team to ensure that any changes to the system meet security standards and requirements.

Treat your system as a living database.

Even after the launch, the system continues to evolve. Once the team starts using the system, you may notice things you hadn’t before, or things that you need but didn’t know you needed before.

Creating a system of feedback, where team members/users can suggest upgrades, report needs, and ask for additional support will be helpful.

Changes to the system are ongoing to adapt to external events and shifts in user needs.

Think people, not software.

Making each stage of the process as inclusive and diverse as possible will create a better system in the end. The more viewpoints you can bring to the table the better the result.

As Abbey sums it up: “One of the reasons I am successful in this role is that, from the product selection through the latest upgrades, I’ve maintained positive relationships with the users and encouraged their input. They know me, and they trust that this system will always reflect their needs. A database is a tool that helps staff and volunteers do their jobs better. That’s especially important with volunteer management, which is all about building relationships.”

“You think you’re buying a piece of software and no big deal. You find the best one you can. But it’s really not about that. It’s about the people.”