View Current

New Learning Technologies Approval Policy

This is the current version of this document. You can provide feedback on this policy to the document author - refer to the Status and Details on the document's navigation bar.

Section 1 - Purpose

(1) This Policy is intended to clearly outline the steps required in consideration of needs regarding learning technologies at Charles Sturt University (the University) so that an efficient and well understood process can be used repeatedly as needed.

(2) The purpose of this Policy is to provide adequate support to teaching staff when reviewing their needs for learning technologies.

Scope

(3) This Policy applies to all permanent and contractual teaching staff.

(4) This Policy applies to the Enterprise, Targeted, Recommended and Experimental Technology classifications, while the use of external technologies is informed by the External Educational Technologies for Learning and Teaching Policy.

(5) The Learning Technologies Unit in the Division of Student Learning and the Enterprise Architecture Unit in the Division of Information Technology can guide teaching staff through any complexities in this policy.

(6) This Policy was developed under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 Australia Licence. Under this licence you are free to copy, distribute, display and perform the work and to make derivative works, in accordance with the following:

  1. Attribution - you must attribute the work to the original authors and include the following statement "Support for the original work was provided by Charles Sturt University".
  2. Non-commercial - you may not use this work for commercial purposes.
  3. Share Alike - if you alter, transform, or build on this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work.

(7) Conditions as specified under clause 6 may be waived if you get permission from the copyright holder.

(8) Requests and inquiries concerning these rights should be through the University website.

Top of Page

Section 2 - Glossary

(9) Nil

Top of Page

Section 3 - Policy

Learning Technology Classification Model

(10) There are a number of different categories of learning technologies at the University, some which the review process is relevant to, others which it is not.

(11) In order to clarify the scope of the process the following Learning Technology Classification Model was defined.

Attributes Enterprise Targeted Recommended Experimental External
Integration Yes Yes No No No
Support Central Central Local Local Local
Availability Organisation Targeted Organisation Targeted Targeted
Assessment Central Central Central (Light) Central (Light) Local
Risk Low Low Low to Medium Low to Medium Low to High

(12) The Learning Technology Classification Model will be discussed in detail in the clauses to follow.

Technology Attributes

(13) The classification of technologies is determined within the model by evaluating and understanding a number of key attributes - integration, support, availability and assessment model and risk profile.

(14) Integrated technologies are embedded and linked within the University's existing enterprise systems. Some typical forms of integration include:

  1. single sign-on identity integration;
  2. full database or functional integration (e.g. use of the University master data); and
  3. frameworks such as Blackboard Building Blocks.

(15) It is common to leverage standards such as the IMS Learning Tools Interoperability (LTI) specification for implementing integrations. Simple linking via hyperlinks is not seen as being "integrated".

(16) Support for learning technologies comes in two forms, central and local:

  1. centrally supported means a technology is supported by the University staff other than exclusively by teaching staff. In most cases, a central support model would involve staff from the Division of Student Learning and/or the Division of Information Technology but it can also include the use of contracted third party vendor support; and
  2. local support describes a model whereby teaching staff are directly providing/facilitating support.

(17) Large scale use of technology (e.g. the Learning Management System (LMS) or Video Conferencing) typically requires a central support model while smaller scale uses may operate with a local support approach (e.g. a small scale pilot or experimental innovation).

(18) Availability describes the extent of expected use of a technology across the organisation.The extent to which a technology requires integration and support is heavily influenced by how broadly the technology will be used across the organisation. For example:

  1. at small scale, integration needs can often be managed in a variety of ways. For a single subject use it may, for example, be acceptable to manually manage usernames and passwords for students rather than implementing a full single sign-on integration;
  2. at full scale, with use across tens of thousands of students, the integration requirement becomes vital as manual identity management is simply not sustainable; and
  3. similarly, support can sometimes be locally managed for limited size technology deployments but again, at scale, central support becomes vital to success as the increase in demand leaves a manual process difficult to implement in a timely and accurate way.

(19) The assessment undertaken when introducing new technologies can either be centrally conducted or locally conducted.

(20) Centrally conducted assessments involve a range of stakeholders in order to ensure the best possible consideration of risk and requirements.

