Roadmap

Understanding current data maturity will help you communicate the challenges and opportunities you face in data management and reporting provision.

To improve, you should consider what you will prioritise, how best to approach change activity and how it will be resourced.

While the Jisc framework describes five levels, you will need to decide which level matches your data aspirations – this may not be level five in all cases. Where current maturity is low, at level one or two, the journey to higher levels is likely to feel unachievable and dedicated resource may be needed over time. You will need to address:

  • Can you realistically make progress in business as usual?
  • Do you need dedicated capacity, and will that need extra investment?
  • Which areas offer you the greatest opportunity to make some progress?
  • Which areas will help you progress strategic objectives?

The examples page contains the key issues that will support effective foundations in a series of common priority areas.

The approaches section includes some project management considerations.

Identifying actions

DMF-2.2 (no text)

  • Select a theme where you want to improve.
  • Select an issue (these may be suggested to you if you complete the data maturity assessment).
  • The roadmap will provide you with information for maturity levels one to five.
  • Identify what you can focus on to move to the next level.

Data strategy

Executive accountability - framework

Level 1 - There is no recognition that data management is a priority for the organisation beyond statutory obligations.

Level 2 - Data management is the responsibility of individuals and as senior leaders we do not generally get involved.

Level 3 - As a senior team we have a role in the formal management of data so that our teams understand their responsibilities.

Level 4 - We add priorities to a data improvement plan that is sponsored by an accountable individual. We modify this as new priorities emerge.

Level 5 - We have published a framework to define our data management approach. Accountable individuals ensure we meet the highest external auditing levels.

View the statements (pdf)

Executive accountability - oversight

Level 1 - Our senior teams have no oversight or responsibility for data and reporting activities.

Level 2 - As a senior team, we have started to take an interest in the data we hold and what we use it for, but our teams understand the detail.

Level 3 - Our senior team understand current legislation and take active steps to ensure we adhere to this as an organisation.

Level 4 - As a senior team, we consider both current legislation and best practice in data and analytics, and understand we have a role in their successful delivery.

Level 5 - We promote data as an asset that is everyone's responsibility, and as a senior team we accept accountability for the role data plays in successful delivery of key activities.

View the statements (pdf)

Executive accountability - security

Level 1 - We don't know whether our data is secure, and we don't know how to find out.

Level 2 - There are known risks in our data but we have not yet considered our organisational risk appetite to decide what we need to address.

Level 3 - We have recognised classifications in place for our core datasets, and are confident enough in this to be formally internal audited.

Level 4 - We have recognised classifications in place for all our datasets, and we have appropriate access policies in place across our organisation.

Level 5 - Our teams are collaborating to consider how new technologies will impact on our data and to ensure new tools can be rolled out and used without risk to our data assets.

View the statements (pdf)

Executive engagement - investment

Level 1 - No data improvement proposals are sponsored or generally visible at a senior level.

Level 2 - We have some ideas that tend to be specific to big problems we're trying to fix. These initiatives can get priority if they are deemed important.

Level 3 - Senior management are aware of the value of data improvement, but support is limited to specific projects or issues, rather than an organisational priority.

Level 4 - Data improvement initiatives are supported by or run at a senior management level although they sometimes lose support in the long-term.

Level 5 - All data improvement initiatives are sponsored by senior management with strong support for providing the resources needed to undertake them.

View the statements (pdf)

Executive engagement - senior awareness

Level 1 - Statutory responsibilities are known to our leadership teams, but we do not focus on delivery processes or wider use.

Level 2 - Statutory data is important to us, especially how we are judged by external bodies and in published metrics, but little value is considered beyond this. 

Level 3 - Our senior leaders are starting to see the value of data, but our position remains generally defensive.

Level 4 - We are actively considering how data can be harnessed to add value to managing the challenges we face as an organisation.

Level 5 - Our teams use data to find points of difference that deliver clear benefits for our students and our staff.

View the statements (pdf)

Executive engagement - senior experience

Level 1 - We have no senior experience of data and analytics in an organisational context.

Level 2 - One of our senior team had access to dashboards in a previous role but was not involved in their production and therefore is not that clear how to develop them here.

Level 3 - Organisational data literacy is starting to be valued by our senior team and we understand our role in enabling improvements.

Level 4 - We have an agreed data champion in our senior team who provides data leadership to our organisation.

Level 5 - Our leadership team includes a range of senior experience in data and analytics delivery and use. We consider these skills in our senior recruitment.

View the statements (pdf)

Information lifecycle - asset value

Level 1 - We don’t know what data we hold or where it is.

Level 2 - We are starting to recognise the value of polices and processes in analysing and managing the data assets that we hold and the risks of not implementing them.

Level 3 - We understand that data is an asset and have prioritised and begun to develop key data polices and processes.

Level 4 - We are embedding asset-based data management across our organisation.

Level 5 - Our strategy requires data to be managed effectively across the whole institution or college which ensures it remains in the spotlight.

View the statements (pdf)

Information lifecycle - constraints and ethics

Level 1 - We have not really considered ethics - we just use data as and when we need to.

Level 2 - Our data specialists understand policies and guidance, but we would not say there is much broader awareness of these.

Level 3 - Our teams understand that our data assets should be used responsibly but we rely on them to do this rather than support them.

Level 4 - We have agreed a plan to develop the controls and guidance needed to guarantee we never misuse data. It is currently focused on new projects.

Level 5 - We have defined acceptable usage cases and have appropriate controls in place to ensure all our data is never knowingly or unknowingly used unethically.

View the statements (pdf)

Information lifecycle - risk appetite

Level 1 - We don’t understand risk appetite, so it is not part of our decision making or processes.

Level 2 - Risk appetite is discussed at senior level, but its impact is not fully appreciated across the organisation.

Level 3 - We are aware of how to manage risk, but it does not influence our approach.

Level 4 - We are clear on our appetite for risk, and it is considered on major projects.

Level 5 - Risk is clearly measured, considered and embedded in all our practices.

View the statements (pdf)

Priorities - change

Level 1 - We don't consider the impact of change at all on data. We assume our teams fit it in as it happens.

Level 2 - We are conscious that data will be affected by change activity, but it is difficult to estimate the impact as we don't fully understand the current state.

Level 3 - We ensure the right people are represented on larger projects and initiatives though many changes still happen before being assessed properly.

Level 4 - We ensure that data assets are built or maintained as part of organisational change and ensure all relevant stakeholders are aware of this.

Level 5 - Data capabilities are fundamental to how we operate. We undertake impact assessments early when our functions change to ensure appropriate resource is in place.

View the statements (pdf)

Priorities - delivery

Level 1 - The only priority for data activities is to fix whatever is currently broken. 

Level 2 - Data is of interest to the organisation, but it is not a priority. We always see other activities as more important.

Level 3 - We recognise that we need to prioritise and plan how to permanently improve our data management and reporting.

Level 4 - Data and analytics are part of our strategy delivery and are referenced in relevant documents and communication.

Level 5 - Data activities are core to our operations and strategy and are high priority as they underpin and enable delivery in other areas.

View the statements (pdf)

Priorities - outcomes

