KevMcCord

Picking The Next Tech Project

If you find yourself in the rare position of having to decide which technology project to do next at your church, pick the one that's most likely to work (technically) and succeed (missionally).  Look for the project that has:

1. High Excitement From the Pastor/Executive Team
2. High Excitement from the Ministry Team
3. Positively impacts the largest number of people at your church
4. Negatively impacts the smallest number of people on your staff
5. Has the clearest set of requirements
6. Has the lowest degree of complexity 

The trick is the last two criteria.  You (Tech Guru) may not be able to control the first four things, but you can impact the last two!

1. You are in a position to clarify requirements.  This means getting to the bottom line things the new technology must do.
2. You are in a position to decrease complexity.  This means finding working models your church can afford and copying one of them.

Chances are...

1. You're smart enough to improve on something someone else is doing or to make it fit your church.
2. You lack the time, experience, and resources to re-invent the wheel

Then again, do you really get to pick the next project?

Church Technology Projects

How we do it:

• Pastor is going to announce "such and such" to the whole church in three months so we need to go research (no time), buy (no money) implement (no long term plan) something because a gazillion people are going to go online and do this the day we launch it (also the day it will be announced).

How we should do it:

• We've had some pretty good results with this new technology we put out there quietly last month.  It was pretty obvious we needed it last year when we decided we weren't ready to automate that thing pastor wanted us to do.  Good thing pastor asked the elders for a budget and gave us enough permission to get a simplified version of our ultimate goal online.   Turns out we didn't need for it to [insert flashy feature here]. Pastor is ready to promote it to the church as part of next month's teaching series and we're sure it will work.

There are churches that do it right most of the time.  There are churches that talk about doing it right next time.

It's been my experience that pastors are reasonable people (as a rule).  I find it is often the people in the middle, those between the doers and the deciders, who over-promise.

What Do People Do At A Multi-Site Church?

Note: This is the 5th post in a series about a data model for multi-congregational churches.  I will use the terms multi-site and multi-congregational churches interchangeably.

What Can People Do In a Multi-Congregational Church?  More specifically, what does an individual do that we want to track and measure

The database is a reflection of the real world. In the real world...

• People can join groups with specific ministry roles (ministry positions).
• People can attend events
• People can accomplish milestones along journeys like spiritual formations and connecting to the church
• People can respond to opportunities to serve
• People can submit feedback (prayer, praise, comments)
• People & businesses can make contributions
• People & businesses can make pledges for future contributions

It would be possible to store all the above data in just one or two database structures, but we decided against this approach.  We separated the different types of activity into separate structures.  Our approach can be summed up with the old adage “a place for everything and everything in its place”.  

This approach results in a few key benefits.

• Users with responsibilities in one area aren’t distracted by data from the others.
• Security can be used to keep users out of categories they should not see
• Reporting is easier since the data is already separated.
• Each type of activity can be related to the Ministry Departments and Campuses in the most appropriate manner.

This brings me to rule #6, #7 & #8 for a multi-congregational data model:

#6: Don't confuse activity by the church in relation to an individual with activity by the individual.

#7: Structure the database so that users will know where to put things in anticipation of the reporting needs of the church.

#8: Connect the various structures (groups, events, milestones, responses) to the ministry and congregation structure so we know which department is responsible as well as the campus where it took place.

Practical application:

A church is interested in knowing whether the people respond to an opportunity to serve are getting connected to that ministry.  People can respond online and through connection cards in the worship services.  The church can also send an email solicitation to people about the opportunity.

All responses are logged in the Responses table.  The response record is followed up by the contact person to that opportunity.  Periodically the church can see what percentage of responses are placed in the specific ministry group to which they relate.

The email sent to people about the opportunity is also tracked, but not in the responses table since that solicitation was initiated by the church.

What Is a Ministry?

Note: This is the 4th post in a series about a data model for multi-congregational churches.  I will use the terms multi-site and multi-congregational churches interchangeably.

Go to a church and ask them what ministries they have.  The list might be really long!  Sometimes the word is meant to indicated a department of the church like Children or Women.  Sometimes the word is used to indicate a specific activity that happens weekly like Sunday School.  Sometimes the word is stretched to cover something as simple as a quilting group that meets weekly to make quilts for people in need.

The reason the word is used in so many ways is because in a church ministry is also a verb.  Anyone can do ministry and any ministry that is done by the same people on an ongoing basis gets called a ministry.

Using the word Ministry in our data model turned out to be somewhat confusing.  Frankly, if I could go back I might opt for the generic word "Department" instead!

Still, when we used the word "Ministry" in our data model it was synonymous with the word "Department".   Ministries in our database for multi-congregational churches were fairly permanent and had clear, stable leadership and regular activities.

