Vocational Training Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the funding eligibility scope get underestimated so often?

Because on a whiteboard it looks like a form with validation. In practice it is a compound rule set that changes every August, differs per funding stream, and has to be evaluated as it stood on the day of enrolment rather than as it stands today.

The scope failure has a signature. A provider specifies eligibility as a checklist on the enrolment screen. Six months later the rules change, so a developer edits the checklist, and now every historical enrolment is being evaluated against the new rules whenever anyone runs a report. When an auditor asks why you claimed for a learner who started in March, the system answers with today's logic, which is not the question and not a defence.

It is specific to this sector because the rules are external, dated, and enforced retrospectively by somebody with the power to take money back. Very little other business software is audited against the version of its own logic that was running last year.

The fix is to make eligibility a versioned rules engine rather than code inside a form. Each rule is a dated record with a condition, a funding stream, an effective-from and an effective-to date. Enrolling a learner evaluates every active rule set and stores the decision together with its reasoning: eligible under this stream and this rule set version, not eligible for that one because prior attainment sits at a related level. That reasoning string is what an auditor reads in eighteen months. When the rules change, your compliance lead edits rules with an effective date in an admin screen, and yesterday's enrolments keep being judged by yesterday's rules. Build this first. It is the highest return item in the whole category.

What goes wrong when you migrate learner and evidence records?

Migration is where a provider gets its first honest audit of its own data, and it is usually uncomfortable. Three things break reliably.

Identity is the first. Legacy records carry duplicate learners created by re-enrolments, several spellings of the same employer, and learners whose unique identifier was typed rather than verified. Merge them wrongly and you fuse two people's funding history. Fail to merge and your prior-start eligibility check misses a duplicate that an auditor will find.

Enrolment state is the second. Most legacy systems store a current status, so a learner shows as completed with no trace of the break in learning, the withdrawal, the restart or the change of employer that happened along the way. Funding depends on that history, not on the final state, and you cannot reconstruct it after the fact.

Evidence is the third, and it is the one providers underestimate. Portfolio files sit in a document store with meaning encoded in folder names and a naming convention, plus criteria mapping that exists only inside the previous e-portfolio product. Move the files without the mapping and an internal quality assurer can no longer sample by criterion, which is the whole point of the portfolio.

Plan three to six weeks inside a first release for this, expect a human review pass on the exceptions, and migrate the event history rather than the current status wherever the source has it. Where it does not, record the migrated record as opening balance with a clear cut-off date, so nobody later mistakes an import for evidence.

Why do the awarding body and learning platform integrations break after launch?

Because most of them are not integrations in the sense a developer means. City and Guilds, Pearson and NCFE range from a workable interface to a fixed-width file you place on a server and hope about, and the file specification changes when the awarding body decides it does. There is often no test environment, no versioning and no notification, so the first sign of a change is a rejected submission during a certification run.

Moodle breaks differently. It is genuinely adequate for content delivery, which is why keeping it is usually right, but a provider's Moodle is a base install plus four plugins, and the plugins break on upgrade. If your funding system reads completion data through a plugin-dependent path, your claim data goes quiet the week after somebody applies a security update.

The third failure is direction. Teams build a two way sync between the learning platform and the funding system, and within a quarter both sides have edited the same learner and neither can say which record is correct.

The fixes are unglamorous. Pick one master for the learner record and push outward rather than syncing. Treat every awarding body exchange as a file plus a reconciliation import, with an exception queue as a first class screen that somebody works for ten minutes every morning rather than a report nobody opens. And read Moodle through its documented web services rather than through a plugin's database tables, accepting the narrower data in exchange for surviving upgrades.

What happens when the audit evidence trail is not covered?

An audit does not ask whether your software is impressive. It asks why you claimed, and it wants the answer as a record rather than an explanation. Systems that store outcomes without reasoning fail this even when every decision was correct.

Three gaps recur. Eligibility decisions stored as a yes or no with no rule version and no reasons, so the only defence is a compliance lead's memory. Evidence uploads stripped of their original timestamp and source because a file was downloaded from an email, renamed and re-uploaded, which converts contemporaneous proof into a document of unknown date. And enrolment status changes written by overwriting a field, so a learner who broke learning, restarted and completed shows only as completed, and the funding profile cannot be justified.

The other live gap is off-the-job hours and employer engagement for apprenticeships. Progress reviews typed up on Friday from memory are weaker evidence than a record created at the time, and providers frequently find the review exists as a signed PDF in an inbox rather than as anything the system knows about.

The fix is an immutable event log on the enrolment: enrolled, break in learning, restarted, withdrawn, completed, certificated, each with an actor, a timestamp and a reason. The funding claim then becomes a projection of that log rather than a separate spreadsheet, and evidence keeps its original capture metadata rather than the metadata of the last person who touched the file.

Should you build custom or configure what you already own?

If you are single site, under roughly two hundred learners a year, running one funding stream with one awarding body, buy. Aptem or Maytas at the per learner rates our clients show us is dramatically cheaper than anything we would build, and the vendor absorbs the annual funding rules change on your behalf. That is a real service and it is worth paying for.

The same applies to portfolio. OneFile and Aptem do e-portfolio properly, and for many providers the honest advice is to keep the e-portfolio and stop there. Keep Moodle too. Content delivery is the one thing it does adequately, and replacing it first is the most reliable way to kill one of these projects.

Build when you employ someone whose job is effectively spreadsheet and have done for over a year, when you have taken a clawback or an audit finding traceable to a mismatch between two systems, when you run three or more funding streams or contract types and the product models one of them properly, when a change you need has been on the roadmap for more than two release cycles, or when your delivery model genuinely has no product behind it. The middle path is where most providers should land: keep the learning platform and the finance system, build the compliance and evidence spine between them.

How do hidden costs get into the quote?

The number of distinct funding streams is the biggest and the most often missed, because each one is a separate rule set with separate returns and separate audit expectations. Going from one stream to three adds substantially to the compliance module, and a proposal that prices funding rules as one line has priced one stream.

Awarding body count is next, at a few weeks each, and the effort has almost nothing to do with the volume of learners and everything to do with the format on the other end. Offline capability for assessors sounds minor and is not: proper offline capture with conflict resolution is weeks of work on its own, and you need it if your assessors work in basements, plant rooms and construction sites.

Historical data migration is always worse than the estimate for the reasons above. And nobody quotes for running the legacy system in parallel during transition, which effectively means building the integration twice.

What separates a build that works from one that fails here?

Put a real enrolment in front of the developer in the first meeting and ask for the data model rather than a wireframe. If they draw learner, course and completion and stop, they are building a learning platform and have not understood the business. The right answer separates the programme instance from the learner, has an immutable event log, treats break in learning as a first class state, and stores eligibility as a dated rule evaluation with its reasoning. A team that has built this produces that model in ten minutes. A team that has not will discover it three months into your budget.

Ask what happens when the funding rules change in August. You want to hear about effective dated rule sets, historical enrolments replayed under historical rules, and a screen where your compliance lead makes the change without a developer. Anything resembling we will push an update is describing a product that does not survive a rule change.

Ask about awarding body integration by name, for your awarding bodies. The credible answer contains the phrase there is no interface and here is how we handle that, followed by a reconciliation strategy. Anyone promising clean two way sync with every awarding body has not tried it.

Then settle ownership before the first invoice: the repository, the intellectual property, the infrastructure accounts and the data, plus the ability to hand the whole thing to another team without permission. Ask to see redacted handover documentation from a previous engagement. On a system that holds your funding audit trail, that is not a commercial detail.