The Engagement Model for New eLearning Service Requests

ITaLI participates in a collaborative process with the faculties, ITS, and Library to develop eLearning service enhancement proposals for Teaching and Learning Committee review. Here is an overview of the engagement model, endorsed at the June 2013 Technology Enhanced Learning Sub Committee.

  1. Needs Collection: High level needs for service additions or enhancements are collected from a variety of sources.
  2. Needs Prioritisation by ADAs with Teaching and Learning Committee review: Twice a year the current list of high level needs is confirmed with Elearning Operational Forum members, and submitted to the Teaching and Learning Committee for review before going to AD(A)s for prioritisation. AD(A)s may elect to consult within their faculties or with each other as they see fit. The results of the prioritisation survey then return to the Teaching and Learning Committee for review before being disseminated to the full instructor community in order to solicit potential solutions.
  3. Investigation and Evaluation: Requirements for the highest priority needs are documented in greater detail talking to the stakeholders. In collaboration with Library, ITS, ITaLI and the faculties the options are identified and shortlisted for a pilot in a collaborative manner using the elearning operational forum. Experts in the ITaLI and faculties are fully utilised wherever they are willing to participate. For transparency and to encourage contributions the status of investigations are documented openly to invite scrutiny and maximise accuracy.
  4. Pilot with ADA sponsorship: Promising solutions are piloted in real classes to confirm suitability, and to confirm training and support requirements. Pilots require sponsorship by an ADA. Sometimes pilots may require funding from the Technology Enabled Learning Fund. The outcome will be a pilot report and sometimes a proposal for implementation or funding.
  5. TELC Review of Proposals: Proposals are reviewed and approved by the Technology Enabled Learning Committee. Some proposals may be funded from the new elearning services budget when its established. Some proposals may involve policy change that are escalated to higher committees. Some proposals may be achievable with existing elearning support resources. Proposals should identify potential functioning sources.
  6. Implementation: ITS, ITaLI and Library collaboratively implement the new service.

The enhancement process is optimised to address broad enterprise needs, in a timely manner, with usable services as outcomes. The faculties retain an ability to have ITS make small system modifications that are possible within the resources available in the elearning SLA, or pay for modifications they need for their faculty alone.

Requirements Sources

Before faculties are asked to prioritise work, ideas and requests are collected from a wide variety of sources in order to achieve a reasonably complete list. Sources include:

  • Enterprise needs (Collected from the University strategic plan, the elearning strategy, PVC(T&L, DVC(A), ELOF, ITALI etc.)
  • Faculty needs (Collected from the ADA, TEL meetings, elearning operation forum members, or individual instructors)
  • eLearning Strategy Committee – 5/year
  • School needs (HOS meets, HOS survey, 30+ School T&L meeting attendances/year)
  • Through helpdesk 40 interactions/day
  • Feedback at staff training (1100/year)
  • Staff satisfaction and needs surveys on TLS support – each year
  • Direct submission from individual instructors
  • Student surveys – e.g. Deliotte’s Student Experience Report 2010, ITS 2012; SOM 2010; TEDI 2009, Niche Consultants 2009
  • Inter University benchmarks and meetings
  • Conferences

Pedagogical Guidance

The eLearning Systems and Support team includes qualified teachers and all technical staff receive training in pedagogy to give context to their work. The eLearning team also seeks pedagogical guidance from experts in ITaLI, the schools and faculties. ITaLI is focused on technology that supports real learning as reported by J. Hattie for instance.

Making Submissions

For submissions made to ITaLI the following considerations will be taken into account.

  • Pedagogical and administrative benefits, UQ wide.
  • Priority against other initiatives. With limited resourcing submissions need to be prioritised against the broader requirements and opportunities for all faculties. Broad requirements include strategic goals, but also solving broad problems or taking advantage of broadly applicable opportunities.
  • A full and valid market scan should be included, else one will have to be conducted as a matter of due diligence. The market scan should consider whether its likely an existing vendor will provide the solution as part of their development roadmap. Sometimes robust and sustainable off the shelf options can be better than a local bespoke solution. Depending on the cost, central procurement may require a tender process.
  • Early prototypes may need to be rewritten to make them robust and secure. Deploying unreliable software, or systems that are difficult to use, will cripple support teams which are critical for the delivery of our core fee earning courses. 
  • Necessary service desk resourcing should be estimated and put in place before any deployments to avoid disruption to delivery of of core business..
  • Bespoke tools need to show where they have consulted and considered the needs of all faculties, else another requirements cycle may be required before the rewrite.
  • Where a licence is involved, full licence and support costs will need to be considered, and costs based on expected take-up levels.
  • Tools need to pass an ITS technology audit. They should be  secure, include single sign on, be scalable, have redundant systems, have a support contract, comes with training, user guides etc. Considerations include: data confidentiality, availability, agility (functionality extension), scalability (#users),  supportability, dependencies, authentication, upgradeability, traffic impacts, backup/archiving, alternatives, accessibility considerations, system and user interfaces, level of testing,  management requirements,  client side compatibility, auditability, jurisdiction, reputation risk etc.
  • Tools need to be UQ policy compliant. Some tools have been found to be selling student data. UQ has polices for retention of assessment material, availability of material or a minimum of 12 months after completion of course, copyright compliance etc. 
  • Development and maintenance of code should not dependant on:
    • project funds (as has been the case it the past); 
    • a risky vendor/start-up. 
    • a single UQ resource, that has not cross trained a backup.
  • Sometimes discipline specific tools may be better supported within the disciplines where there is more expertise and where costs be better justified or not. 

Locally Funded Initiatives

If Schools and faculties have their own funding they can elect to engage with ITS on a fee for service basis. The ITS Software Services team can write and support bespoke systems, and the Enterprise Support division offers hosting services for externally authored systems.

Solutions

Solutions may require: a) funding (acquisition costs), b) policy approval (ESC), and c) support (who/cost?). In a federated environment funding and policy will be provided at multiple different levels as follows:

  1. Local solutions: For solutions to local-only problems. These require faculty or school funding.
  2. UQ-wide solutions are funded as follows:
    1. Automatic upgrades to existing systems – e.g. Turnitin release audio annotations. Already funded through DVC(A) budget to ITS
    2. Small modifications to existing systems (e.g. Si-Net integration, external user tool etc): Covered within TLS capability at  TLS discretion with external input. Note this is very limited and work is strictly prioritised according to how wide the impact is.
    3. Additional enterprise wide applications: Methodical evaluation processes lead to submissions to the UQ Technology Enabled Learning Fund. Proposals are strictly driven by enterprise wide needs and priorities collected from multiple sources above. Evaluations cannot be done by local experts alone as the process requires awareness of enterprise wide requirements, and expertise in acquiring and running enterprise wide systems in a sustainable way.