Finding the Right One: Mobile Technology in Higher Education

min read

Key Takeaways

  • Given students' close connections with their mobile apps, finding the right app involves a search process rather like finding the right person for a rewarding relationship.
  • A team at Lancaster University embarked on a quest to find the most appropriate mobile technology for the institution's mobile needs and the right company with which to form a productive long-term partnership.
  • The outcome of the university and supplier's successful partnership, the iLancaster mobile app, has gained a strong reputation in the British higher education sector.

At a Lancaster University management meeting early in 2011, senior leaders realized that Lancaster had a negligible presence on mobile devices and that the rapidly increasing number of smartphones on campus could not be used to access university services. To make matters worse, a nearby university had just hit the national press with its innovative mobile app. The message was clear — Lancaster needed a mobile presence, quickly. With a mandate from that management meeting, the IT department set a target of delivering a live mobile app, linked to a number of services, by summer 2011. While this gave us only a few months, it did provide a clear mandate and released the necessary funding.

Why Senior Leaders Support the Mobile Project

In the accompanying podcast (18:45 minutes), Pro-Vice-Chancellor for Colleges and the Student Experience Mandy Chetwynd, Head of Strategy and Communications Rachel Fligelstone, and Dean of Undergraduate Studies Gavin Brown discuss the strategic drivers behind the university's mobile presence, how the original project was managed, and the compact steering group that guides the evolution of the live app.

You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialize correctly.

Listen now
Running Time: 18:45 minutes

Just Looking: Understanding the Market

A central challenge in implementing technology is to identify and evaluate all the available options in order to select the right one. The project team surveyed a wide range of mobile products, from high-maintenance "write it yourself" options (which give fantastic flexibility but incur high development costs) to free "out of the box" options (which can be implemented in an afternoon but offer limited flexibility). The key to selecting the right option lies in a combination of requirements elicitation and the capabilities of the project team. Based on our experiences, the important questions to ask at the beginning are:

  • What shape is your IT service in? Developing open-source solutions or a range of native apps for multiple platforms requires dedicated developers with specific skills, especially for the frameworks used by device vendors. The team needs a strong development focus and people with the right skill sets. If you are a seasoned manager of supplier contracts, an outsourced approach might be appropriate.
  • What shape is your data in? Key to delivering a successful mobile app is representing existing data in a mobile-accessible form. If your corporate systems already expose data using technologies such as web services, RSS feeds, or APIs, this will be much easier.
  • How fast do you need it? Mobile projects tend to be rapid and agile, readily adaptable to changing user demands. If you need to get up and running quickly, consultancy support or a platform with out-of-the-box features might be attractive options.
  • How much unique innovation do you want? If you're looking to provide something that no other institution offers, developing your own apps might be the only option. However, hybrid options let you use a framework with standard connectors to common systems, with a development kit to write your own apps or features.
  • How much money do you have? Funding is always a key factor. You should think about initial and recurring costs, on-going licensing, and the internal human resources needed to support and maintain your chosen solution.

First Dates: Meeting and Learning More

Even the least promising of first dates can provide good learning experiences, so we went out, surveyed the marketplace, and identified the principal options. By this point we had formed, within the IT department, a small, agile project management team, and identified a group of mobile-skilled staff who could work with whichever technology we selected.

From the available options we short-listed three products — Mobile Oxford, Blackboard Mobile Central, and campusM — that happened to represent the three main types of mobile application (see box). At Lancaster we needed something we could deploy quickly to meet our ambitious timelines, but that would allow us to innovate in the future. What developer skills we had in-house were stretched, making it difficult to justify building apps from scratch.

Types of Mobile Application

Open Source: This approach allows you to build your own application on a free framework (for example, the open-source Molly, as used by Mobile Oxford).

Web Only: These use web pages that can access some features (such as GPS) of native devices.

Hybrid Approaches: These provide a core framework that works with a range of mobile devices, sometimes with bundled hook-ups to existing services, while also opening up the option of your own customizations on the framework (for example, campusM).

Existing Vendor with Mobile Capability: Larger learning-based systems often include a mobile component. Many LMS providers fall into this category (e.g. Blackboard Mobile Central).

We analyzed the three options as follows:

  • Mobile Oxford: This open-source web-based framework offered a great deal of flexibility and a full range of device compatibility. However, initial deployment would take longer, there would be higher development costs, and adopting a web-based model might preclude future hardware (such as near-field communication or cameras) on mobile devices.
  • Blackboard Mobile Central: This product had a high upfront cost and a charging model which, at the time, would have incurred costs for each additional application to the main product. Much of the product was based around the Blackboard LMS, which Lancaster University did not use, and there was little flexibility to develop in-house applications using the underlying framework.
  • campusM Students: This product, developed by oMbiel, offered a quick initial deployment (within a few weeks), and integration with existing systems and services came as part of the standard package. The flexible framework also would allow in-house developments in the future.