Level 1 - Opportunities to use data to add value are not promoted or supported because data is not seen as valuable for outcomes.

Level 2 - Data is mostly used for compliance activities or to evidence what we already know – it does not challenge our assumptions.

Level 3 - We have access to quite a lot of data and reports but now we need to align these to the metrics we need to better understand our strategic goals.

Level 4 - We are starting to consider how to use data to drive value and for prediction rather than just looking back.

Level 5 - Data is considered offensively and drives questions that prompt new strategic thinking.

View the statements (pdf)

Responsibilities - collaboration

Level 1 - Siloed working is normal and activities are mostly performed by individuals which means duplication and discrepancy is common.

Level 2 - Siloed working remains common and while we recognise that this leads to duplication and discrepancies, we aren't sure how to address it.

Level 3 - Some of our teams are starting to discuss how they can work together more effectively and they collaborate on ad hoc projects.

Level 4 - As a senior team, we are actively encouraging and supporting our teams to collaborate so that outputs are more aligned, and the right people do the right work.

Level 5 - Collaboration across teams is proactive and we are confident that upcoming requirements and change activity is effectively managed. 

View the statements (pdf)

Responsibilities - people

Level 1 - Roles are inconsistent across functions and there is little or no expertise in some areas.

Level 2 - We consider IT and some administrative functions to be responsible for data activities and they seem to deliver these pretty well.

Level 3 - We recognise that our teams need investment in tools and skills development, but this remains limited to a few specialist individuals.

Level 4 - We have made significant investment in people, skills development and tools for specialist roles and understand what is needed by our wider staff base.

Level 5 - Our people, both report providers and report users, are a point of difference and we consider them as leaders who innovate and look to future capabilities.

View the statements (pdf)

Responsibilities - resourcing

Level 1 - It is not clear who is responsible for data activities beyond IT Services, and we have not considered this strategically.

Level 2 - We are starting to invest in some key areas though that means that reporting on student data is much more likely to be resourced than staff, research or other areas.

Level 3 - We are starting to assess skills and capabilities across our teams and understand the need for engagement and delivery outside IT.

Level 4 - We understand the roles and capabilities we need to have in place. Leadership skills gaps are being tackled with a focus on understanding performance. 

Level 5 - We have a defined staffing establishment for our data and analysis functions and capabilities, and this is represented within our succession planning.

View the statements (pdf)

Usage - access

Level 1 - We have no visibility or awareness of limitations. Any access restrictions are decided in an inconsistent manner.

Level 2 - Some limitations and restrictions exist but these are typically reactive, for example, limiting access to more data than necessary through fear of GDPR incompliance.

Level 3 - Some key data sets and outputs are accessible, but many remain limited by default, and it can be hard to address this.

Level 4 - Data is available to those that need it for operational and strategic delivery though this is often managed on a case-by-case basis.

Level 5 - Our controls ensure that access and restrictions are appropriate to business needs. We manage risk and changes in circumstances as part of our business as usual processes.

View the statements (pdf)

Usage - decisions

Level 1 - Data is not used for decision making – most decisions are made on gut instinct, and this is not validated.

Level 2 - Data is used for limited operational decision making but most strategic activity remain unvalidated.

Level 3 - Our key activities and responsibilities are data informed. 

Level 4 - There are clearly defined business needs across the organisation – it is evident to all teams how data can be used in decision making and process delivery. 

Level 5 - We consider our organisation to be data enabled. Everybody understands what that means for them and role specifications and objectives support this.

View the statements (pdf)

Usage - value

Level 1 - The value of outputs from data are unknown - both in terms of what they are for and to whom they may provide value.

Level 2 - Data is understood to be essential for statutory compliance, but the cost of activity is not understood.

Level 3 - Data is valued as the source of our key institutional, statutory and internal outputs and the costs are understood.

Level 4 - Data outputs are of an appropriate cost and quality to match expectations of what is required.

Level 5 - The outputs of data are an integral part of how we deliver our most important services, and their value is well understood across our whole organisation.

View the statements (pdf)

Data governance

Accountability - data ownership

Level 1 - Our datasets have no clear accountability for ownership or sign-off.

Level 2 - Responsibility for data is held informally by the registry or student support teams.

Level 3 - Key datasets are a jointly owned asset between those managing the data and those accountable for it. Other data has unclear accountability. 

Level 4 - Key datasets have visible and respected accountability, while other data still resides in teams or departments where ownership and accountability are unclear. 

Level 5 - We have a senior management sponsor for all data assets. Information asset ownership is embedded and effectively distributed across the organisation. 

View the statements (pdf)

Accountability - data roles

Level 1 - We don't have specific roles for data management or any concept of why we would need them beyond considering data protection issues.

Level 2 - We perform the most basic data management roles, mainly around data cleaning, though they are not formalised.

Level 3 - We have defined some formal data management responsibilities in our key areas like student support teams.

Level 4 - We have several data specific roles which confer accountability across a variety of departments, for both operations and business change. 

Level 5 - Data citizenship is embraced by people in all parts of the organisation, who advocate and manage data as an organisational asset.

View the statements (pdf)

Accountability - resolution

Level 1 - There is no collaboration between cross-disciplinary teams to diagnose, troubleshoot or resolve data issues. 

Level 2 - There is some ad hoc collaboration between registry and other departments to fix serious problems. 

Level 3 - We have a forum for sharing issues around quality and other data management issues which meets regularly and is respected.

Level 4 - Multi-disciplinary teams work together to resolve data issues - either tactically or as part of a data improvement programme. 

Level 5 - Data issues are worked on collaboratively between all functions, and prioritised according to wider business initiatives and needs.

View the statements (pdf)

Assurance - issue management

Level 1 - We fix errors as they are reported to us. No analysis of why the failure occurred is done and we do not track issues after resolution. 

Level 2 - We fix errors during routine checking, but we do not have time for root cause analysis unless it's a very serious issue. 

Level 3 - We track and record all data issues using automated error checking though we do not yet have standards in place for resolution.

Level 4 - We have a data quality plan that defines how we resolve issues. It includes performance measures that we monitor and routinely assess.

Level 5 - Our data quality plan is supported by automated error reporting which is monitored by senior management.

View the statements (pdf)

Assurance - monitoring and measurement

Level 1 - We do not have an approach to improving data quality and there is a sense of apathy towards such initiatives across the business.

Level 2 - We have some good ideas, but nothing formal enough to call a plan. We focus on statutory compliance and tend to 'fix and forget'.

Level 3 - We have data quality targets and Key Performance Indicators (KPIs), but these are not regularly assessed or challenged.

Level 4 - We set, monitor and maintain quality metrics for most of our data, and have automated some remedial work where possible.

Level 5 - We ensure all our data is rigorously maintained to the published levels of quality using well-understood metrics.

View the statements (pdf)

Assurance - policies

Level 1 - We don't believe data is referenced in any organisational policies. 

Level 2 - We have some policies around data, but they are not well communicated nor respected. 

Level 3 - We have data policies, but adherence is poorly monitored and sanctions are rarely invoked when policies are not followed.

