Developing a Best-Fit Governance Model to Manage Your Slate Instance

Good morning or afternoon everyone. My name is Trevor Johnson. I'm the director of service here at technicians. We're going to get started in just a few minutes, but if you can't hear me, you might try refreshing your browser tab.

And feel free to say hello to our presenters and your colleagues in the chat. It's great to seeing everyone saying hello from wherever they are.

So let's give folks another minute or two to join and then we will dive right in.

All right, well, let's go ahead and get started. Welcome everyone to developing a best fit governance model to manage your slate instance. As I just mentioned, my name is Trevor Johnson from technicians and I'll be moderating this session and start with a few housekeeping tips and introduce our presenters here in just a minute.

I'm excited to welcome Alex, Megan, and Josh. Three excellent folks all from Rohb who are going to be sharing some tips, best practices, and excellent slate knowledge with you. This afternoon. I'll let them introduce themselves when we get to their slides here in just a second.

But before we dive in a few housekeeping notes, we are recording the webinar and it will be made available for viewing within the your home site. If you are a festival pass holder, so feel free to review review that portal for all of the recorded webinars, some that you might have missed or others you want to take a closer look at. We have real time closed captioning that's possible for you to turn on for yourself by hitting the CC button in the top right hand corner of the screen. That'll turn on video closed captioning within the chat window.

You can also full screen your viewing of the slides in the video by clicking that little expand button in the top right hand corner of the screen as well. If the video or audio seems odd or out of sync to you, just go ahead and refresh the refresh your tab, refresh your browser window and that should that should correct that stream for you. And if you have questions, feel free to post them in the chat. Alex, Megan and Josh will be diving into some of the questions that were asked ahead of time as well as any of the questions that were in the chat and.

Feel free to put those in and then we can take them as they come at the end.

All right, well, let me go ahead and without any further ado, turn it over to Alex, Megan and Josh to pop in here and say hi and then I'll turn my video off so you don't have to look at me staring blankly at the screen the whole time as I listen to them share their expertise as well.

Alright guys, take it away.

Great thanks Trevor.

All right, everybody can hear me, yeah, I think we're good.

Sweet well hello everyone. Thank you and good afternoon. Glad you all were able to join us today to discuss something very important which is developing a best fit governance model to manage your slate instance. So excited to be here for this today and to hopefully share some knowledge out of the hundreds of institutions that we've had the opportunity to work from both from an organizational and obviously a technical perspective as well as it relates to slate. So I just want to start with just a little bit of introduction.

RHB, if you're not familiar with us at RHB. We inspire colleges and universities toward greater relevance before, during and after college. Helping institutions fulfill their powerful missions. We have worked with hundreds and colleges and universities that rely on our HP's Council each year to assist them in achieving revenue goals through strong, lifelong relationships. Built on consistent and relevant delivery of transformational education.

At RHB we deliver our expertise across 4 practices. As you can see here on the screen, including Executive Council, institutional marketing, enrollment management and obviously for one of the reasons we're here today, slate and related technologies as a platinum preferred partner. Our HB is the seminal and foremost leader in the application of tech solutions slate, offering best in class implementations, diagnostics, audience centric portals, advanced build and we're operating in more than 10% of all slate databases.

We'll just do a quick introduction here and jump in. So again, I'm Alex Williams. I am a senior vice president for relationship development and I've been at OHB for four years up until December. I was also leading our slate and related technology practice until as many of you know, Aaron Gore joined our team as Vice President of client technology, Megan.

Yeah, thanks Alex. My name is Megan Miller. My pronouns are she and her and I serve as a senior technology consultant at RHB. I've been in my role at RHB for almost three years, but I've worked in higher Ed for more than a dozen years now and have spent a pretty significant portion of my career doing work around the topic of system governance management and strategies. So I'm excited to discuss that and share more with you all today, Josh.

Hello everyone, my name is Josh Henry. I'm also a senior technology consultant at RHB. Been in rehab for just under a year now. It's like 1111 a half months now which is hard to believe. Before that I spent about four years at Tech Solutions so I see a lot of familiar names in the chat introducing yourselves nice to be interacting with the let many of you again and I've worked in higher Ed and the emissions world, both undergraduate and graduate admissions.

Or adding 10 plus years before that.

Great thanks Megan and Josh. I will also say I may refresh my screen in just a minute because I'm also getting an echo, but luckily I don't hear it when I'm speaking. So when we are thinking about goals for this presentation, one of the key goals is really to aid you all in the articulation of where data governance, data management and database management intersect and differ.

So hopefully through discussing the various elements that help to shape a governance model, we are hopeful that today you'll be able to take away what this means for your campus. Your slate team, the future of your database, and then we're going to plan on closing out this presentation today with applications for your current environment as well of how to impact this strategy.

When an institution engages our HB in an implementation, or really any work, we're most often contacted by one of the slate captains or a VP who recognizes the magnitude of the particular project and really is seeking that expert guidance on both the decision making side and the build itself. These conversations with me for the most part normally are heavily geared at the how in slate rather than the what are we doing and why are we doing this right? We all know we're getting a CRM of what the purpose is.

