Taking Inventory of the Tech Schools Use

10 min read

This post was originally published at Educating Modern Learners.

Anyone working in or around education technology in the last two decades has likely experienced the tension between district-level technology policies and classroom-level technology implementation.

In very general terms, district-level decisions tend to minimize risk, often at the expense of teacher autonomy and creativity. On the other end of the spectrum, classroom-level implementations – where a teacher brings in an application outside of district- or school-level approval processes – can get teachers the resources they want to use with less hassle. However, over time, classroom-level implementations that sidestep school- and district-level review often result in a patchwork of applications, with little or no review for privacy, security, or effectiveness. Complicating matters even further, district-level reviews and contracting processes aren’t always adequate – and even if they are, district policies are often not explained in terms that make sense or are relevant to teachers.

Disconnects Within Educational Systems

The disconnect between classroom needs and district needs increases when district review schedules do not align with classroom schedules. Because of this longstanding and inherent tension between a district’s need for stability and a classroom teacher’s need for flexible and timely adaptation, we create a situation where districts are not fully informed of software use at the school level, and district security needs are not understood at the classroom level. The fallout from broken processes often results in students, parents, teachers, school administrators, and district staff all having an incomplete and inaccurate vision of the technology used while learning.

The fallout from broken processes often results in students, parents, teachers, school administrators, and district staff all having an incomplete and inaccurate vision of the technology used while learning.

The good news is that this broken communication can be fixed with a simple inventory, and taking inventory of software used to support teaching and learning within a school is not rocket science. It requires time, and the process of documenting software used to support teaching and learning will almost certainly uncover shortcuts in the contracting and vetting process, but we can’t continue to allow the mistakes and habits of the past to shape the learning environments of the present.

Inventory To The Rescue

In this post, we will create a replicable process that can be used by students, teachers, school administrators, and/or district staff to document the technology used in your learning environments. One of the barriers to implementing pedagogically sound technology programs is a clear sense of what is being used, and why. An inventory, evaluation, and privacy review of existing technology needs to be part of how we implement software used in learning. The point of documenting software and technology currently in use is not to be retroactively punitive

In all likelihood, there will be holes in what can be documented initially at both the school and district level. If people at the school level are fully forthright, there will almost certainly be apps used within schools that violate district policy – and depending on the context, that could be attributable to district red tape, school-level intransigence, and/or teachers being under pressure to get their work done. If people at the district level are fully forthright, the inventory will reveal shortcomings in both the contracting and review process. However, the point of documenting software and technology currently in use is not to be retroactively punitive, and “success” does not require all schools and teachers to fall in line with district policies. The goal here is to establish a baseline, and learn how to do better – including questions to ask ourselves, our vendors, and our students – as we move forward. “Doing better” requires changes in district policies, school implementation, teacher practice, and vendor policies. All stakeholders have a role to play.

The process of taking a complete inventory will highlight places where all stakeholders need to improve. School and district staff need to tighten up contracting processes, and do a more thorough job evaluating software and systems for privacy and security. Teachers need to triage applications for privacy and effectiveness. Vendors need to clean up their privacy policies and terms of service and stand fully behind their product, and ensure learners that their work today is not getting fed to a data broker tomorrow – and teachers, students, parents, and administrators need to demand responsible and safe behavior from vendors.

Steal This Process!

The core of any inventory system starts with a list. To jumpstart this process, we created a Google Spreadsheet that you can copy and modify for your local use. The structure of this spreadsheet could also be starting point for a more structured database.

The process of taking inventory includes four steps:

• General information – a list of software or services, with contracting information;
• Purpose: What Does It Do – a description of how the software or service supports learning or administrative needs;
• How: Types of Records, and Data Collected – a description of the data collected by the software;
• Privacy: How Is Data Protected (or Not Protected) – an overview of basic privacy details

General Information

• Name: Name of Application
• Web Site: Web site of the company
• Authorized By: Who brings in the application, or authorizes its use? (District/School/Teacher/Other)
• Contract: Does the application require a contract to use?
• Contract Location: If yes, where is the contract?
• Contract Duration: What is the duration (start and stop dates) of the contract?