Level 4 - We have built actionable policies across multiple functions, and they form part of our wider policy library.

Level 5 - We have defined and respected data principles, goals and practices which are consistently applied to all our data operations. 

View the statements (pdf)

Change impact - managing turnover

Level 1 - We have little visibility of the dependencies we have on individuals, which leaves us vulnerable if people move roles or leave the organisation.

Level 2 - We think we know who we depend on in key business areas but we are not clear how to manage this risk better.

Level 3 - We understand which of our people understand our processes though we can sometimes struggle when key individuals leave their posts.

Level 4 - We are starting to create a framework that considers roles as well as people. This will help us consider succession planning.

Level 5 - Business continuity is critical. Our framework defines roles and responsibilities and managers reallocate roles and ensure adequate knowledge transition when people leave.

View the statements (pdf)

Change impact - new systems

Level 1 - When new systems are proposed, understanding the impact on data is not seen as a priority and our data products have broken unexpectedly.

Level 2 - When new systems are proposed, we recognise there may be an impact on data, but this is often considered too late to be managed efficiently, leading to manual work.

Level 3 - When new systems are proposed, we know there will be an impact on data, and we get enough notice to find and manage downstream impacts.

Level 4 - We have full visibility of integrations so we understand the impact on our data from changes to systems. We can advise system owners of these impacts in advance.

Level 5 - We ensure data specialists join project initiatives at an early stage to advise on the impact of system and process changes on our data, which ensures there is no downstream impact.

View the statements (pdf)

Change impact - organisational structure

Level 1 - If anything about our organisational structure changes, no one considers how our data will be affected. 

Level 2 - When our organisational structure changes, we know our data will be affected but we struggle to identify how. 

Level 3 - When our organisational structure changes, we have processes in place to manage any impact on our data, though the focus is statutory compliance.

Level 4 - We can clearly articulate to colleagues the impact of proposed organisational structure changes on data and reporting outputs.

Level 5 - Senior leaders consider the impact on data and reporting outputs when discussing organisational structure changes so that the cost of change is fully understood. 

View the statements (pdf)

Engagement - barriers

Level 1 - It's a struggle to get anyone interested in data governance and we cannot really point to any area that we would say is engaged.

Level 2 - People tend to focus on data quality, which is a start, but it's hard to raise awareness beyond statutory requirements.

Level 3 - Our leadership and operational teams understand what data governance is. We are developing a plan for each area, so people are clear what will drive value.

Level 4 - We have champions in key areas who raise awareness of data governance. We need to ensure that culture is embedded across the rest of the organisation.

Level 5 - There is a shared understanding and collaboration across our teams. Connecting how we work and how we monitor our effectiveness is seen as being everyone's responsibility.

View the statements (pdf)

Engagement - behaviours

Level 1 - We have no concept of best practice. Our data management is chaotic, and we don't have time to understand scope and reach. 

Level 2 - There is little understanding of best practice or data governance activity outside of maintaining regulatory compliance/statutory reporting.

Level 3 - The data management function is fit for purpose and no more. Therefore, we do have some best practice, but it is not organisation-wide.

Level 4 - We track, prioritise and record issues to underpin a wide range of data uses, auditable to recognised standards.

Level 5 - We ensure that the principles and goals of best practice data management are embedded and advocated in all appropriate policy documents.

View the statements (pdf)

Engagement - stakeholders

Level 1 - We don’t know who our key stakeholders are, so they are part not of any process considerations.

Level 2 - We know who our stakeholders are but we are not regularly engaged with them on the subject of data.

Level 3 - Our stakeholders are known to us and are consulted with on an ad hoc basis - we need to ensure they trust us and will honestly share their informal as well as formal processes.

Level 4 - We have a stakeholder engagement policy, all parties are active and routinely engaged where necessary.

Level 5 - Stakeholder relationships are firmly established and are consulted on key topics - they confirm how they work, not how they know they are supposed to.

View the statements (pdf)

Risk - business continuity

Level 1 - We've never seen a business continuity plan, and we assume there is no strategy for data assets. 

Level 2 - There is a lack of or untested business continuity around our information assets.

Level 3 - Data is included in the business continuity plan (BCP), and we are developing regular testing to ensure it will work under stress.

Level 4 - Data is a key part of the BCP and well integrated with our operational processes during an event. We review and test it at least annually. 

Level 5 - Data drives a significant portion of the BCP plan as data availability is core to our operations during an event. Plans are always up to date and regularly tested. 

View the statements (pdf)

Risk - privacy

Level 1 - The organisation fears risks associated with GDPR and there are assumptions that data cannot be shared even where there may be a legitimate purpose.

Level 2 - Data is often not made available to those who may need it with GDPR cited as the reason. 

Level 3 - Data is generally made available to those that need it, subject to GDPR. However, we struggle with volumes, archiving and deletion.

Level 4 - Subject to GDPR, we make data available in a secure environment to those that need it for agreed purposes and we are developing effective assurance processes.

Level 5 - Subject to GDPR, everyone has access to the data they need in a secure environment and our assurance processes ensure no data is retained any longer than needed. 

View the statements (pdf)

Risk - risk assessment

Level 1 - We do not perform risk assessments on our datasets. Therefore, nothing is recorded in any logs.

Level 2 - We record data related risks and issues in our departmental risk logs although we don't always include mitigation.

Level 3 - We record and review data related risks and issues in our corporate risk logs. 

Level 4 - We effectively manage risk with data using appropriate governance, mitigation, escalation and regular assurance.

Level 5 - Risk and quality are actively managed for all datasets. Breaches and metrics are flagged and responded to by senior management. 

View the statements (pdf)

Value - data lineage

Level 1 - We have no processes in place to track what happens to the data we use, so we struggle when we find errors.

Level 2 - We have examples of key use cases where better visibility would have helped manage errors. We are using these to consider what standards we need.

Level 3 - We are defining standards to document how data transformations are undertaken and piloting these in one area.

Level 4 - We have standards in place in our key business areas. These standards are manual but do ensure we can error check when we need to.

Level 5 - We have automated our processes wherever possible to track changes to data values and meaning. This ensures we can manage our data assets effectively.

View the statements (pdf)

Value - data relationships

Level 1 - There is no oversight of how our datasets relate to each other and no processes in place for how they might be combined effectively.

Level 2 - We are exploring how entity and attribute documentation could improve understanding of the relationships between datasets.

Level 3 - We understand and have documentation in place for at least two datasets and we can point to examples of where combining them has added value to the organisation.

Level 4 - All our key data is documented and we share it with colleagues regularly to test that it is accurate. This helps us maintain trust and can communicate value.

Level 5 - The data we hold is a strategic capability. Where new systems or data sources could add value, our standards ensure we are clear how they relate to our existing entities and attributes.

View the statements (pdf)

Value - definitions and standards

Level 1 - It is not clear what definitions are in place and there is no standard approach to managing them.

Level 2 - We are considering what standards, like a data dictionary, would be helpful for us to better understand the assets that we have - our initial focus is compliance.

Level 3 - We have designed and populated a data dictionary for our top priority data area that we believe can be adopted across the university or college.

