Investing in Business Intelligence

There are many areas of the university already using Tableau to visualise data; many people have been trained to build Tableau visualisations and receive support from CIS as they develop their ideas.  The use of Tableau continues to grow organically.

The need for data visualisation cuts across many different initiatives of Digital Lancaster

Investing in Business Intelligence means investing in systems that let us:

  • Understand how things are now.  Whether that means how our finances are, how many students we have, how our research income looks, we want to know where we stand.  And data visualisation can be much easier to understand than tables of numbers.
  • Understand how data relate to each other.  Perhaps we need to combine data from LUSI and Agresso, so we can understand which PhD students in our department have and haven’t paid their fees.  Or perhaps we want to relate data in Pure to data in Agresso to understand the research income from each department.  But unless we relate data from one system to that in another, we won’t get a complete picture.
  • Understand how data is changing over time.  Sometimes what we really want to know is how where we are now, compared to where we were this time last year.  It can be hard wind back the clock to have create that view.  It can be much easier to take a snapshot of the data periodically, and then compare those snapshots over time.

Most of the visualisations being created at the moment fall into the first category.  And such visualisations are by far the easiest to create.  No snapshots are required, nor do we have to marry up data from separate systems.  There is plenty of value in such systems, and that’s the feedback we’re getting from the people creating and using them.

However, there are also needs which may only be filled if we relate data from separate systems (or silos) of data; and still other needs which can only be filled when we can take a longitudinal view of the data.

BI quadrants

As we determine which BI projects to take on, it will be critical to understand what we’re trying to achieve, and the size of the investment which will be required to meet that need.  If we limit ourselves to the easy projects in the lower left quadrant of the diagram, we can deliver lots of incremental value, but may miss out on understanding either how data relate to each other or how data is changing over time.

On the other hand, if we focus only on projects that require snapshots of integrated data, we need to be aware of the sizeable investment in time that will be required to be successful.

What will be key is to develop a balanced portfolio of projects that identifies the quick wins in the lower left quadrant and lets us reflect on the opportunity cost of the larger projects–finding a balance.

If you’re interesting in seeing how Tableau is being used right now, take a look here:

Undergraduate Admissions Reports (these views required snapshots of data from LUSI to show how undergraduate admissions progresses compared with previous years).

Current Research Projects (unfortunately, this will be blank unless you are a principle investigator)

Research Grant Income (a scatter chart comparing various universities)

Thinking about Careers (showing how mature people’s thinking is about their careers)

These visualisations just scratch the surface of what we could do with data visualisation.  As next steps we should:

  • Think about how best to catalog visualisations as they become available (to help foster and maximize the benefit of continued organic growth of data visualisation)
  • Determine what (if anything) we need with respect to a policy about who should be able to see what
  • Brainstorm, with a wide group of stakeholders:
    • What visualisations they want
    • How they’d benefit from those visualisations
    • How those visualisations might change our business processes
    • The relative size of the investments required to deliver those visualisations
  • Build a high level plan for the delivery of those visualisations (in descending priority order) and the related changes to business processes
  • Determine what resource needs there are (if any) to deliver those benefits at an acceptable rate

Digital Services – A Common Interface

The Digital Services initiative commits us to: “Work towards providing our services through a common interface whereby staff and students do not need to understand our organisational structure”

The staff intranet was built to meet a need identified by the Vice-Chancellor to have a tool for internal communications across university staff.  The resulting collaboration between Communications and Marketing and ISS has delivered the staff intranet which was launched earlier this year.

The staff intranet combines a home page which delivers on the Vice Chancellor’s desire for a twenty-first century communications tool for the university with pages that meet the need of a broad group of staff stakeholders.  We engaged with those stakeholders through multiple means: various in-person events, questionnaires, and emails inviting responses.  We showed them mock-ups and early versions and worked to respond to their feedback.

The resultant staff intranet acts as a nexus for information pertinent to staff as well as the online services that staff use on a frequent basis:

  • Room Bookings
  • Travel Requests
  • Purchase Requests
  • Expenses
  • Timetable
  • Library

There are also links to separate staff services like the new CoreHR system, MyAccount for managing IT accounts and many other services.

Perhaps most importantly, there is an integrated search facility allowing staff to simultaneously search the intranet, the university web site, staff directory, library, events and staff noticeboard.  We can adjust the search results to ensure that the most relevant and up-to-date results are presented first.

So as staff use the intranet more we can tailor it to deliver the search results, representing access to the services that are most important to them.  We are very proud of the new level of collaboration that was at the heart of this project, but this continued collaboration through the use of the intranet itself will help ensure that it remains relevant and useful to all of us.

The student portal and iLancaster are key tools for students to access university services, and we are eager now to deliver the same kind of news, events and notifications services to students that the intranet delivers to staff.

Digital Services – An Agile Approach

The Digital Services initiative commits us to: “Develop an improved service design and delivery approach based on agile processes and using multi-disciplinary teams, embracing the principle of co-production.”

As part of the Digital Services initiative, we have been developing a new Undergraduate Admission System in partnership with the Undergraduate Admissions team.  As the university begins the admissions process for undergraduates joining in October 2016, the new system will be going live–replacing paper application forms.

The Undergraduate Admissions system is an early example of what we mean by taking an agile approach using multi-disciplinary teams.  What has that actually meant in practice for the UG project?

  • A member of the Undergraduate Admissions team (dubbed the Product Owner in agile terminology) was seconded to the project for its duration, and attends daily meetings of the development team.
  • The prioritisation of work is the responsibility of the Product Owner, not the development team.
  • Although we are only removing paper application forms from the system now, lots of functionality in the system is already in use.  And ‘going live’ does not mark the end of the project.
  • We can respond to feedback and make changes when the software isn’t quite right.

The Product Owner.  Having an admissions professional working so closely with us on a daily basis helps us understand and stay current with the needs of the team; it also helps the Product Owner understand the pressures on the development team and how easy–or hard–certain tasks are to complete.  We are never more than one day away from a constructive conversation about the issues that we all faced, and we feel like we’re facing problems together.

Prioritization. Asking the Product Owner to prioritise work means that we can be sure that the Admissions team gets the things they need in the order in which they need them.  This ‘just in time’ approach ensures that we never write software that might not get used–because we’re always focusing on the most important task that is not yet complete.

Incremental Launch. Instead of waiting until everything was ready before any part of the system ‘went live’, we offered as much of the system as we could to the Admissions team for use during the current admissions cycle.  Even though changing systems in the middle of an admissions cycle is difficult, there was enough value in the partially completed new system that it was worth using in the latter part of the current cycle.  That helped build confidence in all of us that the new system was headed in the right direction.

Responding to Feedback. Because we aren’t stopping development immediately after we go live, the Product Owner can decide how best to prioritise further development.  It may be that making a change to the live system is more important than developing a particular piece of new functionality–and they can reflect that in their prioritisation.  The Admissions team need not feel like their on their own when the system goes live.

There are plenty of lessons for us to learn which will help us make co-production teams even more effective in the future, but we’ve already learnt that working in close partnership with our ‘co-producers’ helps ensure we deliver appropriate and effective systems and services.

We’re all eager to see how the new system works in the coming admissions cycle.