Overview
Dashboard projects fail more often from unclear definitions than from technology. If the registrar counts students on census day and the finance office counts fee-paying enrollments, two dashboards will disagree and neither will be trusted. We therefore begin with an indicator dictionary: each metric's definition, formula, data source, refresh frequency and owner, agreed by the people who will use it.
The build follows standard business intelligence practice: a data model that joins student records, course and assessment data, surveys and staff data through shared keys; calculated measures documented in the dictionary; and report pages designed around specific users' decisions. We work in Power BI or Tableau, using your existing licenses and data platform.
Institutional data are sensitive. Dashboards use aggregated data with minimum cell sizes, row-level security so a program leader sees only their programs, and access reviewed by your data protection lead. We hand over the model, documentation and a governance plan so your team can maintain it.
Who it’s for and the problems it solves
This is for you if you are…
- Institutional research and planning offices
- Quality assurance units preparing accreditation or annual monitoring data
- Rectors, presidents and deans who want a regular performance view
- Program leaders who need progression and assessment data for their programs
- Ministries and agencies building sector dashboards
Common problems we help with
- Different offices report different numbers for the same indicator
- Data requests take weeks because every report is built by hand in spreadsheets
- Accreditation data tables are rebuilt from scratch each cycle
- Program leaders have no access to their own progression data
- An earlier dashboard exists but nobody trusts or maintains it
What’s included — and what isn’t
Included
- User needs interviews: who decides what, and which indicators support those decisions
- Indicator dictionary with definitions, formulas, sources, refresh schedule and data owners
- Data audit: availability, quality issues, keys and history in source systems (student information system, LMS, survey tools, HR)
- Data model design and transformation (Power Query, SQL or your existing data warehouse)
- Dashboard build in Power BI or Tableau: enrollment, retention and progression, completion and time to degree, grade distributions, assessment of learning outcomes, survey results, staffing ratios
- Cohort and trend views with filters by faculty, program, campus, mode and student characteristics where appropriate
- Row-level security, minimum cell-size suppression and accessibility checks (color contrast, text alternatives)
- Testing and reconciliation against official figures
- Training for users and a technical handover for maintainers
Not included
- Administering your student information system or data warehouse infrastructure
- Purchasing or managing software licenses
- Identifying or profiling individual students outside a lawful, approved purpose
- Predictive risk models for individual students unless governance, ethics and transparency requirements are agreed first
What you receive
- Indicator dictionary
- A living document defining every metric, with owners and agreed business rules.
- Data model and transformations
- Documented Power BI dataset or Tableau data sources with transformation steps and SQL where used.
- Dashboards
- Published reports for each user group, tested and reconciled with official figures.
- Governance plan
- Roles, access rules, refresh schedules, change control and a data quality issue log.
- Training and handover
- User guide, short training sessions and a technical walkthrough for your maintainers.
How it works
Discovery
Interview users, inventory data sources and agree the first set of priority questions.
Define
Draft the indicator dictionary and resolve definitional differences with data owners.
Prototype
Build a first dashboard with a subset of data for user feedback before full development.
Build and test
Complete the data model and reports, apply security, and reconcile numbers with official returns.
Launch and govern
Train users, hand over documentation and set up the governance and change-request process.
Tools and practices
- Power BI
- Power Query transformations, a star-schema semantic model, DAX measures, row-level security and scheduled refresh through your service.
- Tableau
- Published data sources, calculated fields, user filters for security and dashboards on Tableau Server or Cloud.
- SQL and data preparation
- Views or staging tables in your database or warehouse, and Python or R for complex cleaning when needed.
- Cohort analysis
- Following entry cohorts through progression and completion to avoid misleading snapshot rates.
- Data governance
- Data owners and stewards, definitions, access control, audit of changes and data quality monitoring.
- Dashboard design
- Clear hierarchy, consistent colors, labeled axes and annotations that explain what changed and why.
Start with questions, not charts
Each dashboard page should answer a question someone actually asks: 'Which first-year courses have the highest non-completion?', 'Are part-time students progressing at the same rate?' We design pages around these questions and leave out indicators nobody will use, because every extra chart adds maintenance and confusion.
Common indicator pitfalls
Several higher education metrics are easy to calculate wrongly. We document business rules so everyone calculates them the same way.
- Retention: from which census point to which, and how are transfers and deferrals treated?
- Completion: within normal duration or an extended period (for example 150% of program length)?
- Pass rates: of those who enrolled, attempted the assessment or completed the course?
- Student–staff ratios: headcount or full-time equivalent, and which staff are included?
Responsible use of student data
Dashboards should improve decisions without exposing individuals or labeling students unfairly. We apply suppression rules for small groups, restrict access to identifiable data, and advise caution about predictive 'at-risk' flags, which require transparency, bias checks and a clear support pathway before use.
What the work can look like
Illustrative example — fictional data
Illustrative excerpt: indicator dictionary entry
A fictional university defining first-year retention for its leadership dashboard. Rules are an invented example of the format.
Definition
Proportion of first-time, full-time bachelor's entrants enrolled on the fall census date who are enrolled at the institution on the following fall census date or have completed their award.
Business rules
Internal program transfers count as retained. Approved deferrals are excluded from the denominator. Deaths and compulsory withdrawals are excluded. Source: student information system census snapshot table.
Owner and refresh
Owner: Registrar. Refresh: annually after fall census. Minimum reporting group size: 10 students.
Illustrative example; definitions must follow your regulations and any national reporting rules.
What you’ll need to provide
- Access to data extracts or a secure environment with your source systems
- Power BI or Tableau licenses and workspace or server access
- Data owners from registry, IT, QA and HR for definitional decisions
- Data protection guidance and approval for the data used
- Named business owner for the dashboard after launch
You don’t need everything ready to ask for a quote — tell us what you have and we’ll say what’s missing.
What affects price and turnaround
Price depends on
- Number of data sources and their quality
- Number of dashboards and user groups
- Complexity of security and access rules
- Whether a data warehouse exists or data must be prepared from extracts
- Training and ongoing support requirements
Turnaround depends on
- Time to obtain data access and approvals
- Speed of resolving definitional disagreements between offices
- Data quality issues discovered during the audit
Every project is quoted individually. How we price our work.
Questions people ask before starting
Power BI or Tableau?
Usually whichever your institution already licenses and supports. Both handle institutional dashboards well. We can outline differences in licensing, sharing and administration if you are choosing.
Do you need access to student records?
We need data at the level required to build the model, ideally in a secure environment you control, with direct identifiers removed or pseudonymized. Access is set up under your data protection rules and a data processing agreement where required.
Can the dashboard produce our accreditation tables?
Often yes. Once definitions match the accreditor's requirements, dashboard views or exports can supply many recurring tables, which saves time in each cycle.
Who maintains it after launch?
Your team. We hand over documentation, train maintainers and set up governance. Optional support periods can be agreed for changes and troubleshooting.
Can you build predictive models for student risk?
We can discuss it, but we recommend it only with clear governance: a defined support intervention, bias and accuracy checks, transparency to students and approval under your ethics and data protection processes.