Level 4 - Our data dictionary contains metadata across key areas of our activity. Our priority is ensuring it is used effectively.

Level 5 - We have oversight of a data dictionary that covers all our data assets. We actively ensure content remains accurate and engagement remains high.

View the statements (pdf)

Processes and systems

Business architecture - governance

Level 1 - There is no recognisable understanding from any business unit of how data is managed by IT. 

Level 2 - It is understood that IT is responsible for the storage and backup of data and some of the tools to manage it.

Level 3 - IT is included in wider business processes around outputs, but not fully integrated with new requirements and change.

Level 4 - IT has a peer relationship with the wider business. IT's contribution to the electronic management of data is understood, although not always respected. 

Level 5 - Operational and change activity is seamlessly integrated between IT and the wider business with all roles and responsibilities defined and understood. 

View the statements (pdf)

Business architecture - processes

Level 1 - We have not mapped out any processes for data so we cannot integrate them with wider business processes.

Level 2 - We have some defined data processes, but they are not well-aligned with wider business process.

Level 3 - We have mapped out our operational processes allowing us to replicate frequent activities in our departmental teams. 

Level 4 - Data is represented as a 'journey' as part of wider business processes to ensure value, dependencies and criticality is understood by all relevant teams.

Level 5 - Data processes are clearly documented and rigorously maintained; performance monitoring is in place as a 'business as usual' activity. 

View the statements (pdf)

Business architecture - requirements

Level 1 - We continue with data collections for no obvious rationale other than 'we've always done this'.

Level 2 - We collect data we don't use or collect more than once. We don't know if something will break if we stop collecting it.

Level 3 - There is some confusion around why some data is collected, but we understand our systems of record and our primary data feeds.

Level 4 - We have clearly mapped the flow of information across the organisation in order to understand the impact of change on data models. 

Level 5 - We regularly review our data collection activities in line with our operational and strategic needs. Data collection is driven directly from these models.

View the statements (pdf)

Data assets - data catalogue

Level 1 - We don't have any understanding or visibility of the data available to us or what our systems hold.

Level 2 - There is knowledge of the data in our key systems but it is dependent on a few individuals and there is little or no documentation.

Level 3 - There is knowledge of the data within our systems but it is siloed and we have no formal mechanism to collate it in one place.

Level 4 - We are starting to create a data catalogue containing each data asset, and how our data can be leveraged for business use.

Level 5 - Our business has good knowledge of the data held in our systems, it is well-documented, and we understand it's potential in helping us address our strategic priorities.

View the statements (pdf)

Data assets - master data

Level 1 - There is no consistency across our systems in how our organisational units, business terms, or their attributes are described.

Level 2 - While there is little consistency across our systems, we have created ad hoc solutions to manage mappings for reporting.

Level 3 - There is some consistency across systems with key identifiers and we have a plan in place to expand this.

Level 4 - We are in the process of centralising the recording of master data from our remaining systems. We ensure information is held at the correct granularity.

Level 5 - We have a complete centralised view of the master data in all our business systems. It is well documented in an appropriate format and we consider the impact of changes before we make them.

View the statements (pdf)

Data assets - reference data

Level 1 - We do not have any visibility of the reference data used in systems and onward reporting - what we see is inconsistent.

Level 2 - We are starting to put together some standard reference data tables for our key business areas, but they are not used widely.

Level 3 - We manage key reference data, including our organisational hierarchy, in a central function though it's use in reporting is limited, and we do not yet have appropriate governance processes in place.

Level 4 - We are developing a governance framework for how to manage our reference data at an organisation level.

Level 5 - We have agreed reference data sets across our organisation, with consensus on content, onward governance, and who is accountable for its purpose and change requests.

View the statements (pdf)

Data flows - automation

Level 1 - Data resides in our systems and onward use is through manual extraction on an ad hoc basis.

Level 2 - We have very limited scheduled movement of data between some of our systems, focused on enabling basic operations such as access permissions.

Level 3 - We have mapped out how automation of data flows could support more effective analytics, and are starting to plan out how to deliver this.

Level 4 - We have built automated data flows between some of our key systems but these do not yet support wider activities.

Level 5 - All appropriate data processes from system admin to corporate priorities like reporting, are supported by automated, scheduled and maintained data flows.

View the statements (pdf)

Data flows - controls

Level 1 - When we extract or move data in our systems, we are totally dependent on the person responsible for the extraction to consider if the data is accurate and documented effectively.

Level 2 - When we move data between or outside our systems, some audit information is generated but no one really makes use of it or considers how it might be of value to the wider business.

Level 3 - We capture limited audit processes and are starting to consider how we might use this information to improve our processes.

Level 4 - We are implementing controls in our data movement activities but we still have some work to do before we are confident in using these effectively.

Level 5 - We have visible and documented audit data and impact assessment for our systems, appropriate error handling processes and a schedule to help us understand how to manage a variety of scenarios.

View the statements (pdf)

Data flows - validation

Level 1 - We have no consistency of data input - our systems do not support this and none of our people have access to any standards in relation to this.

Level 2 - We are starting to define how individual fields should be collected and what validation might be needed to support this.

Level 3 - We know how data should be collected to support our strategic goals. New system developments contain appropriate field level validation.

Level 4 - Our key systems contain field level validation. We need to improve our processes to ensure these are used effectively.

Level 5 - We have processes and standards to support data collection and entry. All our corporate systems are configured to support these standards.

View the statements (pdf)

Data models - data management

Level 1 - We have no idea how many datasets we have, where they are or what they are used for. Therefore, no master copy exists.

Level 2 - Organisational and department data doesn’t reconcile, and changes are not supported by robust business process or data governance.

Level 3 - We have an agreed single source for core datasets, even if this means we just know where the copies are. 

Level 4 - An agreed single source is in place for core datasets and we signpost our teams to these sources to ensure their use is embedded.

Level 5 - Our data is created, integrated, consumed and purged with traceability to the master data model, and supported by rigorous business process. 

View the statements (pdf)

Data models - documents and ERDs

Level 1 - Data has no formal presentation. There are no links between what the organisation does and the data that supports it. 

Level 2 - Data is represented in low-level technical models to aid daily operations and systems development. It is rarely surfaced outside IT and the student team. 

Level 3 - Data is represented through a variety of models and schematics but not well integrated with wider business operating and change models. 

Level 4 - We are starting to use our data models and documentation to work with stakeholders to understand data that is not needed.

Level 5 - We have a common business vocabulary for data which builds into a master view of the data journey through the organisation.

View the statements (pdf)

Data models - meta data

Level 1 - We don’t have any formal metadata available for any of our core or non-core datasets. 

Level 2 - Where available, metadata is used to help understand impacts to datasets. No formal taxonomy or dictionary is in place.

Level 3 - Metadata is available (if not complete) for our core datasets, but generally developed and maintained within the student team.

Level 4 - Metadata is developed by named information asset owners and is available as part of a lineage and audit process.

Level 5 - Metadata is complete, rich, managed and maintained. This lack of ambiguity enables high re-use and ensures we can develop new services in a timely fashion.

View the statements (pdf)

Enterprise architecture - components

