RX 24 - Mining For Gold: Lessons Learned from Moving to Rock - David Drinnon

Transcribed Content

Hello, everybody. Welcome to the second to last session of day one. Here we have David Drinen with Second Baptist Church in Houston, Texas to tell us all about his process of migrating to Rock. David? How are y'all? Good. Good. You're like, I need a snack. Well, glad you're here. How many of you are oh, sorry. My bad. Let's start over. Anyone need a snack? No. How many of y'all are in the process of moving to Rock? Like, you've decided, you funded, you're on your way, but you're not quite live yet? Just a show of hands. Okay. How many have recently gone live? Okay. A few, myself included. Anybody who's in the evaluation process trying to determine if Rock's gonna be the best fit? Oh, perfect. Okay. Well, I'm glad you're here because I think that the nature of this topic, we're gonna try to be somewhat comprehensive. I'm with Second Baptist Church in Houston, Texas. We're a multisite church and multisite school as well. We are less than a year into rock. We went live last October. And so all of the pain and sweat and tears that you're experiencing now, we're we're still showering from that ourselves. I mean, it's it's just been a a very long and tedious process. But I wanna share some lessons learned for you. We've named this session mining for gold, and it's my prayer and my hope that in all of this that maybe you find a few pieces of nuggets of gold of value that you can take back and help you with your implementation. Again, I'm with Second Baptist Church. We have six locations in Houston just to kinda give you an idea, but we have been around since 1927. So in three years, we'll have our hundredth anniversary, and we we have only had six pastors in our history. So it's been long tenured. So the blessing for us is we've had very mature processes in place over the years. And so to automate those and bring those into rock was to our advantage and made it easier. Now just to kinda give you an idea of of kind of where we've been and some of the lessons learned I'm going to share with you, moving is no easy feat. Y'all know this. And depending on the size of your church, the number of locations, the pain, you know, ranges from easy to extremely painful. So but we were migrating forty years' worth of data. We were basically 600 reports from our old system, which we couldn't take with us. We were literally having to kind of go from scratch. We're overhauling our event registration, our check-in system. So it was a big lift for us. There was a a number of the impact was not just on our staff, but on our laypeople because the check-in system was one. We had an app that was used by all of our bible group leaders, if you will, that both an app and a website. So all of that was in the scope of our launch. We we were trying to move a lot in a in a little bit of time. So the impact was huge. And just to kinda walk you through, we decided to strategize what had to be there day one versus over time. And so you've probably heard the term minimal viable product. What is it that you just have to have to go live? That was a very important lesson that we had to stick to, a lesson learned that paid off, was going through the decisions of knowing what needed to be there and what didn't. And so we had to work with a lot of our departments to set those expectations. A lot of of the success of your project has a lot to do with the expectations you set early on. So we set those expectations on what was in scope, what was out. And unfortunately, not all ministries are created equal. There is a pecking order. So so that's how we we kind of phased it in. Now in trying to explain what was in front of us, we had to make sure our staff knew the scale of this because a lot of them don't understand what happens behind the curtain. Right? They just, hey. Can can you just, you know, put the icon on my desktop and let's go? There was a lot going on behind the scenes, and it was important that when we set a date, we kept the date. It was important that we had priority attention of our staff because we had to do a lot of meetings to collect lots of information. So we had to make sure from the senior pastor all the way down, the priority of the project was was significant and the effort was was monumental. And so we'll talk about how do you do that in just a minute. But part of this illustration I show you here was to help them understand that when we migrate this data, it was a four data it was a four day process to move all of our data for us. It it was just a lot of well, I don't even know how to put it in words. But but just to kinda give you in numbers, we removed 861,000 plus people from one system to another. We had over 12,000,000 attendance records that were moved, 7,700 groups, a number a 12,000 prayer requests. And here's what was an interesting number. Over four close to 4,500,000 contribution records, which totaled $1,600,000,000. So this was a putting the scale of this in numbers helped our teams, our executive team understand, hey. Look. You know? And someone asked me yesterday, did the 2 pennies make it? And we were like, yes. The two pennies made it at the end of that dollar sign. So, you know, there was no one left behind. And, you know, so that this was the scale of what we're up against and the the challenges. So I'm gonna walk you through kind of the process of how we walked into this project and how we came out alive. Okay? So part of the setting expectations is really preparing the people, but knowing that there's different conversations at different levels of the organization. So with executive leadership, we had to kinda sit down with them and get commitment to say, hey. Look. We're a multisite church. In our in our organization, we have one senior pastor across six campuses. We have one budget for all six campuses. I know a lot of other models were a little bit different in the fact that no one sees financials, like no one has access to contribution information except for four people. So none of our pastors, none of our campus leaders, they don't have visibility into that. So we had a lot of different uniqueness, but it was helping them understand that, look, when we go into this, we're not implementing rock for six churches. We're implementing rock with as one church with standardized processes because we're human. Right? And we have a lot of different campus pastors who like to sometimes do their own thing. You got any of those kind of rogue mavericks in your organization? Yeah. Trying to pull them in, rein them in. So getting that commitment was important. Helping our leadership understand. We tried to use different illustrations to kind of cast the the scale of this. Building a building was kind of one of them. Taking all that money out of the bank and trying to move it physically to another bank, you you want to make sure it all makes it. So all these different ways, but when you talk with your leadership, part of the success is making sure they understand the magnitude of what's about to happen. And depending on the age of your pastors, you know, more or less, generally speaking, if they're not as tech savvy, you may have to do a little bit more communicating. We also wanna make sure that we, wherever there was data silos in our organization, we wanted to try to rule those out and eliminate those. So we had a very thankfully, I didn't have to do a lot of effort or work to lead this effort from the second chair when it came to the organizational structure of our church. We have clear chains of command in our organization. So for example, if I was at one of our campuses, you really kinda have two bosses. I have a campus pastor who oversees me and is responsible. I'm responsible to them for the everyday operations, you know, of of my particular role. But then I also have what we call a ministry or program chain of command. And that person, for example, like, we'd have one person over all adult ministry across all locations, one person over all children's ministry, all student ministry. And so it became easy for us because we would work with those ministry, heads of chains of command because they were the ones that would help us standardize processes across the board. So we weren't having to develop and build out different parts of rot for different personalities. And that was an important thing is that when you build out your system, you want to design it around processes and not personalities. Now, were we successful in that? No. There there was a few personalities, and of all places you might guess, they were in the accounting team, that we had to work around. But in the end, it went well. The other expectation and a lesson learned was going into this, we were quite overwhelmed with how are we going to train everyone. Six locations. Just to give you an idea, we have 1,500 staff. About 400 would have a login to our membership system. And so we're trying to think, Okay, we have an IT team that really is centrally located at one location. How are we going to transfer all of this knowledge? So part of the expectation that we needed from the very top was the expectation on all staff that that the responsibility of training and learning the new system is not that IT doesn't carry that burden. It's not all on our shoulders. So they helped us with that with setting that expectation. But these are all conversations you have to think about when you're either planning or in the process of trying to get your church over to rock is setting these expectations at the highest level. And because at some point in the process, someone's not gonna like a decision you make. They're not they're they're gonna argue that now I have to it takes four more clicks to do it now than I did before. You know, you're gonna have all this sometimes you're gonna have some dissenting voices at various levels of the project, and you need that executive backing to push through and not let small voices derail you. Now when it comes to talking with our our staff and laity, we set the expectation that we're this is a two to three year project. And when we go live, not everything that you have today will be there day one. And so we we had a triage, if you will. If you're in the medical industry, you understand what that means. You put priority in order on the different areas of the system. And that's what we did, and that's what we've been doing. And so we had a three year road map to to reintroduce all the features that we once had and some new ones along the way. And as politely as you can, let people know that everyone has a voice, but not everyone has a vote. Right? That that's the art of of loving and caring. Right? So that's where you get your pastors involved. IT people aren't the best of that. Alright. So the other part is and we didn't really realize this at first. I mean, we had thought about it, we would have. But we were so focused on go live, the cutover, that, you know, the the reality that every month for a year after go live was another go live of sorts. Anything that you do seasonal, it's another go live. So it's really a year of firsts is really what happens. And so if you're leading on the if you're on the project team or leading the project team, trying to find that cadence and that balance to know that, hey. Look. It's not go live is not just the finish line. It it it's it's really the halfway point in a in a lot of ways is a helpful expectation to set. Now when we worked with Triumph, Triumph is the team that we worked with to do our implementation, and they did a phenomenal job. And they had an illustration that we borrowed and we shared with our staff is imagine, you're trying to switch out the jet engine on an airplane mid flight. And maybe you've heard that illustration already. It is an adequate one and one that we use frequently. So I think it's helpful to people let people know. This will be there will be challenges, and and this just comes with the size and scale of any implementation like this. Now I've covered a lot of these, so I'm gonna go through these. I really wanna make sure we have time at the end for some q and a too as well. The other thing too is we were very honest with the ministries that we saw going into the project that were gonna come out with the most pain. Our prayer and care ministry, we knew they were going to feel the brunt of this more than any other department. We are coming from a system that we had developed largely on our own, custom developed. About 80% of it was custom developed. The other 30 part was a was a third party system. And we had put more effort and code and development into the prayer module than any other part of of the system. And so we took several steps back when we moved, but, honestly, it was a healthy thing. They needed to they were overly engineered and complicated in their processes. But in the end, they're functional, but they are still waiting in line for things that they want. But setting that expectation up front helps you, avoid a lot of frustration later. The one thing I hated doing, and, actually, it did happen often, but there was a number of things that I had set the expectation that would be there at GoLife that didn't make it. And I kept resetting that expectation probably eight, nine times for the first three months after go live. And that was my most stressful was you just can't go back to the well more than once or twice. Trying to reset expectations is very difficult. And so doing that upfront, I think, saves you a lot of grief. And at the end of the day, not everyone benefits the same. And casting that vision with your staff is important that, look, we may take two steps forward, maybe even three steps forward with this new implementation, but we may take one step backwards. But in the end, it's still a net gain for the ministry of the church. And trying to help them shape their expectations, not around my specific area of responsibility in ministry, but look at it from the perspective of the whole. So setting and casting that vision helps. Couple of different strategies we use to to kinda execute on a lot of these principles. Our big thing that was we found successful is what we call our roadshow events. So IT would literally go to every location. We went to them. We didn't make them come to us. We we went on their schedule at their convenience. We brought snacks. We had drinks. We had giveaways. We did t shirts. We had one campus that was so excited. They even had my name printed on a t shirt with a a guitar. It said, Drennan Rocks, you know. So and then there was Pet Rocks that started emerging and coming to our office through the interoffice mail. So I knew we were being successful in building excitement, but those roadshow events were hugely helpful. And here's what we did at that event. We would basically start by giving them casting the vision, the effort involved, the priority of it, and then we would give them just some screenshot snippets of some of the coolest, best features in rock that they didn't have already in the system we were in. We wanted to tease them and show them that, look, we are leaving Egypt and we're going to the promised land. Right? And once we get there, we don't wanna go back to Egypt. So we wanted to set some expectations that, hey. Look. This is what we're moving towards. We kinda teased what Rock was going to be able to do with them. And they don't have to be profoundly huge. Little things can go a long way. And so try to identify those and knowing what grabs the attention of our our staff was important. And the giveaways didn't help either. They didn't hurt either. And we even had a Dwayne Johnson cardboard stand up. No. He did not come in person, though we we thought about that would be cool if he came up at go live, but that didn't work. Yeah. I don't know if he would yeah. He okay. So it might have been inappropriate. Anyway. Alright. So, some strategies we didn't use, but I wish we had used. I wish we had recorded every meeting. We recorded several, but not all of them. I wish we had recorded every meeting. And in hindsight, if we had recorded every meeting, in the meeting, we would have introduced verbal cues like, this is a decision item or this is an action item and use very specific terms, get the transcript from Microsoft Teams, and then use AI to summarize the transcript and to organize it based on decisions and action items off those verbal cues. Does that make sense? So that was a strategy that that really didn't hit us until later. But that would be that was hugely helpful because I can't take how many times we would meet, get so deep into the weeds, make a decision. We didn't document our decision, and then two weeks later, like, would we decide on that? I don't remember. It was so complicated, And we pulled the audience, and everyone had a different take on the meeting. And we wasted time on the project. So documenting your meetings coming out of them, having a notetaker or recorder, or if you don't like the technology side of it, that's an alternative. So that was one thing I wish we had done more often was documenting our progress. Now, building the system. So now we've set the stage. We've talked with everyone. We're moving forward. We're building the system. And so let me give you some tidbits on working with consultants. Now, I kind of giggle a little bit because I didn't know the consultants on our project are in the room today. So I was like, oh, wow. So but there's no negative reflection on them. But there are some things to learn along the way. Inspect what you expect. Right? Now we didn't have the same project lead along the course of the whole project. By the way, our project implementation spanned two years. So until we got to go live. It was a long time. Now there was wasted time on our end and things we learned that we could do better. But inspect what you expect. Learn the functional areas of rock. This was one thing. It had nothing to do with our consultants, but had everything to do with us. We didn't learn rock for ourselves before we really got into the decisions of where our data would land in Rock. So we would have to stop, pause, get educated on the different area or options of Rock that would best fit that ministry process, then decide it, and then start, you know, working and focusing on the migrating of the data. So we could have done a better job, and we spent more time, really and we did the Rock Masterclass, but it does not get you anywhere close to what you need to know to really understand how best to bring that data over into your system and to maximize, to tailor fit Rock to your needs, if you will. And build time into the project to transfer knowledge from consultants to your internal support team. We had planned on doing that. We have not done that. We went live in October, and we still have a regular retainer with lots of hours and awesome friendly visits with our Triumph consultants. So we love them. We really don't wanna let go of them. But at some point, financially, you've gotta build in time to transfer some ownership of that. Now let's talk about transfer of knowledge because this was what worried me the most in this project. Was well, one one was the timeline. Two was, look. We can roll out the software, but no no one really takes the time to learn it. It it will fail. And how are we gonna train that many people and to the to the level of proficiency needed for them to feel successful and that there's no disruption to their ministry. We did a couple things. One, we trained the trainer. That was our model. So we actually went to each campus pastor. We asked them to provide three to five people from their location. We wanted specifically one person representing each of the major program areas, adults, kids, children. We wanted people we gave them kind of a biographical profile of kind of the type of person we're looking for. We're not looking for pastors. Right? Most pastors are great with people skills, but, you know, they don't you know, a formula in Excel, they're lost. So you want to find the right personality, temperament, and the skill set to be on your train the trainer team. And that was extremely helpful because what it is, it really brought our training effort from 400 people down to, like, 20, and that was much more manageable. And so we would spend a number of Teams meetings. We did a number of other tools to create training material to get them up to speed, and then we put it on them to schedule their own training at their own location. So IT did not have to coordinate all the schedules for all the locations. Train the trainers. We totally empower them to run with it and go with it. Now there was a tool that we found that was game changing for us, and it was scribehow.com. Has anyone ever heard of scribehow? Okay. A couple of you. Now we debated what was the best way to, you know, transfer knowledge. Is it video? Is it, you know, Word docs with screen, you know, pictures? Is it in classroom teaching? We looked at all this different thing. But what we determined was ScribeHow was going to be the best tool for us. One, it's hard to watch a video and do what the video is telling you to do on the same screen you're trying to do it on. Does that make sense? And so that was one of the challenges we ran into. The other challenge is, you know, if you miss something, have to rewind. You have to go back. It's very cumbersome to kinda the video is too fast because some people are too slow. They need help. So we went with ScribeHow. ScribeHow is basically an automation tool that takes all of the screenshots of yours and puts it in a step process. And then it you can, create a link to it, And then you can create it exports to PDF. So we did all of our documentation in Scribe, exported to PDFs, organized it by area of functionality, and that created our training manual for our trainers. And we only printed training manuals for the trainers so they could notate. And then all of what they did is they took and ScribeHow, the way it lays out on the screen, that's how we did a lot of our classroom teaching. We just pulled up ScribeHow because of the way it visually displays on the screen was very efficient. So they didn't have to go build out a bunch of PowerPoints. So that was kind of the way we we did that. ScribeHow also has a place called pages. And a page is like a landing page for you to have a list of scribes. A scribe is basically a stepped visual tutorial. So we created a a single page for the different areas or functions of our church, and then we linked all of those pages to one landing page. And then we put an icon and rock that took you to that landing page for all the training. So we had all of our training material right off the Rock menu and easily accessible to them as well. We also used SharePoint. We use SharePoint. Microsoft SharePoint is an intranet in our organization, and we would put updates there as well. And then use Teams quite a bit. We use Teams quite a bit on go live weekend. We we had staff at every location. And on go live weekend or the weekend following go live, we would have basically staff at every location reporting in on how check-in was going. And so visually, I could see in one place what was going on, what issues were happening, and all of us so we had a core team monitoring for issues locally and then centrally, and the central team did all of the issue mitigation. So the the team that was in the field was basically communicating and giving us context to ensure communication went quickly. And then the central team did all of the issue remediation. And if it could be resolved then, we could do it. If not, we would give them workarounds in the process. So Teams was very helpful for that. And we also had a texting keyword through Clearstream so that anytime on the weekend, our staff could text to 9 and report any problems or issues or concerns. And that would hit everyone on the support team so we could respond quickly to it. Maintaining momentum is very important. So we were intentional about having one point of contact for all support requests. We didn't want to so we had a help desk ticketing system, so everything goes there. One place to go for all ongoing updates and fixes. We would use our intranet to post updates and then one email a week to push out updates. So we had a a push and pull communication methodology. But one of the things that we found extremely helpful, though it didn't really work, but it was still a good idea, we we teased everyone with special features that we knew they would enjoy, but we held some back. So we have the the Outlook plug in for Rock. You y'all are familiar with that that feature? It's a wonderful feature. We kept that under lock and key, and we introduced that at go live, to try to, like, oh, wow. I you know, Christmas, I opened my present. I don't know about y'all. Most kids my most of my kids know what they're getting on Christmas morning before Christmas morning, but we left some presents out for them to open up and build some excitement. And then we identified a few issues to roll out in the second, third, fourth month to maintain a level of excitement. Things that were ready to go, but we held them back for the pure purpose of maintaining momentum and excitement so that they didn't feel like what happened on day one, and that's it. Like, that was all. That that's all we're gonna get? No. There's more coming, and that kinda set the pattern. So that was kind of some of the lessons learned along the way for us in implementing Rock. So I'd love to if there's any questions, I know that was pretty quick, but open it up for questions.