But usually always there should be larger institutional goals that are really kind of pushing this beyond. So even for institutions who are coming to OHB for advanced configuration assessments, things like Portal build in that space they're so heavily focused on the how we need to make things happen that we're often really just failing to take a step back at the larger picture when we enter into an engagement. One of the first conversations that we do have with an institution is really geared at the data governance and management of the system, and I think you can imagine working with hundreds of institutions we have seen.

Tons of different models we've seen. No models. We've seen one person managing at all and trying to handle the government side, so there's a really wide spectrum, which is why we felt that this presentation would be pretty relevant across the entire kind of partner base. But one of the key distinction here is that teams often will complete data governance with data management, and so it's OK to appoint because you can't have one without the other. But data management is a component of overarching governance, right?

We work with teams to help develop a structure for decision making, and this can come in several forms from our HP. Most notably, we offer an organizational assessment in either our enrollment management or institutional marketing practices that assesses for an institution whether the right people in the right seats at the right time, or if we're bringing all appropriate voices into the field and to the table. So these assessments really lean into how we're making decisions about procedures and various policies that will come into play with regard to the data we're capturing and how it will be used, but additionally.

These conversations really help us to assess not just the priorities within the enrollment or advancement or student success divisions, but really at a higher level as institutional priorities and goals. So as we walk through the next several slides, my hope is to really help you break down some of this alliteration of people, procedures, policies, priorities. There are a couple more peas actually, and don't worry, there's going to kind of break each one of them down individually. So for the first one that we're going to be focused on people, right? The foundation starts.

With people, I think we've all been here before, particularly if you're coming into a new instance of slate. And luckily we get to come into new instances of slate all the time. But while it's tempting to jump right in when you get your hands on it because of all the amazing things you can do, or the wonderful things that you've seen, it's really important for us to take a step back, right? We want to lay a foundation for decision making, and this is where we take the first step in developing a governance model. When we discuss governance with institutions, many teams are jumping right into individuals who are going to be responsible for the build or automatically.

Assume that they're set with the captains that they have in place, but the captains that's database management and Josh is going to get to that in just a little bit. We have to be able to drive the conversation higher. We use an example, right? We've all heard it before. It isn't needed as a part of an implementation. We've heard it, but it gets drastically taken out of context. Tech solutions, other people who you're talking to. They don't mean that you don't need it to help inform the build. The statement means you don't need a strong IT background to actually build in the system.

Due to intuitive design and experience, most notably, we all know how important it is in this right. They're going to us and establishing what data elements are necessary in slate to remain functional and advance operations and assists or any other systems that are out there. But at the highest level, we have to think about ownership of the system, right? Executive sponsorship. So where does that really rest on a campus?

Traditionally right, this is really kind of been either in it or it's been in the Admissions office itself, but as slate and tech illusions has continued to expand offerings and what you can really do in the system, this executive sponsorship may also be something that has to change on campus overtime, right? If we start with a database, focus on emissions, but then we opt and say, well, now we're going to be doing some student success or we have an advancement database over here as well. Sometimes that sponsorship either needs to evolve or shift as time goes on.

Once we're past that, we're at the core of the Governance Committee Steering Committee. Whatever you want to call it right. The focus here isn't just why it is a valued player at the table, it's also an assessing who else requires not deserves, right? It's who requires a seat at a table for this to be effective. So we've got folks who are working in security and marketing institutional research. If we're going beyond emissions, obviously it's student affairs and conduct. Advancement, finance, legal. There are a lot of stakeholders who should really inform.

Steering or governance committee. That list is going to vary per institution and per build, particularly depending on where the system is resting and what the focus of it is. But assembling this poor governance team is going to ensure that all voices are going to be heard throughout the process, right? Because these are the voices that are going to inform what data needs to be captured at what stages of the life cycle, they're going to inform how the data is used across their different departments in ways that those of us who might be at the input stage of capturing data haven't really considered.

As we are really thinking about how are we using the data ourselves, right?

These voices are also going to shape the ways in which we capture data for extraction into other systems. Back to my comment a minute ago about it, but also for things like modeling or data visualization that we may be doing in other systems. These voices are going to determine how we're securing data and when we're deleting it and how it's processed across campus, and they're going to discuss what's worked in the past, right? You're moving too slate likely from another system, or maybe in some cases no system at all. These folks should have insight into what has worked well in the past, what hasn't worked, and how we can set this system up in ways that improve.

Outcomes, not just for admissions or student success or advancement, but holistically across the entire campus. So this scheme should really be composed of individuals who are capable of making decisions in these different departments that are going to align with the institutional goals that I talked about before. And I'll come back to goals again in just a little bit that we spoke about earlier, so failure to have this in place means that building your instance of slate is really operating in a silo, and we all know too well about those, right? It's going to be incredibly difficult.

Time consuming to reshape this in years to come.

So the outcomes that I just kind of spoke about are really driven by the procedures that are defined, and that's the responsibility of this team as well. So we get to the next phase of this after people we talk about procedures.

Procedures thinking about how are we going to mitigate risk? How do we ensure that we've got clean processes for capturing information at different stages? How often should we allow for updates or changes, right? We've added a new program. We need to update the application. Oh, we have a new checklist requirement. We need to put in or or we've got new brand guidelines and so we need to modify these templates. We need to be able and this team should be able to articulate how are we going to get those procedures that we're going to set here. So that way it moves down the funnel to the operations team.

