Governance Part III: Database Strategy and Progress

Senior Technology Consultant Megan Miller concludes this series on Slate Governance.

Over the course of my time at RHB, I’ve worked in more than 100 Slate databases. In terms of complexity and functionality, I’ve collaborated on developing everything from straightforward undergraduate admissions instances to Slate databases with hundreds of graduate degrees to systems for K-12 programs that incorporate parent proxy portals and course registration modules… and more. 

But regardless of the institution type, the populations served, the business process needs or the functionalities developed, there seems to be a universal truth for Slate projects: although implementations may be defined through a series of distinct phases and deliverables, none of us are ever truly “done” discovering and developing new ways to use our systems. Over time, our business processes may shift, we might identify opportunities to expand our use of the system or our operational structure may change. On top of all that, Technolutions is constantly introducing new features and functionalities to explore. This means that maintaining a robust Slate instance requires us to have a larger database strategy from day one. 

In a previous Insights post, Alex Williams outlined the fundamentals of Slate data governance. He noted that governance isn’t just a set of rules designed to keep Slate users in line and prevent errors. Instead, governance identifies the people, policies, procedures and priorities that allow our Slate databases to be functional and effective. 

And that need for governance doesn’t end when we’ve wrapped up our implementations, as my colleague Josh Henry discussed in part two of our discussion on Slate governance. He explained that when it comes to the ongoing evolution of how we utilize Slate, intentional data management is essential for sustainability and accountability. 

Through data governance and data management, we’re able to work within systems that are structured to meet our needs and support our institutional goals. This intentionality also enables us to create consistent business processes, properly control access to objects, records and tools in the database, and ensure that our users have the proper technical and contextual knowledge regarding how our systems and teams operate. Through this, we provide a structure that gives users confidence in the integrity of both our Slate instances and the data contained within them. All of this then informs how we will develop the third aspect of governance, database strategy, so that we can expand and refine our instances to do even more for us with a foundation for sustainable, continuous progress.

So What Is Progress?

When we talk about our database strategy, there are two different types of progress that we need to consider. First, we have the existing opportunities: those things that we know are there for us to pursue when we have the resources to do so. These might be projects such as setting up a direct integration for test score imports instead of uploading score files manually, converting old event landing pages into portals, consolidating decision letters by using dynamic content, adopting the use of Inbox, or updating rules to use Configurable Joins. We have these on our radar and have bookmarked them for the future.

But in terms of progress and strategy, there are also those emergent opportunities that will develop and may take us by surprise. These might be internal; for instance, needs may arise due to changes in institutional structure, the introduction of additional programs or new initiatives being announced. 

These emergent opportunities can also be external. Every month in Technolutions’ Slatest newsletter, we read about features that Technolutions has just rolled out, and a quick glance at the Feedback Forums will tell you that Slate’s developers are hard at work on further enhancements. You’ve likely heard Slate colleagues at other institutions talk about some really cool stuff that they’re doing in Slate, and if you’ve ever attended the Slate Innovation Summit, there are probably numerous times you’ve sat in a presentation and said to yourself, “I had no idea you could do that in Slate!” These emergent opportunities are ones that we didn’t fully expect and that we’ll want to consider pursuing.

Regardless of whether we’re talking about planned progress or emerging opportunities, we need to be aligned with our greater database strategy and confirm two things before we move forward.

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? We need to be realistic here. Few things are more frustrating than finding ourselves partway through an initiative before discovering that it can’t be done given our current realities.

And second, is this something that will add value as we pursue our goals? There are a lot of brilliant and innovative things we can do in Slate, but not all of those are the right fit for our institutions. The cold hard truth is that if we’re pursuing something that seems exciting to us, 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 and their defined priorities, that’s not progress. Instead, it’s a vanity project, and vanity projects often have a negative cascading effect when it comes to keeping our systems and users on the right track.

But How Do We Know? 

We’ve identified what the key questions are—“Can we do it?” and “Should we do it?”— but these questions won’t be of much use if we don’t have a way to effectively discover their answers. 

When it comes to managing systems that may conduct major operations for many departments and hundreds of end users, we have to account for a multitude of factors, and those can oftentimes be siloed, decentralized and/or poorly documented. The only way we’ll be able to make any sort of progress at all will be by developing a structure that allows for both top-down communication and bottom-up communication. This will 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.

