When you’re looking for a grants management system you want to know what it’s like to actually use the system, of course. During the decision-making process, organizations sometimes will ask for a sandbox to play around in the system to see if they like it. This seems like a great idea on its surface, but ultimately, I want to tell you why it probably won’t provide the information you’re looking for.
Sandboxes are most typically used for cybersecurity reasons during software or program development. A sandbox is typically used to test product configurations or updates. Some examples include workflow configurations, application forms, and user security configuration. Basically, a sandbox is typically used as a test environment. Developers can test out new programs to ensure there are no errors. Sandboxes can also be used to “user test” software, and they can be useful in the right circumstances.
Grant management is not exactly one of those circumstances, and here’s why:
Test driving in a sandbox environment is not exactly like test driving a car.
When you get behind the wheel of a car to see if it’s the car for you the chances are extremely high that you have driven a car before. You have some prior experience to base your analysis on. If your organization is on the smaller side or is looking to move from paper-based management to a GMS, you may not get much value from trying to navigate a new system on your own without guidance or support. If your organization is large and is planning to migrate data from a legacy system, you may have experience, but there is another potential pitfall.
The “dummy data” in a sandbox environment can’t replicate your organization’s data.
Ultimately, you will most likely find the system to be more challenging to use in a sandbox than it is in reality because it is not configured to your organization’s unique circumstances. Your organization has unique processes and workflows in addition to unique data points, and they can’t be effectively replicated in a sandbox without having gone through a thorough implementation process, including solutioning and configuration. You’ll see the user interface, but you won’t see how the system can improve your processes and workflows, or what using it on a day-to-day basis is like either. Because of this, you can’t draw direct comparisons between sandbox performance and actual product performance.
Moreover, implementing a GMS is about change management. You'll likely need to adopt new processes to get the most return on investment out of a GMS, so comparing your existing paper-based processes or processes across multiple systems really isn't a good comparison and may mislead you when evaluating systems.
Without training the value you’ll gain from a sandbox is minimal.
There is only so much you can evaluate using fake data with no hands-on training. If test users are not trained to use software, they are more likely to avoid engaging with it than anything else. Sandbox usage tends to last around five minutes per test user, and often, many test users don’t even enter the environment at all. This is most likely because it is intimidating to use software on your own that you have no experience with, or training in. Setting up a test site using your actual data for the purposes of actual training during implementation will be much more beneficial than a sandbox, and you will also set your team up for success when it comes to product adoption.
So, how can you effectively evaluate software?
When you’re evaluating software, requesting a demo is always your best option. When it comes to grants management systems, you’re looking for a partner, not just a salesperson, and the demo process should reflect that. During a demo, you can get real-time responses to your questions, advice on how to best replicate your unique processes in the system, and advice on how the system could integrate your use cases. Your demos of the system should be about you, your questions, and your needs all being addressed by an expert, not just a sales pitch.
If you absolutely must have some hands-on time with a system before purchasing (maybe you've been burned before, or had bad experiences) we recommend having a small number of tasks or objectives that you want to see carried out in the system – ideally 3 to 5 – and work with your sales representatives to set up a session where you can walk through these processes together in a system that's configured to your requests.
If you have questions we’re always here to help, right from the beginning.
-------------------------
Photo by Markus Spiske from Unsplash
Topics: Drive Best Practices
Essential Resource