Who was doing the build that we'll talk that Josh is going to talk about on the database management side? To really ensure that before it gets down here? It's well articulated at this level to keep things clean and keep lines of communication really open.

So we're thinking about who's responsible for ensuring that all players adhere to these decisions and the procedures, right? That we're talking about at this Governance Committee this governance level. They're not things that are geared at like how do we? What's the procedure for building out a workflow from an operational perspective, right? It's the procedures that outline how the system will be managed to ensure it's configured in a way that allows for data sharing that has an emphasis on data integrity.

Obviously, informing this directly are going to be the policies that are in place on campus, and I can tell you everybody in here that's working on a campus. We're all not aware of what all of those policies are. Sometimes our policies that people are making up their heads, and they're other policies, right? So this team, this Governance Committee Steering Committee is really going to be geared at ensuring that any policies that are in place or policies that need to be put into place are clearly articulated across the organization. So things like defining.

What data should or shouldn't be retained and for how long? Like I just mentioned with retention policies, identifying decision makers and the policies for change and change management? How is onboarding going to be handled? What are we going to be doing from an ongoing training perspective to ensure that all end users of the system or those who are building are doing things in a consistent way that resonates with the procedures that we already have in place?

How should things like permissions and roles be deployed? What should we be doing in House or what should we be doing? Outsourcing these are all considerations that are vital in establishing the policies that are going to dictate steps that have to be taken. Decision making, chain of command and overarching maintenance of the system policy. I would say like policies, budget structure and without structure everything falls apart. So all four of these components that we're talking about here, right people, procedures, policies, and what we talk about next priorities.

Really all come together, but they have to be in place in order for this to be effective.

One of the final components that we think about when we're thinking about an actual governance model here really includes priority setting to. Often our team and I imagine some of you are exposed to conversations where priorities for implementation are not aligned right. We have an application that has to open on August 1st. We need to get a drip campaign going by May 15th. We have to put these new branding guidelines into the templates. We really need to focus on security.

That's one of the difficulties I think that institutions struggle with anyway. In an implementation in general is that there's not always a lot of alignment there, but at a higher level. We also have to think about priority setting for the institution, right? One of the questions that was submitted for this presentation was should marketing have a seat as a captain, right? Josh is going to talk about the Captain model and database management in general. My response at this level of the conversation is it really depends on whether or not marketing has a seat of the governance table and they should. They should have a seat at that table, so I'll just tell you that.

Right are they? If we have to start with the people there, we have to be able to set the priorities for marketing and ensure that those are aligned at the governance level and that everyone understands what those priorities are, right? But the role of that governance team is to really shape the priorities there, right? So other questions we consider right are the priorities for the bill driven by timelines or opening applications. Are there systems that are being sunset? Are you bringing search in-house? Great? Those are all great priorities to figure out, but they're all.

It's centric if we think about higher level priorities, which is where we should really be at a governance standpoint. That's when we're starting to ask questions like or say things that we need to do. We have to boost enrollment in certain markets or we are interested in driving an increase in giving by X percent toward a specific campaign. Or we want to streamline the student experience when scheduling advising appointments, right? These are higher level objectives and institutional goals. The governance team is responsible for all these priorities and more so the decision makers.

On these teams need to or this team? I should say need to be equipped to understand how all of these priorities relate to one another and then what other elements cascade from there, right? We know without saying and you all probably live it every day and oftentimes we're a part of the conversations as well. There's going to be disagreement and ensuring that all team members are aligned and what those priorities are, but it's better for that disagreement to happen when there's a structure in place for conversation around what those priorities should be, and eventually we can get to a spot.

Of alignment, I'm going to pass it off here to Josh, who's going to dive into the data management and database management components and then Megan will follow up with putting some of this stuff into practice, so take it away, Josh.

Great, and if anyone's having trouble hearing me with something in the chat and I'll try giving out on that.

So really everything Alex just talked about developing a government's model. It all leads to groundwork for successfully managing your data and your data base. All the people involved the procedures.

The agree upon the policies in and the institutional priorities. They really all come together to.

Inform how you're going to put that into practice in slate and the intended outcome is of course to be able to manage both your data and your database, with efficiency. Managing strategically manages successfully and harmoniously.

So when it comes to practice, it's not just getting into slate and starting to configure things. There are still a lot of questions, a lot of high level strategy decisions you need to make that are going to influence how you configure slate. Data management is different than database management. Data management is the collection of those guiding principles and best practices you want to develop, either at the outset or as you learn from your uselessly to maintain accurate and accessible information, the policies.

Procedures, priorities and let's be real. The politics involved will dictate how your data is accessed and managed by your users in your database. So database management is not something that just happens as a result of your result of governance. It's something you have to take the information gleaned from your governance model to design data management for your database. And there's a lot of really important questions you need to continue to ask yourself as you begin to think about, OK, we're going to collect data in slate. We're going to share access to data in slate.

Right, first of all, who owns the data itself, right?

Think of four very different pieces of information. You have a personal records educational history, the admission decision on a graduate application, a donors giving history as well as maybe the program of interest for a prospective first year student who's still in high school.

It's possible that some, if not all of those data points could exist on the same single person record in slate.

