 And welcome everyone. My name is Caitlin McTurden. I'm a senior consultant with Just Tech and I'll be one of your co-presenters for today. So we really appreciate you joining us. We're going to be talking today about case management system implementations with a particular focus on the project management that goes into that entire process. So we'll get started first with Interactions. So like I said, I am with Just Tech, which is a technology firm. We provide a lot of security, case management system, document management system, project support across the country primarily for legal aid providers. My background is in case management systems. So I work especially with legal server, though this entire presentation is designed to be platform agnostic. So I have worked with a lot of folks during their implementations and excited to kind of share some of what I've picked up through that process. So Shelly, I'll kick it over to you for Interactions. Hi everyone. I'm Shelly Reid. I am the manager of the Legal Services National Technology Assistance Project, commonly known as LSNTAP. Our mission is to empower the legal aid community to improve client services and build capacity through effective and innovative use of technology. Our Google group and listserv is probably our most well-known service, but we have a variety of services. We encourage you to check out our website and reach out to our staff if we can assist you. Hi, my name is Angela Tripp and I am the director of the Michigan Legal Help Program and I am also a co-director of Michigan Statewide Advocacy Services. And it is in my role with the Michigan Advocacy Projects IT Department that I will be talking about project management through our recent move to a new case management system. So today we're going to kick things off with just a very brief overview of what goes into a case management system, what the implementation process looks like, very generally speaking, and then we'll go back to Angie to kind of walk through her experiences throughout the onboarding project. So just want to make one housekeeping note. We asked that you please stay muted, but feel free to turn your video on. It's really nice to see faces and you can put in questions into the chat throughout. I'll be keeping an eye on it and then if we need to, we'll save some questions for the end. So we'll kick things off just kind of defining the basics. What is a case management system? So CMS systems, CMS are repositories for data. They allow individuals to collect and to track and to report on case data, like case outcomes, notes, assignments, legal issues, client demographic, contact information, a whole robust set of data points that are all a part of the overall case management process. They also provide a way to kind of standardize and structure that data collection process. So there's workflows that users are required to follow along, like the intake process or closing process, for example. Depending on the platform that you use, there might be a lot of additional features that you rely on it for, anything right from timekeeping to grants management. There may be integrations with platforms like the ability to send out SMS or to tie in with a payroll system. So there's a whole wide range at this point of what you can look for your CMS system to do and it really, it's going to vary by individual provider what to look out for in that process. So for those that are thinking about making the switch over to a new CMS, the first and probably biggest decision is what platform are you going to be going for, first place. There are a lot of factors that go into that. So like I said, thinking about what kind of features and modules you expect of your case management system, kind of integrations you might be interested in. And then certainly things like cost and security, the ability to access support and to kind of participate in a community that might be able to help you further develop your site, the ability to customize your site. So a whole host of metrics that you might consider in that process. Once you've made the selection, there are a few core steps to any implementation project. And they don't necessarily all take place in one given order. It will vary depending on the platform that you're transitioning to, what their exact flow looks like. But I can say at the basic level, there will be a need to decide what data you're bringing in from your existing case management system. So what's coming over with you? What do you not need anymore? Your plan to leave behind? That could be cases that are decades old that you no longer need to reference. That could be data points for grants that you no longer have. So just kind of identifying what the need is in terms of maintaining that data and bringing it over. And then also just kind of working through how to bring it over. So what might be collected in one way in a case management system might be structured a little bit differently in the next one. So deciding those kind of mapping rules of what goes where. After you make those rules, there's generally some process of bringing that data in and checking to make sure the rules and the mapping is adhered to correctly and all set up properly. So that work we call data testing, making sure that the data is coming in, that the data you'd expect to see for each case is there. They're not missing any cases. So just checking that nothing got lost in that transition from your old site to your new one. And then there will will likely be a period of configuration work. So most platforms will have kind of some offering out of the gate. So maybe like a standard intake process that they start everybody with or a standard display of the home page when you first log in. And I'd say again, it varies by platform, but most offer some customization options. So that takes a bit of time and look at into that with the end of how you customize it and tailor it to meet your specific needs. And that might look like designing multiple intake processes for different teams, having a two step closing process where the advocate closes it and then the supervisor checks it. Lots of different options for how you might want to refine the site to make sure it's aligning with your specific use cases. And then there's also a significant effort around test training. So you want to make sure that whoever is expected to use the system knows how to use it is comfortable and understands what's expected of them, what policies they need to adhere to with that CMS. So that is always a big part of this. Go live will look a little bit different depending on platform, but generally it will involve migrating the data over to the live site, checking to make sure that that migration happened correctly, doing any fine tuning cleanup, and then helping users get acclimated to the system, making refinements on the fly, just trying to get it everything in working order. And then certainly there, you know, there's no end. I think we'll talk about this. There's not really a very clear stopping point where like, great, this is fully done. We're never touching the system again. There is usually always a need for some kind of maintenance, even if it's just, you know, adding new fields for grants or keeping up with user management. So we like to flag that as part of the onboarding process too, right? Because you want to think about, okay, now that we've got the system in place, how are we going to be able to keep it going? So in the long term, it meets our needs. And not just in this one current moment. So at a very broad level, that is the implementation process. I just want to make sure everybody had a basic framework in mind as we dive into this in a lot more detail. So I'll stop talking now and turn it over to Ange, just to give us an instruction of your organization and what platform you transition to a little bit of background in that migration. Sure. At the Michigan Advocacy Program, we had been on PECA for my whole tenure with the organization. I think it was at least 15 years. And we, you know, got the news that PECA was no longer going to be fully supported. And we began the process of looking for a new case management system. I'll talk a little bit about that process. In the end, we did select justice server. And along with several other legal aid programs in Michigan. And my program went live on July 11th of this year. So we were able to finish this entire project cycle. And I think that is, yeah, you can ask me to cover it. Yeah, no. That was great. So we'll go into each of those uses in more detail now. So for those unfamiliar, I just wanted to make a plug for the Alice and Tap Toolkit on project management. That's going to be the framework for our case study discussion today. So the sections that you see here, initiating the project through to closing the project, all of those are sections in the project management toolkit. So if actually, if you don't mind grabbing the link and putting it in chat, yeah, just so everyone has that to access. So let's start things off with initiating the project. And could you talk a little bit about what your organization's goals were in deciding to move over and leave Pica behind? Sure. I mean, the primary reason was that Pica wasn't going to be supported anymore. And so we wanted to move to something that did have support. And while we had to do that, we wanted something a little bit more modern, something that was more mobile friendly, something that was more easily integrated with other tools like email, GIS mapping, you know, potentially HR and grant management software. And we were also looking for a product that had a larger community of developers available to do the work. That was one of the issues. One of the challenges with Pica was that there were not a lot of people doing development. And so it was hard to make changes to the system. Complex changes to the system. So when you were shopping around for a new CMS, can you talk about who made up that team internally to make the selection? Sure. As I mentioned before, many legal programs in the state made the move from Pica to Justice Server and we made the decision together. We were all on Pica together and that enabled many efficiencies of scale. We have a statewide support program that hosted and maintained all of those in Pica instances. It also made data sharing really easy and a lot of collaborative work between the legal aid organizations really easy. It enabled us to do projects like we got a TIG and added a texting capability to Pica and we were able to do that and then roll it out to all the programs. And so we all realized that there are a lot of advantages to being on the same case management system. And we decided that we wanted to move together as much as possible. And so initially, we had a very large group of stakeholders of all the legal aid programs in Michigan who were on Pica or even not on Pica who were considering moving to something else. And so we did research on the options. Hold on, I have a sneeze. We got demonstrations from vendors. We also spoke to programs using the different case management options and got demos from them. So it wasn't just like a small group talking to them, but we got them to do demos to our full, you know, large group with reps from all the agencies. And then as a group, again, a big group of people from many programs, we discussed our priorities, the pros and cons for each option. And then we chose one. Even and then within Michigan advocacy program, you know, we had our own discussions to contribute to the big discussions. And, you know, on that team, obviously our IT staff, but also in our executive team, but also managers, other case handlers, you know, we didn't involve all, you know, 150 people in the organization, but we got input from many different folks that we then took to the larger conversation. We did have a wish list that, you know, we talked to different folks within our organization and kind of compiled a wish list of features and, you know, capabilities. Sounds like a very deliberative process then, both within MAP and then across the broader coalition to get to that point. And I'll be honest, it took us more than a year. We took our time and really thought about things and, you know, waited to see what happened with, you know, some developing case management systems. And it took a long time. We knew we had a, we had a fairly long runway with PICA. So we took our time. So then you mentioned that internally, right, you would come up with, you had sort of a discovery process of your own figuring out what was on the wish list, what different types of users wanted from it. Could you talk a little bit about what some of the key considerations or the criteria that you found through that discovery process, Mark? Yeah, absolutely. Of course, price was very important, both the initial and the ongoing. Because we were working with the whole state, you know, we had programs with 200 staff and, you know, millions of dollars of budget and we had programs that were seven staff and much smaller budgets. And so we wanted something that could be made to work for everyone. We wanted ease of use, you know, that feeling of modernization, those integrations that I mentioned. Everyone was very concerned about reporting, because reporting is so important to what we do both for grant reporting, but also for just program evaluation and analysis. As a program that had been hosting our own PICA for 15 years, we were very attached to the ability to make a lot of modifications ourselves. And so that was something that we talked a lot about. And then we also wanted a system that gave us the opportunity to take advantage of the economies of scale by doing a Michigan prototype, reducing the sort of initial cost for all the programs, so that even the small programs could be part of a, you know, a really nice modern case management system. And that's awesome, that kind of knowledge sharing, that you're able to build that in from the start of this entire process, yeah, versus having each provider kind of, once you make the selection have to go through it fully on the room. Great, well then, we'll turn to next. Once you've made that selection, you got the consensus from the group what it looked like at the onset of the implementation project. So starting us off, could you talk about who made up the team internally to help oversee the entirety of the project? Sure, and I'll just add one piece of information that not every program on PICA decided to move to Justice Server. There were a few programs that didn't want to make the change and so, but I think in the end, we had 12 programs in Michigan that made the transition. So in the big statewide project, we had a prototype team with representatives from the three biggest programs in the state because we figured they had the most complexities and they used their case management system more fully than smaller programs maybe. So we chose programs that would answer all the questions that we needed. Even if not every organization needed every one of those features, we would get them taken care of with these representatives. So we had representatives from the three biggest programs in the state and they were primarily from the IT and or operations sectors of the programs. And so we needed a small team to do the weekly sprint calls to do the basis of the work, although we did meet every month with the group of stakeholders representing every organization to keep them up to speed and to get their input on things. It was, you know, you can't, you can't have 30 people on a committee to build a case management system. So within MAP, our core team was me as a joint executive team slash IT operations staff person, our two primary IT and operations staff, our manager of advocacy, and our one of our longtime office grants managers. So we had, you know, the IT team and we had the the advocate team, you know, the folks who who use the case management system every day in ways that the IT and operations staff simply do not. I was the project manager or Scott, our systems administrator was the technology lead. And we all attended weekly, sometimes twice weekly sprint calls with the developers plus internal meetings in between calls. Later on in the process, we got more people involved, but I'll talk about that as we talk about the later steps. I'm going to jump out a little bit because you mentioned that you had you were on one to two calls a week just with the developers and internal. Could you talk a little bit about what the hours looked like for that team? Was it similar for all five of those folks or did it vary a little bit depending on role? Yeah, I'll turn it to you. I think it varied depending on role. I mean, I think the IT team took it upon themselves to do a lot of the work in between calls. The I mean, you know, the the the advocate staff, you know, their role was mostly to keep the IT team from going off the rails to remind us all of like what what who are end users are and what they need. But we I think we did a little bit more of the the work in between. And the work absolutely varied by phase. In the beginning, we had like, as I mentioned, a one hour sprint call, and then probably another one to two hours of work per week. In the last few months of the prototype development, which is the statewide group, we had two calls every week, and I would say three to four hours of work in between having meetings, answering questions, gathering information, making decisions. For the map implementation, it was the same thing. We started with the one one hour call. And then as we got closer to launch, we needed two hours a week. And you know, by I would say May, which was you know, we launched in July, we had two sprint calls a week, one hour meeting with our group of testers every week. And then I would say three to four other hours a week for the IT operation staff and me and slightly less for the others. And I just wrote in my notes, June and July were madness. I think you just did a lot of really important things there, right? Like that there's a ramp up to this. So yeah, it's not gonna, it probably won't stay static, but then it won't be 10 hours for the entirety of the project. So it kind of it ends and flows. And then I also just wanted to really like highlight the point you said about having a balance of voices in the room for who's making decisions, like for your internal team bringing in people who can speak for the end users and are familiar with their processes and pain points, but then also having the kind of technical expertise there. I think that what I've found in just providing some support for a lot of onboardings is that kind of blend is very helpful when you have one voice and not the other. Especially if you don't do user testing throughout then, you can get to a point where you go live and people are like, wait a second. They're expecting one thing and this wasn't it. Not for lack of trying for sure, but it's just yeah, having that kind of representation in the group is really key. So then you're mentioning June's like crazy. Can you talk about what the timeline was like overall? So from let's say from when you made the decision to move to justice server through to when you ended. Right. We made the decision at the end of 2020. It took a while to get contracts done the way that it always does. So I looked back and our prototype meeting, our prototype kickoff meeting was February 2 of 2021 and we did not finish the prototype until probably April of 2022. It had been our intention to finish the prototype before we started any individual implementations. We ended up with an overlap, which made it complex for the developers, but we made it all work. So our kickoff for our individual implementation for Michigan Advocacy program was February 8 and go live was July 11. That one, we stuck to the timeline, even though we had to jettison some aspects, move them across the deadline and say, we'll come we'll pick that up and finish that after go live. But because we had so many programs moving at once, particularly the four LSE programs that moved to justice server, we had to go one every week for the month of July. And so everyone was very motivated to stick to their timelines, but they didn't mess up anyone else. And so we all worked really hard to meet all of our timelines there. And you're saying for a map internally, it was February to July? Was that of the same year or was that crossing year? That was the same year. Yeah. I mean, you know, the prototype was so much of the development that the implementation for us was just fine tuning, tweaking data migration and whatnot. You know, the prototype build was the really complex part. Got it. Yeah. I think that is somewhat similar of a timeline that I see with like legal server implementations. It's going to vary depending on like resources and do people have the staff to do five or six hours, at least towards the end of the week and how much they can handle internally. But I would say like, like seven, six, I'll say six to eight months, I would put it at is usually what I see from starting like data mapping through to going live. So some folks, I might take a little bit longer than that. Some folks might breeze through, but definitely there's there's a range. And then last question in terms of planning at the onset. Were there any particular tools or like documentation sources that you use that just you were helpful in project managing throughout the entirety of this implementation? Yes. We use Trello. And I have to say that as an individual who has been, I've just never succeeded in adopting a project management software before, I really learned how to use Trello to work this project and it was really, really helpful. The developers kind of forced us to and I'm grateful for that because we really do have a system, a really good system in place now. We also used our it ticketing system, which is a essentially a Google group that we have set up with a bunch of labels and assignments and fancy things to make it a decent ticketing system. We use that post launch a lot to help us track issues post launch and answer people's questions. In terms of timeline, we were given pretty early on an Excel sheet of all of our different tasks and different deadlines for both the developers and for us. And that Excel chart I printed it out and taped it to my wall and it was just a constant reminder. That was really it on our end. I'm sure the developers had more complex systems in place, but this was those three were the things that that we use on our end. And I think that could be great, right? That doesn't mean I feel like a large quantity of project management tools does not necessarily make things easier. So you've got the place you're tracking tasks, you've got your timeframe chart. You mentioned there are deadlines put into the Excel sheet. Did you find that those like changed a lot? Was there any upkeep there or were they largely like consistent from the onset? They changed a little bit, but mostly they were like motivators. Internal motivators to to get our work done. You know, like seeing the whole timeline being like, oh, well, if we push this back a week, then then there's there's actually no time for this. We're losing this window. Yeah. There's no where to push this date. So keeping the whole big picture in mind. Yeah. Holds your feet to the fire, I guess, a little bit more. So then switching over now to working the project, so the actual kind of day to day to get this in place. What was your process like for deciding what data to bring in? Did map decide to import any data from PICA? And if so, who was like involved in that decision? We did. We decided to bring over seven years of well, obviously all of our open cases and seven years of closed cases, including contact fields. So we brought everything from the last seven years closed and everything that's open. And, you know, we discussed that like we talked about it statewide. I mean, every organization could do what they wanted, but it was a good kind of conversation. What were other people thinking? You know, in that we felt that seven years was our obligation under Michigan's ethics rules and what kind of our practice was with physical files. And so it did represent a change because while we only kept seven years of paper records, we had never purged any of our electronic data, but had been talking about how we should purge some of our electronic data. So now we are in a place where we will be maintaining only seven years. So that was a big change. The people involved in making that decision, the executive team, I keep mentioning that I should say, the executive team in our organization are all of the directors. So there's the executive director of MAP and then there's the two directors of Michigan Statewide Advocacy Services, our CFO and our grants manager and our director of litigation. So, you know, the executive team had kind of the final say. But again, we talked about the issue with the IT team. We talked about the issue at management, at a couple of management meetings, you know, to hear people's thoughts and concerns and wait all of that before ending at seven years. And then did you decide to bring over all of the data that you had for those seven years worth of cases? Or was there any part to the process where you were thinking about, you know, we don't need these specific fields anymore? We, I had hopes that we would jettison more fields. We did not. I mean, we did jettison a couple. There were a few that like, you know, we had a COVID-19 checkbox and we decided that at this point, everyone is impacted by COVID-19. We didn't need that marker anymore. But we just thought it was easier to just bring it over and have it rather than like get a year and a half in and realize, oh, we need this for some reason. So we did bring nearly, nearly everything. It's always nice to know, yeah, that if you have to draw from it or if somebody, you know, didn't maybe vocalize that they needed this field until they got to the reporting process a year in, okay, there's something there that you can like lean back on. And then, so it sounds like you brought in different voices. You're saying the executive team who is not strictly the, was different than the team that you had leading this implementation. So you're bringing in different voices for the data migration. Can you speak to if and how you brought in others for the user testing? So once you were doing the kind of fine tuning of the system, how did you bring in additional voices there? Yeah, this was one of my favorite parts of this project. So pretty early on, we knew that we wanted a team of super users of early adopters and testers. And so we pulled together a group of people. We asked managers for suggestions and we tried to get a mix of early adopters of technology and people who were not so early adopters of technology. We ended up, we specifically recruited one person from every office in every program. So our organization is huge at this point. We have about 250 people, two halves of the organization, one LSC funded, one not LSC funded, five statewide programs on the non LSC side, six offices on the LSC funded side. And so we got people from every office. We got people at all at all different roles in the organization. So legal assistance, paralegals, attorneys, intake staff, grants managers, managing attorneys, and we called them, brought them together. We named ourselves the GoBots that was inspired by Lakeshore Legal Aid who named themselves the Thundercats. And so we were rivaling 80s cartoons. No, we worked together. So anyway, we met with them every week for an hour and we would kind of start by updating, like, here's what we're working on. We always had a batch of questions, you know, like, all right, what do we think about this? Do we still need this field? Who uses this field? Does anyone need this? What should our drop downs be? And then we also, and then we would show them, okay, here are five new features, you know, please test this over the next week and give us feedback. And we had, I guess this is a form of project management that I forgot about, but we had this Google doc that are someone made for us that you can, every time you open it, it will give you a new box. And it was just like reporting bugs and issues. And so it collected, like, the date, who's doing the test, the issue they found, the question they had, a place for screenshots. And so we had that, it's hundreds of pages now. But we used that during the testing to, for people to log their feedback whenever they were looking at the system. And so they, you know, they were just priceless is the wrong word, but they were critical to the development of Justice Server. They also helped us figure out what kind of training we needed to be thinking about. And every step of the way helped us check our assumptions about what was easy and what was not easy. They put in a ton of time. In addition to the one hour meetings, we asked them, you know, to please spend, please budget about a week of an hour of your week for testing. And then in the month before go live, or maybe six weeks before go live, we started a practice that we stole from Legal Services of Eastern Michigan. We scheduled two hour blocks on Fridays for intense testing and feedback and discussion. We bought everybody gift, DoorDash gift cards to say like, please order lunch, spend two hours with us on an open Zoom call. We'll give you things, we made assignments for testing. We had breakout rooms to work through specific issues with different groups of people. And just it allowed us to, they were also incredibly helpful when we had to test the data migrations, because testing the data migration is like, look at every single box on 10 of your open cases and see if it's there. And so it was just incredibly helpful. You created this team of testers who like already knew enough of the system to be able to find that field, which I know could be like a hurdle for testing in the first place. That's fantastic. No, I think the GoBots is an incredible idea, especially because it's really like, it's kind of committing to user testing throughout the entirety of the process. Then you have this team that you can go back whenever you kind of need it, but it's also saying, you know, we're not going to just do this one round of testing, we'll make additions, we'll make changes based on the feedback and we'll like keep going. So I think just having that standing team in place is great. And then kind of connected to that, having a centralized place where you can track tickets and testing must have been, I can imagine, so helpful. I guess I should have mentioned before I worked at Just Tech, I was at a legal aid group in New York and I helped them on board. So I was sort of in your position, Angela. And I think one thing we learned quickly on in the process was we needed that central hub because we were, we were, everybody on the team was fielding different emails. And it was easy both to kind of slip through the cracks or for one person to respond and not really as the other one had. So just, yeah, kind of helping everybody involved in the testing process by saying this is the one place that we are going to look to see your testing feedback. And it's going to be like the source of truth throughout, I think must can imagine save, save some headaches. Yeah. And then I would, you know, every week before our sprint call, I would go through the log and I would look at every card that people had submitted and either, you know, like submit it on the trailer, put it on the Trello board as a problem or an answer to something or I would make a note, this is a training issue. This is not broken. We just need to train you how to use this better. And so like flagging training issues. And so like my process would be before the sprint call, go through all those things, move them all to Trello board, Trello cards, so that when we had our sprint call, we can move through the Trello boards and get them in the different places. And then I would report back to the GoBots on the Monday meeting, like, okay, here's all the things that we fixed that you told us about last week. And it was, it was a pretty good process. I'd like the separation to between sort of the formal place where you're, you're voicing the technical issues to the development team versus having the internal one. Yeah. So you're not kind of using the developer's time then for issues that you might be able to handle internally. So I think, yeah, also a good approach. Right. It also let us make decisions. Like people would say, I want this to work this way. And we would say, no, no, we don't, so we, like, it was a little bit of like, you know, weeding out and saying, like, yeah, no, that's, that's not, again, let's do something that's broken. That's a training issue. I don't want that on the developer's board. So it was good. Yeah. One last thing I wanted to, like, that I resonated with me that you had said was giving the testers parameters. So saying, you know, we expect there's going to be this one hour meeting and then we want you to test for one hour week. Because I think, you know, it really depends on the person, but they could spend five minutes, they could spend a whole day doing it. So saying, okay, you know, we, the system is a work in progress. We know that this is the time frame that we want. We're asking for you to commit. And then that way, they can also plan for it. I think it was just, yeah, it was a really great idea. So then looking, looking back now with your months of kind of distance from the project, was, is there anything particular about either the data migration or the configuration phases that you found to be particularly challenging? Honestly, the sheer volume of decisions that needed to be made was kind of overwhelming at times. There were times when I was just like, I don't care about the answer to this problem. But I have to answer it somehow. It was, it was a lot. It was challenging the kind of domino effect of seemingly minor changes. I think you'll have that with any technology project. But you know, like, oh, can we tweak this thing? Yes. But then it breaks for other things. And then you've got to decide was this thing worth it? Or do we fix these? It was a challenge to not fall into the trap of just rebuilding PICA, but to like using the new capabilities to improve our processes and to get others to do that too. Like we don't have to have this kind of, you know, three step process that we had in PICA because it was the only way like we can make it faster. Or just different. Change management is always a challenge. I mean, that was like the other real reason we did the go box was to like have those early adopters to help everyone else with change management. Managing expectations, continual challenge. You know, saying, yes, this is going to be amazing and great. It's definitely worth your time. And it's not going to fix everything and do everything. But it's still worth it. And then I will say the last thing was sometimes it was difficult to explain some of our processes to the development team. And I don't know if that's a sign of like wacky legal aid practices or non lawyers on the other side, probably both. But that sometimes we would just go round and round. And I was like, I can't think of another way to explain this. But we made it through. Great. I'll keep us moving along. Yeah. So you worked through those problems, developers, you kind of got through the configuration and data migration. So now we're going to pivot to what your actual go live period looked like. So starting there, can you walk us through like what that week, weeks, whatever the period was between when you said, okay, we are now taking the data from PICM or moving over and opening it up to your users? Right. So the actual timing of the go live process, we did a week of intensive live training. And then there was a short week that included July 4th. So we had two days of regular work. And then we had our two day blackout period for the data migration. And then the next Monday, we went live. So we were really only dark for two days. As part of change management, we use those two days. One day was a program event where the program paid for all of us to go to the zoo and have a lovely lunch and hang out with each other for the first time in two years. So it was lovely. And then a half day holiday on that Friday. Change management strategies that we used just to speed through. Yeah. We talked about just a server early and often. We did demos early and often just to keep everyone, you know, not intense demos, but just like, Hey, remember, this is what's happening. Here's like a little fun demo to keep you interested and engaged. Close to launch, we did a pretty detailed memo outlining the logistics of the actual transition. Here's an online intake is going to end. Here's what's going to happen with your referrals from call. Here's the blackout period. Here's how you do your time sheets. Here's when you can start justice server. We also did a shared Google calendar where we put all the important dates on the calendar so that everyone could easily see them. On the launch day, a lot of offices offered donuts. So and then obviously there was a lot of training that was part of change management as well. In addition to all the intensive training that the go-bots got, we did a week of intensive training that involved three hour blocks of training where we like show one, do one. We gave time for people to experiment live. I mean, not live, but experiment in a place where we were there to answer questions. That was really helpful. It was basically live troubleshooting for us. We made a ton of changes and fixed things after that. We let them just play in the new system during that short week and then on the day of go live, we had a library of training videos and PDFs ready. For every training topic, we did both video and written PDF. We used Tango, which captured it's a screen capturing tool that made a 40-step process that made into a PDF, the video. Then after go live, we did office hours that were really helpful where we just opened a Zoom room for I think three days a week for an hour each time where people could drop in and say, hey, I can't find this case. What am I doing wrong here? It was great to just be able to screen share and show people what was going on. That was a very quick run of our training. That was fantastic. I think you got all the questions on this slide. One very brief all of how long were you doing the office hours for? We did them for about a month. We're actually thinking of bringing them back. We're also thinking of bringing our go-bots, bringing the band back together on the go-bots. Not as often, but just as we talk about future development and as we roll out some of our integrations to have for all the same reasons that we had that team working before. There was a real drop off after I would say six weeks in terms of the tickets that we were getting and the people showing up for office hours and so we tapered off. Makes sense as they get comfortable. We talked about some of the tools that you're using with Trello and the ticket bugs. Is there anything else you want to flag that you want to speak towards monitoring throughout the project? Any resources you lead on to raise risks or to track that? You're hitting those timelines. The Trello board, I'll say the only other thing that I haven't mentioned yet is that I started a giant one single Google doc where I recorded my notes from every meeting that I've ever had about Justice Server from the very beginning to till today. We had a statewide meeting where I just kind of put agendas and notes. It's been a really nice historical document. It's not everything, obviously. It's kind of just what I remember to write down, but it does help me to have kind of a record of when we met and what we did. And nice to know that it is in one spot. You're like, okay, if I have a note on this meeting, it's going to be here. Then you made it through Go Live. Can you talk a little bit about what, if you consider this project to be closed, at what point you'd say it would be closed? I know you said just now, I'm going to bring back the Go Bot, so there might not ever really be closing, but... Yeah, I mean, I think we want to make a distinct closing of the build, the implementation, and make an official move to maintenance. I would like to do that around the end of the year. Again, it's never going to be finished, but just to really mark the transition to, okay, now we are in maintenance mode. Maintenance mode includes additional development as things happen, but I think we want to do that by the end of the year. Are you still working with developers now? Did those meetings drop off? So we chose to continue working with the developers a set number of hours a week, because we do still just have a lot of... It's been great because people are really getting into the new system, and so they were like, oh, can you create another services for this? Can you do this for me? I would like to do this. And then, as I said, we had odds and ends that we needed to kind of add. So we still are meeting with the developers and have a few hours of their time in our budget every week. That helps keep us motivated to move forward, too. So open, but still like six months or so following Gullager. Aiming for your closing. Yeah. Great. Do you have a designated person for handling the upkeep, like looking towards that transition? Yes. Our two primary IT staff, our systems administrator, and our director of operations are the two folks primarily responsible. We also have brought in one of our help desk staff to kind of be the justice server point person for the help desk. And with the exception of the help desk staff person, the other two have been involved from the very beginning, but our help desk staff has been on the help desk. And so she's watched all the tickets come in, and she's quickly getting up to speed on everything that she needs to know. So I guess the question about a postmortem is a little bit premature, then. Maybe something to consider. Is there, like looking back again, any part to this process that you wish you had handled differently or anything that you wish you knew at the start? I mean, I can't think of anything that I really wish that I had done differently. I guess one sort of regret that I have is that I got so deeply involved in this project and I really love it, but it's not part of my job. You know, like it's part of closing the project. Like my role is over. I don't need to manage this project anymore. So I need to step away. And it's just a little bit hard because, you know, I have a lot of knowledge about the project and like little tiny details of like why that checkbox looks like that. And I can say, oh, well, because eight months ago, remember, we had that meeting and we decided XYZ. But I really do, you know, it's not an ongoing responsibility of mine. So figuring out that transition time yet. I guess I can take a little bit to that too, since it sounds like you are in the middle of that now. But I found it can be helpful to kind of keep in mind the eventual transition to ongoing maintenance from the start. Right. So when you're building out customizations, if there's places to write descriptions in for like why, like how is this being used? Or if you're like, say, like naming things, naming pages in the back end, sticking to some kind of naming convention that indicates, again, like either who's requesting it or what the function of it is. So building, there's, I've seen folks be deliberate about building some of the knowledge that you're talking about, like that it lives in your head into the site. So that will be it, you know, in a year or five years, whoever is going to eventually take over in a transition for maintenance, they have some, it does not all have to come from like a knowledge dump out of your head. And then I'd also say in the transition period, I see folks thinking about coming up with like formalizing processes to request revisions or to flag problems in the long term. So a lot of times there'll be something put in place in the immediate moment to say, okay, it's go live and we're going to get 100 requests. This is how we're going to deal with them. But figuring out, should that process stay for the long term? Or is there something better? And then figuring out also who gets to approve and implement that who decides should we make this change. So just, yeah, I'm sure these are things that you must be working through right now. But yeah, all part of that, that kind of closing into ongoing maintenance. Yeah, I think one other lesson is that the, you know, what programs were used to, the amount of work people programs were used to needing to support PICA, I think is different and less and the amount of work needed to support justice server. It's just a very different type of case management system. And especially it's still early on, like I reminded people so many times like the version of PICA that you were using in June took us 15 years to build. So, you know, when you think about that, like, oh, yeah, we didn't get to everything. We only had, you know, a year and a half. But also it's just a different, it's a different type of system and requires different, a different level of ongoing work and maintenance. And I think that has been a challenge for many programs. That will transition us really nicely to our last slide and just talking about kind of some of the things that went well and some of the things that were more challenging that we had chatted about before this. So if you want to, if there's any, I think we've chatted about some of these to various degrees, but we want to speak a little bit to any of the points under what you thought went well, what was like a positive coming out of this project. Yeah, I mean, we got a new case management system. And I have to say like objectively speaking, you know, it went really well, like the data all migrated and, you know, we were open at 9am on July 11th and could do our work. We did a lot of community learning and community building. We still, we have a standing meeting every Thursday at one for all, for any, for all justice server admins from the state. And so like it's a great place where we, you know, exchange questions and tips and information. All of the, the preparation for go live, I feel like really, really paid off. I think all of us who were closely involved learned a lot about project management and change management and probably even people who were less closely involved. I mean, you can look and see, you know, you know, if some, if you got enough information ahead of time or not. So hopefully those are really great things, you know, the challenges we talked about. Yeah, I mean, every, every project is going to have challenges. So it's good to just be aware of them before you go in. Yeah, essentially, I think it sounds like you did a lot of work to you were kind of had an idea that there was going to be a need for change management strategies. So then you built that in throughout the entire process. Flacking it early, flacking it often, building in those, those advocates within each group to really try to, I guess, push through what is a challenge, which is going to happen no matter what kind of technology system you are going to implement via the case management system or something, something new. I think we are, I think that is just about it. So and we've got four minutes left. So if there are any questions about anything we talked about today, any parts to this process that we didn't touch on that you'd like to talk through, anything that went particularly well for your own onboarding, if we've got folks that have done this transition recently, feel free to put it into the chat. I'll have a couple of minutes to adjust those. One thing that I'll say that we didn't quite get to you, one of the questions was what lessons transitioned to other projects. And I think something that we actually talked about earlier today on our statewide call was the importance of different types of training materials. I think everyone thinks, oh, training videos, it's the way to go with something interactive like this. But, you know, I thought about how when I need to do something on LSCs, LSCs grantees, I don't go to the videos, I go to the PDFs, like I have my PDF printed out, I've got my notes on it and I have it in my folder when I need to when I need to submit reports. And so, you know, I was like, we have to have printed materials and like realizing just that has been useful in other projects. I think also just knowing that like, I don't know if this is true or not, but like 40% of the work happens in the last two months. And just knowing that that's going to happen and it's going to come and just to be prepared for it. I also learned a lot about prioritizing, you know, what do you need to get the plan off the ground? What are the absolute things that have to get done for GoLive? What can get pushed over the line? And it's actually fine to pick up in the weeks following GoLive. We're, you know, getting ready to launch a new version of Michigan legal help. And so I'm dealing with the same things right now, like, okay, what do we need to get the plan off the ground? Yes, yes, no, no. Because you can't do everything and just kind of acknowledging that and learning to live with that and prioritize, like, what, what, where do you focus the little time that you have left as you get closer to GoLive? Yeah. For the training materials, did you, were you all coming up with those yourselves, or were you able to lean on like this, did the platform have any trainings? Where did you? So that's a great, that's a great question. We thought all along that we would have, we would be able to share trainings, but in the end, every program had their own, like we made enough modifications during implementation, but also there are just really different ways that people use the same tools that we realized that everyone really needed to make their own training materials. And, you know, even the developer didn't know enough about how we're going to use it to do a decent training. So we did our own trainings, and then even, you know, individual programs within MAP did their own trainings that we don't even know about because they built things out specifically for them. So it ended up being really individual. And every program did that, found that. It was a similar experience with the group that when I was internal at an organization, we found that there were, there were existing training materials out there, but similarly, not just the, like, our processes in the system were so unique, but even just the vocabulary. So the way that we would call, you know, like case status meant something very different in the system we were moving for. So it was like providing like dictionaries beyond just what was available and being like, okay, here's our little corner of how we do this or save us term. And this is what it means here. So yeah, I definitely, I would second the need to at least build out some resources that are custom to your site. Well, we're at time and I haven't seen any questions come through. So I guess we will stop my screen. We'll end it there. Thank you so much for putting in chat. We'll have this recording up shortly so you can reference it anytime. When I give a huge thank you to Ann for sharing all of your great lessons learned and everything about your process. It was so helpful. And yeah, we'll wrap it there.