AVAIL conducts a lot of software evaluations. Firms of all sizes from across the globe and in different verticals of AECO take AVAIL into consideration. There is some commonality between all the different companies in terms of why they want the product, but the thing that usually differs is how any given company will spend time evaluating the software. My last post talked about how we’d like to collaborate with the industry on how to improve the learning experience, so in this blog, I focused on some of the more productive evaluation techniques that we have experienced - some of which we’ve even implemented into our own processes; after all, we’re customers, too. Here’s a brief list of things we have seen that have been very effective - we recommend doing them all.
-
- Develop a clear idea of what needs improvement.
- This is essential if you’re writing a business case or want to make an ROI analysis.
- If saving time is a goal, clearly identify how much time you’re spending on the current task before you start any product testing. Ballpark estimates can work, but try to be realistic.
- Use the tools! Most companies will (or should) let you use their software before purchasing. Just ask!
- Before using the tools, develop and send a pre-engagement survey to your end-users.
- Make sure the survey contains quantitative and qualitative feedback opportunities.
- This is a good opportunity to assess the 'current state' mentioned above
- After using the tools, develop and send a post-engagement survey to your end-users once the product has been evaluated.
- Again, make this quantitative and qualitative.
- Reach out to your peers in the field and ask them questions about the products they’re using, and specifically about the product you intend to use. Many times people have experience with multiple vendors for the same solution and can give great advice on the differences.
- Ask direct questions about the company’s support, what their success program consists of, if they hit their development goals, and if their customers participate in the development of the software.
Keep in mind: This is different from asking for references from the vendor!
This list is by no means conclusive - just things we’ve seen or used that have worked. The soft costs of software are acquisition, rollout, and implementation, and, finally, the continuing relationship between vendor and customer. The path to learning about new tools is risky and can be frustrating, but if you develop a program, then you’ve gone a long way to mitigate those risks.
What do you think? What does your firm do?