 Well, welcome everyone to today's presentation, Building a Roadmap for Implementing an ECM Solution. Organizations that want to implement a new enterprise content management solution or move from one ECM to another often underestimate the resources necessary to not only move but to improve business processes. So ECM solutions should be implemented with full knowledge of their capabilities and the objective of improving the way employees work by taking advantage of all of the features of the ECM solution. Those of you in my class are learning about many of those features. This session will explain how to look at where you are today and build a roadmap comprised of the steps and a timeline for implementing a solution for tomorrow. Our presenter Helen Streck is president and CEO of Kaizen Infosource. She's had 32 years of experience in records and information management. She successfully described and defended her program designs and practices to the U.S. Attorney's Office and that's a big deal. She served as director of corporate records and information management for pharmaceutical companies and records manager and consultant for municipal government agencies and law firms. She has crafted information management program strategies for a broad spectrum of domestic and international clients. Our presenter is active in ARMA International and has presented at international conferences. She has published articles in various professional newsletters and is a past contributor to the AIM Infonomics Magazine. So right now I'm going to present to you our presenter Helen Streck and she's going to continue the presentation. Helen you can start sharing now. Yeah so we're going to talk about what you have to roadmap and what that means to organizations. So let's get started. I want to start with talking about the background of technology because you have to understand some certain components of the technology in order to make sure that all that work is captured on the roadmap. We'll talk about the approach and the approach is Kaizen's approach. We believe that there are three major segments to roadmap and to an implementation and then we'll show you pictures or I'll show you pictures of how we build a roadmap for our client. We've been doing this for the last 10 years and we have found it works. It's very effective approach to help organizations put in technology to more migrate from one platform to another. So let's look at the background information first. When we talk to folks we make sure they understand that there has been complete, not complete, there is a groundwork in the citations for moving to electronics. We still find smaller communities in the municipal arena where they're like well can we use technology? Do we have? Is it legal? We still hear that today and there's only if you're and we do a lot of work in California. That's important. The only place I have been able to find where a wedding signature is still required is in a will. Otherwise electronic transactions, electronic documents are very acceptable. But you must prove that your system is trustworthy and that you are protecting the records and information. This ISO standard, if you haven't gone through it, is a really good background document that talks about document management and electronically stored information. It is the second version of this document. So the rules for having technology have been around a very long time. These rules, these standards are important for you to understand because as technology evolves and it will, do you still meet the criteria of the standards that make sure that information is protected? That's where we're going with this and that's why our roadmap's important. And we'll talk about why it's not wise to just go out and buy something off the showroom floor and why these standards matter. The other thing we recommend when we talk to folks is that you have to understand what a web or cloud-based system is versus an on-prem. And we have it all over the board in terms of some clients only want cloud, some only want on-prem. There's still a lack of trust in your software vendors as a service. And I'm going to tell you, most of the folks that play or strong contenders out there in terms of software, the vendors must meet standards where they're just not going to stay in business. They won't because people will move on because they're going to find somebody that helps them meet all these criteria. And some of that, you can protect an organization with terms and conditions in the contract. But how do you enforce that? And there's still a long ways to go. It's important that you understand when you put in the cloud services or you're using web services as a software, as a service, as social media, there's still areas that are not clear and straightforward. But you can take care of your client or you can take care of your organization by making sure there's a plan. So one of the things that we get a lot of questions is, why is it so difficult? Why can't we just go out and buy something, implement it, make it work? Well, the people making the decision at the top in most organizations truly don't understand the technology. What it can do, what it can't do, what are all the options? Because most decision makers are out there trying to solve a single problem. And they're not looking for a solution that can maybe do two or three things. And that's important. Many IT departments are pressured to just get it done. Most IT departments are not your data experts. They don't understand the requirements behind the documents in the system. They don't understand whether it's protection, security, access. That's not IT's forte. And so they don't understand why it takes so long. Also, most IT departments are not business improvement, business process improvement experts. They are technology experts and you have to bring both sides to the table. There are people who are vulnerable to sales pitches and it makes it very difficult. I've met large organizations, high tech organizations in the Silicon Valley, where they bought million dollar systems and they didn't work because two executives went out on the golf course and they said, yes, you know, the vendor said yes, we can do that and they can't. So you really have to understand what the software does. But the software won't solve problems magically. It isn't, I've got this technology. We've often seen technology put in and one mess moved to the new system without fixing the mess. So you're only moving the organization or the mess into maybe something that compresses it faster or smaller, but it is still the same mess. So we have to take the effort to understand what change is going to happen. And often change includes changing employee behavior and that makes people uncomfortable. You have to look at, I've got this technology that can eliminate activities, may add some activities, but I'm going to need you to change. And we have to, as professionals, say to our clients, and your organization is your client, you can't continue to operate the same way if you want to get the best out of this software. And a lot of executives are finding it harder and very hard to tell people they can't do what they've always done. The other thing that makes, the other things that make it very difficult is that technology keeps improving. So how do you stay current? Do you need to stay current? And the answer is somewhat. You have to stay ahead of the curve so that you understand what the technology can do. But you don't have to be an expert, but there are people who don't stay on top of it and they get way behind very quickly. The other thing is we're seeing IT people turn over. That means those people who got the system installed have retired or moved on and that technology expertise of that software is gone from the organization and you have to bring people back up to speed. Now, if you're going to use a cloud-based system, there's a problem that often that mass storage and the duplication of storage, the contract terms are missed. Or they miss the retention and how do you require the vendor to meet those requirements? Most people are bringing us in today, and this is important for you to understand because they're having a data overload. And you might hear the word data or phrase data glut. There's just too much and they can't find things. They can't access it timely. They get 14 copies of the same thing. And all of a sudden they're going, we can't do this anymore. It's costing us human time and the experts are running behind a lot. And the last thing I want to share that makes it so hard is organizations don't assign a business owner to the system. We believe, we, and when I say we, Kaizen, we don't ever recommend IT be the business owner. The business owner is someone from the department that where they have a stake in the game. They have an understanding of the business. They have an understanding of the document. And if you don't assign that, there's nobody to really manage the system once it's up and running. So where do you go and how do you get started? Well, first of all, develop a problem statement and a vision statement. You might be surprised that you go, well, that's obvious. And I'm gonna say most people don't. And most organizations define the problem statement to say, I need a piece of technology to do something. That's not the problem. If you don't have a clear problem statement of what you're trying to solve, you don't know what the technology is that needs to solve that problem. So you need to work with people to make sure you clearly define what the problem is. We can't find things. We have multiple versions of things. What are the problem, or problems, so that you know what technology really means? You should define the rules first. You have to do information governments first so you know how records are going to be stored, how they're going to be accessed, how they're going to be indexed, and how they're going to be protected before you buy the system. This has to be included on the roadmap, or if you move any data before you do all this work, then you're not going to be able to manage it effectively. And you're moving the data mass or data glut from one system to another. And when you do get any new technology, are you willing to tell people they have to work differently? How do you do what you do today? How do we make things work through and flow through the organization? Because many technology ECM solutions will do work flow. We have a client right now where they had eight signatures on a contract. And I kept saying, why? Why do you need eight signatures? The answer was we need to prove that all of these people involved saw the contract and were okay. Work flow and approvals will do that, but you don't need eight signatures. And so we now got that to where there's only one signature that binds the organization. And then you have to, once you get the system involved, you have to make sure people are trained. And I jokingly say all the time, when you get tired, train them again. You'll have new people come into the organization, you'll have people who need to understand this, or they only learned a certain feature, they need to do more features, jobs have changed, you'll have to offer continuous training so people understand. And you have to make sure that people are doing what they're supposed to do, procedurally, because you wanna make sure the system is doing what it's supposed to do. So let's talk a little bit about the approach, because the approach is what you're going to put in the roadmap. We break it down into three phases. The first phase is you're going to plan for technology. And we'll talk about, there's a lot of work that goes into the planning. The second phase is selecting the technology. And I also often jokingly call this selecting your new best friend, because you're going to get into a very long-term relationship with a vendor. You have to know what that vendor offers, and if you like that vendor. And then phase three is post-selection, what's going into the technology, where's it coming from, and how do we get it there as quickly as possible. Most ECMs today in the public arena where I have spent a lot of my time are just glorified imaging systems. The full extent of the software is not being used. And part of that is lack of education and training. Part of it wasn't planning correctly. And part of it is really not liking the vendor, so I don't want to do anything else. I'm not going to make it better. Excuse me. So what do we do when we plan for technology? In any organization, this project needs an executive sponsor. That's the person at the C level or just below the C level that removes all the roadblocks that exist. And you're going to make sure that all the right people are at the table so that this project moves forward. Because when you implement technology for different departments and you want to move their documents, you're going to engage a lot of people. And we'll talk about what the team should look like. Create a problem statement and a vision statement. Always know where you want to go. Usually at this point, if some people go, why do you need a vision statement and a problem statement besides they make sense and you manage the project? But if you don't have a vision statement and you don't have these statements, you don't have boundaries around your project. And there's an horrible, and I call it horrible because I've seen it happen, opportunity for scope creep. So if you don't define the boundaries in which this project is more than worth, you may never get it off the ground. And that's important. Then you're going to understand what an ECM can and cannot do. What modules exist? Do you need cloud or do you want on premise? What's the trade off? What does the vendor support me? Does that mean it does, and annual maintenance is not ongoing changes. You have to, if you're going to change something, then it will cost your organization more money. So when we talk to our clients, if you put in an ECM and you want the system to do something, you write out those requirements, the vendor comes in and you do a test. We'll talk about that. If the test doesn't work, they have to make corrections. And that's important. If they put in the system, you test it, it works, but you want something else, that's a change. Change costs money, corrections do not. And a lot of the software out there today comes in modules. So you're talking about a project that is going to cover anywhere from two to four years. Putting in an ECM does not occur overnight or over one year. And in the planning stage, the fourth step is to define what are the business and functional requirements? What do you want the system to do? This thing you want to do is plan on a budget for three years, minimum. You can't get it all done. You're doing change management. You're making people change the way they work, you're moving documents. You just can't physically do it all or logically do it all in one year. You're going to, in the planning phase, you're also going to develop the government. Now, you can build the governance, which are the file plans, the retention requirements, and it doesn't mean you can't change them once you know that the system offers a certain functionality, but you really need to have them sort of built up front so people can make sense of the data and the documents going in. You're going to select that business owner who's not IT. Who has administrative rights? Who do you go to when you want something new in the system? It should be the business owner who has oversight over the whole application so you know where everything is and how it was built. Then you're going to sit down and put your roadmap together. Even if your roadmap isn't perfect, it serves as a guide to the organization about what is going on, about how long it's going to take, and that's important. Things that are often left out, and we talked about this so I'm going to, is the problem statement. The other thing that the vision does is it manages leadership expectation. If you tell the C level, the vice president and the chief operating officers or the CEO that it's going to take you three years, and you found a plan, they're going to go with you most of the time. But if you don't have this written out, then they don't know how to manage, you're not going to be able to manage their expectation. The other thing is we believe that a racy chart needs to be created in the first place. A racy chart is a chart, and I have a picture of one, so we'll show you, that shows who's responsible, accountable, who should be consulted, and those in the organization who just needs to be implement. So racy comes from, is an acronym of those requirements. So you're telling people, here is who needs to do what, and that's important. And the vision statement should change the overall program effort and direction. Everything's important. So let's stop and talk about who belongs on the team. Well, the business owner, we've mentioned a couple of times. You still need IT on the team because they need to make sure that your ECM solution will actually work on the organization's infrastructure. And if it's going to require time from IT, what does that look like to them? You need the executive sponsor. We believe you need that information governance or records and information management professionals, somebody who understands the rules about the document. And then I would bring in somebody from the business who's got to have a stake in the game about it's my record, I wanna know what's going on, and I wanna tell you about how we use these documents. And often we get the question, well, who else should be there? At this point, those first five are almost critical. You can't do it without it, but you might have people, the who else might be somebody who's gonna do a lot of the work. You might have one or two admin people, if they're going to be scanners, they're going to be putting documents in the system, you might have a business user in there just so they can provide insight onto how they work. So we talked about what RACI is, it's gonna be inside your roadmap or part of it, but this is a picture of a RACI chart. So I believe you have the slides, you can look at it. This is one for a city, and it calls out the position of the city manager, the department heads, the city project manager. So the organization needs a project manager, your vendor will come with the project manager always, and the vendor project manager's timeline will impact or meet with the organization's timeline. You need a city or an organizational project manager. We have IT, we have the system manager or system administrator. You might need consultants, maybe not. So who's gonna be doing work? That goes on the left-hand side, major milestones go across the top, and in that chart you will put, so project sponsorship, the city manager is probably accountable. That means the rate or the response, the actual role of making sure this happens is at that level. Responsible is usually the people or person doing the work. Consultant means I need to come ask you and talk to you, what do you need? And other people may just need to be informed. So that's what a racy chart looks like. It's a wonderful tool, and sometimes we use it just to manage the management so that not everybody weighs in at the same time. The importance of a racy chart also shows where things are not done in a vacuum. So you're not making these decisions by yourself. You're showing everybody who you're talking to because you know how communication or the lack of it can make or break a project. So you wanna make sure you define who's responsible, who's accountable, who's doing the work, who's at the executive level, making sure they're signing off on the budget, who do I need to talk to, and who can I need to tell about the project? You'll need to define all the communication points in your roadmap, and you need to think about that upfront. Thanks to, this is also in the roadmap, selecting the technology. Do you have to do an RFP? Some organizations do, some don't. There's been in the government entities, most of them do. So you have to have a lot of experience with doing an RFP, and that's a whole different session. You're gonna have to compare the responses from that RFP. You may want to have the vendors do demos. Now we write the script for our clients because I want vendor one and vendor two to do a demo that compares their products apples to apples. Otherwise they come in and show you the best thing about their system but it may not be what you want. So we control the vendor demo so that the client or customer can see what it does that meets the needs to address the problem statement. Oh, so where's that problem statement comes back up in this conversation again? You'll get script helps answer those questions. And in this space, you're gonna have those demos and you're gonna rank the vendors by using charts or scorecards, we call them scorecards, and then you're gonna do a selection. You'll contract with that vendor in this phase and you may even refine the deliverables, the modules that you want and the cost. And you're going to continuously update the roadmap along the way. You're in a relationship, you need to like your choice. I have watched software vendors lie to people and lose the entire contract because of that. You're in a relationship, you're gonna call them, do they pick up and answer your question? Do they, and I put in the word respect, do they respect your customer's knowledge? If you're the expert on this team, your customers may or your clients, right, whatever word works best for you may not have the same knowledge. So they may ask questions that you feel are very elementary but it's important that they're answered with respect because they're going to be the users. So that's important that you feel good about your choice, vendor choice. You should do a comparison chart. You should see what your, if you're doing a demo and you have many people in the room, you wanna see what they feel about this vendor and if they answered the question. You also wanna check their references and make sure that they have a history of doing what they say they will do. The last phase is post-vendor selection. Now you're gonna say, okay, who goes first? What department? We call it a proof of concept or a pilot. It just, how do we get the first group or departments into the system? You create the file plans. The file plans are how you index, organize the information and how you apply the retention requirement. If it's on-premise, you're gonna have to configure the server and all of that has to be done right after contracting. You'll configure the file plans and the rules. You'll wanna know if there's workflows. Do they have retention? How many users do you need them to be? If they're a public agency, will they need to be shared on a public web portal? All of this gets done post-vendor selection. And you have to have the new environment set up and configured first before you move documents over there from another application. And if you're changing the structure quite a bit, that's a little bit harder than you think. And at the same time, many of the vendors can help you with that process. You'll be testing. Again, we use a script. Is it doing what you told it to do? You'll refine, make corrections, but all of them will have, all the vendors will have you sign off and confirm configuration, otherwise it's never ending loop. And they won't do that. So it's important that you understand at some point they're gonna say, are we done? Is this what you want? Once you sign off, you're going to train and educate the end users. The people that are going to use the system, whether it's a look to put documents in, to save, everybody has to be trained. And along the way, you're gonna update the roadmap. Documentation you're going to need. Here's a list, during implementation, you're gonna need specification, testing scripts, rights and ownership, groups and their rights and post implementation. Implementation, you're gonna need new procedures. We're gonna do this differently. We're gonna have rules for moving electronic documents, capturing metadata, tenant auto index, so I don't have to index anything. And depending on what your document is, yes it will. Procedures and schedules. Who's doing what for dispositioning the obsolete documents? Because isn't that part of the rule system? We have a retention schedule. So how do we get them dispositions and bleed it out of the system? And you're always gonna have rules for access rights. Who has a right to know what's in there? Now, for most public agencies that we work with and even some of the private companies we work with, we talk about always start with access rights being open. That means anybody can see it and they can print it. Not everybody can change anything, but they can see it and open it because part of the problem maybe you're solving is the proliferation of duplicate documents. Well, if I can't get to it, I'm gonna make another one. So we're gonna, the only way that's gonna be stopped is if people can see the documents and can get to them. So there's a lot of work that has to change over time to put in an ECM to achieve what you want it to achieve. And then you're gonna train the people on the governance. What are the rules? What's the policy? What are the procedures? How do I classify my information and provide access rights? People need to understand and use it. They people need to be trained on how to use the system to the extent they need to know. Now, that might sound obvious. You don't need to train people who are just gonna be looking for documents, how to scan them or how to upload them or how to import them. To be careful and thoughtful about the training because people only need to know what they need to know to use the system. You want to encourage a culture of compliance. And you also, in the training, on every training course, wanna make sure people know where to go for help because I've gone off on vacation for three weeks and I can't go, I don't remember how to do something. And we see this all the time. And so you wanna make sure, well, I know I need to call up Helen or I need to call Pat, whatever's the right person, whoever's the right person, you wanna make sure people know where to go to quickly and easily. So training is not always, let's sit down at the computer and talk or see a demo or see a video. Sometimes it's being able to just make announcements or put something on an intranet page that says, if you have questions, call me. So I look at training. I'm a big, big fan of point-and-time training and as my term made it up, at the point in time you need to know something, how fast can I learn to do it? I call that point-and-time training because most of the time, if it's one task or one or two tasks, what can I give to somebody that they can do this if you go through the training in less than five minutes and know how to do what they need to do? And in order to make that happen, you're going to need what the system and many administrators going to need to really know the system in order to break it down into step-by-step processes. So now that you know all the work that has to go into a roadmap, so let's build a roadmap. This is how we're gonna get there. All the phases of inflammation go into the roadmap and it's about a two to four year period. It's a plan. I like a roadmap because everything is in one document. You're gonna say what work or tasks must be done for all three phases. So that means you're gonna really have to stop and think about it for a while. How do I measure success? What can I say to management, we've achieved this milestone, so I know we're going in the right direction. You wanna be able to estimate the time it's gonna take to work. Now, one of the reasons that folks often bring in outside help is because they have no idea how long it's gonna take to work to get work done. And at the same time, when I come in on a project, they go, what else are you working on? I have a client right now who's trying to put in two systems at the same time. I'm the project manager and there are many days, it's a lot, it's very chaotic because there's so many steps and so much work to be done. In that plan, you're also not only gonna talk about the work but who's responsible for getting it done. And maybe you need more resources, maybe you need money, maybe you need more people, maybe you need an IT person to focus with you, maybe you need a consultant. There's a whole lot of opportunities for resources you want to lay it out so your management's not surprised. You're gonna talk about who's responsible and I like to add a column and I'll show you in the next couple of slides, that is what I call the status column. And if you haven't worked on dashboards or haven't talked about them, it's a way of showing to people that, to your management that it's blue, we haven't started it. Green, we're on target and we're working on it. Yellow, we're working on it but we're a little behind. Red, we run into some plant problems and we might need that sponsor to intervene and black, the task has been completed. It gives management a picture and a single document of how, where things are today. So let's look at a roadmap. So we start with a list of initiatives. So for this organization, and this is a real one, they've decided it's gonna take over 30 months to do these 23 initiatives. And we spent a lot of time breaking this down into can you get this done during this period of time? Things will move all the way around. So it's important to list all of the major initiatives that are going to happen in your roadmap. I put it in the overview page right up front. Now you can say, well, that doesn't tell them a lot. No, it doesn't. And we'll get into the details. But it does show them that all this work has to happen and it can be impacted if you don't have a project manager or there's a number of initiatives going on. So if you're bringing in an ECM solution and IT is putting in another major transaction-based application, that's a lot of IT resources. All of this has to be discussed. Or else maybe this is more than 40 months to get something done. Once you have these initiatives laid out, then you're gonna start putting detail to the roadmap. You're gonna say, okay, what are the tasks for that specific roadmap or what are the milestones? I like milestones. I don't wanna break it down to tiny tasks. About what timeframe are you gonna get it done in? Who has to take responsibility? And do I need some more support or resources and the status? So this is the second page. So I take that first initiative and make it number one. Here's what we're going to do in the second column is I've really taken number one from the initiative from that overview page. I just cut it and paste it right in there. I break it down into milestones or major action steps. And then I said, we can start that in November and we'll be done by April. Now, if you don't have control over the timeline where you can really get started at that point, you can combine these two columns into a single column that says estimated elapsed time. And you can say, well, this is going to take five months. Who has responsibility? And in this case, they already hired us so we let them know that it's already done. So in this task status task, we could say, well, that's done. So that block would be black. Again, you can show when things are done through this roadmap and you don't need another document. What's really hard in project managing these large implementations is many people create a lot of tracking documents. And it takes a lot of time. It takes an enormous amount of time to do that. So we're trying to reduce the amount of reporting overhead so that you can actually focus on the work. So you take the initiative, you lay them out one, two, three, four. In the next column under initiative, you've restate the initiative. The third column, you put in the milestones or major steps that start in complete state or you can have estimated elapsed time and you want to show responsibility. Now, I have seen in some roadmaps another column that says just comments. And if you do that, then you want to say, here's where we ran into problems, here's something that didn't work. You can provide some feedback. Again, it's just how complicated do you want the roadmap? This style has been very successful for many of our clients because then they kind of just tick the box. We've got that done, we've got that done, we've got that done and they know who to bring into the project at the right time. So on CAST 3 initiative, redefine the backup cycle time, the IT manager knows that he or she is responsible for that task. And this roadmap is shared with the people that are involved and engaged prior to you actually beginning the execution. In the planning phase of an ECM, you might need executive support. You need all those other folks too. In the implementation or sustainment, you're going to need additional people. All of a sudden, your vendor comes into play or VAR, which means value added resailor. And you might need a consultant, you might need someone from records and information management. You actually might engage somebody from the training department to help you. You still might need more resources. Each phase takes a lot of time. Questions we, you need to ask when you're putting in an ECM solution and you should have some answers when you're asked, who gets to go first? What's the overall order? Well, I always look for somebody who has the biggest problem, who's willing to put in the work to get it done. And it always looks for the department if the client hired us and they're an administrative department, I always suggest that whoever brings you in or wants you to do this project, also be in the pilot. Pilot or proof of concept. We use them interchangeably for this roadmap, but you can't do everybody at once. That's the bottom line. You might want to do a proof of concept with one department to prove what the system is capable of. A pilot on the other hand, you might have multiple departments that are going at the same time again, but you aren't going to be able to do every department at all at once. That's not humanly feasible. You need to think about the functionality you want. Today and down the line, because that's going to impact how you roll this technology out and how are you going to bring employees on board? All of those steps, the fourth bullet there is about change management within an organization. And you really need to have somebody's focus on that to make the system work. Most folks don't have realistic expectation and they don't apply change management. And that's very sad because most people are not in an organization doing nothing. They have to have, they don't have the time to plan. And yet if you give them doable steps, people can get this done. I'm a big believer that your job in putting in this roadmap and this project is to break the work down into achievable steps for everybody involved. Run the pilot with a proof of concept and make sure that they understand what's going on and you hold their hand because as subsequent groups go through, it'll go faster and you won't need to hold their hands as much. Phase one and two take about one and a half, one to one and a half years. It takes a while to get through to the point where you're actually putting data in. Using the roadmap, you can keep people informed. And that's important. You want to train people. We like to give people a guidebook. You know, here's the screenshot of how you do this step, but it's screenshot shots of their system, not the generic screenshots from the vendor's guide. It doesn't show them what they're supposed to do. Author periodic updates and luncheons, learns trends at new hires because remember, you're changing the way an organization works. Important things to remember. If you don't write the pass down, no one will know that you have to do it. The roadmap tells executives, this is what has to be done. So be sure to write it down. If the timeframe is too long, management might want it faster. So, you know, they might give you more resources. But as you get through and get started into the project, don't assume you can't make changes. Life happens. And you need to go back to the roadmap and the plan. How do I need to make changes? And keep the executives in the loop so they can stay as your champion for the project. I want to tell you why the Anisian project often fails. Many organizations have what's called, we've termed it showroom syndrome. That means they've gone to a demo or gone to a showroom, saw the technology, they go, I love this. This is what I want. And they go back home and it's not, and they buy it and they won't do what it's supposed to do. Software is a box. You can do that when you're buying a car. I bought a car this year. I walked on the showroom floor, I go, I want these features, I want this color, and I can drive off the lot. Technology's not like that. It is a box. And the vendors should come to you and go, what are you with the rules to be? So you have to do that first and that's important. The other thing that causes failure or the project not to be as successful as you want is that you don't include the end users, the people doing the work. Let them have a voice into the process or if you don't provide adequate resources internal or external, I think this is only gonna happen in one year. Your life will not gonna hit success. You can go too fast on a project and miss so much work or go too slow and lose momentum and there is a balance. So there is such thing as going too slow on implementing technology and losing support. But one of the things that cause ECM projects to fail is you don't re-engineer the way you work. You don't need to necessarily sign documents if the technology does electronic signatures. Because a lot of them do. We moved to the East Coast and my husband moved ahead of me. Everything we did in terms of real estate transaction was done via technology with electronic signatures. We'd never had to sign anything with a wedding signature. And the other thing that's causing projects to fail is there's just not enough change management which includes communication, training and testing. So overall, I love ECM solutions. It can transform the way an organization works. You start by building the repository. Where are the records going to go and how can I find them? You apply the rules consistently and simply so that you can manage them. You can standardize forms, workflows, routing approvals, electronic signatures, and all of this improves efficiencies and benefits to the organization. However, it just doesn't happen overnight. It takes time to make all of this work and people need to know what that work is going to be. So thank you for your time. Do you have any questions you can unmute your mic or type them in the chat area? I see one in the chat area Helen. So the question is, do I have any advice or feedback for adapting cloud-based software as an ECM? Also adopting a system that's underutilized. That's a big question. So Emily, so let me do the first question first. Adoption of a cloud-based software, you go back to your problem statement. I promise you this is not magic. If there is a problem statement in Salesforce, I'll answer that question, then use Salesforce. I've not had as much success with Salesforce as an ECM and we tried and I had a project where we tried because it didn't do the retention component well. And that was one of the things that was causing the problems for the organization. So you have to make sure that the software will do what you want it to do. An adopting a system that's in place but underutilized. Then I would try to do a proof of concept. Find somebody who's willing to show that we'll do more and make sure you kind of take it on the road. You might have to do a lot of demos internally. You might have to show a lot of the opportunities of that system and it's change management. So you'll need a sponsor to do that. You'll need somebody to do the proof of concept for you. Make sure that staff has the right training. All those things are really what's gonna make people use a system that can do what it's supposed to do but they haven't had the right support to get it done. And I hope that answers your question. And that's a really big question, couple of questions you asked. Thank you, Helen. Anyone have any other questions? We're using Microsoft Office 365 and SharePoint in our course. And there are debates over whether or not you could call SharePoint in ECM. What's your opinion? No. That's what the general consensus was. I'm just kidding. I was gonna say, but did I say that too fast and then kindly? SharePoint is a great intranet and it is a fabulous place to collaborate. But when you need to lock down documents and apply retention requirements to them, we have a client who's using it but they have to go out and buy more software to be able to manage the documents in SharePoint. Can you share with us what they purchased? We've looked at Collabware and Gimmel products, for example. Thank you, the Gimmel product. I knew it was a G. It was a scapegoat, the Gimmel product. Right. That they're buying. And you know what? If you don't put the rules in, we have a client who was affected by that ransomware. And they had three versions of their ECM solution. Two older ones and a current one. And I kept saying, why are you bringing the oldest version back up? Do some risk analysis. Maybe those documents have passed the retention. But it's been sad because they were down for three months from that ransomware that hit the city of Atlanta, a hospital in New Jersey. So there was an organization in California that was hit by it and shut down completely. Oh my, did they end up paying? Do you know? I don't know. I didn't ask that question, but I know that they crippled their systems for a long time. That's an unbelievably long time, isn't it? They had to go back to paper processes for a while. And then everybody got a new laptop and got it all cleaned up. And it was ugly. Oh, I could imagine. Wow. Okay, anyone have any other questions? If not, I want to thank our speaker, Helen. This was really interesting. I appreciate it. And we'll be talking more about your presentation in class, certainly. All right, well, thank you for having me. And if you have questions in the future, Pat, don't hesitate to call me. I will do that. Thank you.