Welcome, everyone, to today's Mara guest lecture. We have two presenters today, the dynamic duo of Nathan Owens and Parry Swift. And Nate is the Records Manager at Ohio Attorney's General's Office, and he crafts retention schedules as part of his tasks, assists with records-related issues, manages the office's document records management system. And he also serves as chair of the Ohio Electronic Records Committee that develops standards and guidelines for electronic records for public entities in the state of Ohio. And we've been spending a lot of time talking about standards, so this is perfect. He has a Master's of Arts in Public History, a Master's of Library and Information Science, and an Information Governance Professional Certification that he's earned from ARMA International. Parry is the Records Manager for Ohio State University, and she has also served as Senior Records Manager at the Ohio Attorney General's Office, a local government records archivist, and then as assistant state archivist in the state archives of Ohio. So Parry's been very busy there in the state. She served as chair of the Ohio Electronic Records Committee and Ohio Historical Records Advisory Board, was president of Nogara. You hear me talk about Nogara every once in a while. And is president of the Greater Columbus ARMA. She chairs Nogara's Professional Development Committee. I'm on that. She makes this work like crazy. She's received her BA from Wittenberg University and her MLAS from the University of Pittsburgh, and Parry is the Certified Records Manager. So I'm going to turn this right over to our two presenters because I know they have a lot to share with us. Well, good afternoon, everyone. Thank you for joining us today. Nate and I have done this presentation a couple times. This is all about how we implemented a document management system and a records management system at a state agency. Les Nates Hart, I knew this was coming when I hired him and I couldn't tell him any specifics because we didn't have it at the time. But he came along, joined the Attorney General's Office, and we had a good time implementing the system. We certainly learned a lot. And so hopefully we can share with you some of the things we learned. But while the focus of this case study is on the acquisition and implementation of a document and records management system, a lot of the lessons that we learned and the approaches are going to translate to any system procurement process and rollout. I think it's really important to understand that even if the system being purchased isn't a document and records management system, it's probably a system that is going to hold records and information. And that means that records management should be involved in the process. This process also helped me when I came to Ohio State because they have a document management system. We didn't do the procurement process. They already had it. They were partway into it when I got here. But I have been able to translate a lot of the lessons learned from the Attorney General's Office over here to Ohio State. For a government agency, the Attorney General's Office is actually very diverse compared to a lot of other state agencies where they kind of have a single focus such as Department of Health or Department of Natural Resources. At the Attorney General's Office, we are kind of made up of these five pillars. I like to call it. And so those kind of cover our legal department. So these are going to be the attorneys that work with all of our client agencies in the state of Ohio. We have investigative groups. So these are typically like our Bureau of Criminal Investigation, more of our law enforcement style employees. We have the Ohio Police Officers Training Academy, which is a whole school unto itself that is training police officers. So we have records and information coming from them. There are the basic operations groups of the Attorney General's Office. So your finance departments, your general services, records management, you know, those types of groups. And then lastly, we have a collections enforcement section, which is basically those groups that are collecting money owed to the state. So we have a very diverse group of departments within our office. And, Al, there you go. So we, at that time, we were a very decentralized office. It was and when I say decentralized, I don't mean just the five pillars that Nate talked about. I mean, it was almost an every man for himself situation when it came to organizing and painting their records. Every division did it differently. And it was their job to tell records management when records were up for disposition and what those records were. More often than not, that just simply led to them not getting rid of records at all. They just didn't have the time for it. Individuals who used the records were responsible for the order and manner that they were maintained. So in an office of nearly 1,700 people with frequent turnover, it was an unwieldy mess. Imagine 1,700 different filing systems.  Some staff were going paperless, while others still printed everything. Anyone needing to find records had to go to multiple locations and possibly through different types of media. So looking at this image on the screen, imagine the center dots being a unit. They each did things their own way. That was incredibly difficult, not just for us in records management, but also for cross-section collaboration. We ended up keeping too many duplicate documents, reinventing the wheel instead of building off of each other's work, and sending out the dreaded, has anyone ever written a brief on this topic or done research on this topic? It was a nightmare for our staff that pulled together public records requests. We had too much on litigation hold through this process. Sometimes it felt a little bit like this, and something needed to change. The Attorney General's Office needed something to help us control the assets that we called records. So we made a decision that we didn't want to decentralize. We wanted this picture instead. We wanted a more centralized system than our shared drive system allowed. Plus all the other law firms in town had document management systems. We knew that there was going to be a huge paradigm shift, but perhaps we didn't even comprehend all of the struggles that were to come. This is the way we've always done it, seemed to have become a battle cry. So when you look at this, there were some changes that had to take place. Before our document management system, we used shared drives. The sections or the divisions worked separately. We're going to move to one system from the shared drives. These sections working separately, all of a sudden we were going to be able to collaborate with each other. And then we had personal shared drives, and this isn't uncommon. Most places have personal shared drives, but there are issues with personal shared drives. We wanted to try to eliminate those personal shared drives and keep it more centralized. Everybody thought of email as my email, or they thought of their records as my records, and why wouldn't they? Because we work so hard on our stuff, we take a lot of personal pride in it, but in actuality, it was a public office, and they're not ours, they're the public's, and we needed to focus more on function and the role than the individual person. And finally, we had this, keep it all just in case mentality, but what we wanted to do was move toward a more defensible disposition, automated retention periods that would then allow records to automatically be deleted instead of us having to wait for somebody to come to us and say, hey, we're ready to dispose of records. So what, you know, a document management and records management programs were the solutions that our office was given advice to look into and ultimately went out and seek. And when we talk about document and records management systems, they're kind of two separate programs, or at least within the Attorney General's office, they were two separate programs that worked together. And with a document management system, what it does is it captures electronic documents and the metadata of those documents. It then registers those documents, stores them and indexes those documents. So, you know, you can search based on name, based on author, based on the content within a document. It provides a lot of controls for ownership and access rights. So you can lock down a document at the document level, at a folder level, and at a, what we like to call workspace level, so series of folders. There is the ability to retrieve, check out and return documents. So it kind of prevents unnecessary duplicates from being created, as well as controls versioning. It allowed us to integrate with Microsoft's office. So it gave us the ability to be saving our email correspondence or other records that we might receive through an email. And it did what Perry was saying, you know, we're getting away from this idea of my records and focusing more on what the records are about. So it's a much more matter-centric kind of environment. So we organize our records based on case, based on project, based on initiative. So this product we ultimately ended up with was very geared towards the law firm realm. That's how it was created and presented to, you know, buyers out there in the public. But along with this, the records manager system, what it did was it captured all that information that goes into the document management system. So we know the documents, we know the folders that are created within the document management system, and we can start applying records retention to those folders. But along with that, you could also identify and flag physical records that relate to these things. So if we're thinking about a group of records for a case file, we might have electronic records, but you might also have that Manila folder or a flash drive or a hard drive that you receive for a case. So those are all records of this office that need to be tracked and maintained.  So we could apply records retention to these things through the records management system. We could also apply litigation holds, legal holds on these records to prevent them from being destroyed unnecessarily because we have a court case or something going on where we need to have these records on hand. The records manager system also allowed reporting of records. And a bar coding system. We could tag our physical files and keep track of where they are. Are they in a file room? Are they in our offsite storage? Are they in an attorney's office? Where are they? And there is a circulation mode where we can keep track of those records now where they are location-wise. So it's, again, that defensibility on being able to get our hands on those records when needed. And this really led to, you know, there are a lot of benefits to a document management system. Like Peggy was saying, you know, the desire for collaboration of those five groups I pointed out at the very beginning, there's oftentimes many of those groups are working together on projects or on initiatives or on cases even. So we need to be able to coordinate between each other and not have to be creating 500 extra duplicate documents, you know, emailing back and forth a copy of a Word document everyone's working on. Maybe we only have one document we all work off of for once. That defensibility, you know, being able to set a streamlined security approach to the entire environment. So that way you can protect that sense of the information outright while also allowing that public or more, you know, less sense of the information that could be shared between sections to be more available. This system also provides a structured filing system. So rather than me being able to just create something called NAICS stuff or NAICS miscellaneous records out there and I could put whatever I want in there, I need to be filing and organizing my records based on what they are. This is case ABC, this is project 123, those types of situations. The searching capabilities of the document management system are better than what our shared drives or local drives can provide us. Rather than just knowing the name of a document, you could also search based on the creation date who authored it, comments that are tagged to those documents. We could search the contents of a document itself or file itself and find information now. So it provides a much more powerful search capability for our office. And then lastly, that automation process, you know, where we can automate that records retention schedule now. So we can identify all those records that once that have met its records retention requirements and be able to dispose of them in accordance on a more routine basis. So these products are great, they sound really neat, but how do we go about getting one? So the first thing we had to do was the request for proposal. But it wasn't as simple as you might think for the records manager. I actually had to make a case for records being involved in this step. I was kind of brought in at the last minute because I had somebody there that was saying, you need to bring the records manager in. The people involved first were our IT department, some attorneys as subject matter experts, procurement and litigation support. And it was actually somebody in litigation support that kept nudging them and saying, this is a document records management system, you need to involve records management. I knocked on a lot of doors for this. I kind of jumped up and down, wave my arms, hello, look at me, listen to me, let me be involved. You can't just stop the first time somebody says, nah, or we're not really sure how to involve you, you just need to be persistent. What I did was I requested similar RFPs from other states, and I was specifically looking at RFPs for records management systems and the records management requirements. Because I understood that there were a whole group of people involved in this, and we're gonna talk about those roles later on. But my specific role was looking at the records management side. So that's what I was looking for in these RFPs. And I had some contacts in other states I knew had done similar things. So I asked for those so that I wasn't reinventing the wheel. What did they require? What did they really want? What questions did they ask? And then we put together a list of the requirements for the system and kind of ranked those requirements. All of the vendor questions that were asked during this process, so you put the RFP out and then there's a time for vendors to come back and ask questions. They were funneled through the IT project manager, but then he would push them out to the subject matter experts for a response. So if the question was specifically about records management or some of those functions, he would bring that to me and I would be the one to respond. And the RFP is the request for proposal. So this is the document that's going out that says we want to purchase the system. We want the system to do certain things. And now we want vendors to come back to us with proposals on how their system will do that. So we had some document management requirements. We had to be able to save and organize all doc types, including email. This was very important to us that we'd be able to manage email. It had to be able to search and display results, retrieve documents. We wanted granular security. We wanted to be able to lock down everything from an entire group of like an entire unit all the way down to maybe just one document out of that unit. We wanted to be able to categorize it with retention periods and record series. And we wanted it to have certain workflows. Additionally, we wanted it to integrate with existing tools. Nate already mentioned that we wanted it to integrate with Outlook, but in an office the size of the Attorney General's office they had all kinds of other systems that they were working with too. And we wanted it to be able to basically talk to those systems. It needed to capture certain metadata attributes about the documents. And we'll talk about some of those later on. We wanted to capture versioning. So instead of having to go draft one, draft two, draft three, we wanted it to capture that in a way that we only had one document. And within that document there were different versions. And we could look at the most recent version or go back and look at the first or the second version. But that eliminated some basic duplication in documents. We needed to be able to redact. We were a law office, we dealt with a lot of sensitive information and being able to cover that information up before those records went out was important. It needed to have audit capabilities on the system. We had to be able to comply with personal information regulations and there are a lot of them. We also needed to be able to comply with public record exemptions, certain pieces of information that don't go out to the public. And it needed to have disaster recovery capabilities since we were basically gonna put all of our documents in here, we needed to be able to recover those in the event of a disaster. So those were the document management requirements. Now the records management requirements are a little bit different. The records management system doesn't actually house the documents themselves, but it houses a record of the documents. And this is where we apply retention. So the records management requirements were that we'd be able to intake the file structures, assign retention schedules and retention settings to those, manage our own set of metadata fields in addition to the metadata that was coming over from the document management system. We needed to store track and ultimately be able to dispose of physical records because a lot of times we had some records in electronic and we had corresponding records in boxes, whether they were in our own storage areas or in an offsite facility somewhere. It needed to have security on the system. We needed to be able to search the system ourselves. We needed to be able to put legal holds on things to check documents out. If you check documents out, you can't make changes until they're checked back in. And it had to comply with Department of Defense requirements for secure document management systems. Once we got these proposals back, we created a team that included different parts of the office. So for the document management system, we would recommend a team that consisted of IT because they're gonna be the ones implementing it. Records management because records are going into the system and so records management needs to be involved in how they're going in, how they're coming out as well as a varying group of users because while we were mostly lawyers and we had lawyers on this team, there were other users. Maybe it was the finance department or HR that were also gonna be putting records in to this. And we had a procurement on this team as well. We scored using a consensus scoring. We had a score sheet that directly aligned to the sections of the RFP. So in the request for proposal where we had a list of requirements, our score sheet directly aligned to those requirements so that as we're reading these proposals and some of these proposals could be an inch, inch and a half thick. They were big proposals. We wanted to be able to easily mark whether it had met a particular requirement or not. Each team member filled out a score sheet and then we would meet to discuss and agree on the final score. So this is important, especially in a public agency where all of our records are subject to public records request. We would discuss the final score and we had one person that wrote the final score into a tally sheet. That way it was that tally sheet that was the one that was record and not each of ours that was basically just serving as our own personal reminder notes. The subject matter experts led the focus discussion. So if it had to do with system hardware, it was led by IT. If it had to do with the public records aspect, it was led by our public records unit. If it had to do with the records management aspect, it was led by me. So that way each person would understand and be able to convey to the rest of the group why something did or didn't meet the requirements. So a question has come in that's pretty simple to answer. Ask if we collaborated with the State Archives of Ohio. We do have one. It's different from the Ohio State Archives, which is where I'm working now. We do have a State Archives in Ohio. We did not, it does not certify records officers and we didn't really work with the State Archives during this process, but it was in the back of my mind. Having come from the State Archives, it was in the back of my mind, are we gonna be able to get stuff out of the system and to the State Archives, which we were able to do and we needed to do for the things that were historic. So after we got it down to the top three proposals, we invited those vendors in. Every vendor had equal demo time to keep it fair. We told them in advance what features we particularly wanted to see demonstrated and those features appeared on our interview scoring sheets. And we asked a standard set of questions based on the functional requirements, again, so that we're keeping the interviews with the vendors fair. So I know this is really hard to see and you're not gonna be able to read that, but I wanted to put this up here so that you had an idea of what our score sheet looked like and how we divided it up into broad category and then sub requirements under there and then the rating system on the right hand side. We made sure that we had the same person, the same group of people at each demonstration. Each person had a set of questions in their area of expertise. Of course, we could all ask additional questions if we wanted to. Just like in reading the proposals during the live demonstrations, we scored on our individual sheets and then we met right after the demonstration to discuss and come to an agreement on scoring. So now you've picked your vendor and now it's in the hands of who? And this is, honestly, this is when I joined the office at this moment, pretty much, I think, right, Perry? Yes. And this is where the title of our presentation and Take the Village really comes into play and like Perry said at the beginning of this thing, it doesn't matter if it's a document management system or another type of program that a office is implementing, it really does take the effort of multiple departments to really roll something out because systems impact the business of an office nowadays. It isn't like it's some sort of technology IT can just push out and people can start using. There are a lot of people involved in this process and in our office it was these groups mainly. And what we'd like to show here is that there are a set of ideal roles that you should really think about when rolling out a system in an office. So for instance, with a document management system, you have that ideal role of the vendor. They sold this product to us, but they're still gonna be involved in it because they need to work with us on developing the structures for the program. They need to work with our IT and educate them on how to set it up, how to maintain it, how to fix when there's issues with those systems and then that they assisted in design processes with our business unit. They sat down and tried to understand what we do and how we could build the system around those business needs. Obviously our IT would be involved in such a project. They are the project managers within our office for systems then overseeing the projects and rolling them out. They also have the infrastructure support in our office. So when we have issues, they'll be the ones to fix them. And then lastly, our change management education group, our trainers are based out of our information technology section. So they were ones that would teach the office how to use this system. The records management was obviously involved as well because the system is helping to manage the records of the office as well as controlling and automating the retention of the records on a more regularly scheduled basis. So in records management, it makes sense. We understand the groupings of records. We, while information technologies had started going around and meeting with people and talking about their records, eventually I said, well, let me come to these meetings too because as the records manager, I've been talking to everybody about their records all along because it's my responsibility to make these retention schedules. So it just made sense. And I already understood the records retention requirements and we could give guidance on template development because we understood how people were already grouping and using their records. And then of course, it's important to involve the business units as well because they're the ones who ultimately understood their records the best. And they had had some of the requirements and they needed to be assured that it would work within the system. They had security concerns, file formats, organizational concerns. They understood what individual documents fell into a particular record series. They set the policy and procedures for their staff and how their staff would use the system. And nobody understands their business process and access requirements than the unit itself. So it's really important that the unit be involved as well so that we can make sure that we have a tool that's gonna help them with their processes and not make them change their processes to bend to a tool. The original plan was to, and it made sense on paper. It was to do some conceptual training for each section. I got up and I did some training on, this is how we do it now. This is how we're gonna, this is the new terminology. This is how our old terminology matches to the new terminology, how shared guys match us to these workspaces that we're gonna have. So we did this conceptual training and then next we were gonna design the templates and the system. And once it was designed, do some hands-on training, then roll it out one section at a time and then when it would roll out to a business unit, then people would go around and do one-on-one support. However, as in life, it came down to, well, that didn't go quite as planned. In actuality, what happened was we did this conceptual training and we did the hands-on training and all of this occurred weeks, sometimes even months, before the sections actually rolled out. So if we don't lose things, we forget things. So by the time it actually came to the sections getting the roll out of the program, they had forgotten what they'd learned in the conceptual training and the hands-on training. So we would end up going back and redesigning and then doing some one-on-one support and redesigning again and retraining. Design sessions were held with each section by the vendor and IT and records management with the goal of making these templates that match their work. But we had to go back to the drawing board quite a bit because it was kind of a chicken-in-the-egg scenario. How could they design something for a system they didn't understand and yet how could they go into a system that hadn't yet been designed? So our initial plan made sense on paper, but in actuality, that's not really how it went. Yeah, like the well-laid plans are fairly ever really done well. You're always gonna have bumps in the road with these types of things. And one of the things that we would caution people right off the bat is those designs are the key for that user buy-in. So users are not happy with the templates that you provide them or set up for them. How are they gonna buy into this program that you're pushing out? This is not a step that you really need to rush. So when we came to issues, there were a couple things that hit us that kind of caused these bumps in the road. We had a standardized standards committee that streamlined a little too much throughout each of our business units. Some of the templates, some of the designs that they had were a little too similar between business units. And as we saw at the beginning there, we have five very diverse business units in this office. So we can't have designs that fit across the board for all of those. They need to be a little bit more specific. When it came to the vendors in IT led design sessions, again, this is where there was a little bit of lack of realizing records management and how it could help with the designs in this thing. Because we are already subject matter experts, in starting become system experts, we are often served as an intermediary, helping to express concepts to our business units while also trying to put record processes and designs of those specifications. But it's also an IT project. So that means there is a schedule on hand. So that means they cannot be held up. They have to keep pushing forward so they can have this system online or pushed out to the organization by a certain date and time. So, this is where you need to be a little bit more flexible in your schedule. You can't be getting things done accurately within a short timeframe or a unrealistic timeframe. And oftentimes during our sessions, it seemed like records management, check off box or attendance at a meeting was often left out because we have to push ahead with the design. And again, if it's not designed correctly, it won't work correctly. People won't be happy and it's gonna cost you time and money to redesign over time. And Nate, I'm just gonna add that even when I got here to Ohio State, it was the same thing. So it's not an issue that is unique to the Attorney General's office. It's kind of a different issue between the way information technology is trained and the way we were necessarily trained. They stick to project plans and project schedules. And I've often had to say, whoa, let's slow this down again. We need to think about this in a different way. I'd rather do it right the first time than to have to go back and redo it at a cost later on. So it's not a unique issue. Right, yeah. It's definitely something across the board. It doesn't matter the institution or organization. It's more of just a strategic way of approaching things. So I kind of explained some of the issues that our IT and our vendors had during this process and records management as well. But from the business user's perspective too, when we done trainings, when we did these designs and some of this conceptual training wasn't quite grasped by the attendees or we had done it months before the group actually received these products and allowed them to kind of revert back to their past practices. So once they got into the document management system, they kind of tried to redesign what they had already done in shared drives. What I can do on my local drive of my computer. But it doesn't really allow them to take advantage of the classifications of retention and the searching capabilities that the system provided. So you need to really focus on lining up that training and those conceptual trainings along with the design. So it is all within that same time period so people can retain it and understand it more clearly. And again, when we talked about the design aspects and the templates that were made for the document management system, we need to always think about how this is fitting a business process and how it's also fitting a record retention schedule of the office in order to make them work well. So again, if users are kind of revertened back to Nate's file, where is Nate gonna file all his stuff? I'm oftentimes gonna squeeze a bunch of things that shouldn't be together into one place. That makes it much harder to apply record retention to it. And then there's oftentimes where we have the question, do we create containers per the matter, case name, project, initiative, per the year or through some other formula in order to effectively apply this record retention? And the solutions often were more additional meetings and trainings, guidance documents based on these common issues and such as that. But we, throughout this process, I'm sure Perry can say the same thing over at OSU, we need to get over this stigma that records management is really only involved at the end of the life of a record. This is a really consistent scenario that happens in organizations where we need to keep budding in early in the design process to really make the case of why we're being involved at the beginning of a records life cycle. Records management is tracking the life cycle of a record from its creation, through its use, through its inactive state to its ultimate disposition. So why wouldn't we be involved at the very beginning of a system? Day one is being made, records are gonna be going into it at some point. Why aren't we there at the beginning to understand what's going in here, how long should we maintain information in this system and when can we ultimately delete that information from those systems? So it's something that was a hurdle we always had to try to get over. And I like to say now, my office has definitely gotten over that hurdle. It's just one of those things that we didn't think about at the beginning. And I see a question that I want to address before we go further. The question is what specific designs did we have to redesign? And the easiest way for me to explain it is we were going from a shared drive system where everybody basically made their own files. So I could make a folder and I could make as many subfolders as I want and call those subfolders whatever I wanted. And Nate doing records management as well could come up with his own and they could be totally different and storing the same documents. Whereas in this particular system, we had workspaces and we had templates. And so if it was a case file for an attorney, once they opened a case file, they got the same set of folders. Every case file they opened had the same set of folders. Every HR personnel file that was opened had the same set of folders called the same thing. So that's what we were kind of designing was these templates that could be used and that were a standardized look to them. And let me just add another point. And the intention of that is it cuts out the need for me to guess we're at the file something. So if we had a workspace called Case ABC and it had an email folder, a folder for my pleadings and orders, a folder for my settlement agreement information, I know exactly where I had to file that information.    We standardized it. So it takes a lot of the guesswork and a lot of the legwork off of people when they're having to file their records of the office. Okay, so we had some other issues that came up along the way. And I think that you're gonna see a common theme running through here, which was Nate and I in records management were trying to figure out how to communicate with IT and vice versa. And we got there eventually. But one of the issues was who to end users go to with problems. And we'll see on the next slide how we ended up dividing that up. But what we knew is that IT knew the system features. They knew how to run the thing. And if there was an error, they knew how to fix that error and run certain things. But records management understood how the system should be used for the function that it was there for. So I came up with a, who do I ask document? And we put this out there during training and made this available to everybody. So those things that needed to go to the IT help desk or support desk were how to, if you need to add a new user, or if you were missing a feature or a plugin, it was there yesterday, it's not there today. If there was functionality that was going wrong, adding, removing people from groups, issues checking in and out documents, these very technical things. But records management was responsible for creating a workspace. I need a new workspace. I need a workspace deleted. Those are records management functions, making the space for the records, deleting the records. We were also charged with security changes, updating any kind of metadata, updating the matter type, which is basically the record series type. So something needed to be re-indexed. Coming up with new workspace template designs. This was our thing, because this was all about how do we organize the records? Closing off the workspaces, because ultimately that's what's gonna start that retention clock running. So we were responsible for that because that's a function of records management is the retention.  And I've probably taken those classes as well. How do you find information? So I laid it out this way, partly for the end user and partly for the help desk itself because sometimes they were trying to answer these questions about, well, what folders should I put? If I need a new template, what folder should I put in there? And I had to, again, wave my arms and go, now that's not really a technical thing. That's more of a records management thing. I'll work with them to come up with the template and what folder should go in it. And then I'll hand it to IT to design, to do the programming to actually create the template that I've designed with the business unit. So we were constantly running up against competing ideas of an open system for collaboration versus privacy and security settings that are prescribed by various rules and regulations, basically the law. And our document management system was intended to provide strong security controls as well as a good collaborative environment. The problem with security though is while we have attorney-client privilege material, that's a big concern. The issue laid more with a few other things. So for instance, in our previous share drive system, we could hide records easily. And this was often done in that idea of attorney-client privilege, that material that only the attorney and that client are allowed to look at. The document system was supposed to be more open by default for collaboration because we wanted to be allowing sections to work together. So this led to more people once we have the document management system in place trying to again hide information because they were afraid of being not compliant with their attorney-client privilege requirements. Groups also got in trouble though, where they may have gone a little too far with setting security and hiding records that even our administration couldn't access. And our administration should be able to access most things in our organization. So if we're hiding certain documents from even them, that becomes a little bit hard to manage those groups. So big hurdle that we had was that the general idea was to lock down as little as possible, such as say a single document or a folder instead of a whole group of records. So maybe you have a draft, I should only lock down that draft until I have my final version. I shouldn't be locking down everything that I have in that entire workspace or those series of folders. And what this led or possibly could lead to was incomplete public records requests and discovery responses, where we can't find those records because they've been hidden from us to be able to answer a public's request or start preserving records for a litigation scenario we're in, as well as it affected transitions in our office, employees come and go from our office all the time. So if we have hidden a bunch of documents to only ourselves, it becomes much harder for the new person that comes into our role to be able to pick up the work and continue. Government keeps moving on just because you've left doesn't mean that work stops. We also had some concerns with collaboration, understanding the security hierarchy took some time getting used to it. It wasn't very clear to everyone. So, you know, there had to be some educating on that.  Who gets what default privileges at the start and who shouldn't. And records management really stepped in where we worked to identify ethical blocks or ethical walls that need to be set up due to attorney conflict or, you know, two sections of our office going to court against each other. It happens more often than not. The benefits, though, with collaboration is, you know, it really did ease transitions in the office. I can find a case that I'm taking over from a retiring employee and it made it much easier for me just to jump into their shoes and start that work. It also allowed different groups to be able to work together in one place, eliminating those duplicates, you know. Eliminating the need to be emailing a draft to back a fork between people. You can just go to this one document and work on it all together. Really, you know, from the rollout we did learn a lot from this. You know, your rollout schedule really does need to be flexible so for your user's benefit, you know. If someone is not ready to be rolled out, don't train them. Don't force them to be on that system until they feel confident in the system. You really need to have a designated design team. I think design often fell onto the shoulders of whoever was in the room at that time kind of situation. So you really need to have that specific group of people designated to be involved in the design process. And then lastly, you need to have a post-implementation plan who's going to take on a support role. Who do users go to for questions? You know, like Perry was showing, we had to create a document that explains who to contact when you have an issue. And this really led to, well, okay. So that was the document management system. I just want to briefly go over, you know, the roles of how we rolled out the records management system. So remember again, we have a document management system and then we have the records management system. And we're looking at about 10 minutes. Yeah. Yeah. Sorry, I'm trying to speak through these. So we ideally have three groups in for our records management deployment. Obviously records management is a unit of our office. We were involved because we entered in records retention schedules. We identified storage locations in our office. We ran the records retention processes and we worked with the sections on the defensible deletion of records from the document management system. RIT was involved because they could sync information from the document management system to the records management system. They could provide that technical support. And then our office's records coordinators, people that understand the records retention rules of the office could work on adding in those physical records and barcoding them, assigning them locations and managing that check-in, check-out process of the physical records of the office. And you know, with the records management system rollout, records management, you know, we're rolling out this part of the system. IT's main role was really to keep tabs on the vendor and make sure that the infrastructure behind the system was running as it should have been. Records management worked with the sections, records coordinators on hands-on trainings and we tried our best to tailor those trainings specifically to those section needs. Quick question that I wanna address before we move on. To what degree was your vendor involved in changes or customization? And I would say that at the beginning, probably for the first 18 months, they were thinking it would only be a year. It ended up being 18 months to 24 months, I would say. They were involved heavily in changes, especially in changes to the programming and the background and the functionality of the system. Records management was responsible for changes to the templates and security and things like that. So if it was a basic change, records management and RIT department were responsible for it. But if it actually involved a major programming change, or if it was an issue that hadn't come up yet, then the vendor was heavily involved. So one of the things that we learned was that there is actually math involved. See, I was naive. I thought that the whole process of retention from start to finish was automated. In actuality, there is human intervention at every phase of the retention process. The computer still needs something. It needs to be told to take an action. It is no different here at Ohio State University. We are programming these retention things in on the background. Nate, if you wanna go ahead and... Yeah, sorry. So it's kind of like an equation. This leads to this, which leads to that. This made it take, it took longer to program in our retention. I thought I was gonna put in human resource records five years after the person leaves the office. But it was much more complex. Retain five years from a judgment entry, but only 60 days after dismissed. So there's two different retention things going on there. And we had to program each of those with these if, or, and then statements. All those things that you thought you could forget about when you walked out of math class, it felt like we had to do. So a very simple retention period, such as retain five years from a matter closing. We actually had to program every step of the way. So we had to program a trigger, the matter has closed. We had to put in a date that was gonna trigger the matter to close. And then we had to program a retention clock for five years. But we're a law office and a public office. So oftentimes we had to delay something, whether it's for a public records request, a lit hold, because we thought that an issue might come up. So we've programmed in a delay. And then if we needed to delay it, then we had to re-queue retention eventually. And then we had this approval and then the actual destroy. And each of these were steps that we had to program in and we had to take. What this actually led to was making us rethink our retention period statements to use fewer triggering events, such as matter closed, employee separation and more static retention periods. Maybe like what I'm doing here at Ohio State is I'm working with our document management system is instead of if it's gonna have an or statement and it's not too much different or if it has a trigger and it's not gonna make that much of a difference, I'm almost willing to add a year or two onto the retention to make it a straight, say seven year retention rather than having these trigger events that we have to build in. So it made us rethink what we were doing. And yeah, and when it came to the disposition, this was where some of that customizing had to come in, talking with the vendor and that kind of thing. Because out of the box, the product really did lack the criteria we needed to be able to document the destruction of records to the way we're supposed to be by the Ohio law. So we had to finagle a little bit and really come up with a workflow for our office to be able to provide reports, two sections to review, have them authorized deletion of those records, delete them, and then we produced several reports to kind of put together. So we knew what we referred to when we destroyed the record, what retention schedule, the date and time those records are actually deleted and kind of combined it that to give us an accurate record of the disposal of those records. So now we're to lessons and learned and I guess we can kind of breathe through this, Perry. Yep. So we learned that people are not necessarily quick to embrace change. They don't like it. They don't trust that the new system isn't gonna lose their documents. But we prided ourselves in helping them get through that and being able to put their faith in the new system and not have that fear. We also learned that acceptance seemed to run along a generational line. Younger attorneys coming out of law school were more likely to say, oh yeah, this is a great system. I'm all in versus attorneys who had been there longer. It was hard to shake this, mind not yours mentality. There was this fear that people were gonna change other people's documents or delete other people's documents even though we all work for the same agency and all have the same goal in mind. Fear of losing privilege or confidentiality in the open system. And we saw that lack of procedures lead to people making up their own procedures. Now, when it comes to these types of projects, you gotta really ask those questions constantly. You're not gonna know everything we're asked about and your vendor does have the answers or they can at least look into it and provide you an answer in the end. And you really need to rely on those vendors for those fixes, at least at the beginning. So what we ultimately ended up doing at least for the records management role outside was we planned weekly meetings with that vendor. So we would come with a list of questions in hand. Hey, we're trying to do this or hey, we're noticing this error message happening. And they'll be able to work with us and figure out solutions for those things. So what I would encourage you to do is if you're in a situation like this, like I said, whether it's a document and records management system or any other system that's gonna hold records or information in some way, shape, or form, get involved in the design. You need to be anywhere where records are gonna be affected. Reflect the record series off of your retention schedules in the design, be open to questions, be open to asking questions, and be represented in the meetings. Get yourself at the table. Another thing about is also really playing in that sandbox. So if there's a test environment or a sandbox that the vendor sets up for you, try to get access rights to that. Trial and error is a really big thing to really understand how to use these projects or products and understand features of them. This is really how we learned about how metadata works in the system. It's really important to understand it because that's how you can search, that's how you can identify and manage records within the system. And like Perry said, her and I both have a library and information science degree. So we understand searching. So we played around with searching in the system and how to make very narrow searches, very broad searches, that type of thing. Also allowed us to understand how the security hierarchy works in it. And we would actually integrate older records, things that had already met retention at that point into the system so we could test it out. So we could see we could actually delete a record or something. And there was that preparing and assisting options of our office after we rolled out. Focus on groups and not on the office as a whole. That's the one big thing I could say about this whole thing. You can't be trying to train everyone at once. You need to focus on specific groups. And when you do those trainings, you need to have examples that are meaningful to those groups. You can't just talk about case work to a bunch of HR people because they don't deal with case work. You need to talk to them about personnel files or benefits. One of the big things, I know this is kind of silly to say, come early and stay late. When you show up early, you can make sure everything's running appropriately in that training room. And when you stay late, that's when you get people asking questions. That's when you can really make those contacts, make those people that, these are the people that you're gonna go back to and really help out or really figure out those issues that might be underlying other people's minds as well. And then design guides, tips, graphics, system functions, do brown bag sessions, do lunch and learns. All these types of things really do help out in the long run. And of course, you have to have buy-in from upper management for all of this to be possible. And you have to have policies and procedures. If you have policies and procedures and guidelines laid out, it prevents individual decisions in what is supposed to be a group collaborative environment and it prevents lax use. And policies and procedures allow users to take on the responsibility of using the system. You know, this was a multi-year process. And I would say we're close to being done. And we know the good. We've come a long way and there's more work to do, but we can already see the results. I can already tell you, we've had people leave our office, Perry included, and I've heard them come back and say, man, I really miss that document management system we had. It was perfect for our needs. I'll look, Perry, jump in here. And these systems are really great, but don't think that your work is gonna be done once you have the system in and purchased and in place. You have more work to do. If it has to do with records and information, your involvement is not for a finite period of time.  So I know- Thank you, guys.