But very different people. Very different processes would have an interest in those different pieces of information. So you really do have to determine who owns each piece of data within your database. And by owns I mean who's responsible for that data for maintaining it and for checking it and maintaining its accuracy.

Tangential to that is who has access to that data, right? So should someone in admissions have access to that donors, giving history or not? That's a very interesting question. I bet a lot of institutions would answer in very different ways, but you do have to think about not only who owns the data, but then also who has access to the data. And that's going to inform a lot of your slate configurations, especially as you get to permissions and security, which we'll talk about in just a minute or two.

And in terms of access to data, you know access to data can be very universal where everyone can see everything, but maybe only some people can update or everyone can see an update.

But you have to be strategic about that thought. Like, should everyone be able to see data or do we need to manage access to data using permissions and roles and populations?

To make sure it's locked down in a specific way.

You also want to ask some of the same questions around process right? Who owns the deliver tool? Who owns events? Who owns release decisions? Who owns querying all these different tools and slave? Who should be responsible for maintaining these at the highest level? And then who needs access to the to process? Who should be able to create deliver mailings versus send them? Who should be able to access and run queries versus maybe edit them? Or create an edit reports so these types of questions stem from your governance model stem from the people.

Involved in the policies and the the processes processes. Need to stand up but then you need to really ask them. Very pointed ways as you begin to dive into slate and think about how are we going to successfully manage all of this data.

And then at some point the data and the process is they're going to be shared, right? There's going to be multiple people in need to use delivered me multiple people that need access to the data on the custom tab on a person record. So when data needs to be shared, it's always important to take a step back and ask, OK?

Where must collaboration exist and very importantly, where must internal communication exist so we can achieve successful data management in our database. So once you have the governance strategy in place, really answers to these questions help to inform your data management guidelines and best practices and that's what you really put into practice with database management in sleep.

So I said this before. Data management is different than database management. They're definitely closely related. They're even relying upon each other, but they're distinct elements of your implementation of slate or your continued use of slate, or your kind of updating of your slate processes. The ideas and goals for data management come first from that governance model that you put in place, and then the decisions around data management both inform your use of technology, your database management, and but they also need to be informed by what the technological.

Possibilities are in sleep, so it's not a one way conversation.

I like this just kind of articulating again. The data management is both a goal and an outcome of successful governance, and it really comes back to having those clear expectations. Those clear communication lines in place and then taking those to implement effective solutions in your database technology.

You know to the technology solutions in Slate are really there to enhance your data management processes through that database management you can explore how slate, what we're going to explore, how slate can support a governance strategy without necessarily dictating strategy. Something I know Alex has a lot of is that technology is not strategy, right? Technology is a tool that helps you execute on your strategy. So we want to look at Slate. As you know something's going to support our processes and look at those support and mechanical support mechanisms.

Translate to help us execute our governance model.

One of the simplest things you can do in slate is actually just develop very clear and consistent naming conventions and folder organization within your database. You know if you label your fields and your prompt keys in a way that is intuitive to the end user, it can.

Enhance the accuracy of their work and similarly with your photo organization and slate, making it easy for someone to find something if they need to go into the forms, go into queries and find the specific item. Just making it easy for them to navigate there doesn't mean your folder structure is going to be the same for one tool for the next, because it might be very different in the rules out of there than it is in. Say, you're the forms tool, but.

Making it as organized and clear as possible for the end user is going to put you on the right starting ground. That's something you can do. You know the very basic level of communication. Beyond that, there's a lot of other technology base level technology. There's a lot of technological tools you can take advantage of to really aid in that data management that governance model to make sure everyone's on the same page and achieving the desired results. Templates are a huge thing in Slate, right? You can definitely set up templates for forms and events and scheduler, but you can think of templating other processes as well. Think of something like your source.

Formats in slate. They're all gonna be very different, but you want to make sure you have consistent mappings of field and of fields and values in your source format so that as the data comes in the what comes in you're mapping it to the right destinations in slate. So it's how it's being collected, how it's being mapped on the way in really important when looking at your source formats, you want to make sure again the data is the what the data collections that have that those processes are consistent across all the different inputs. You have. Templates again, go a long way.

Been doing that for all your forms and events.

Templates are also as outlined a big part of your brand and your identity, so having templates in the liver is a great way to make sure that when people send communications they have a consistent. They're consistent with your brand identity that they use the right fonts and all that stuff. But also there's settings within templates like who are who, it's the sender name and email address for messages from this department. That's something that you can set on individual emails and sleep, but it's easy to forget to do if so if you set it at the template.

Go where it's gonna override that default sender for you.

Again, just creates that consistency. It's one less thing that the end user has to worry about, but something you can manage at the database level to make someone's life a little bit easier.

Talk about applications in slate. You know, anytime you're collecting data from prospective students from applicants you want to make sure you're doing that in consistent process and get that you're collecting data that is easy for someone to report on it. The highest macro level you also want to have consistent processes around.

Your operations around how you actually process applications and complete them as well as application review. Application Review is an interesting one, especially if you're a graduate environment. Working with a lot of different parties, a lot of different constituents involved. There's going to be variation for sure. There's going to absolutely need to be variation in that review process, but you also want to make sure you have a baseline level of consistency there that you kind of agreed upon at the highest level to say we're going to ask people to tailor their review processes to this.

