
Education
Count the Whole Workload Before Buying Education Software
Include setup, support and repeated admin in the workload calculation.
Read the perspectiveLook at the work beyond the demonstration
A product demonstration usually follows a prepared route. A class already exists. Learner records are complete. The activity is ready to assign. A report appears with a few clicks. The teacher's actual week contains all the work around those moments.
Someone must prepare the material, check the roster, explain access, recover forgotten credentials, review unexpected results and communicate what happens next. If the institution keeps its previous reporting process, the same information may then be entered again elsewhere.
A workload claim should include that complete sequence. “Creates a quiz in seconds” describes one action. It leaves open whether the questions are suitable, the answers are correct and the results can be used without further preparation.
Start the evaluation with a real task and the people who perform it. Ask them to show the current process from the first preparation step to the final follow-up. Include routine interruptions and exceptions, rather than drawing an ideal process that nobody recognises.
The Education Endowment Foundation's implementation guidance treats context, staff behaviour and implementation process as integral to adopting an approach. A school software project needs that attention before the purchase becomes a timetable.
The aim is to expose the work clearly enough to redesign it. Teachers should be able to see where the new system helps, where it introduces responsibility and which existing steps will disappear. Without that account, efficiency remains a feature description rather than an operational proposition.
The most credible time-saving feature may be permission to stop doing something the institution no longer needs.
Keep a workload account that includes corrections
For each proposed workflow, compare the current task with the new one. Preparation and entry are only the beginning. Include checking, handling exceptions, answering questions and producing whatever record the institution requires.
A compact review can follow five parts of the working cycle:
Preparation: finding or creating suitable material and adapting it for the group.
Delivery: assigning work, explaining access and responding when something fails.
Review: checking submissions, interpreting results and correcting system errors.
Follow-up: giving feedback, arranging support and communicating with learners or families.
Reporting: recording outcomes in the places that staff and leaders actually use.
Measure the parts that matter in the setting. A short diary or observed sample can reveal repeated effort that a questionnaire misses. It need not become another permanent reporting burden.
Consider a hypothetical tutoring centre adopting an assessment tool. Automatic marking reduces one task, but tutors must manually match learner names to the centre's records and reformat results for progress reports. The project may still be worthwhile, yet the integration problem belongs in the scope and cost.
Count the work transferred to other people. A teacher may save time because an administrator now prepares every class list. A learner may spend longer navigating instructions that used to be explained in person. Those changes need to be visible, even when they are acceptable.
Keep educational quality alongside time. Faster preparation has limited value if the material requires extensive correction or fails to suit the lesson. The EEF's EdTech research agenda describes a mixed evidence base and separates workload questions from learner outcomes. An institution should preserve that distinction in its own evaluation.
Name the process that will be retired
A new system often arrives more easily than an old process leaves. Staff may continue maintaining a spreadsheet because leaders still request it. A paper form survives because nobody has agreed whether the digital record is sufficient. Two systems then become the default.
Every efficiency proposal should identify the work it replaces and the person authorised to stop requiring it. If the answer is that all existing steps must remain, describe the project honestly as an additional capability and account for the time it needs.
Examine the reasons behind duplicate records. Some may serve a genuine requirement that the new product does not meet. Others may be habits or temporary precautions that have never been reviewed. The remedy depends on which is true.
Settle the authoritative record for shared information. Class membership, assessment results and attendance can change. When a correction is made, staff need to know where to make it and how it reaches the other systems that rely on it. Asking teachers to reconcile conflicting versions repeatedly defeats the purpose of the integration.
Also decide what happens during transition. A brief period of comparison may be necessary to verify records, but it should have a purpose, an owner and an end condition. Indefinite parallel work is a common way for temporary caution to become permanent workload.
Procurement should include these operational commitments. A supplier can explain export formats and interfaces. The education provider must decide which reports it will accept, who maintains shared data and when staff can stop repeating the old process.
The most credible time-saving feature may be permission to stop doing something the institution no longer needs.
Pilot the ordinary week, including awkward cases
Choose a pilot that resembles the environment in which the tool will operate. A group of enthusiastic early adopters can help discover possibilities, but it cannot reveal every support need or establish how the wider staff will cope.
Include varied levels of technical confidence and the relevant teaching contexts. Test a new learner joining late, an incorrect record, an absent staff member and a class with unreliable access. Observe who resolves each problem and how long the interruption lasts.
Agree the support route before the pilot starts. Staff should know which issues belong to a local administrator, which require the supplier and which call for an educational judgement. One teacher should not become the unofficial help desk simply because they learned the system first.
Provide time for preparation and training. A course in how to click through the interface may leave teachers uncertain about how the tool fits a lesson. They need a chance to practise the actual workflow with their own material and ask questions about the changes expected of them.
UNESCO's 2023 recommendations on technology in education call for choices that are appropriate, equitable, supported by evidence and sustainable. In a small institution, sustainability includes having enough staff capacity to keep the service working after launch.
Capture feedback in a form the project team can act on. “Difficult to use” is a starting point; “I must recreate the group before each report” identifies work that can be examined. Protect time for those conversations rather than treating low adoption as proof of staff resistance.
A pilot should make continuation, adjustment or withdrawal possible. If the purchase is already treated as irreversible, staff feedback has little practical authority.
Expand from a demonstrated working routine
At the end of the pilot, review the complete workload account again. Which steps became easier? Which moved elsewhere? Which errors or access problems occurred? What preparation is still needed each week?
Look beyond an overall average. A tool may help one subject team while creating extra work for another. It may suit a repeated activity but perform poorly when teachers need to adapt material. A narrower deployment can be a sound outcome.
Agree what must be resolved before expansion. That could be a reliable roster connection, an accepted reporting format or enough support coverage. Turn those findings into project requirements, with owners, rather than leaving them as general lessons for staff to absorb.
Keep a route for later changes. Terms, features, curriculum requirements and staffing can shift. Review whether the tool still removes the intended work and whether the old process has quietly returned.
Finally, be precise about what the evaluation establishes. A reduction in administrative effort is worthwhile, but it does not automatically prove improved learning. If the institution also expects an educational benefit, define and examine that outcome separately.
Education technology earns a place in the working day when staff can use it reliably, understand its purpose and sustain the responsibilities it introduces. A successful rollout leaves a clearer routine behind it, with fewer avoidable steps and a realistic account of the work that remains.
