RX 24 - Rock Your Rock Implementation - Emmy Friesen

Transcribed Content

Welcome to the NAP session of day one. Please give a warm welcome to Emmy Friesen as she's gonna go over Eagle Brook Church's process of migrating to rock. Thank you. Thank you. There we go. Hi. I'm Emmy. I am from Eagle Brook Church. I am the technology project manager, so I was very involved with our rock migration. I've been on staff for three and a half years going on four. Yeah. And it's today, we're gonna just chat about our project, what went well, what didn't, and what strategies we used as we approached it. Before I start, a little bit about me. So I'm married to my husband, Kale. We've been married for almost four years. We have an adorable toddler named Henry. He's wearing his best chip adjacent outfit there. I had to include that. And then we have our dog Arnie. He's a Wheaton Terrier, and he's very silly. We like to go on walks together, explore the Twin Cities, and watch Packers football. So big packers fan. A little bit about Eagle Brook before we get started for context. So we're based out of Centerville, Minnesota, which is North of Saint Paul, but most of our campuses are within the Twin Cities. We have 12 physical locations, soon to be 14 this fall, and in our online campus. And we have been on ROC for just a little over a year, so still pretty new. Even though we've been on ROC for a year, the process to move over started way before that. We moved from CCB, so Church Community Builder, to ROC. I'm not going to talk a bunch about the reasoning why. If you have questions about that, someone from my team, myself, someone else can definitely answer questions for that. But we just really outgrew the system. We felt we couldn't really scale with that and to really reach our vision of being a church of the Midwest. We just knew we needed to move. And there were a lot of manual things in there that were slowing us down. We did partner with Triumph, who we highly recommend. Even just having a migration partner in general is amazing. We could not have done what we did without them. They did a lot of the heavy lifting, helped guide us and give us best practices. And as we were designing solutions with them, they could really steer us in the right direction and data migration and all that fun stuff. Our project team consisted of team members from our ministry development team and our technology team. We also brought in people from almost every other area of our church, anyone that used the church management system, to learn more about their processes and make sure they had buy in. I'll talk more about that in a bit. Also important to note, we did not migrate over our website and app. We felt that the church management system was a big enough project to tackle, and our timeline was pretty short. So we knew that we really needed to focus on that before hitting anything else. So our timeline, we started in July of twenty twenty two with the approval from our leadership team to go ahead. We'd obviously been planning and researching before that, but this was kind of like the start line for our project. We started internal pre discovery meetings in September of twenty twenty two. So these were meetings with different ministries throughout the church and figuring out what they used their church management system for and just getting more input from them. In December of twenty twenty two, we started our full discovery meetings with Triumph, again bringing in a lot of the ministry teams that we had already met with. So Triumph could ask them questions. We could all gain a little more clarity on what was needed and give Triumph the info they needed before really starting our implementation, which that started in February of twenty twenty three. And between February and our launch in June, we went through three different phases of implementation with Triumph, and they really guided us along in the best pacing for that and helping us get everything ready. We started our staff training in May of twenty twenty three, and then our launch was in the June. So as we went along and went through our project, we had a few strategies that we really focused on. Some of them were we said out loud, others we kind of, I guess, fell into but found a lot of great success with them. The first one was becoming an expert in ministry processes. So as I hinted at before, we spent a lot of time in prediscovery meetings with our different ministries and teams on staff. It was really crucial to learn so we could translate what they needed, their requirements to Triumph, and then bring questions from Triumph back to our teams. Without this, I don't think we could have advocated as well for our ministry teams as well as we did. And I will say our team was in a unique position that myself and my I call her my rock buddy, had camp or time on campus before and worked there. And she's been on staff way longer than me, so we were able to really speak into that. And even just spending the extra time with our ministries was great. The next one, think through the lens of a campus perspective and a central perspective. So the way Eaglebrook's set up, we have a large central team that equips and supports our campus teams and provides strategies for them. And I think both groups have the same mission, but we also have there's different needs and different perspectives of what's important. You want to make sure you keep your central teams in mind because you want great data integrity. You want people being consistent, standardization. That's really important, especially as you scale. But then also on the campus side, you want to make sure that you're actually creating things for them that they're going to use and aren't time wasters basically. That maybe it's really cool, but maybe it really isn't that useful. The third, testing and refining was a really big thing for us as Triumph would come to us with solutions to the different processes we needed in rock. My rock buddy and I made sure we went through and tested everything from start to finish. It was overwhelming at times because we really didn't know rock. But we learned a lot through that, but also because we wanted to make sure that what we were agreeing and signing off on was actually something that our teams would use again and want, and it would be useful for them. And keeping in mind scale and the culture of Eagle Brook as we did that. I've already mentioned this a little bit, but having a rock buddy, it was amazing to have someone kind of going through the same well, really the same project with me, but also even the mindset of having to learn rock, advocate for our ministry teams, do a lot of hard work, project manage, all of that. And I think that having someone who is in the same boat as me was really helpful and we could speak the language. We can finish each other's sentences now. We all know what each of us is going to say before we finish it. So that's a plus. This is probably one of the biggest strategies we have is the one year philosophy. This is something that it's more for after you implement. But when we were training our teams and launched, we told them, if there are any changes that you want to processes, we are not going to make any large changes until a year after our migration. So this would have been June of this year for us, was that year mark. Obviously, there was something that really wasn't working, was causing a lot of tension, was crucial for ministry, we would change it. But this was for us so we could kind of filter out if people had negative feedback just because they didn't like the change versus, no, this is actually not serving us well. We also did we wanted people to give feedback. It wasn't that we didn't want to hear their voices. It was more we're going to kind of live in it for a while and then address it a year later. First of all, I had to throw a meme in here. But you got to watch out for scope creep. This was something that, I think at the beginning, we were doing really well keeping with our scope. But then it was very, very easy to go out, especially with a tool as amazing and useful as rock. One of the biggest things I would recommend is define your scope early. So even beyond which parts of Rock that you're migrating to, so web, app, church management system. But also, what are the things that are important for you when you launch? What is important to make ministry happen versus this is just really cool or makes things a little bit easier? We really focused on well, wanted to focus on having a minimum viable product. So really, like I said, what was needed to make ministry happen on the weekend? So launch weekend could be campuses didn't feel stressed and could successfully run a weekend. But there's always times when that's really hard because things are really cool and you want to add as much as possible. A little personal story with this. So during our implementation, we were probably a couple months in, about a month or two out from our launch, and we saw a solution that another church had for their volunteer serving toolbox that it was really, really cool. And a member of our team was like, this is it. This is what we want. And I think we gave Triumph a bit of a heart attack because they'd already done a lot of work for us. And they were great about kind of getting us back, doing a little bit of a reality check of, no, this was a lot of custom time, money. Basically, you to start over on the discovery process. It's a great thing, but remember what you came here to do. And I think this is scope creep is so easy. There's a lot of times people will come to you with great ideas and you want to say yes, but you got to keep in that boundary. So with that, we've been on rock for a year. We can look back at what what went well, what didn't went well go well with our project. As I talked about before, our pre discovery prep and documentation, I felt was a really strong part of our project. Like I said, we had met with almost every ministry, any ministry and team that uses our church management system to figure out what did they what did they really need out of it, what type of processes were they, what did they like about CCB? What were what were their needs? But what didn't they like? What was holding them back? And how we could help create a solution in ROC that would just get us further. I also collected all of the documentation that we had at Eagle Brook, which is a lot, from our different ministry teams, even training, culture, anything that could potentially give Triumph a sense of Eagle Brook and our processes. Now I probably gave them too much, but it's Okay. We also, when we were meeting with our ministry teams, we flowcharted all of their processes on whiteboard, and then I sent them over to Triumph. And that was really great because it helped us learn the ins and outs while also giving Triumph a lot of info for them to work off of when they were creating things in Rock for us. Our hands on learning. We didn't really know Rock very well before we started our migration. We read through the manuals and went to the demo site. But there's only so much you can really do, especially if you don't if it's not, I don't know, applicable to your own church. And when we dove into testing solutions, we really learned about what Rockall had. It was overwhelming and it was really hard to manage and work through this project while also learning. But it gave us an edge even when working with Triumph because we could speak pretty knowledgeable about the system and ask them questions too that we maybe wouldn't have been able to ask them post launch just because we were already meeting with them. It also equipped us really well to answer our staff's questions. So when we got to training or launch post launch, we already felt like we knew the system pretty well and could answer most questions without having to do a ton of research. That was super helpful. We also were very intentional with our design of our instance of rock. Now obviously, Triumph did a lot of the heavy lifting, but when they would come to us with solutions, like I talked about before, we really dug in and made sure that there was something that our church would use that our staff would be able to actually benefit from and make sure that things were working the way that we wanted them to. And we really wanted to think about too what will serve us well in the future and how we scale and not just accepting something because it would work now, but what about five years down the road for us? As always, there's always things that we would do differently that would readdress in the future. Casting vision. We did some vision casting, especially with leadership when we were wanting to move, But I think we could have done a better job bringing people along for the journey of the project. We really could have done a better job of connecting everything to leadership's mission, our ministry strategy, campus operations, all areas of the church of the and really connected to why why this migration matters and why this change matters. Change is hard. So if you can cast as much vision as you can, it's gonna be payoff in the long run. Set realistic expectations. Something that I think we even had a hard time wrapping our heads around was what what to expect, not necessarily expect on launch date, but how to effectively communicate to campus teams what what product they were receiving. So we almost you know, looking back on it, we're saying we had the house, we had the building, but we had not a ton of customizations. We really didn't have decorations in there. It was pretty bare bones. And I think we could have done a better job communicating that to staff and working with them in in vision casting of this is where we're at now, but we're just at the floor. We can grow so much more from here. And even on the other side of that, I think we could have done a better job rightsizing negativity. So we did have a few staff members that were pretty vocal, did not really want the change, didn't like it. And I think it wasn't necessarily my job to do that, but I think we could have done a better job really just bringing the campuses along and getting them on board with the change. Staff training. I wish we would have had a lot more time to do this. I think we did our best to provide really good resources for our staff and Triumfell trainings with us, which were great. But at the end of the day, we just didn't have enough time to really give staff time to acclimate, to learn, and to feel comfortable on launch date. We really tried to focus on check-in or the things that are necessary for a weekend to happen. But we definitely could have done a better job providing more resources, again, with more time. Finally, probably one of our biggest misses is we did not include our digital team in a lot of decisions and meetings. I think naively we thought, oh, we're just switching over our management system. We're not focusing on our website and app right now, which caused a lot of tension, unnecessary tension that we could have avoided. I really believe that if we would have included them, we could have gotten a lot further even just in our relationship building with that team. And the truth is it affects them digital so much and Rock really disrupted our workflows and processes and who owns what. And we're still, to be honest, trying to figure that out right now, especially as we're operational and moving forward. So my biggest advice is to build a really great relationship with your digital team and use this time of change to dream big and make improvements to your existing processes because you're not going to have time right after launch, I promise you that. I have a few final thoughts of advice and things for you to noodle on as you work through the rest of your day. Ask questions on Rockchat. You've probably heard a bunch about the community and how great everybody is. Everyone is so nice. You can ask whatever question you want on there, and everybody will be very kind. And no one's going to think it's a bad question. So please utilize that. Or if you meet people here, DM them on there. We want to help you. So please, please, please reach out. And we probably have a lot of advice of what not to do. Being Okay with saying no or not yet, this was something that along with scope creep is really, really hard. I had to work through a lot of, I wanted a people please. I wanted everything to be right for everyone. And at the end of the day, you have limits and your project, you need to keep limits on that. And I think it's perfectly valid to keep a wish list and say, hey, we love your idea. We just can't. We don't have it's not possible to do it right now. Challenge yourself. During launch and our migration, we were so busy. It was really hard to keep up with learning rock and doing anything beyond just our migration project. But as much as you can, think about making what you can do to improve your knowledge of rock, how learning how rock works, all of that. And I think it's it's hard, but it's definitely worth it to invest some time into that and thinking future and not just migration. Something else that I kind of just talked about, but continuously learn. Just keep pushing forward. We there's great resources on the Rock website and in the community. There's classes. And even if you are not a fan of the manuals, they're super handy. And if that's not the way you learn, but there's so much great information in there. So I highly recommend diving into those. And just remember that perfection is a myth. You're never ever going to get rock to a 100% perfect state. And that was something that it took me a long time to really wrap my head around. But you can only do the best you can do. And at the end of the day, it's going to be amazing. So yeah, I'm realizing I'm finishing up a lot quicker than I thought I would. But here's my contact information. My email, that's my ROCCAT handle, just my name. But yeah, please reach out at any time. I would love to help you. And especially because we're pretty fresh off this migration, we can hopefully help as much as possible. So thank you.