Because we know this is what works successfully, it's like and this is going to what's going to allow us to report on data and collect data in a way that we can really look across departments and across divisions.

That again leaves into querying and reporting where you really need to understand each user's data needs. Who needs access to data? Who needs to be able to.

Find data themselves versus who needs to be able to just be handed data through a configure query. There are a lot of different permissions around the query tool, so understanding what basis someone needs access to and should have access to. In which cases does that access need to be specific to a certain population of records? There's a really important questions to ask because when you get in slate and start configuring everything you have a lot of options on the table there. So knowing what you want to achieve before you start building and slate is really important.

Definitely leads into security. Again, a lot of possibilities there, as we've all know you log in and look at the user account. It's like there are a lot of different permissions you can grant users the power to do a lot of different things or just a few little things, but being organized there is really important as well. Developing user roles that.

You know that you know users of this type will need these base set of permissions is really important because it gives you.

Just a confidence in that you've given someone the right level of access to your data into your process within your database. Understanding what permissions offer population aware capabilities that you can allow some of them to have access to application records, but only for records within the certain population is really important. Same with what.

Processes what items in your database can be grouped with special access as well, and with that I'm really talking about realms, so if you can put forms and realms emails and realms that allows user to really see what's what's specific to them without having to see a lot of other stuff that's going on there right without having to get overwhelmed by the totality of anything and accidentally update the wrong thing. I always say with permissions it's a lot of it's locks and keys, right? Like everything in slate.

As a default lock on it, and when you grant someone in permission, you're giving them a key. Well, you can take advantage of the custom permissions and kind of create your own custom keys. Put your own custom locks on different items and grant those custom keys to different users. It really again goes back to your data needs like who needs access to something who needs access to this piece of information, who needs access to this process?

So all those tools are used successfully. Really only when users are trained on how to use them, which is a really important part of database management as well. You have to develop the best practices and then you have to document them and you may do that in something like slate collar, custom content or someone clicks that light bulb when they're looking at an event form and they see some of your best practices for configuring the registration form and making sure they have the right fields. You know if they're building the new template or they're.

Creating an email and you have your own custom content there that tells them, hey, make sure you do XYZ anytime you're creating or sending an email. Some schools we've seen have developed really robust kind of training and I guess glossaries of sleep processes external on their own websites and they've been great for users and I think when we work with schools and we develop some custom processes, Roy's offering and documentation options like hey, we're going to document how we did this so you know how to manage it going forward. That's a really big piece of slate because.

As we know people, people change, but some of these processes you want them to be Evergreen. You want them to last and stand up overtime.

So very important to make sure you're training users and you're documenting your processes so that future users can learn from them.

As well as possible.

To that effect, you know Slate is something that is ongoing. It's something that doesn't stop, and Megan's going to talk about that and how you maintain progress and momentum with your uselessly.

And thank you Josh for walking us through that I I am personally rather passionate about structuring resources in order to support that larger framework that we've built out. So everything that you just said there is really music to my ears. Thanks for talking through that, I will say a really quick disclaimer at the front of this that I am recovering from COVID right now. I got it at the end of last week so please bear with me if I get a little gravely or I have to take a pause.

And take a sip of something I do not have my full vocal capabilities at the moment, but just ride with me on that and hopefully we'll get through this together. So as Josh mentioned, when it comes to Slate, implementation is happening in phases, but it's never really, truly like done, right? And that's where I'm going to start my discussion of the larger database strategy, which is going to sit at the confluence of.

All of those peas of government that Alex and Josh mentioned earlier, and it's going to use that to take us and arrive at our final P, which is progress. We love alliteration here at our HBC you get 6P's of governance management strategy. This is the place progress that's the place where because we have confidence in the integrity of both our slate system and the data that's contained within it.

We can't expand and evolve our instance to do even more for us, right?

And when we're going to talk about data based strategy here, we're really going to be thinking about two kinds of progress. First of all.

First of all, we are going to have those opportunities that we know are there for us to pursue when we have the capacity and bandwidth to do so. There's those known elements out there. We don't have them yet. Maybe we'd like to someday. That might be some things like setting up a direct integration for a test score import instead of uploading score files manually, or converting all of those event landing pages.

Into portals or consolidating decision letters by using dynamic content. That's like my favorite thing there. Those are all these things that we might have in our slate parking lot, so to speak. There are things that we have bookmarked as opportunities for the future.

But in terms of progress and strategy, there are also going to be those emerging opportunities that are going to develop, and they might take us by surprise. Those might be internal, for instance, things that might arise due to changes in institutional structure, because in higher Ed we do love a good reorg, don't we? Or maybe there's a new program or new initiative that's coming on board internally, but those also can be external, such as Lynn Alexander.

Clark is going to stand on a stage in Nashville in a few weeks and tell us about all sorts of new features that technicians will be introducing into slate. You've likely seen several presentations over the past few weeks where you've seen your slate colleagues who are talking about some really, really cool stuff, right? And they're doing this in slate. If you'll be at Summit, you'll hear even more of that there. And at some point you're probably going to say to yourself, I would love to be able to do that someday.