(21) The review process documents the centrally managed technology assessments process; and centrally managed assessments are necessary when centralised technology support and/or integrations are required.

(22) In instances where technology introduction will not require integration or central support, an assessment may be undertaken directly by teaching staff. The External Educational Technologies for Learning and Teaching Policy provides a checklist to support this self-assessment.

(23) The risk profile of a proposed technology is influenced by considering the combination of other technology attributes:

  1. technology that has been centrally assessed and that is integrated and centrally supported has a low risk profile. The low risk profile comes as a consequence of the supporting processes including significant effort being put to identifying and mitigating risk to reduce it to the lowest practical levels; and
  2. in other contexts wherein a technology has not been centrally assessed or is not integrated or centrally supported the risk profile can vary from low to high depending on the specific attributes of a given technology.

Technology Classifications

(24) The classification model provides five possible classifications for learning technologies - enterprise, targeted, recommended, experimental and external.

(25) Enterprise learning technologies are those which are offered with full integration and central support and assessment which are available for use across the entire organisation. Examples of enterprise learning technologies at the University include:

  1. Blackboard;
  2. PebblePad; and
  3. EASTS.

(26) Targeted learning technologies have either integration or central support and have been centrally assessed.

(27) Targeted technologies are available only to specific (targeted) groups within the organisation. For example, the use of dentistry simulation software is an example in which a targeted classification is appropriate as this technology has no applicability beyond that particular discipline.

(28) Recommended technologies are those which are not integrated and are not centrally supported but which have been centrally assessed. Through the centralised assessment the level of risk for recommended technologies is known but no effort has yet been put to mitigating any risks and as such the risk profile can vary from low to medium (high risk would not be recommended).

(29) Technologies are commonly classified as recommended when they are emerging and the full affordances are not yet understood or in situations where the level of demand has not yet reached sufficient levels to warrant the costs of implementing centralised support and/or integration. Examples of this classification include the many mobile apps which have been identified for potential use in support of teaching.

(30) The experimental classification is used to describe technologies which are currently being trialled and researched. Emerging technologies are often initially classified in this way while sufficient information is gathered through a proof of concept activity to inform a reclassification into recommended, targeted or enterprise categories. Examples of experimental classification include when:

  1. technologies are not integrated and are locally supported;
  2. the risk profile for experimental technologies ranges from low to medium in recognition of the fact that additional information is needed to form a fully informed view; and
  3. external technologies are not integrated and are not centrally supported and have not been centrally assessed.

(31) External technologies are chosen by teaching staff to support a wide range of needs and are a common component of many subject offerings.

(32) The use of external technologies is supported and informed by the External Educational Technologies for Learning and Teaching Policy. An example of an external technology is the use of game simulation technology within a specific subject.

Process flow

(33) The process flow for the review process is divided into two channels: the experimental/recommended channel and the targeted/enterprise channel.

(34) These two channels exist in recognition of the significant differences in the depth and breadth of consideration required between small-scale initial trials and proofs of technology and the full-scale implementation of technology at an organisation wide level.

(35) Proceeding through one of the two channels is preceded by determining the nature of the need i.e. either an idea or a specific learning technology.

Experimental/Recommended Channel

(36) Technologies are assessed via this channel in order to develop an informed view as to the viability of new technologies and their possible future use at the University.

(37) The process steps within this channel are intentionally "light weight" in order to encourage dialogue and stakeholder engagement and allow expedient progress. Active collaboration between the proposers, Division of Student Learning and Division of Information Technology is sought in order to provide value-add sharing of knowledge between parties.

(38) The experimental/recommended channel has an initial "light" assessment to ensure relevant high risk considerations have been catered for and that the appropriate stakeholders have been engaged to ensure a well-informed decision can be made on the future applicability of the proposed technology.

(39) The outcome from the experimental/recommended channel is a determination that the proposed technology is either non-viable and be classified as recommended; or should continue on to a more detailed assessment in order to support classification as either an enterprise or targeted technology; or that more information is required.

(40) In the event that more information is required it is possible to conduct a secondary pass through the experimentation/recommended channel. It is expected that any secondary pass would build upon the first (i.e. that new insights and knowledge be garnered) and that the process would be repeated in full - including a "light" assessment to confirm continued alignment and value.