Purpose: What Does It Do

This section summarizes what the app does, and why it is useful or effective.

• Description: what does the application do, and/or how does it support learning? Is the application used/supplied by the district to manage student, parent, and teacher data? Example applications here could include a gradebook, a student information system, a system designed to manage IEPs, systems designed to support communications about snowdays, etc. Is the application used to support learning? Examples here range from a district-supplied textbook from Pearson to a schoolwide use of IXL to a math app or a music app used by an individual teacher.
• Access: How do students access this application? Is the application a web site available online, a program that is downloaded, an iPad or tablet app, a Chromebook app, or any of the above?
• Indicators: what indicators show that the app is effective, or supports the goals it aims to achieve?

How: Types of Records and Data Created

This section provides an overview of data collected by the app, and where the data is stored. It is likely that some vendors will not support or share some of the information outlined in this section. If a vendor does not support a feature or describe their data process, the column can be marked “unknown” or “unsupported.”

Also, this section contains two questions related to the Family Educational Rights and Privacy Act, or FERPA. This only applies to the United States; if you are outside the US, omit these questions and delete these columns from the spreadsheet.

• Data Stored: What data is collected and stored by a learning application? This field can be a link to a detailed data specification, or a general list of data points that can often be found in privacy policies.
• FERPA: Does the app create educational records as defined by FERPA? It’s worth noting that many apps will collect data that is considered an educational record under FERPA, alongside data that is not considered an educational record. The data that is not part of an educational record would therefore be governed by a vendor’s terms of service. The point here is to get a sense of what the legal obligations are with respect to the data collected in the application. The US Department of Education provides some solid resources around FERPA.
• Other Data: Does the app collect data that is not considered an educational record under FERPA?
• Student Review: How can students and parents review, modify, correct, or delete data collected by the application?
• Storage: Where is data collected by the app stored? Is it on a local server controlled by the school or district, on a server controlled by the vendor, or in another form of remote storage?
• https: does the app use https at all times? In this doc we try and avoid absolutes, but if an app collects data and is not using https it should not be used.
• Security Measures: how is data protected? Many apps contain some details about this in their terms of service of privacy policies.

Privacy: How Is Data Protected (or Not Protected)

This section highlights some elements of how vendors will use or transfer data, as defined in their privacy policies and terms of service. To complete this section of the inventory, you will need to read and review the terms of service and privacy policies of software and services. See here for tips on triaging privacy policies and terms of service.

• Privacy Policy: What privacy policies govern use of the application? Link to the policy.
• Terms of Service: What terms of service govern the use of the application? Link to the terms.
• Additional Terms: Are there additional terms or conditions that govern how the application can be used? Link to any applicable terms or policies.
• Opt Out: How can students and parents opt out of using a specific application?
• Affiliates: Do the privacy policies and terms of service allow for data to be transferred to partners or affiliates?
• Business Transfer: Do the Privacy Policies and Terms of Service allow for the sale or transfer of data in case of an acquisition, merger, sale, or bankruptcy? Most apps currently allow this, and this is an area where vendors can improve their current practice. The effect of allowing sales in case of merger or bankruptcy means that we can’t predict where data collected in an educational setting will end up, or how our student’s data will be used over time.
• Cancellation: If the teacher, school, or district ends the contract, does all school/district data get deleted?
• Data Sunset: Does the vendor have data sunsets (a period of time after which user data will be permanently deleted)?
• Portability: How can parents or students download data collected and stored by the application?
• Parent/Student Deletion: How can a student or parent fully delete their information from the application?
• Changes w/o Consult: Can the vendor change the terms without consulting users?

Closing

As mentioned earlier, the spreadsheet and the process described in this writeup are intended for you to take them and use them. Modify them as needed. If there are things you feel should be added here, please let us know.

Once the inventory has been completed, the list can be made public so school communities have a clear sense of what technology is used, and the privacy protections in place with each service. Getting the details documented lets us start the conversation from an informed place. We can’t build on or improve current practice without a clear sense of what current practice looks like.

#privacy, #documentation, #edtech