Those are those emergent opportunities, the ones that we didn't fully expect, but that we're going to want to consider pursuing. But regardless of whether we're talking about the planned progress or those emergent opportunities, emergent opportunities, let me say that a little more slowly and more clearly. In order for it to align with a higher database strategy.

We need to confirm two things before we move forward. Two questions we have to ask first, is this something that we have the resources to do? Do we have the time and skills needed to get it done or can we outsource it to someone who does have that time or that skill because there are a few things that are more frustrating than finding ourselves in that scenario where we get partway through an initiative before discovering.

That it can't be done given our current realities. We want to avoid that wherever it's possible.

And the second question is, is this something that will add value as we pursue our goals? Because let's be real, if it's really cool, but it requires a lot of ongoing, hands-on, arduous management.

Or if it doesn't have a tangible impact on the work our teams are doing that really is not progress. That is a vanity project and vanity projects often have a really negative cascading effect when it comes to keeping our systems and users on the right track.

So in order to discover the answers to those questions, and in order to drive true progress forward, we need to develop the appropriate communication channels within our governance framework because.

True progress requires solid communication.

If we want to do things in slate that move the needle, we need to have a structure in place that allows for both that top down communication and that bottom up communication. This is going to allow our decision makers to have the context they need to pursue the best opportunities that exist.

And it will allow our end users to understand how the individual pieces fit into our larger slate strategy. So let's unpack that a little bit.

OK, so going back to what Alex was talking about a few minutes ago when he introduced us to our first P which is people Alex discussed that idea of a steering committee that defines those other pieces. The policies, the procedures and priorities. For Slate this steering committee. They don't go away once an implementation phase is complete. Instead they are going to shift into steering the management of sleep. They're going to be up at the top of that slate ladder.

Using the meta information about our work, our data, and our systems to maximize our slate instance.

And then down on the other side, we have those end users who are those folks in the system each and every day, and who rely on slate to get their work done? They may only engage with certain modules or functionalities in the instance, but slate is a huge part of their everyday working lives.

Uh, both of these groups have messages that they need to communicate that relate to both how slate exists in its current state and where there are opportunities to advance beyond that present day reality. Overall, the Syrian committee side there are going to be slate updates to share. You know, maybe there's a new material metadata form that's been set up for your transcripts, or we've run into retention policy to remove some old objects that hadn't been used in a while.

There might be new policies that have been developed and that users need to be aware of. There may also be some future plans that we want everyone to bear in mind. All of this is really important information to share.

But our end users also have really valuable things to say.

These are the folks who are on the front lines of slate, right? And their input is important to hear. They're the ones who can articulate.

Specifically needs they have those pain points and workarounds that they're currently encountering, and other requests that are going to help them work in slate effectively and appropriately. They might not have all of the answers, but they do help us discover the themes that we should be keeping in the back of our minds when we're thinking about new slate opportunities, I will add right here, institutions that don't have a place to hear these user voices.

Are missing a really huge piece of that puzzle when it comes to strategy, not just in terms of identifying those next big ideas, but also as it relates to uncovering knowledge gaps or training opportunities that might exist in various functional areas of slate that help keeping you moving forward. Protect your data integrity, protect your processes in your system.

So anyway, those messages are coming from both groups. They are essential for building for progress in slight this information those messages will help us answer those two questions I mentioned earlier. The can we do it and does this add value? Should we do it so in order to confer these messages into a true strategy, we need to have a communication structure that's going to synthesize what these two groups are saying, and that right there is where?

Business unit representation is going to be so important. These slate power users serve. I like to think of them as serving as strategy ambassadors for you. They are the folks who know how the work is done for one or more of your key stakeholder groups. They have that context. Maybe it's first year recruitment or marketing, communications or data processing, or major gifts or academic advising.

What have you? But they also understand that bigger picture that the steering committee is working with and how that fits into the day-to-day for your end users. So those business unit representatives serve as an essential communication channel that will drive our slate strategy. They're going to provide the information that helps us to identify what we should do next with the opportunities we've had bookmarked for a while based upon what they're hearing.

From end users and what they're seeing in their own work.

And they're in pot, and their input is also going to provide us with context and agility in responding to those emergent developments that arise. That new feature, for instance, that is exactly what a business unit needs in order to address an operational change that they've raised up. Or maybe that upcoming structural change. That means we're going to need to adopt one of those new functionalities that we've been thinking about for a while.

This is what's going to link together the top down and the bottom up communications and feel progress for us in slate. Now I can't really tell you what you're specifically instances. Progress is going to look like or what specific opportunities you should be chasing after. We're really kind of focusing on the framework here, and every institution strategy is unique, so your mileage may vary with these different elements, but I will encourage you all to create the kind of slate.

Culture where progress is expected and where your users are really invested in it, wherein summit and cycle prep season right now and both of those serve as natural starting points for dialogue around all of this. And I've also found that this becomes pretty organic and self sustaining once we've put it all into place. Set all those pieces up. It kind of can help drive itself because you've got the energy and the investment behind it.

Umm?

Excuse me at the heart of it all, I would say just think of it this way. Progress is your rocket ship which has a lot of exciting potential, right? But it's really only going to blast off if it's on a stable launchpad, which would be that governance model that Alex talked us through, and if it has that right fuel, which would be those management practices that Josh covered. So if you want to boldly go where no slate user has gone before, at least in your instance.