Level 1 - There is no concept of data architecture in our organisation. Consequently, we have no formal vision, metrics or principles for data. 

Level 2 - There is no formal data architecture but some of the concepts are partially implemented in our governance activities. 

Level 3 - We have a data architecture function, but it is not fully staffed, nor does it have a mandate for real enterprise-wide change.

Level 4 - Data architecture is understood and embedded but not across all disciplines. We use target architecture to steer our change and development. 

Level 5 - Data architecture is part of our enterprise level blueprint - it plays a major part in operation and change within the organisation.

View the statements (pdf)

Enterprise architecture - design

Level 1 - Technology dependencies are hindering us in managing our data. 

Level 2 - Technology does not support our data lifecycle in any recognised manner. We have some tools but no real processes to use them.

Level 3 - We have limited data management specific technology, but this is not well integrated with wider management solutions. 

Level 4 - We use technology to actively support and develop our data lifecycle management. 

Level 5 - Effective use of technology enables us to manage data across its full lifecycle by analysing, improving and controlling information assets. 

View the statements (pdf)

Enterprise architecture - organisational agility

Level 1 - We usually feel on the back foot when the university or college needs something new. We have started system projects that have failed.

Level 2 - We deliver new system and process requirements successfully - but it generally takes a long time and is resource intensive, risking other activities.

Level 3 - Our structures and knowledge ensure we can react to new priorities in a timely fashion, though we would like to be more proactive.

Level 4 - Our strategy prioritises the ability to respond at pace to new demands. We have identified and resourced key areas that we need to tackle to achieve this.

Level 5 - Our target operating model includes provision to manage new requirements and we aim to pre-empt systems and process changes.

View the statements (pdf)

Technology and applications - applications

Level 1 - We are dependent on manual activity to move data from one application to another.

Level 2 - We have automated some key processes, such as permissions, but we still rely on manual operations to update some of our key systems.

Level 3 - We have mapped the dependencies between our applications and have an agreed plan and budget in place to automate integrations.

Level 4 - All our business systems integrate automatically though this can leave our data vulnerable when we want to make a change to an application.

Level 5 - We have an abstract data layer linking our applications via APIs. This ensures we can change applications when we need to without impact on downstream data needs.

View the statements (pdf)

Technology and applications - business systems

Level 1 - We do not have clear sight of the systems environment and therefore the extent of data sitting on shadow or non-shadow IT.

Level 2 - We have corporate systems for our main areas of activity but we know there are localised solutions to support some other processes.

Level 3 - We know what systems our organisation needs to support its processes. A roadmap is in place to deliver those we do not yet have in place.

Level 4 - We have standard systems in place for all our processes. Any remaining localised solutions exist because we have strategically decided that is the best solution.

Level 5 - Our systems architecture forms part of our enterprise architecture. Our focus is on managing change so we are prepared for new requirements from the organisation.

View the statements (pdf)

Technology and applications - servers and storage

Level 1 - We really struggle with our data - it's all over the place, on individual computers and in some cases in hardcopy formats.

Level 2 - We are starting to put some standards in place and most of our data is now in an agreed location. It is still hard to access for some users.

Level 3 - Our data is mostly stored in a secure, backed up environment. This is usually a local server with managed access.

Level 4 - All the data we need for our operations is secure and backed up. We are using cloud options for an increasing amount of our data storage where this is the right solution.

Level 5 - We are streamlining the data we store as part of our strategy to ensure we only hold the data we need, in a supported, securely accessed environment.

View the statements (pdf)

Reporting

Data exploration - data science

Level 1 - We only look at data we have been asked to look at by whoever needs it.

Level 2 - We are starting to think a little more proactively about how data may help our organisation, but we don't really have the skills to access or analyse it effectively.

Level 3 - We are aware that we have access to lots of different data. When we have time, we might have a look at what is there and think about how it might be useful but it is not really a priority.

Level 4 - We are raising our awareness of exactly what data sources the organisation owns. We are actively evaluating the tools and skills we might need to leverage them effectively.

Level 5 - We understand our existing and likely new data assets and are proactive in considering how they could help solve our organisational challenges. We support our analysts to develop the skills to exploit them.

View the statements (pdf)

Data exploration - predictive analytics

Level 1 - We can barely provide descriptive data and there is little confidence in the accuracy of the outputs we produce.

Level 2 - Lots of people talk about predictive analytics, but the reality is that we do not yet have enough core data to support our standard processes and decisions.

Level 3 - We have a good foundation of descriptive data outputs that are mostly trusted by the organisation. We want to consider how to harness data for predictive activity but we lack the skills to do this.

Level 4 - Our organisation is confident in the data outputs we create. Machine learning and AI are key areas of interest that we are actively considering how to exploit and resource.

Level 5 - We are trialling the use of predictive techniques in one of our business areas as the first step on our journey to leverage our data assets more efficiently and effectively.

View the statements (pdf)

Data exploration - strategic outputs

Level 1 - When a senior leader wants to understand an issue, we struggle to get some data together and provide a spreadsheet with basic outputs that often contradicts other reporting.

Level 2 - We can provide data to our senior leaders, but we are not sure if it is what is needed because they keep asking for more data.

Level 3 - Our analysts can provide information to senior leaders when asked, though it can still take some time. We recognise it could be more customer friendly and put less onus on the end user to work out what it means.

Level 4 - We can produce efficient outputs but we are working to develop our analysts to think critically and creatively about the problems they are asked to consider. This is still a work in progress.

Level 5 - Our analysts can access standard datasets to investigate our organisational challenges in innovative ways. Outputs are presented as a visual narrative, directly addressing the issue, informing decision makers.

View the statements (pdf)

Modelling and datasets - availability

Level 1 - Our data is primarily in raw tables only accessible to IT or business systems owners. We usually start from scratch each time we need something.

Level 2 - We have standard tables in place to feed our transactional reporting, but these mostly only contain live or near live data. We do not really know who has access to what.

Level 3 - We have standard datasets for some of our business areas containing trend data but coverage is quite limited, and they are only available to the BI or MIS team.

Level 4 - We have subsets of data to feed all our core reporting and these are available to the BI or MIS teams.

Level 5 - Managed and governed datasets, consistent with our core reporting offer, are available to "superusers" via appropriate reporting software and with appropriate permissions.

View the statements (pdf)

Modelling and datasets - integration

Level 1 - All our data is in silo. There is no modelling or analysis performed when creating or modifying datasets and entities within them. 

Level 2 - Our data is primarily in silo, although we understand some of the key interfaces between the different systems and databases.

Level 3 - We have the concept of mastering data through our primary datasets, but interfaces and extracts do not follow a recognisable model. 

Level 4 - We integrate our datasets under the control of best practice master data management.

Level 5 - We have complete models that drive our data design, and our approaches ensures the whole organisation sees 'one version of the truth'.

View the statements (pdf)

Modelling and datasets - purpose

Level 1 - We have little exposure to data storage, definitions, and management options.

Level 2 - We are aware of multiple terms for data storage and management but do not really understand the differences between them.

Level 3 - We understand how our operational data store supports some of our reporting but we are not yet clear how we can improve our analytics capability.