So, one way to describe a multi-site church is to talk about it's ministries (aka departments) and its congregations (aka campuses).  These two structures are the main pillars of the entire database.

This brings me to my 4th and 5th rules.

Rule #4: Ministries should only be listed once in the multi-congregational model.  Groups, Programs, and Events should be related to a central list of ministries.

Rule #5: Ministries and Congregations are not the same and should not be confused.  The Ministries of the church work in and from the congregations of the church. 

Practical application:

A church that has experienced significant growth is now maxed out in it's main campus.  There are over a dozen departments serving the community and the people who attend that church.  A decision was made to start a video campus in a remote location where many church members live.  The Children's, Worship, and First Impressions Ministries will build teams to serve the new location.  A new ministry called "Remote Campus Leadership" will be created with at least one team.  Over time some of the other departments like Students and Women may also build teams at the new location.

Families Should Worship Together

Note: This is the 3rd post in a series about a data model for multi-congregational churches.  I will use the terms multi-site and multi-congregational churches interchangeably.

Attending church is a family activity.  This doesn't change in a multi-congregational church.  A traditional church database being used to track multi-site church ministry may force the church to track each individual's primary campus separately, but this is both inefficient and misleading.  It is very easy to get a family out-of-sync in the database. 

While there are exceptions, the church assumes and expects that individuals from the same household will worship at the same time and on the same location.  Furthermore, the multi-congregational church will generally assign care and assimilation to teams at each congregation (aka campus).  Those efforts can be divided and confused if different members of the family are assigned to different congregations for care.

This brings us to another rule for our data model:

Rule #3: An individual's primary congregation is indirectly determined by their household.

As we developed our multi-congregational data model we made a choice to have an explicit record called a "Household" that would link people from one family together and allow the church to easily track the following things (among others):

1. The family's primary congregation
2. The family's primary address
3. The family's home phone number

If this were the extent of our deliberations we would have hit some real problems!  It wouldn't take long to come up with exceptions whereby an individual in a family is attending events at other locations or participating in groups from different congregations!  

This brings me to an important principle: accountability should exist, but it shouldn't limit participation.

Our multi-congregational data model allows for an individual to belong to a household that is accountable to a primary congregation while attending groups and events that are based in other congregations and take place at other church locations.

Practical Application:

First Church is about to launch an "East Campus".  An appeal went out to families living near the newest location.  45 people from 30 families have committed to participate in this effort.  A new "Congregation" was created in the database and those 30 household records were updated to indicate their intention to begin to worship at this new place and time.  Many of those 45 people will continue to belong to groups from their old congregation and attend events at the existing locations.  Over time, their group roles and event attendance will probably shift to ones based out of the new "East Campus Congregation".

You Might Have More Congregations Than Locations!

Note: This is the 2nd post in a series about a data model for multi-congregational churches.  I will use the terms multi-site and multi-congregational churches interchangeably.

A good database model will prevent redundancy and promote clarity!  When you attempt to use a traditional church database to manage multi-site ministry you often end up listing your congregations several times in different areas of the system!  This complicates many tasks including basic navigation and reporting.

Rule #1:  We want to list our Congregations once and only once.

When I began modeling multi-congregational churches a few years back it became clear that some multi-site ministries were more complicated than others!  In some cases, a church has multiple congregations in one location!  This is most common when two different language groups worship at different times in the same location.

Rule #2:  Many Congregations can share the same location.  We need a separate list of locations.

While multi-congregational churches come in several styles.  It is best not to assume that there will only be one congregation at a single location.  Churches widely refer to their sites as "Campuses" and even use this term to refer casually to the people who gather for worship at those locations.  The word Congregation is not used by most cutting edge multi-site churches.  Public facing software may need to accommodate this common practice.  For instance, when someone goes online to make an offering they may need to be asked to "pick their campus" if that is the language they expect.   However, depending on the culture they might be asked to "pick their church" or "pick their venue".  Regardless of the public semantic in use by a church the multi-congregational data model needs to prevent redundancy and promote clarity!  For this reason, the list of congregations and the list of locations should be separate and exist only once.

Practical application:

Maria is the administrative assistant to the First Church Español.  When she books an event, she clearly indicates it is for the First Church Español (a congregation), but the event will be held at the Central Campus (a location) so room availability should be checked against all the events in that location by all congregations that use that location.

A Data Model for Multi-Congregational Church

 A congregation is defined as the assembly of people for a given purpose, a corporate body whose members gather for worship, or the members of such a body.

A multi-congregational church is a church with several related, but distinct congregations.  Groups within the church assemble at different times and in different places for corporate worship.

