by Plaster Group’s Data & Analytics Team
At some point, most organizations find themselves evaluating new tools to improve and modernize their data processing. The approach taken when making these decisions is incredibly important because it will affect many aspects of the organization including budgets, the development processes while implementing the tool, the operational processes to monitor the tool once it is moved to a production system, and (most importantly) the business users and/or customers. I have witnessed a number of different approaches to performing tool evaluations — some more effective than others.
Companies sometimes simply look to research organizations such as Gartner and assume that if a tool ranks as a market leader in their “magic quadrant” that this is sufficient to determine a tool’s effectiveness for their needs. Another approach that I have seen is choosing a tool because your company and the company that sells the tool have common board members – a truly bad idea and a conflict of interest. Or, companies sometimes keep an existing tool that does not meet their current or future needs because of concerns for the time/complexity of converting existing application code. Although these approaches yield a quick decision, the end result is often a tool that lacks key functionality to meet business requirements, and that makes processing data into information a daunting task for development and support staff.
Instead, spend extra time up-front to determine your organization’s specific needs. This will ultimately lead to a better purchase for your organization. Ideally, requirements should be put together by a cross-functional group of individuals from across the organization. This group will include engineers, support staff, management, and business users. Requirements should be identified across a broad range of areas such as:
- vendor support
- operating system requirements
- security requirements
- ease of hiring or training development staff
- database support
- ease of business user access to reporting and ability to build their own ad hoc reporting if necessary
- licensing costs
- ease of installation and maintenance
The above criteria should be used to pare the list down to a handful of top contenders. Then, the vendors should be brought in to demonstrate their product, ensuring that the tool functions as expected and works well with the organization’s existing systems and databases. For each requirement there should be an appropriate number of tests that span a distribution of easy, medium and complex tasks. When presenting the results, include scores that reflect the degree of difficulty to accomplish each task, the complexity of the solution, and the time necessary to implement and to run the task.
While this more comprehensive process requires more time and effort, it will keep your organization from having to trade up to a different tool because the initial one chosen did not meet the organization’s need. More importantly, this approach enables better application development, more effective operations, and improved solution delivery.