You have to make sure that you have it all configured properly. You put all of those pieces together and you're looking at a whole picture that's worth getting excited about.

And in my humble opinion, that seems like a pretty perfect note for me to end on, so I'm going to do just that and I am going to hand things back over to Alex at this point.

Great, thanks Megan. I was going to use the word Launchpad too, but then it always feels a little bit weird for me to use the word Launchpad when I'm talking about technovision. So to reiterate, this final slide here when we're thinking about the whole picture and really pulling it all together. It's kind of like if you're new to slate or you've been in the system for over a decade. It's never too late to reassess or assess before going into it. Your general governance and kind of management model. We believe firmly at our HB and.

Hope that you do as well that an informed strategy among all these things, people, procedures, policies, priorities, practice and progress that an informed strategy is going to guide you toward greater sustainability as you continue to evolve this powerful tool as you're working toward not only your enrollment or advancement, but your larger institutional goals in an ever changing landscape of higher education, right? I hope that I we all hope that you found this helpful. We have about 12 minutes.

Looks like for exciting questions, so we can certainly take that on. But before we jump into the questions, I'd also say if you've been to any of the other RHB sessions so far you've been looking at your emails that are coming out related to Summit. We do are we are going to be offering an RHB Academy if you're coming to Summit it's going to be hosted on the Wednesday before Megan's going to pop a link in the chat. Here we have a handful of spots that are left in there so feel free to give that a check out.

There are a number of sessions focused on portals communication strategy. Some of our sessions are at capacity for that, but it's a really geared to be a training and strategic experience. So all right, I think we can go ahead and take some questions.

Our first question on here is from Michael. What are some warning signs you tend to see from institutions whose governance models might need some work?

I can actually. I'll speak about this one. I'll actually speak to it from where we see this a lot actually, which is in one of our service lines, which is a slate diagnostic. It's a comprehensive technical and process analysis of your system and how that's been configured, and we start those diagnostics when we're going through kind of in the order in which you implement, but we start looking by fields and prompts, and then we work through kind of what you would consider that the typical tech solutions road map.

When an institution has been enslaved for a number of years, there's a good indicator that there's something going on with governance and the management of the system in general. If we're seeing redundant fields or fields in both scope that are doing similar things, and for us, that's a really large red flag right out of the gate, and so one of the conversations that we'll have as a part of that diagnostic is really to understand how the system has changed hands over time as well as who is responsible for making decisions on the core infrastructure that needs to be configured.

Other areas that we would see in a diagnostic that would be indicative of a governance model that wouldn't really mesh, as if we're looking in forms or events or scheduler and we see tons and tons and tons of templates that have been created. Usually people often think like, well, that's a security thing. We shouldn't give everybody access to go in and create their own templates, and that's true, but that's a result of not having a governance model in place where we're defining what those procedures need to look like for determining who is going to have access to those.

Individual kind of spaces and one final thing that I would say about this is in conversations with institutions. We can see the stress on the operations team of the build of the instance when there are priorities coming from tons of different locations and no one is really there to identify which of those priorities is really going to be important. Or if it's such an important priority, understanding that something else is going to have to take a backseat. So if teams are experiencing something like that, that would be a good indication that.

We need to go up a level and either figure out how are we filtering these priorities down, or are the priorities that are coming in actually priorities at all? Megan or Josh? I don't. If you want to add anything to that, but.

Yeah, I mean, I think that everything Alex said I absolutely totally agree with. I think the other note that I would add is.

That those processes and strategies you know those don't. Those don't stop when implementation is over and they still will probably need to evolve over time, right? We are thinking about the idea that.

Chief.

Like

You know, as we talked about, Slate is kind of this living thing, right? It's a I think I saw Misty Moy on here. I've heard her refer to someone as a Lego set. Before that, you're just consistently building. I have two boys who are always building now. I always think of it as slate. So thanks for that. Misty. But you know, we're looking at a system that just because it's one way right now doesn't mean it's always going to be that way. So it's not just about setting up those templates.

At the start and saying no, we're only going to have this many at templates or what have you, but it's also about saying OK, we're going to regularly go back and assess what we have in place, what, what is the lay of the land right now? Cycle Prep is a perfect time for that. Where we go and say, do our templates? Does our documentation do our workflows? Our processes match with where we're trying to go right now, where we're doing our work? Or do we need to make make updates? Do we need to archive some things? Do we need to?

We think any of this.

Don't be afraid to rebuild things. That is not a sign that you did something wrong. It's just a sign that you understand. Sleep better now, or that your processes and initiatives have changed. So I think that that's the other thing that is really important to remember. Slate is continually going to be evolving, growing for you. Like I said before, there's lots of really cool things to do in order to make space for those really cool things. We also need to make sure we're assessing what really cool.

Things, or, you know, basic things even we already have in place in slate so we can make room for progress and make sure that we're not doubling up work, creating inefficiencies or making things more complicated than they need to be.

Josh, not sure if you have anything else to add to that, but.

Uh.

Nothing else to add to that. I mean, I could talk Legos all day, but nothing else to add to that.