Level 4 - We understand that we are likely to need structures like a data warehouse or a data lake, to enable our operational, statutory, analytical and exploratory needs.

Level 5 - We have considered which methodologies best suit our needs and can articulate to key stakeholders the benefits they will bring to our analytical data management.

View the statements (pdf)

Orchestration - maintenance

Level 1 - No one seems to understand how or when our data processing happens or what the impact will be on our reporting if something goes wrong. Fixes happen when a user spots a problem.

Level 2 - We know which processes are scheduled to run daily, weekly, monthly and annually. If something looks wrong, we fix it, though this often happens after reporting is refreshed.

Level 3 - Our ETL is monitored through ad hoc checks. Where there are issues, our scripts are updated so that our data remains accurate. We do not yet have a consistency of approach across people or datasets.

Level 4 - We are creating a template to improve consistency in our ETL activities and we are developing a framework to ensure the impact of changes in the business or our systems are understood.

Level 5 - We have a well-documented and maintained schedule for ETL. We know who is responsible for our processes, their accuracy and relevance and issues are flagged and rectified before reporting is impacted.

View the statements (pdf)

Orchestration - organisation

Level 1 - Extracting, transforming and loading data seems to be labour intensive as it is not standardised - even for frequent operational activities.

Level 2 - We are focusing on a key dataset as a starting point to thinking about how to improve our processes - though we struggle to find time to progress this.

Level 3 - Our processes are documented and can be carried out by any trained individual. We struggle when the process doesn't create the output we expect. 

Level 4 - We have repeatable and well understood processes using appropriate environments to create and assure our most repeatable transaction and outputs. 

Level 5 - Our processes are fully integrated with our organisation's operating model and most of our data operations are automated. 

View the statements (pdf)

Orchestration - transformation

Level 1 - We do not manipulate our data; we only analyse it as it is structured in our systems, and we are unable to integrate datasets.

Level 2 - We transform data on an ad hoc basis when the need arises, but we do not have any consistency in how this is achieved.

Level 3 - We have standard processes to transform our key datasets but they still depend on some level of manual intervention.

Level 4 - We are starting to develop automated pipelines and to create consistent standards for data transformation.

Level 5 - We have a documented and well-structured approach to transforming data, creating consistent datasets across all systems and business areas.

View the statements (pdf)

Report providers and users - approach

Level 1 - It always feels like we are firefighting, because we are struggling to keep up with demands of operational and change activity. 

Level 2 - We have a do-and-forget mentality - there is no defined business process for many repeatable activities.

Level 3 - Our most repeated activities are reasonably well resourced. We struggle to deal with change or new initiatives.

Level 4 - Our daily activities are well understood, staffed and processed efficiently. We can handle unexpected events and periods of additional work. 

Level 5 - Daily activities are largely automated and supported by simple business processes. It is very rare we need to intervene.

View the statements (pdf)

Report providers and users - functions

Level 1 - We have no analytics capability other than spreadsheets in individual departments. 

Level 2 - Data cannot be easily analysed to support operational or strategic decision making. 

Level 3 - We have a basic, people-driven analytical capability for one or two datasets. 

Level 4 - A strong business intelligence (or similar) function is in place and providing decision support to more than one department or functional area.

Level 5 - We have made an investment in predictive analytics capability and supporting technology in support of our most important activities and aspirations. 

View the statements (pdf)

Report providers and users - hub and spoke

Level 1 - Teams or individuals involved in data and reporting activity work in siloes and may not be aware of how others work with data and what areas they are responsible for.

Level 2 - There are attempts to work more collaboratively and efficiently but they are met with quite a lot of suspicion.

Level 3 - A central function is in place to define best practice. We are starting to define which team owns which area, and where teams should collaborate.

Level 4 - We have functional capability for our data and reporting provision - standards are provided to business experts who consider themselves part of a cross organisational team and are supported to innovate in their areas.

Level 5 - We are collaborating to consider if data mesh architecture would benefit our organisation and how that might be technically enabled to allow our teams to work with consistency and agility.

View the statements (pdf)

Reporting offer - core reporting

Level 1 - We create reports whenever they are needed, and they are provided solely to those that request them.

Level 2 - We provide a core offer of operational / transactional reports, but our trend reports are mostly ad hoc.

Level 3 - We provide standard trend reports in our most important business areas at key times of year. Transactional reporting is available year-round.

Level 4 - We are working to ensure our analytical reports are updated more frequently but reports are typically generic across user groups.

Level 5 - We provide a core offer of transactional and analytical reports by defined user group across the full range of our business areas, accompanied by user focused documentation.

View the statements (pdf)

Reporting offer - report access

Level 1 - Reports are emailed directly to individuals or groups who are then responsible for storing them locally.

Level 2 - We have multiple spaces to hold reporting - individual servers, in systems and on different sections of our institutional webpages.

Level 3 - We have created a dedicated space to hold reports. This ensures data and reports are not emailed or stored unnecessarily. We are working to ensure all reporting is stored there.

Level 4 - Reports are accessed via a central webspace, though it remains quite generic. We are trying to ensure users can access what they need, particularly for activities or decisions.

Level 5 - A dedicated website or portal provides access to all corporate reporting, guides and documentation, for all user groups. Role-based permissions ensure individuals can access what they need at appropriate granularity.

View the statements (pdf)

Reporting offer - visualisation

Level 1 - Our reporting outputs are usually in data tables, created either in spreadsheet software or from largely transactional reporting solutions (eg SQL server reporting services).

Level 2 - Individuals create visualisations in their reporting outputs, typically pie charts or bar charts using default reporting tool settings.

Level 3 - We are using software to create standard dashboards where visualisations display key metrics. We can also exploit spreadsheet software to produce visually attractive outputs.

Level 4 - Our providers use visualisations to help tell the data story, and we are trying to promote best practice and consistency across the organisation in quality and execution.

Level 5 - We have a suite of interactive dashboards which utilise best practice visualisation techniques, built from a consistent corporate template using colour and accessibility best practice.

View the statements (pdf)

Requirements traceability - business questions

Level 1 - We do not consider "business questions" in our reporting provision and tend to make assumptions about the reporting that is needed.

Level 2 - We ask for requirements before we create reports, but we do not consider this information holistically or store it effectively.

Level 3 - We hold our requirements information in a central repository and define key business questions to direct our reporting.

Level 4 - Business questions form the foundation of our data processing, and we have started to create reporting to share this information with our users.

Level 5 - We present a business question backlog as part of our service. Business questions are the starting point for our data orchestration activities.

View the statements (pdf)

Requirements traceability - business rules

Level 1 - The definitions for the reports we build are held in individual's heads and there is no visibility beyond this.

Level 2 - Reporting producers are starting to share and document definitions for key fields, but these are not always visible to business users.

Level 3 - It is clear what definitions have been used in some of our reporting but there is minimal consistency across reports which can create multiple versions of the truth.

Level 4 - Ownership of reporting areas is becoming established and we are working to ensure definitions are available for both technical and business users.

Level 5 - Definitions reflect business questions and statutory specifications. They are available to technical users and the wider business in appropriate formats and are maintained as part of our reporting governance structures.

