KevMcCord

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.