One Step in Results Processing Takes Most of the Time. Here Is the Benchmark We Would Set.

Results processing begins on a Monday. The marks arrive from the departments as spreadsheets, each laid out a little differently.

For days, two clerks bring them into one sheet by hand, checking as they go. Then the old tabulation program is run overnight, one programme at a time. It stops twice, and has to be started again by the one person who knows how.

Everything after that takes a day. The section works both weekends. When it is over, everybody agrees the merging must be sorted out before next time. Then the next piece of work arrives, and nobody has the time.

What We Found

For this article we went through the public record on the time results processing takes, and on what holds organisations back from changing old software: one cross-sector survey of IT professionals, one developer’s account and one survey of developers.

First, what we did not find: no figure, in India or anywhere else, for how long a results run takes, which step takes the longest, or how often a run is late. No case at a college of our readers’ size, and nothing from the Middle East. The record says nothing about tabulation programs or about marks merged by hand, and we do not guess.

Organisations hold back from changing old systems that work. In one cross-sector survey of 504 US IT professionals, which is not about education, half of those asked said the biggest reason they had not upgraded was that “the current system still works”. Among the reasons, 44% named budget limitations and 38% fear of disrupting operations. The publisher sells related services.

The fear has a reason. One developer, writing about old code in several languages, put it plainly: “There’s nothing scarier than making changes to a critical legacy system with no tests.” It is one person’s account, not from education.

And the checks are often missing. In one survey of 1,720 developers whose main language is PHP, a widely used web language, “32% of developers still don’t write tests at all”. The survey is global and not about education.

We should be plain about our part. IOanyT does not run or monitor results processing, and we promise no results on time. We do not handle, correct or vouch for any result. What we can do is read your own application, write down what it does, put tests around it, and rebuild one step as a module if you approve it.

What a Rebuilt Step Opens Up

A slow step is usually seen as the price of a results run. Our reading is that it frees more than time.

• The run stops resting on one person. A program that only one colleague can restart becomes a module the institution’s own team can run.
• The checks staff make by eye are written down. Some of them are judgement, and stay with the staff. Others the section may decide are rules, and only those it confirms are written into the step.
• The remedy fits the problem. The choice stops being a whole new examination system or nothing.
• The next narrow point shows itself. Once one step is quicker, another becomes the slowest, and can be looked at in its turn.

This is our reading. It is not a measured market figure.

Three Ways to Deal With the Slow Step, Weighed

Option	When it fits	What it risks
Get through it each cycle with long days and care	The step is slow but sure, and the people who know it are staying	Care is real, and it tires. The step rests on one or two people, and the agreement to fix it is made again each time
Replace the whole examination application	The application is failing in many places, and the institution can carry a long change	Every rule has to be set up again, and the step that hurts most waits for the whole programme. Choosing or installing a packaged product is not our kind of work
Write the rules down, put tests around them, then rebuild the one step as a module	The application is used every cycle, and one step takes most of the time	It takes stages and costs money before the step changes, and the staff who know the step must give time. Some of what they check by eye is judgement and will stay with them

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first stage begins, and fill in as each stage is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Share of the application’s rules written down and confirmed by the section	None; the rules are in the code and in a few people’s memory	Every rule the application applies, in plain language, each confirmed or queried by the section	The section’s sign-off on the specification
Share of the results logic covered by tests that record today’s outputs	None, or a check of the new case only	Every part that must change, covered by tests that record what it produces today	The test report
How long it takes to list what a change altered	It cannot be listed; “it should not have”	The time of one run of the tests	The test run
How long the slowest step takes	Not measured; known as “most of the time”	A target agreed with the section, measured before and after the step is rebuilt	The institution’s own timing

The starting points above are what we expect to find; in an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for an education body, and none of them is a promise about any result or any date.

A small part of the finished plan might look like this.

Stage	What it produces	Who decides	Status
The rules, written down	The specification, rule by rule, traced to the code	The examination section confirms or queries each rule	Signed off; three rules queried by the section
Tests around the parts that must change	Tests that record what the application produces today	The section rules on each difference the tests report	Handed to the institution’s own team, who run them
The slowest step	One module, with a traceability matrix	The section accepts it, or not	Approved for the staged plan
Results processing itself	Nothing from us	The institution’s own team, throughout	Outside our work

The rows above are an illustration, not taken from a real institution.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about your examination and results application, where the time goes in a results run, and the step everyone has agreed to sort out. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your institution’s own examination and results application, one it built or had built, and nothing else. Where a supplier holds the code, the institution arranges read-only access to the code with its supplier, as its contract allows; that step is the institution’s, and we do not obtain code from a supplier. It produces a map of the system as it stands, a written specification of what it does, with every rule the application applies written in plain language for your examination section to confirm, a risk register, a cost comparison between keeping and replacing the slowest or most manual step, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Here your own experts are your examination section, and whether a rule is what was intended is its decision. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.
4. If you approve, we build. Here that means two stages at most, each approved on its own. First, we put tests around the parts that must change: tests that record what the application produces today, so that a change which alters an outcome is reported by the tests, and we hand them back to your own team (tests included). Then, only if you approve it, the slowest or most manual step: we replace a system one module at a time while the old one keeps running, and here that is one module only. We never do a single cutover. A traceability matrix links each old function of that step to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This has a price. The staff who know the slow step must give time to show every part of it, the checks they make by eye included. Some of those checks are judgement, and a program does not wholly replace them. The rebuilt step may produce something different from the old one, and the section then decides which is intended; we do not. Once one step is quicker, another becomes the slowest. Tests cover only the cases chosen, and they do nothing about a mark entered wrongly by hand.

What we do not do: we work only on your institution’s own examination and results application. We do not run or monitor results processing, and we are not on call at results time; your own team runs the application, the tests and the rebuilt module. We do not handle, correct, re-issue or vouch for any result, and we do not say that any rule or result is right. We do not look back at past results or investigate past errors. We promise no results on time, and we do not say that results will come out sooner. We do not say what any examination rule requires. We do not work inside a packaged examination or student product. We do not ask for student records; any we see in the course of reading the code are not copied or kept. We do not say we are empanelled with any university, board or government, and how each stage is bought is the institution’s own decision. We have no published case of this work for an education body.

At the end you hold the specification with every rule your section confirmed or queried, the tests and their report, the traceability matrix and the code of the rebuilt module if you approved one, and the filled-in benchmark.

What changes for the business:

Role	What they gain
Head of institution	The institution stops resting each results run on one fragile step and a few people’s weekends.
Controller of examinations	The step that held the section up is rebuilt as one module, and the section accepts it only after checking it against the old one.
Registrar	Where the slow step is the hand-over to the registry, it becomes part of the application, written down and accepted, and stops being a file somebody carries across.
Head of IT	The slowest part moves to current technology as one module, with the rest of the application left alone.
Head of finance	Money goes to the one step that takes the time, as one accepted module, and not to replacing the whole examination application.

None of these means any result will be right or on time.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation: we found no public evidence on where the time goes in a results run. Its figures come from one vendor’s survey, one developer’s account and one tool maker’s survey, which we do not name.	For an institution’s own examination and results application, we write down the rules, put tests around the parts that must change, and rebuild the slowest step as one module if the institution approves it. We do not run results processing or vouch for any result.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Before anyone proposes a new examination system, we would find the one step that takes the time, and write it down.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →