As we prepared for our rollout, we knew we needed to find a way to make certain that the ministry teams at all our campuses had the support they needed to hit the ground running on our new system. Yes, we did spend time training and preparing, but the real test is when the system is live and you have to get your job done because Sunday is coming!

We ended up setting up “Triage Rooms” at each campus for our first two weeks of production on Arena. Yes, we realize that for many of you this brings to mind images of M*A*S*H and a bloody operating room, but we called them that anyway! We found a central location that was convenient for the teams at that campus, stocked those rooms with candy and snacks, and manned each one with members of our team so that we could provide face-to-face support. We do have some unique challenges because of the size of our staff and the fact that we are separated geographically, so being onsite allowed us to provide a personal touch, which went a long way to providing a comfort level to our ministries. We didn’t know how effective this would be, but it ended up being a huge success!

A lot of work certainly went into getting us to this point, and we look at this as just the beginning. Now that we’ve built the foundation (yes, we still have a few “punch list” items to take care of), we are excited about adding on to that foundation to provide new tools, sites, and systems to the ministries at our campuses. This is one of the (if not the) biggest technology projects we’ve ever undertaken, and using these triage rooms helped us provide the support and customer service our ministry partners needed to be able to confidently do their jobs using the new system.

How do you support your church when you make a big change?

It’s challenging a lot of our staff and management to really ask the tough questions about how to best motivate employees and team members.

Here’s a video that explains some of the book, etc.

What is motivating your ministry and tech team?

Is it food? Is it money? Is it something else?

How would you be better suited to motivate?

Answering these questions can seriously change your work environment, for the better! And, I’d like to think that we’ve got a great work environment to begin with!

• As much as we technologists might like playing around with computer systems, and as excited as we might be about launching something new, not everyone feels that way. It’s important to keep in mind that we very likely might be in the minority when it comes to this, so we should remember that in our delivery, planning, etc., and not assume that others are as geeky as we are.
• It’s important to try to be as specific as you can, with realistic examples and exercises. It’s hard enough to remember your training once you start using a new system or application in earnest, but if the exercises were more theoretical than practical it will be even harder.
• As much as we’d like to think we can train everyone so that they can hit the ground running once a new system is implemented, that’s just not reality. Our own experience supports this fact. There’s always a ramp-up time of regular usage before someone is truly comfortable using something new. This certainly doesn’t mean that we shouldn’t train people; rather that we should realize that formal training is just one piece of the puzzle. We are planning some follow-up targeted training, video screencasts, and other ideas to provide ongoing training for our staff.
• Make it fun. We’re firm believers in the Fun Theory around here, and while we might think a full day of computer training is fun, not everyone does. So come up with something that can make training fun - we played trivia games after each break (What does the word Arena mean in Latin, and why?) and incorporated some small prizes.
• Have good snacks! We had soft pretzels, ice cream, and other goodies for our afternoon breaks, plus an assortment of candy, gum, fruit, etc., for the entire day. Everyone enjoyed getting to eat some candy they hadn’t had since they were kids (chewy sweet tarts, anyone?)

So what do you do to train your users?

Add trying to coordinate a few crazy-busy people to drop blog posts can drive people over the edge…! So how can it be done? What’s our strategy?

Very simple: Create a Master Schedule, assign dates, and then commit.

It’s that simple really! What we’ve done is assign our team specific friday’s to blog and then we trust that person to write. It’s not too complicated and it really can work.

We also help each other out when we’re struggling to come up with topics (because not all of us are born-bloggers). We’re a team, remember?

Have you got a strategy for posting blog posts on your church’s properties? How’s that working out for you?

Every couple of months or so we get a request for embedding a video within an email. Our immediate reaction is to do a spit take (I think I actually did one once), so we wanted to let you know why this makes us shudder to think about. The answer will always be no, and here’s why:

1) There is the question of web standards and quality.
Wait, why are you talking about the “web?” This is about emails. Yes, yes, an email now-a-days is basically a un-glorified web page. I say un-glorified because, while it gives you the ability to have pictures and different colors and fonts and stuff, it doesn’t let you take advantage of 98% of the aspects of a web page. There are no css files, no forms, no includes, no jquery and NO EMBEDDING OF VIDEO.

On the web you can embed a video, and you can also set the option of having it auto-play or have the user click to play. At first thought, “autoplay’ sounds good - one less step the user has to take to enjoy your wonderful cinematic experience. Normally the less clicks the user has to take, the better. This is not true with video. Ask any web monkey what they think of “autoplay” and they will give you a look of horror and disgust (similar to asking about using comic sans on a page). Imagine opening up an email and suddenly having someone start talking to you. Better yet, take 3 out of 4 random spam emails from your spam folder and imagine them in video form. Not a pretty picture huh? So this is case #1 against the concept of embedding the video in an email.

2) Email is for text. Web pages are for multimedia.
45 years ago Email was originally created for the sending of text and the ATTACHMENT of multimedia (i.e. images/video). The web was created, and is used, to display text/images/video/flash/forms etc. That is why it was created and has evolved to what it is today. While still not standardized 100%, the web is pretty refined and we know that there are 4 commonly used browsers we can develop for (IE, Firefox, Safari, Chrome (sorry Opera and all Linux browsers)). This brings me to #3.

3) Your favorite email client is not everyone’s favorite.
Do you use Gmail? Yahoo? Hotmail? Eudora? Thunderbird? Apple Mail? I could go on. There are too many email clients that treat/render HTML incorrectly, if at all! Even if it displayed it properly, some clients block or send to spam emails that have too much code in them. Javascript? Nope, not in email. And for good reasons, too.

4) What about phones, Blackberrys, etc.
How many emails do you get a day that don’t look right? Those emails probably use images so imagine getting a video email. What do you see instead? Do you get a broken email that uses images as the fail-safe? How many broken emails do you get that don’t have text as a fail-safe? Insert can-of-worms here.

So to sum things up: Email is not the medium for this type of multimedia. While I understand the enthusiasm about sending an email with a video in it, I do not agree with trying to put a square peg in a round hole.

This year we did something special for our staff. I wanted to hang one of these up in front of our copiers and printers, but a very wise person advised against it.

Therefore, we altered our internal DNS to point all traffic to social media sites to a custom internal site straight outta the 90’s. There were about 18 domains total that we redirected, including the usual suspects like twitter, facebook, etc. We kept it up for about four hours and then took it down.

Also (to make it seem like this post is helpful in some way) we set up Casper to run the dscacheutil -flushcache command on everyone’s computer to ensure that people could resume their social media activities as quickly as possible. Anyway, here is a video of it in action.

So, we created some Social Media Guidelines to help educate our staff about acceptable usage, etc.

You can take a look at our policy here.

The process we’ve gone through has confirmed a couple of things for our team:

• Data migration isn’t the most exciting task - unlike new site designs or cool apps, no one tweets about how smoothly a data migration goes.
• It’s not as simple as it seems - especially when you’re moving from old systems with non-relational databases.
• The devil’s in the details - mapping the major fields is usually straightforward, but then there’s always that “oh yeah, we also need to have this attribute in our new system” that you have to account for.
• It’s important - I know we would all rather spend time thinking about the front-end design, new features and functionality, etc., but that shiny new site will get pretty ugly pretty quickly if it doesn’t work because the customer or user data isn’t there.

So the main lesson we’ve learned is that we need to set aside sufficient time and energy to ensure that the underlying data for our sites and systems is complete and accurate.

Exciting, huh?