(41) During the period when the technology is being assessed and trialled it is classified as being experimental.

(42) An example of a technology which has been considered through the experimental/recommended channel is the eExams technology.

Targeted/Enterprise Channel

(43) This channel is used to assess targeted and enterprise class technologies.

(44) In order to support the requisite implementation of centralised support and/or integration, the assessment in this channel is significantly more comprehensive than the "light" considerations of the experimental/recommended channel.

(45) In the instance where enterprise technology is being considered (as opposed to targeted) an additional layer of consideration of the risks and impact of scaling to an all of organisation level are also included within the assessment.

(46) The outcome from the targeted/enterprise channel is a determination as to whether a technology is enterprise, targeted or non-viable. Examples of technology considered through this include Blackboard, Adobe Connect and PebblePad.

Top of Page

Section 4 - Procedures

(47) The review process outlines a step for the preliminary identification of the nature of the need (i.e. either an idea or a specific learning technology) followed by the five main steps for the experimental/recommended channel and the seven main steps for the targeted/recommended channel (refer to the needs review process flowchart).

(48) The process step for identifying the nature of the need is:

  1. Assessment - which involves:
    1. confirmation of the nature of the need i.e either an idea or a specific technology; and
    2. if it is an idea, agreement between Division of Student Learning and Division of Information Technology, that the percieved need is worthwhile pursuing further, and that current technologies within the University environment are not able to meet the need.

(49) The process steps for the experimental/recommended channel include:

  1. "Light" assessment - which involves:
    1. shared understanding of the intent of the proposal;
    2. confirmation of a non-duplicative proposal;
    3. agreement on Proof of Concept (POC) considerations and approach; and
    4. determine the technology delivery channel for the POC.
  2. Assign Experimental Classification - a temporary classification of "experimental" is applied while the technology is trialled;
  3. Proof of Concept - to obtain increased understanding of the proposed technology;
  4. Determine Classification step - decide on the classification to determine if the technology should be classified as recommended or if it should proceed for consideration as targeted or enterprise classification; and
  5. Assign Recommended Classification - classify the technology as recommended.

(50) The process steps for the targeted/enterprise channel include:

  1. Assessment - which involves:
    1. confirmation of alignment with relevant strategy, policy and legislation; and
    2. confirmation of technical and process fit within the enterprise.
  2. Proof of Concept - which involves:
    1. confirmation of applicability across the organisation; and
    2. understanding of risks and potential costs involved in implementing the technology at scale.
  3. Determine classification - determine and assign technology classification;
  4. Assign Targeted or Enterprise Classification - classify the technology as being of targeted or enterprise class;
  5. Identify Delivery Vehicle - agreement for priority and allocation of resources for implementation:
    1. Division of Information Technology contract review process - successful negotiation of any necessary legal contracts;
  6. Technology Delivery - successful delivery of the full technology solution.

Assessment

(51) The assessment step is a collaborative endeavour between Division of Information Technology and Division of Student Learning and in particular the Enterprise Architecture (Division of Information Technology) and Learning Technologies (Division of Student Learning) teams.

(52) The process is initiated through either Division of Student Learning, Learning Technologies or Division of Information Technology, Enterprise Architecture depending on the nature of the proposal and the conversation that preceded it.

(53) Depending on the contact made, either the Division of Information Technology or the Division of Student Learning will act as custodian of the process and the chief contact point for the proposer throughout the Introduction of Learning Technologies Review Process.

(54) uImagine in Division of Student Learning will be a particular contributor of potential innovations and needs.

(55) The assessment commences with determining the nature of the need i.e. either an idea or a specific technology. Agreement needs to be reached that the perceived need is worthwhile pursuing further, and that current technologies are not able to meet the need.

(56) The primary intention of this step is to add value to technology proposals through the identification of risks, the confirmation of strategic alignment and the compliance with necessary policy, standards (e.g. privacy and security) and legislation.

(57) A variety of stakeholders may be engaged in undertaking this assessment where additional detail is required. For example system custodians are commonly involved in assessing if a proposal duplicates existing services.

(58) Within the context of an experimental/recommended channel assessment, the focus of the conversation is around risks, costs and ensuring critical organisational requirements are considered (e.g. privacy and security).