View the statements (pdf)

Requirements traceability - reporting architecture

Level 1 - We have not considered what reporting is needed across our organisation and any development is purely ad hoc.

Level 2 - We are starting to consider the different areas of our organisation and the reporting needs in each area.

Level 3 - We understand our business areas and sub areas, and have visibility of the reporting in each area.

Level 4 - We record our new reporting products systematically, so new reporting areas are defined and are aimed at agreed user groups.

Level 5 - We have an agreed hierarchy covering the full scope of business activities and users, enabling the management and analysis of our reporting products.

View the statements (pdf)

Decision making

Administration - granularity

Level 1 - We find that the information we can access does not tend to be at the level we need it. This means we often keep our own records.

Level 2 - We can typically access the information we need to deliver our processes. It's possible that we are holding unjustified information on individuals to do this.

Level 3 - We are starting to assess what information we are holding to feed into our reporting teams as requirements so that we do not need to hold unnecessary data locally.

Level 4 - We have a plan in place in the form of a SLA or equivalent to ensure it is clear what should be provided centrally and the expectations on our teams.

Level 5 - We can access information at multiple levels of aggregation. Where there is a business need, and subject to GDPR, we can access individualised student or staff data to ensure we can progress activities effectively.

View the statements (pdf)

Administration - information

Level 1 - We struggle to access the basic information we need to deliver our processes. It feels like we are always firefighting.

Level 2 - We know who to ask for reporting to support our day-to-day operations. Typically, this means a new report is created on an ad hoc basis for whoever asks for it.

Level 3 - There is a lot of operational reporting, in systems and produced by central teams. It is not always easy for people to find what they need.

Level 4 - Our teams can access standard reports that deliver the information needed to complete our processes. Where information is missing, we know who to contact to ask for a new report.

Level 5 - We actively consider the impact of new processes and projects well in advance to ensure the reporting we need is available, fit for purpose and will be retired when we no longer need it.

View the statements (pdf)

Administration - latency

Level 1 - The information we see in centrally produced reporting rarely matches what we can see on our systems, so we don't really trust it to help us deliver our processes.

Level 2 - The reporting we are given does not update as often as we need it to, so it is useful for some of our work but not for all of it. We understand some of our teams struggle to relate data in reports to our systems.

Level 3 - We understand that we need to be clear what information we need to deliver our operations and how often it needs to be updated. We have not really started progressing this yet.

Level 4 - We have provided clear requirements to define what information we need for the decisions we need to make. Reports are available for our key activities.

Level 5 - We can access information updated to an agreed schedule, appropriate to the process or decision we need to complete. Our teams understand how this information relates to what we can see on our business systems.

View the statements (pdf)

Data literacy - analysis

Level 1 - Decision making is largely intuitive and not supported by data.

Level 2 - Data is used to support decisions, but the quality is poor or unknown.

Level 3 - Data is trusted to support several key decisions for daily operations and planning purposes.

Level 4 - Data is trusted, accurate, timely and available for supporting operational and strategic decisions.

Level 5 - Data is presented in customisable, analytical output and supports us in sophisticated analysis.

View the statements (pdf)

Data literacy - capability

Level 1 - We have very little visibility of individual skills and confidence in data work and interpretation and we don't really think about it as a priority.

Level 2 - We assume that managers can use data and although some can, there are definitely areas where this is not the case. We aren't that clear how to address this.

Level 3 - We are actively looking at job specifications to ensure our expectations are clear. We are also starting to ensure decision making responsibilities are clearer to help our teams understand where data may add value.

Level 4 - We are creating a skills development framework to align our people, the data we have, and decision-making responsibilities.

Level 5 - We view data capability as a core skill for most of our people. Everyone understands the data expectations in their job and has a development plan in place to improve where this is needed.

View the statements (pdf)

Data literacy - communication

Level 1 - Our teams do not tend to think about how data can support them in making decisions.

Level 2 - Our people know that they should use data in their roles, but many are unconfident or even fearful about doing this.

Level 3 - Our teams talk about data and reporting a great deal, and often ask for more information. Our focus needs to be on understanding materiality, so that lack of data does not hold us back.

Level 4 - Our people are mostly confident in analysing the information relevant to a process or decision. Data informs how they think, but they can make good decisions without it.

Level 5 - Our organisation is data enabled. We are aware of the benefits and limitations of our data, and people communicate with confidence. Data is embraced as part of the fabric of how we work and how we innovate.

View the statements (pdf)

Identifying improvements - baseline

Level 1 - We struggle to find out basic information like "How many students have we had for the last five years".

Level 2 - We can find out what we need, if we know the right person to ask - but it's not unusual for the numbers we receive to contradict other information we have used in the past.

Level 3 - We can access a basic level of trend information for our key areas of activity but many datasets remain inconsistent.

Level 4 - We can get hold of most information we need - sometimes we have to ask someone and there are still occasions that numbers can be challenged.

Level 5 - We can access a core level of trend information for all our major areas of activity that is trusted and utilised across the organisation.

View the statements (pdf)

Identifying improvements - benchmarking

Level 1 - Benchmarking feels like something that is done to us - via league tables and statutory bodies. We always feel like we are on the back foot.

Level 2 - We are starting to think more about how we can use benchmarking information in understanding how we can improve, but we have to ask someone to provide it for us.

Level 3 - We can access external data for our major areas of activity. The datasets can feel very lagged but they do give us a sense of how we compare to the sector.

Level 4 - Our core reporting includes impact dashboards, showing likely metric scores for key benchmarked comparators from the data we submit. Our teams use these to consider improvements we can make.

Level 5 - We have agreed comparator groups tailored to our different business areas. We know where we rank against these in internal and external metrics and use these to inform our strategy and priorities.

View the statements (pdf)

Identifying improvements - causality

Level 1 - We struggle to understand our baseline position, far less get a sense of how different types of cohorts or activity vary from that.

Level 2 - If we want to understand what we should be doing better, we usually have to ask someone because the reports we have access to are difficult to work with and do not enable the comparisons we need.

Level 3 - Our core reporting includes many of the attributes we want to understand better. It is still hard to tell what we should do next, though.

Level 4 - The core reporting we can access provides clear baselines. Priority groupings are filterable so that we can understand variances and target our activities.

Level 5 - We can ask specialists to use statistical techniques to interrogate datasets to determine causality between factors - this can help us get a much more nuanced understanding of what we should be doing better.

View the statements (pdf)

Informing policy - innovation

Level 1 - We are mostly focused on our own operations and do not really consider how other organisations utilise data in their decision making.

Level 2 - We attend sector events and we are constantly bombarded with best practice examples but we haven't really got a clear sense of what we should do.

Level 3 - We know we want to be data enabled. We know we need foundational work to achieve this and that we need to define what data will bring to our organisation.

Level 4 - We can point to best practice examples of analysis that has made a difference to how we think and what we do. We are not yet sure how to make this happen more often.

Level 5 - We aspire to be market leading in how we use data. We encourage our people and our specialists to innovate in how they think, and the tools they use. We all agree this approach will benefit individuals and the organisation.

