Introduction
As we all have seen in headlines over the last few years, there are unprecedented headwinds facing Higher Education. Some of the most striking challenges are widespread removal of degree requirements for sought after tech sector jobs1, expansion of online program delivery, rising tuition costs, and growth of non-traditional education such as short courses and certifications. Institutions cannot afford to ignore these disruptive factors – they must confront them head-on to ensure their survival.
Institutions can leverage data to combat these challenges and establish a competitive advantage amongst their peers. The Joint Statement on Analytics from AIR, EDUCAUSE, and NACUBO perfectly articulates the call to action in light of these challenges: “Higher education must re-energize its efforts and unleash the power of data and analytics across higher education to support students and institutions.”2
I know you are already thinking about how a nice cloud data lake, automated data pipelines, a colorful visualization tool or a well-formed data governance committee could potentially address these issues, but I implore you to take a step back and perform adequate due diligence and planning first. Use the sense of urgency to your advantage – it provides an opportunity to build cohesion across the institution and create a solid blueprint for how data capabilities could be deployed to address these concerns. This blueprint will become your institution’s Data Strategy.
Let us look at what a Data Strategy is and how it can save you from common pitfalls of data programs, with some real world (anonymized) client examples of what happens when things are well planned versus when they are not.
What is a Data Strategy?
Strategies can come in all shapes and sizes, but the main components should cover the following three areas and address all these questions:
I. Current State: Here is where we are today.
- Where is the institution today with regards to challenges and objectives?
- Why is there a need for any action at all?
- Where would the institution rank on a data maturity assessment?
II. Future State: Here is where we want to be in the future.
- What does the final vision entail?
- What benefits will be realized by various stakeholder groups (Students, Staff, Faculty, Leadership, Industry Partners, Local Community, etc.)?
- How will this future state enable our institutional and departmental objectives?
III. Roadmap: Here is how we will get from current to future state.
- What activities need to be performed to get us from the current state to the future state?
- What will be the resources needed to achieve the objectives?
- What is a realistic timeline to reach the future state?
- What potential challenges/obstacles may be expected and how can the institution plan to address those?
Importance of Starting with a Strategy
A Data Strategy helps institutions work through critical questions before jumping into a solution. We explore the four we find to be most important – and the impact of not addressing them at the start of a data program – below.
I. Define Success
Success of a data program will mean something different to the CFO compared to that of a Provost or the head of Institutional Research. Each leader/department should be aligned on what success would look like based on their own objectives and pain points. If these visions of success and expected outcomes are not aligned across the institution, then do not expect the final product to bring the two together. Use your data strategy planning effort to ensure that what can and cannot be achieved is fully understood and carry these visions of success throughout the program so that they are addressed in governance forums and all team members are aligned on the objectives.
What could go wrong? While the impact of not aligning early may be pretty obvious, we recently had a client who had multiple resources pouring hours into developing a dashboard, but it was clear that the business did not understand how that dashboard would address their needs. They did not align completely on requirements or expected output and thus were marching in different directions for weeks before things blew up. At that point, one side felt personally invested in what they built, while the other side felt completely unheard as to their needs. The teams came together and reset expectations. Then, with closer collaboration, they developed a product that would meet the needs of the business. Unfortunately, this was only after they wasted time unnecessarily and resulted in pushing out the backlog of development. Never assume anything and align early is the key!
II. Define Program of Work
Data programs are often seen as projects to implement an enterprise data and analytics platform with a focus on the integration, storage, and visualization technologies. While these are all extremely important components of a data program, they are only part of the entire story and if the other pieces are left ignored then the program will not be successful. So, what additional activities are needed? Let’s explore a few of the pieces that we would deem as critical for the success of a data program.
- Data Governance –Data Governance is critical to all aspects of collecting, maintaining, and disseminating data at the institution. This topic deserves its own research if you are unfamiliar with the nuts and bolts. Also, for EDUCAUSE members I would highly recommend joining the monthly Data Governance Community Group Meetings as they are doing some great work discussing and demonstrating what has worked and what has not worked for institutions going through Data Governance journeys. A data program without Data Governance is a data project doomed to failure.
- Change Management – There is no point in undertaking any project if there is no change, and all projects should evaluate the areas of change and how to manage that change. Data projects by their nature necessitate changes – they could be big changes such as organizational structure changes or smaller changes such as updating roles and responsibilities of analysts at the institution, but there is no avoiding them. Simply implementing a platform but not having support services wrapped around it will not achieve the intended benefits sought in the strategy. A data program without Change Management is like building a 6-bedroom house and sleeping in the half-bathroom.
- Training & Skills Uplift – With anynew platform or changes in business processes there will be elements of training required. A data initiative is no different in that we need to uplift the data literacy of the institution and ensure that support teams and end-users have the necessary skillsets to achieve the intended objectives. A data program that does not consider Training and Skills Uplift is like telling a group of archers that they will be going into battle with swords.
- Data Security – Any time data is leaving a source system, there needs to be careful consideration at each step in how the data is protected from both internal and external threats. While bringing a lot of disparate systems’ data to a single place is exciting for potential analysis purposes, it is also daunting from a security perspective as it is a new location from which a breach can occur. A data program without Data Security considered is a breach waiting to happen.
- Metadata Management – This often takes the form of documentation of datasets available to end-users, lineage information on where the data came from, who should be contacted for a given report and other critical information on what is being built so that others can support or utilize the platform. We all know by now, especially those software developers reading this, if it is not documented at time of creation then the chances of later coming back and documenting are slim to none. Yet it is critically important, especially for end-users and for new staff who join the organization, to be able to quickly understand and leverage the data services deployed at the institution. A data program without Metadata Management is a ticking time bomb which will result in chaos.
What could go wrong? One client went down the route of a data warehouse and did an amazing job of implementing the technology, establishing a base set of reports for the business units, and even training users on the complex interface to build their own reports based on the data in the warehouse. Their initial implementation was seen as a success with handfuls of users now using the platform to perform their operational processes without many issues. The shine started to wear off when staff were allowed to copy reports to create new versions of the reports with minor changes to address a niche need for the one unit. This continued for years, and as staff turnover started to pick up it was clear that reports had little metadata documented in terms of report purpose, owner, how it was constructed, or whether it had any known issues. Users began to lose trust in the reports and shy away from the warehouse due to its complexity and lack of user-friendly documentation. Had the institution wrapped in strict Data Governance standards and training materials as part of the program then this likely would not have been as big of an issue. Note: Building multiple reports with slight variations is very common as it is an easy approach to address a request, but is not best practice from a maintenance and consistency perspective.
III. Secure Funding/Commitment
The vision outlined in the data strategy and its corresponding roadmap of how the institution can arrive at the desired outcomes are only valid if the institution can make the necessary commitment of resources. This may not be in the form of 100% commitment across the life of the program. In most cases an interim funding agreement should be sought with alignment to specific tollgates or deliverables within the program. Regular reviews of progress towards goals along with tracking budget versus actuals will be a continual process to ensure that the program has the necessary traction to meet the original goals within the expected timeframe and resources.
What could go wrong? One institution implemented a data warehouse without any buy-in or real involvement from its international campuses. When I arrived there, I asked whether a data warehouse existed and that was quickly met with a “yeeeeah…..but”. That “but” was the fact that no resources were involved in the planning stages from the international campuses, and they were only approached to “integrate” data into the warehouse. That was as far as the project ever went, so there was no validation on the data loaded into the warehouse and no reports ever built for the international campuses due to not being involved in the planning and committing resources into the project. A great opportunity was missed to bring together disparate datasets into a common platform to ease institutional reporting both internally and externally. I will say that this institution has since hired an amazing Chief Data Officer, established one of the best data strategies I have seen, and launched multiple streams of work which have been extremely successful. They would now be considered as a poster child for the “how to do things right” with regards to data programs. You can come back from data program mistakes!
IV. Build Consensus
Coordinate with other leaders to flesh out what the future state should look like. Create alignment on how the strategy will address current pain points and help achieve departmental and institutional objectives. An equally important piece is clearly establishing what the data program cannot fix. This iterative process of reviewing with leaders/departments establishes a sense of co-creation that also improves the chances for success as there will be a joint sense of ownership across the institution among those who reviewed it, provided feedback, and can now see their success tied to the implementation of the strategy.
What could go wrong? This is the trap that we see too often, with one department (IR, IT, Data/BI Unit, etc.) taking it upon themselves to build a data platform with little to no input from the business units. This is what I refer to as the “if you build it, they will come approach”, which is normally a bad idea when done at an enterprise scale as the investment of time and resources without business involvement is often larger than any benefits derived by the institution. The tell-tale signs of these approaches are often technically sound data platforms with minimal business usage, platforms loaded with only a single source system, and platforms with large datasets that have never been tested or had reports built off them. The bigger harm in this approach is the lasting impact on the culture of the institution with regards to data projects where every idea is met with a “yeah, but last time…” which takes time, energy, and lots of convincing to overcome.
Conclusion
While it may feel like there must be some immediate movement on data and analytics solutions because of the challenges facing Higher Education, taking time to properly plan out the approach and get everyone onboard with the vision will drastically improve the odds of the technology, processes, and people being successful in the long-term. Just take a deep breath and get started on your Data Strategy!