After evaluating the three candidates, we reasoned that campusM Students was the most attractive option for our needs.

Making a Commitment: Getting the App Out

Having made the decision and initiated a relationship with the campusM team, we embarked on a project that we managed using Prince 2, a project management methodology in longstanding use across the UK public sector. We used a three-person project team skilled in project management, web programming, copywriting, stakeholder management, and communications. We set up a project advisory board, chaired by the dean of Undergraduate Studies, who accepted the role of project executive. Lancaster's head of Service Delivery took on the role of senior user, and a project manager and lead developer assumed the role of senior supplier. Critical to success in this phase were the agreement of the project mandate and brief, a close relationship between the project manager and the suppliers, and a clear communications plan. As in any Prince2-managed project, keeping documentation up to date was crucial as the project progressed, as was regular reporting on progress to university management groups, notably the Business Process Advisory Group, who as well as stewarding business-critical workflows across the institution, played an important role in overseeing the finances of IT projects such as ours.

Our project goals dictated the delivery of iPhone, Android, BlackBerry, and web apps within 12 weeks.

The project team now worked tremendously hard with oMbiel to build the interfaces required to integrate systems such as timetabling and library, and to work with Lancaster's user authentication mechanism. We began by scoping all the configuration changes required to the interfaces, based on technical documentation and conversations with oMbiel, and making all required information available. A three-day site visit brought our project manager into close contact with the campusM team, allowing us to complete and test the interfaces as well as training our administrative staff in the use of the back-end systems that support the app. At the end of this phase we had a test version of the app and started ironing out integration issues and bugs.

A much trickier hurdle was how to manage the relationships with our "extended family" of stakeholders across the university. Areas requiring particular negotiation included:

  • Creating the Pocket Guide. These static pages provide core information about campus life, linking to locations and external websites where appropriate. Content editors identified information from a number of web pages and sites, synthesized and updated it, and also customized it for a mobile context. We had processes in place to check and approve the content with more than 50 stakeholders.
  • Engagement with the student community. We ran a number of student focus groups (with free lunch included) where we presented icon sets, designs, Pocket Guide content, and other ideas. We elicited their views and asked them to rank our developments and ideas. After a period of change and redesign, we ran further focus groups to validate that the app aligned with student needs.
  • Rebranding of icons and banners. Rebranding required central approval. With hindsight, earlier coordination with the university's Marketing department would have been valuable.

The app, called iLancaster, was soft-launched at beta stage to iOS and Android devices. We relied on word of mouth by the focus group students to gradually increase the number of test users. Once we felt confident about the technology behind iLancaster and the features within it, the app was promoted in key student (and staff) publications and publicized on digital screens. It is worth noting, however, that word of mouth was the main source of promotion at this stage.

As promised to our stakeholders, we had delivered the app (figure 1) within the agreed project time and budget.

Figure 1. The iLancaster mobile app, available at

Getting to Know Them: Users and Suppliers

It's only when things begin to settle down into a routine that you can really start to develop a deep understanding of both your supplier and your users.

Following the initial launch of iLancaster we started to think about how we could develop our own features, with the twin objectives of benefitting our users and differentiating ourselves from other universities using the same framework. We reconvened our focus groups, with the same participants, to review the latest developments on the app and consulted user feedback data. Through these mechanisms we discovered that bus timetables (giving users arrival times at bus stops across the region) was our most requested feature. We wanted to deploy this capability quickly, as well as learn how to use the application framework ourselves. With this in mind we created functional documentation including wireframes and screenshots of the user interface and asked oMbiel to develop the app while allowing us to follow the development process. This approach would not only deliver results quickly but also give us the experience needed to develop features by ourselves. We signed up to a public service API to provide bus timetable data for the area, and we wrote our own web service wrapper to customize the app to the needs of people on campus (figure 2). This had the added benefit of improving performance.

Figure 2. iLancaster bus timetable feature

Shortly after releasing the bus timetable, we developed our first completely in-house feature, which gave users itemized statements of their financial accounts with the university. This feature used a similar approach of designing user interface elements, then developing web services that exposed the required data. Using an agile development approach, we completed the feature and released it in just a few days.

Customizing the App

How did staff at Lancaster University customize the mobile app from the out-of-the-box functionality provided by campusM? In the accompanying podcast (14:16 minutes), author Chris Dixon, head of Service Delivery and Operations, and Brian Green, iLancaster service manager, explain their approach and highlight the customized features that have proven the most popular. They discuss in-house development resourcing and making the best use of legacy systems and data feeds.

You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialize correctly.