(59) The goal of this step is to flag possible risks and to identify mitigating tools and strategies for those risks.

(60) When executing this step in the context of the targeted/enterprise channel proposal, the focus shifts towards consideration of how the technology can fit within the broader University landscape.

(61) Key concerns include technical fit and strategic alignment (e.g. applicability to teaching across the organisation) such as:

  1. the costs, risks, impact and deliverables required to centrally support and/or integrate the technology are considered in this context; and
  2. for enterprise class technology additional attention is put to the impact of organisational wide use of the technology.

Proof of Concept

(62) As with the assessment step the proof of concept (POC) step can be executed within the context of either channel. For example:

  1. when executed within the experimental/recommended channel the POC step is very heavily focused towards learning more about the potential of an idea. The POC is where pieces of new technology can be tried and tested and where the knowledge from real-world experience can be garnered through small, controlled-risk, application of new technologies; and
  2. when operating within the context of the targeted/enterprise channel consideration of the POC shifts towards surfacing issues that may impact on the fit of the learning technology at the University and/or the sustainability of its use across the organisation.

(63) Additionally, this step affords the proposer the opportunity for further exposure to the proposed technology within the University context. This is important in ensuring alignment between user expectations and the features of the technology.

(64) Ultimately, the key outcome from this step is agreement (or not) to continue forward. This decision is particularly important within the experimental/recommended channel context where the idea being discussed is relatively raw and untested.

(65) In some instances the decision to not move forward is the best decision. The success of this step is not necessarily an agreement to move forward but rather that a well-informed, agreed and clearly communicated decision is made.

Determine Classification

(66) A key outcome from both channels is the determination of the classification of the technology under consideration. For example:

  1. within the context of the experimental/recommended channel the possible outcome is assignment of a recommended classification (the experimental classification is applied during the assessment) or to forward the technology on for targeted or enterprise classification consideration within the targeted/enterprise channel.

Identify Delivery Vehicle (Targeted/Enterprise Channel only)

(67) At this point in the process the proposal has been confirmed as having a solid technology fit, a well aligned strategic position and has proven to be suitable for use by end users.

(68) Shifting the learning technology from a small scale Proof of Concept (POC) into the organisational technology environment requires the identification of a suitable delivery vehicle.

(69) There are a number of different potential vehicles for technology delivery at the University, each of which is geared at supporting varying levels of change, risk, cost and complexity. For example:

  1. at the simplest end of the spectrum are standard business as usual (BAU) functions which are typically coordinated through the Division of Information Technology Service Desk;
  2. slightly larger activities can be proposed for inclusion on the Division of Information Technology ICT Significant Works Register (ICT-SWR); and
  3. the Initiatives and Strategy Implementation Plan (ISIP) process exists to support large scale proposals.

(70) The key outcomes from this step are the identification of the appropriate delivery vehicle and then the subsequent lodging, endorsement, prioritisation and resourcing to support the implementation of the learning technology.

DIT Contract Review Process (Targeted/Enterprise Channel Only)

(71) In the instances where the implementation of the learning technology requires a legal agreement, the Introduction of Learning Technology Review Process will link to the Division of Information Technology Contract Review Process.

(72) This process is responsible for gathering a contract review team, obtaining the contract, securing expert business and legal input on the contract and then negotiating the final terms of the contract with the requisite vendor and/or legal representation.

(73) In the context wherein the Division of Information Technology Contract Review Process is executed in support of the Learning Technology Review Process the key stakeholders from the learning space will be included in the contract review.

Technology Delivery (Targeted/Enterprise Channel Only)

(74) The final step of the process is delivery and implementation of the Learning Technology via the delivery vehicle identified in the Identify Delivery Vehicle step.

(75) Execution of this step follows the process defined for that form of technology delivery.

Relationship with other documentation of the University

(76) This Policy needs to be read in conjunction with the:

  1. External Educational Technologies for Learning and Teaching Policy as it relates to external educational technologies; and
  2. Learning Analytics Code of Practice and Learning Analytics Consent Statement as they relate to privacy requirements and management of personal information.
Top of Page

Section 5 - Guidelines

(77) Nil