View the statements (pdf)

Informing policy - market differentiation

Level 1 - When we consider our strategic direction, we don't really focus on the sector, and we cannot say that we use data to inform our priorities.

Level 2 - Our strategy sets out our plans for each of our priority areas. We are trying to create an operating plan to deliver the strategy but it is challenging to understand what our activities should be.

Level 3 - We recognise there are finite resources and customers in the market, and we should define what we believe our share of this should be. We are conscious that we could be better informed.

Level 4 - We use benchmarking information to identify our strengths and opportunities. We understand our market share and relative quality, and have identified where we believe we can improve.

Level 5 - We consider the future - population and volume growth - and diversifying markets in our strategic thinking. We can access or request information which informs our priorities.

View the statements (pdf)

Informing policy - optimisation

Level 1 - We are focused on our customers - students and external bodies. There always seems to be a new priority and we never seem to have enough people.

Level 2 - We are starting to use data to consider which areas need more investment, but it's hard to get what we need. When we do get information, it's not always trusted.

Level 3 - We understand the performance of each of our areas but we tend to have a one size fits all approach. We want to use data to understand our different markets better.

Level 4 - We understand the relative contribution of our subjects and departments and their role in our overall strategy. We consider both qualitative and quantitative information in our assessment.

Level 5 - Our areas have clearly defined roles within our operating plan. We assess performance against targets suitable for each market and focus on organisational strengths rather than intra subject comparators.

View the statements (pdf)

Measuring change - benefits realisation

Level 1 - When we undertake projects, we don't tend to think about using data to support them.

Level 2 - We know data might be useful when we undertake change activity, but we don't really know who to ask for help - everyone is really busy.

Level 3 - We ensure a data or reporting specialist is part of our project teams, to ensure we can access baseline and impact information if we need it.

Level 4 - Our benefits realisation plan includes measurable impacts. We have dedicated resource to ensure we can monitor these, though it can sometimes be hard to determine what has driven the change we are measuring.

Level 5 - Our change activity is driven by our strategy. This means we already understand our baselines, so our focus is on monitoring the impact of our development activity.

View the statements (pdf)

Measuring change - performance indicators

Level 1 - We don't really have PIs - our KPIs cover all our areas of measurable activity.

Level 2 - Managers have agreed metrics for their areas and can access data on these when they need it. This is managed locally.

Level 3 - We are trying to align the collection and management of PI data in our area with reporting in the organisation so that it is consistent.

Level 4 - Our core reporting offer includes PI dashboards for each of our business areas so they all have access to a consistent level of information.

Level 5 - Our business areas have agreed PIs based on the operating plan. Where an area is an organisational priority, we monitor our PIs to help inform progress in the linked KPI.

View the statements (pdf)

Measuring change - key performance indicators

Level 1 - We have a series of KPIs which someone reports on. It's not clear what actions they drive, and there seem to be lots of them.

Level 2 - We have an agreed list of KPIs that are monitored by senior teams. The production of the reporting is generally labour intensive and only updated on request.

Level 3 - We have an automated KPI dashboard produced by a named team or individual. It is consistent with other reporting, updated in a timely fashion and accessible across the organisation.

Level 4 - We have reduced our KPI list to focus on the priorities for that strategic period. Automated PI dashboards monitor other areas of activity.

Level 5 - Our KPI reporting includes drill through to linked PIs, metrics, trend and transactional activity, to ensure our senior teams can monitor how we are progressing towards meeting our targets.

View the statements (pdf)

Statutory obligations - FOIs

Level 1 - When we receive a freedom of information request, it's difficult to find anyone who has the time or capability to respond to it.

Level 2 - A small group of people tend to respond to FOI requests. If one is received, it can derail their other work for several days which they try to get the data together to respond to it.

Level 3 - We recognise that it is crucial for our data to be accessible to those dealing with FOI requests so they can respond efficiently and effectively. We are actively considering how to manage this better.

Level 4 - We are building effective processes to deliver FOI requests but we can still feel responsive rather than proactive because we are not always confident making the decision to decline a request.

Level 5 - Managing FOI requests is part of our operating procedures. It is clear who is responsible for data and communications activity and we are comfortable rejecting requests. This is covered within our governance frameworks.

View the statements (pdf)

Statutory obligations - PSRBs

Level 1 - Professional and Regulatory body returns are dealt with by individual areas and there is no oversight or central support for this activity.

Level 2 - PSRBs are delivered by a central function but we struggle to get hold of the specialist subject or department information that is needed.

Level 3 - We have agreed requirements for PSRB obligations but we are trying to decide how they should be delivered between a reporting team and the department or subject area.

Level 4 - Our core reporting includes products designed to support PSRB delivery. These are consistent with our other reporting and where definitions vary, the subject area and central team have agreed how this should be managed.

Level 5 - We know exactly what PSRB obligations we have and in what format. We proactively manage our relationships with our funders and accreditors to ensure we can manage changes to specifications.

View the statements (pdf)

Statutory obligations - statutory returns

Level 1 - Our major statutory returns are incredibly resource intensive to deliver and we are totally dependent on a small number of key individuals for their completion.

Level 2 - We are trying to bolster support for individuals, but it is hard to tell if poor processes or data quality is the bigger problem. There is a lot of manual fixing.

Level 3 - We have developed processes to create the data we need for our returns. We can still struggle with interpreting guidance and managing the quality of the data we need.

Level 4 - We are investing in our teams to ensure we understand our systems, processes and governance. This can still be challenging where nuances in data specifications are not understood, particularly when these change.

Level 5 - Our organisation prioritises its statutory obligations. Our governance processes ensure guidance is interpreted appropriately for our environment, our teams understand definitions and usage, and change is managed.

View the statements (pdf)

Approaches

You can approach your maturity journey in different ways. The scope could include the entire data maturity landscape, or focus on one of the five elements, one theme or an individual issue. Resourcing is likely to be challenging and can be approached in multiple ways, some of which may be more effective than others:

OptionsAdvantagesDisadvantages
Project - Initiating a formal project with a defined objective and budget.
  • Dedicated resource
  • Speed
  • Costly
  • Slow to launch
Enhanced BAU - Delivering with current resources alongside business as usual.
  • Quick to launch
  • Embeds into BAU
  • Slow to deliver
  • Overworking team
Opportunities - Tackling specific issues when the opportunity arises
  • Quick to launch
  • Agile
  • May never be the priority
  • Overworking team
Defer/review - No current resource or capacity; review in 6 months/1 year
  • May be realistic
  • May never happen

Even without a formal project in place, it might be helpful to maintain an overarching view of activity to ensure they remain aligned with university or college vision, for example:

Term A Term B Term C Term D Term E Term F 
StrategyEnhanced BAU Enhanced BAU 
Governance  Enhanced BAU Enhanced BAU 
Systems   Project Project Project 
Reporting    Project Enhanced BAU Enhanced BAU 
Decision making Opportunities Opportunities Enhanced BAU Enhanced BAU 

Roles and skills

For improvement activities to be robust, a thorough understanding of the as is environment is essential.

Next section: roles and skills