ChMS evaluation criteria

We are evaluating candidate ChMS systems on the following criteria:

1. The company. We expect to run the selected system for the next 5-10 years. Accordingly, we are looking for a great ChMS supplier that will meet Resurrection’s needs now and in the future. Has the company attracted and can it retain a great management team? Does it have a great reputation for product quality, timely delivery, and responsive customer support? Is it financially strong? Does it have a compelling product vision? Does it have healthy relationships with other companies and organizations in the ChMS market?

2. The technical platform. We are looking to minimize long-term platform risk by selecting a platform in the mainstream of technology that will adapt over the life of the system to as yet unknown future requirements. Further, we expect to integrate other applications and systems with the ChMS in configurations that may be unique to Resurrection. Accordingly, we are concerned about the technical aspects of integration like APIs and data exchange formats that will allow us to develop our own innovations. We prefer a product at the center of a vigorous marketplace of 3rd-party products, professional services, and so on.

3. Product functionality. We are looking for a rich, full-featured church management system that at minimum has an equivalent way to do everything we do now in Shelby V5 Church. Second, we need to achieve executive management’s project goals – to greatly improve our ability to track interactions with congregants particularly in adult discipleship and congregational care (CRM-type functionality) and to provide better reporting/graphing for decision support and tracking progress on annual church-wide objectives (management dashboard). And finally we’re looking as much as possible to address user desires uncovered during requirements gathering.

4. Product usability. We are looking for a system that is intuitive, elegant, consistent, discoverable, and requires minimum training for web-savvy users. Page layout and choice of controls should follow Microsoft user interface guidelines and other best practices in web user interface usability.

5. Project risk. We are looking to minimize the short-term risks associated with executing the project. Being averse to cost and schedule risks, we need to stay within the available budget and have a successful cutover by June 30, 2008 at the absolute latest. Additionally, we need to convert existing data to the new system with a high degree of confidence in data preservation. Finally, we need to feel very comfortable about the training and cutover plan to minimize user disruption and ensure widespread user adoption.

6. Cost. Our estimate of total cost of ownership over the first 3 years is the final consideration. We will not automatically select the least costly option. Rather, cost is one of the six factors affecting our decision. Naturally, if the cost is beyond our budgetary ability, then it would be decisive.

I'll post again soon about our finalists.