Listen now
Running Time: 14:16 minutes

We also realized, in response to institutional pressures, that we would need richer reporting from the app to justify the investment made in campusM and to help inform priorities for future developments. We ran a number of internal sessions with stakeholder groups to elicit their reporting and analytics requirements, and fed these into a workshop led by the campusM team and involving a number of campusM customers. We had also created wireframes and demo layouts, which we shared these with campusM staff, who gave us access to beta versions of the reporting framework. The Insight reporting tool (figure 3) is now operational at Lancaster University and across the campusM customer base, providing valuable and rich data that helps us justify investment in the app as well as prioritize future app developments.

Figure 3. The campusM Insight reporting tool

As in any relationship, there have been challenges along the way. Some developments, such as BlackBerry versions of the app and the reporting tools, took longer than expected, and there have been some bugs and niggles (as expected with IT system development). However, the key to resolving these problems, as in any healthy relationship, has been open and ongoing communication, with on-site meetings, telephone conferences, and wider cross-university collaboration on iLancaster developments.

Staff Load

How much work do staff at Lancaster University carry out now that iLancaster is live? The accompanying podcast (10:10 minutes) with author Dixon and iLancaster Administrator Andy Taylor recalls the learning curve their staff underwent with mobile technologies and the support they received from the vendor during this period. They then build a picture of the day-to-day support needed at various points of the academic calendar with a cloud-based, commercially provided mobile platform.

You are missing some Flash content that should appear here! Perhaps your browser cannot display it, or maybe it did not initialize correctly.

Listen now
Running Time: 10:10 minutes

In understanding more about your partner you come to understand more about yourself. We learned how to respond quickly and more flexibly to university events such as Campus Open Houses and Orientation Weeks, promoting them with in-app banners at relevant times. We are also well positioned to create new features rapidly; we recently authored a feature in just a few hours to help staff through a busy Campus Open House. We've also released features such as PC availability (which locates unoccupied computers on campus), laundry room availability (which interoperates with our Internet-enabled machines), and integration with the Lancaster University Sports Centre for booking and account management.

Factors that have helped us to achieve our goals include:

  • Transition of project to service: We assigned a number of service-specific roles: a service owner, a service manager, and a steering group that meets regularly to establish future direction to project team members.
  • Employing a full-time developer: Over summer 2012 we dedicated a full-time developer to the project, with the intention of retaining a part-time developer for new features.

Keeping Your Relationship Strong: Working toward Future Developments

It's useful, every now and then, to remind ourselves why the Lancaster University team chose to commit to campusM. Doing this reminded us not only of how far we have come but also of some of the goals we still want to achieve together, all of which require strong relationships with our partner and extended family of stakeholders.

Long-term happiness with our mobile app depends on:

  • Personalization: Allowing users to control which icons, functionality, and information they see and providing targeted content for specific groups will keep our stakeholders satisfied.
  • Internationalization: Lancaster University has many international partnerships and overseas campuses, so it will be important to tailor content to those regions.
  • Wider engagement for development: We see a benefit in allowing students to write their own features and deploy them in a "lab" area where users can test them before they are released, fully supported, into the main app.
  • Future mobile technology: Near-field communication, augmented reality, and QR codes are just a few of the areas of emerging technology that we need to explore. Key to this will be our relationship with oMbiel, especially in distinguishing what can be provided via the campusM framework from what we will have to innovate ourselves.

In summer 2012 we took a big step toward our personalization goal by upgrading to campusM Enterprise. With the enterprise version we can create multiple profiles for groups such as guest users, staff, and students, then target features within the app to specific user groups. Users will be able to switch functionality on and off for a more personalized experience.

Key Lessons

  1. Engage with stakeholders early and throughout the project and service.
  2. Provide feedback mechanisms. iLancaster offers user feedback mechanisms not just at an app level, but on every page of the pocket guide and at other key points. The feedback is easy for users to fill out.
  3. Prioritize, listen, and respond to feedback. We respond to all feedback and act on it with regular service meetings discussing common trends and assigning priority for developments.
  4. Use a fast, flexible, and agile project approach. The mobile market moves too fast for more traditional management approaches.
  5. Keep on top of your supplier relationship. Push them, challenge them, and seek mutual benefits. Let the supplier focus on platform and technology challenges while you focus on customization and differentiation.
  6. Be open to new ideas, and keep a can-do attitude.

Every relationship has its ups and downs; this is particularly true in the high-pressure, rapidly changing environment of mobile technology. However, if you can remember why you entered your partnership in the first place, if you can each focus on achieving your goals, and, above all, if you can continue to communicate about the good and the not so good things that happen, then you should be able to establish a relationship that will endure and flourish. Strong, productive partnerships will equip your institution and IT organization to meet the challenges the future may hold.