A few years ago, one of my younger readers asked me about a “hit by a bus list” (HBABL for short). So, I thought it might be good topic for an article.
First, it might be helpful to define what at “hit by a bus list” even is. The definition may vary from church to church, but basically it seeks to answer the question, what happens if you’re hit by a bus on the way to work one Sunday morning?
Can others pick up and pull a service together (while they mourn your unfortunate loss, of course)? A saying that I often use with my team is, “Just so I’m not the only person that knows this…” and I’ll fill in the blank with some bit of information that others should know.
Think of it this way, if for some reason you couldn’t be there on Sunday, what information do others need to know to do your job? That information goes on the HBABL. It might be key info like the login to the presentation computer, or password to the audio console.
It may be the location of the pastor’s mic or a detail on how he likes it set out. Depending on the size and scope of your ministry, this list could be one page, or take a 3-ring binder. You may want to break it down into chunks by position (eg. video, audio, presentation, etc.).
Regardless of how you do it, you need to find a way to get information out of your head and on to paper (or in the cloud if you prefer; as long as others have access to it!).
Before we get into a practical example, let me tackle the philosophical side of this. Some tech guys hoard information. They keep it all to themselves and believe it makes them more valuable. I argue that is a bad strategy. First of all, do you really want to be the only person who can turn on the PA?
Second of all, good churches need people who build into others and develop teams. TDs (or technical leaders) should be trying to share as much knowledge with others as possible. Getting off soapbox…
Back then, I called 2011 “the year of the volunteer” at Coast. I really want to start bringing in more tech volunteers and building our team. We had done a lot with systems over 18 months, and we were ready. This meant we needed to document everything.
Documentation makes it easier for the volunteers who serve once a month be successful. Sure they can call me over and ask questions, but when they can look at a checklist and figure it out themselves, they feel better about what they do.
So here’s an example (and it’s only one example) of what I mean. We had started capturing our service straight into FinalCut Pro for easier processing of the video podcast. To help facilitate that, I created the following guide for our video directors.
I walk them throughout he process, step by step, complete with screen grabs, so they can do the job. I beta tested it on my least technical volunteer; with no training I handed it to her and said, see if you can do this. She nailed it! So I knew we had a winner.
We created documents like this across all disciplines. Another example is our Presentation checklist—it’s a different type of document, but outlines what the presentation tech needs to do on a typical weekend.
A HBABL can take many forms; what’s important is that it works for your situation. It all starts with you sitting down and considering what you do every week (in detail) and committing it to paper.
Then edit out the unnecessary information, distilling it down to the most critical. That’s your list. I’m keeping this short so you have time to go work on your lists today…
Is your list ready? How do you plan for the unexpected?
