Requirements / User Stories for ChMS platform selection

Let’s say (hypothetically) that you’re a certified program manager, with a few decades of experience in leading technology platform development and organizational change management in large corporations. Then you took a career pivot to apply your skills and abilities to the not-for-profit / church community as a consultant.

You’ve been handed a “project” by a client to investigate changing their ChMS, but the initial high-level “requirements” list is really a list of tools they think might work better than what they have now. Being an experienced PM, you know that starting with a set of tools in mind is not going to necessarily lead to success.

QUESTION: does anyone know where I can grab a decent first-pass template on which to build out a complete set of requirements / user stories in the ChMS space? (Obviously ChMS reviews / surveys / polls provide some of this data, but I’m trying to not reinvent the wheel.)

Here you go - Nick has done a great deal of the work for you already!

Has filters to narrow down choices. We used Capterra for our initial selections to test.
Obtain list of needs from the client; especially pain points with current system. That will help evaluate needs.

The decision of fully web based, or local server based, or web with installed client based will send you in a direction of systems to look at.

Get demo logons from the various systems under consideration, and be sure client staff tests them. Do not just get ‘vision’ input from the leadership, they often only use the systems for directory info. You must speak with the church staff that are heavy users, they will know what information the pastors ask for, and how the office uses the current system.

  • Greg

This is actually a very challenging topic because churches usually look at this from a couple distinct points-of-view.


In a world with homogenous products, like “apples”, it’s easy to start the conversation with price. It is literally and figuratively an ‘apples-to-apples’ comparison. Traditional church management software provides a lot of the same type of functionality but over the years, many options have entered the marketplace that provide different flavors and focal points for the software. It is more important than ever for a church to learn more about how software is designed and what it is going to do for the church overall so that the price has context. For example, product A may be more expensive than product B but if product A has additional functionality that will allow me to reduce the burden on my administrative staff (saving time and money) or replace some of the 3rd party software that I’m having to pay outside of my ChMS cost, then the higher price may actually be a better value for my church. Additionally, if the software can help to intentionally get families on mission with our church, statistics show that this will account for thousands of dollars in increased giving for the budget. If a church rules out a software option based on price without that context, they could pass up the ideal software for their ministry.


There are a lot of reasons why starting with a functionality comparison is not ideal for church. First of all, the “list” of functionality that is used for any comparison is going to greatly influence the options that a church might consider. There are many reasons why a list might be less than ideal:

  • The list could be slanted toward a certain type of software (i.e. administrative software like the list above)
  • The list could be slanted toward a church’s past usage of software (i.e. They may not know that there is a better way to accomplish what they’ve used the software for in the past. They could be looking for functionality that is actually outdated or less efficient.)
  • The list could be slanted toward a particular revenue stream (i.e. A consultant could slant you toward software that his company services or a website could lead you to software that has paid more in advertising than others.)
  • The list could be geared toward the front lines (volunteers) and functionality, as opposed to the bigger picture of the church’s mission, values and goals - which is more of a leadership-level discussion.

These first two categories (price & functionality) are usually included in most RFPs or RFIs that churches send out to try to ‘narrow’ down the software that they will consider. After 10 years of helping churches through this process, I’m convinced that this mainstay from the secular business world has led many churches down a wrong path. Unfortunately, a mistake at this level wastes time, energy and money, while damaging the trust of the congregation when the church has to go through this process to change everything again in 2-3 years.


The most successful churches I’ve seen go through this process, regardless of the ChMS that they eventually chose, have been the churches that understand the importance of looking at the overall needs of the ministry first and foremost. Involving the church leaders in the conversation that can speak to that topic is crucial. Finding out WHAT the church needs the software to do can allow the software company to explain HOW it can (or cannot) accomplish the task at hand. It also allows the church to learn more about the vision and focus behind the software - what it was designed to do. It also allows a church to find out what type of relationship and support for their ministry that they can expect from the company in the future.

Just like it is important to understand the bigger picture of the needs of the church, there is also a bigger picture to consider about the company that is behind the software. Is this organization seeking to be a partner with you in your ministry or simply a software merchant? The main difference is that a software provider wants to sell you software as the main goal. A ministry partner would work with you to find the best software solution for your church, even if that is not their particular software offering. The needs of the church are greater than the desire for a sale.

For example, I was speaking with the son of a Pastor here in our hometown. He was extremely excited about how “easy” it was to sign up for their new ChMS. They didn’t even have to speak with a salesperson or go through a long process. They signed up, paid and they were ready to go. Fast forward two years later, they’ve realized that their choice was a disaster and that “easy and cheap” is not always the best way to go when dealing with something as important as ministry. The next time around, they started the conversation with the needs of the church and that led them to a new provider that we all hope will be able to serve them for years to come.

In summary, I just want to say that I believe that pricing or functionality alone are horrible starting points for a church’s ChMS evaluation. Starting with the needs of the church and then moving down through software options and how they would be able to solve those needs is the best way to find the right software for a church. I also believe that when dealing with something as important as ministry (and the eternity of individuals), looking for a quick shortcut to find a software package is simply poor stewardship. That’s just my 10 cents, for what its worth.

NOTE: Even though I work for a ChMS company, I admit that we aren’t right for every church. There is no silver bullet or perfect system. My hope is that churches will realize this as well and actually go through with the due diligence to find the right choice for their church. I hope that makes sense.

WrightMD, gbrenneman and DavidCoons … thanks so much for your responses.

I’m totally in agreement with this statement:

My only change to your thought DavidCoons is that rather than “pricing or functionality alone are horrible starting points” I’d say “pricing or functionality of specific solutions must never be included in the discussion of starting points”. In my 30+ years in the hi-tech industry I’ve seen waaaaaay too many slow-motion-trainwreck projects that started with specific solutions or initial cost considerations as constraints.

That’s not to say there can’t be technical or cost constraints on a project (there better be!) but focusing on them too early in the analysis and planning phases more often than not leads projects off the rails.

So let me return to my original question:

There’s a flood of info on the web that speaks to general concepts of gathering requirements (e.g., And obviously I can start from scratch to create a requirements list for my church client … I’m just hoping there might be someone on this forum who has walked through several such projects and has a “template” they’d be willing to share.