Written by Mark Evilsizor
From his column Tech
Some technology selection decisions take little thought and have minimal consequences. When I was looking for a phone app to scan a paper document into a PDF, I could try one, and, if I decided watching an ad for hair cream was more annoying than paying five dollars, I could easily delete it and download a new one. But some technology decisions we live with for years. For example, choosing a vendor to build a new website, selecting a church management system, or deciding which accounting system to implement. These choices become entwined into organizational workflows, staff training, and member interactions. Changing them is a big effort that we don’t want to do often. In this article, let’s consider how to approach such choices to improve the chances for success.
As with many things in life, the quickest path is often not the most beneficial in the long run, so, too, with technology system decisions. While searching the web can be a useful part of the process, starting out by searching for “church accounting” and then signing up for a demo with the first vendor on the list is probably not a good path. The slower but more effective way is to start by looking inward. Create a small team who will be most impacted by the decision. Be sure to include the person most likely to be resistant to this change. The primary goal of this group will be to discuss things your organization likes most (and least) about the current system, concerns about changes, features everyone would most like to see, and learning about dependencies you were not aware of. Equally important will be consensus building and cultivating excitement for the new system. The team will be involved in change of which they are part rather than on the receiving end of change done to them. Such involvement will encourage the spread of knowledge and anticipation for the adjustments to groups with which they interact.
Out of these meetings we should create a functional requirements document. This contains a brief profile of the organization and how it uses the current system, features essential in a replacement system, and features that are not required, but would be desirable in an ideal solution. Now that we know what our organization is looking for, the internet can be a great place to explore options. Most likely we will find a bewildering array of potential replacement systems. Knowing what our team values most can help us to quickly filter out offerings that do not meet our requirements or are outside the range of budget.
At this point we likely have a handful of promising candidates and we can let our team know what we are considering and ask them to talk with their peers or other organizations to learn what has worked or not worked for them. At this point, it’s a good idea to whittle it down two-to-four choices and set up demonstration sessions.
Demonstration meetings are great times to see a solution in action and imagine how it would work for our organization on a day-to-day basis. Sending our functional requirements to a vendor ahead of demonstration meetings will make them more productive. And when the demonstration occurs, we include the whole team to allow for different perspectives and questions, which should be encouraged. Every vendor highlights the strengths of their solution, so we shouldn’t be bashful about asking tough questions about how their solution will integrate with current workflows or affect organizational procedures.
From these meetings we should get a sense of the organization and their solution. Are they pushy, helpful, do they hide the ways in which their solution will be disruptive or are they open and up front about weaknesses as well as strengths? Soon after each meeting it’s a good idea to gather the team and debrief while thoughts are fresh regarding the tradeoffs of each solution. After these have been conducted, it’s time to narrow down options to two (three at most), if possible, for final evaluations.
As part of this evaluation, the vendor should provide a detailed proposal including one-time costs, such as implementation, as well as ongoing costs, such as support, subscription fees, and the period of service being committed to. How is the system licensed, e.g., per user, or per volume of data? Consider how the church or organization may change in the next few years and estimate the three-year cost beyond startup.
For the finalist, references should be requested from similar organizations. If possible, it’s useful to have one or two people from the team participate in each reference call. Use these to ask how implementation went, what they like most and least about the solution, and if they would choose it again. After this, gather the team and discuss the findings. At this point, if the process has been thorough, one solution should appear as the best match for requirements and budget. The next step will be the hard work of implementation.
Choosing a major technology system for an organization is like choosing where to live. The effort to move is a significant undertaking that we don’t want to do again soon. So, take your time, build consensus, know the features needed, evaluate the options, and choose wisely. If the process has been followed carefully and with thoughtful involvement, the solution should be a benefit now and in the future.
Mark Evilsizor has worked in Information Technology for more than 20 years. He currently serves as head of IT for the Linda Hall Library in Kansas City, Mo. Opinions expressed are his own.