In his Insights post I referenced earlier, Alex noted how important it is to ensure that the appropriate people are at the table at the appropriate times. In order to do that, we need to identify who our stakeholders are, clearly define what their influence should be when it comes to managing Slate, and then organize them into working groups that are granted the appropriate authority to collaborate, plan and act. 

At the top of this Slate ladder, we have our Steering Committee, which defines the policies, procedures and priorities for Slate. This team doesn’t dissolve once an implementation phase is complete; instead, they shift into steering the higher-level management of Slate and use the meta-level information about our work, our data and our systems to determine what comes next in terms of maximizing our Slate instance. But within this strategic infrastructure, we also have our end users, who are in Slate each day and rely on it to get their work done. They may only engage with certain modules or functionalities in our instances, but Slate is still a huge part of their everyday lives. 

Both of these groups have messages 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. Over in the Steering Committee, there are Slate updates to share—maybe there’s a new material metadata form that’s been set up for transcripts, or we’ve run a retention policy to remove some old objects that hadn’t been used in awhile, or we’re adding a new field to track an application data point that was previously unmapped. There may be new policies that have been developed and that users need to be aware of. There might also be future plans that we want everyone to bear in mind. All of this is important information to share.

But our end users also have really valuable things to say. These are those folks who are on the front lines of Slate, and it’s important to consider their input. They’re the ones who can articulate specific Slate needs they have, the pain points and workarounds they currently encounter, and other requests that will help them work in Slate effectively and appropriately. They may not have all the answers, but they help us discover the themes that we should be keeping in the back of our minds when we’re thinking about new Slate opportunities. 

Institutions that don’t have a place to hear these user voices are missing a huge piece of the 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.

The messages coming from both of these groups are essential for building for progress in Slate, and that information will help us answer those questions of “Can we do it?” and “Should we do it?” But in order to convert these messages into a true strategy, we need to have a communication structure that synthesizes what these groups are saying. For this, representation at the business unit level is essential. 

Your Slate power users who oversee specific business objectives in Slate are your strategy ambassadors. They’re the folks who know how the work is done for one or more of your key stakeholder groups; maybe it’s first-year recruitment or marketing communications or data processing or major gifts or academic advising. And if you create the right structure, they can also understand the bigger picture that the Steering Committee is working with and how that fits into the day-to-day for end users.

Business unit representatives serve as an essential communication channel that drives our Slate strategy. They provide the information that helps us to identify what we should do next with those opportunities we’ve had bookmarked for awhile, based on what they’re hearing from end-users and what they’re seeing in their own work. And their input also provides us with context and agility in responding to the emergent developments that arise, such as that new feature that is exactly what their team needs in order to address an operational challenge that they’ve shared, or the upcoming structural change that means we’ll need to adopt a new functionality that we’ve been thinking about.

This is what links together the top-down and bottom-up communications and fuel progress.

Creating a Culture of Communication and Trust

I can’t tell you what your specific Slate instance’s progress will look like or what specific opportunities you should be chasing after; that’s a question that has to be answered internally, as each institution’s strategy and needs are unique. However, I can encourage you to dedicate your efforts toward creating a culture where communication and trust allow Slate teams to understand and support one another, where progress is an expected outcome of this dialogue, and where your users are well-informed and invested in contributing to this continuous improvement. 

This starts by identifying the stakeholders who should participate in the various levels of governance and by establishing the expectations and process for these collaborations. Although this takes some initial effort to launch and may require leadership buy-in to first bring the right people to the table, I’ve found that this cooperative effort becomes organic and self-sustaining once we’ve put all those pieces into place. 

Slate is Like a Space Shuttle Mission 

At the heart of it all, I think of Slate as being like a space shuttle mission. There’s so much exciting potential that’s waiting to be discovered, but you’re only going to make it out of the atmosphere if you’re on a stable launchpad (that would be your governance model that Alex talked us through) and if you have the right fuel—those management practices that Josh covered. And then, once you’ve blasted off, you need your engineers, flight controllers and astronauts all reporting to one another regarding the various systems’ performance, noting any anomalies or concerns they’re detecting and articulating what to expect next for the mission; that’s the database strategy that I’ve discussed here.

Ready to boldly go where no Slate user has gone before (well, at least in your instance)? With a strong and comprehensive governance framework, the sky’s the limit.