These days you may hear the term "multi-site church" or "regional church."  In my opinion, these terms describe a subset of multi-congregational churches.

I believe every growing local church will become multi-congregational.  Either it will...

1. Help to start another church, or
2. Strategically launch ministry in multiple campuses, or
3. Support a different language group, or
4. Develop different worship venues in a single location, or
5. Engage a combination of the above strategies.

In the multi-congregational church (aka Multi-site or Regional Church) the congregations share leadership, vision, teaching, resources and administration.  In some cases this is a permanent reality.  In others, it is a temporary reality.

I accept that there are exceptions, but I will deliberately ignore them in my effort to support and organize ministry.  I am willing to bet the vast majority of exceptions aren't growing if their short term plans do not include at least one of the above.

I believe church management software systems must have a multi-congregational data model.  In fact, I designed one.

My next few posts will explore the multi-congregational data model.

Raking Data

Yesterday I raked a lot of leaves.

Raking leaves and analyzing data share a number of similarities.

You don't rake leaves unless there are enough leaves to make it worth your while.  You don't analyze data unless you have enough of it to make it worth your while.

If you don't rake often you'll get blisters and you probably won't have the best tools.  You may even avoid the job.  If you don't analyze your data regularly you may find it hard to begin and painful to accomplish.

Gathering the data is hard work, but it isn't quite half the work.  You still have to do something with it.  Getting leaves in piles is not the end of the job.

If you have a lawn mower that bags debris you can cut your grass and get the leaves up at the same time.  If your information management systems are well designed analysis is built right in.

No one rakes leaves efficiently the first time.  There are tricks you learn from trail and error and from watching others.  Someone who rakes leaves for a living expends less energy and gets more done.  Analysis tools like Google Analytics are designed for websites with millions of hits a day.  You can leverage a tool like that even if you have a little church website.

There is a beautiful yard under there (you think).  You may find out the grass is dead when you pick up the dead leaves.  You always begin data analysis with an assumption.  Some people don't want to rake the data and find out the assumption is wrong.

In the end the analogy breaks down since data is useful stuff and dead leaves aren't very useful.  In both cases though you can get a sense of accomplishment when you look at the finished product and you bring order to chaos.

I have a lot of data to rake this next few weeks.  I need to know what I'm going to do with the data before I get it all piled up.  I need to list the questions that need answers, confront my assumptions, determine my goals, and mock up the final product before I start raking it together.

ChurchTeams Article

I'm very interested in ChurchTeams because many of my clients are interested in ChurchTeams.  The company has demonstrated a solid understanding of small group ministry and they have developed what several users tell me is a very usefull tool to connect people to groups and then manage those groups.

When my Google Alert on Church Databases surfaced this article today I read it with interest.  It deals with a topic that I deal with daily.  The question that is the title of the article is "The Problem of Two Church Databases R U Sure?"  Here's a quote from the article...

It seems to me the shepherding and discipling you can do with Churchteams is worth the inconvenience of updating databases. For whom is simplicity a higher value - paid support staff or front line volunteer leaders?

I posted my comment on the article, but it is still awaiting moderation.  So I thought I would share my comment here.

Boyd,

I can appreciate your thinking. People are surprised when they hear me tell them to go with what works even if it means separating their data. I believe we have been over-sold by some major ChMS vendors on the promise of what they can do.

What I hope will happen is that companies like yours with tools like ChurchTeams will dilligently pursue a full featured Church Management System with which they can truly integrate.

The problem isn’t that we have just two databases it is that we have 5 or 6 (check in, contributions, small groups, worship teams, events, etc).

At some point those of us in the back office become servants of the tools instead of servants of the ministry.

Blessings,

Kevin

Getting People Into Groups & Teams

It shouldn't be any harder than...

1. Setup groups/teams and describe them.
2. Setup people and describe them.

Then you can run a report that...

1. Selects a person and show the best group/team matches.
2. Selects a group/team and show the best people matches.

Today I wrote two reports in about 4 hours that do exactly that.  However, the reports themselves are not the big deal, the two stored procedures behind the reports are the big deal.  They can be referenced by a web application.  Imagine that you are the small group leader and you log in and see people who are candidates for your group.  On the other hand you might be a person who logs in and sees the groups that are the best candidates for you!

For this to work you have to have the following ingredients:

1. A database that handles the data properly.
2. A system for managing the data and user interactions with the data.
3. People who will enter the data diligently.
4. A way to deploy the information to the target audience.
5. A target audience who will engage the information and then connect with one another.

We've got 1, 2, & 3 covered, but we need #4 before we can engage with #5.  #4 is where our old tools failed to deliver.  Good thing we are working on fixing that.