By doing touch on Steven, just asked a great question before we get that there was one question I wanted to touch on and we got asked in advance of the webinar today and it was specific to an advancement process. It was about how do you manage governance around gift entry and control, and I think that's a really interesting question. Important question because I get it right like entering GIF data in Slate or any sensitive data in slate you are worried about accuracy to the utmost degree like in the end degree. You want to make sure everything's entered accurately and consistently.

So you might only want your gift reporter, your gift manager to be 1 entering that data at the same time. That creates a lot of granular work for your gift manager or gift reporter when you probably like to be working on some higher level things. So it's an interesting pool and tug there. It's like from a functional perspective like yes, you can be very cautious with who you give.

The giving update permission to who you give the ability to update gifts on individual records, but you can also put processes in place that allow other users to be able to handle some of that work. You can build forms for internal gift entry where you can control the prompt options that are available, set logic behind the scenes, hidden fields. So if someone you can really have anyone go in and enter the gift and the form construction itself is going to help to make sure that it's all entered correctly. So that's an area where you can.

Put your data management into practice and database management and free up time for that gift recorder that gift manager to be doing. Some of the other high level things that they need to be doing, and I think that's strategy that you could extend to a lot of other areas. And like whether it's like entering contact cards from college fairs at the emission level, you can really have that strategy where it's like we have a form for this process because it's a very prescribed process, whereas other people might just go in and create a new record and edit the record.

So you can differentiate that and you use slate internally to your own advantage.

And then.

Yeah.

Yeah.

Yep.

Yeah, I I like questions Steven asked here about those suggestions and tips for smaller slate teams. Because yeah, you there are a lot of schools out there that are kind of like these behemoths, right? That? Have a bajillion users and slate. Josh and I do a lot of graduate implementations. We get to do a lot of projects together actually. Which is real fun. But those are. Those have a lot of people involved. A lot of times. But there's also those really small teams that where you're wearing many hats. A lot of times.

I used to joke that my my previous job at higher Ed. I was basically just the director of other duties as assigned. That was what I used to refer to myself as or as the Chief etcetera officer. Because there's just a lot of things that I was taking on just because of the size of that institution. But I think the thing that I would say about those smaller slate teams.

Is that you certainly want that model to be scalable? Like like Alex said before, we need to identify who needs to have a seat at that table. It's not about who deserves a seat at the table necessarily. There's some politics that can be involved with that. But really, it's about again vetting. Who are those informational stakeholders who can speak to our business goals, our initiatives, strategic enrollment goals, strategic?

Use skulls says something like that.

And who are able to be pragmatic about that and see how that all fits together in the bigger frame of things? That might be someone who does that for multiple business units. It might be. You know, it might be someone who's you know. Managing quite a few different. You know. Programs for instance, or something like that. But it is really one of those things where we start and say OK. Who are the people you always start with? The people, the people help drive that process forward.

I do really, really strongly advocate for regular, regular recurring meetings. For this, whether you're small or large so that that steering committee that Governance committee is regularly getting FaceTime to talk about what's going on in the system, being informed about what's coming up. I also think you know I talked about those business units, making sure those representatives are also regularly in contact with each other, meeting with meeting with each other to talk about what they're hearing.

End users, what that identifying what they want to escalate to the steering committee? But really, it's again comes down to that communication. Sometimes it's easier with smaller, smaller schools because there's less people to talk to. You know you kind of have the folks in the room pretty easily, but you know, it's just the complexity will be possibly in terms of who's doing what. Oh you're doing multiple things versus having one defined role.

Yeah.

Oh

So now add to that documentation. I think is really important to have a smaller team, because as Stevens followed question illustrates like there's going to be turnover, and if you have one person, a small team leaving that can create a huge knowledge gap. So it really documenting your processes, whether it's slave scholar, custom content or just adding notes to forms or queries that have this thing. Things going on, documenting those processes for the next person to be able to see. OK, this is what's been done before. I would say that lifecycle turnover also creates opportunity, right? Maybe it is.

that's

Well.

Opportunity to have you know someone like an RFP? Come in and do a diagnostic kind of tell you how we think you're utilizing slate, but it's also an opportunity just for it's kind of a freeing aspect for staff. When I was leaving my last admission job in higher Ed, some of my colleagues said, you know, oh, really worried we're not going to know how to do things, and I said you also get to figure out how you want to do things like just because I do them doesn't mean I do them the best way possible. You're going to figure it out for yourselves and create your own processes going forward.

Exactly, yeah.

Take some somewhere else, right? Yeah, yeah, what we all love Legos. I think it on on this screen. I don't know how you feel about them Trevor, but the rest of us are pretty pretty passionate about.

Me and Lego so.

Wait?

Cool.

I love Legos. I actually just built the like Star Wars like Big Walker like the at a team Walker in logos.

Oh, that's a good one. Yeah, yeah.

I've been I've the mini version.

Hey perfect.

You need to come in here.

Good.

I love it. Well, thank you. Please join me in thanking Alex, Josh and Megan for spending their time with us today. Thank you guys so much. We really appreciate it and check out the recording later. And and for those of you who will be joining us in Nashville, we can't wait to see you in a couple of weeks and for everybody else we hope to see you on a future. A future slate stage webinar coming up soon, so thanks everyone. Have a great rest of your week.

Thank you all.

Bye.

Bye.