Athlete Performance Management Software Problems: The 6 That Cost Real Money, and How to Avoid Them

Why does athlete identity and session context get underestimated so often?

Proposals say integrate the data sources. That sounds like connectors and it is not. Every platform has its own athlete list, its own identifiers and its own idea of what a session is. The global positioning system knows a training session by timestamp and drill period. The force plate system knows a test by date. The medical system knows an athlete by a clinical record number. The gym application knows them by an email address they last updated two years ago. When a player arrives on loan in January, somebody creates them five times.

Owning the identity layer is the project, not a preliminary to it. One athlete record with vendor identifiers mapped underneath, so a new hardware supplier becomes a mapping change rather than a migration. One session object carrying the coach's plan, meaning the drill, the intended intensity and the phase of the week, because nine hundred metres of high speed running means something entirely different in a rondo than in a match simulation.

The fix at scoping time is to ask the developer to model the domain in front of you. A team that has done this draws athlete, team membership with date ranges, session with planned and actual context, measurement from a named source, and a derived metric with a version. A team that draws players and workouts has built a consumer fitness application, and the difference shows the first time a loan player arrives mid season.

What goes wrong when you migrate historical load and testing data?

Three things, and the middle one is the one clubs regret.

First, athlete matching across historical exports is manual. The same player appears with a shortened first name in one system, a middle initial in another, and a squad number in a third. Automated matching on name will merge two academy players who share a surname, and that error is invisible once it is in.

Second, and more damaging, metric definitions differ between vendors and between firmware versions. High speed running thresholds, acceleration bands and how a vendor treats signal dropouts are not constants. Loading three seasons of a composite metric from an old platform into a new store and charting it as one continuous series produces a trend line that is partly a change in measurement. Baselines built on it will be wrong, and nobody will know which part.

Third, absent data gets treated as zero. A national team camp with no feed becomes a fortnight of rest in the chart, and the system will tell you an athlete is fresh when he is not.

What works: migrate raw or near raw measurements wherever the exports allow it, and recompute your own metrics from them so the series is consistent by construction. Where only derived metrics exist, load them tagged with source and definition version and render breaks in the series visibly rather than smoothing them. Mark external periods as estimated rather than measured, and never as zero.

Why do the hardware vendor feeds break after launch?

Because a meaningful share of them are not interfaces at all. Catapult, Kitman Labs, Smartabase and Teamworks offer exports and programmatic access, so the data is not locked in the crude sense, but underneath the marketing there is a real difference between a documented interface and a nightly file drop with inconsistent columns. The second is more common than vendors admit, and it breaks on column order, on a renamed export template, and on a firmware update that adds a field.

The second cause is human. A staff member changes an export setting, or a new performance analyst starts producing the file manually because the scheduled job was never explained to them. A file that stops arriving looks identical to a week where the squad did not train.

Three controls carry it. Validate every inbound file against a declared schema and reject the whole file rather than accepting a partial parse, because a half parsed session is worse than a missing one. Monitor expected volume by source and by squad, so a source that normally delivers four sessions a week and delivers none raises an exception on Monday morning. And land raw data in your own store first, before any transformation, so a mapping error is repairable by reprocessing rather than by asking a vendor for a re export they may not provide.

What happens when medical confidentiality and dual programme athletes are not covered?

These are the two gaps that turn a performance project into a legal problem and a risk problem respectively.

Medical information is special category personal data under United Kingdom and European Union data protection law. If separation between clinical detail and performance data is handled by staff discipline about which screen they open in front of whom, it will fail, usually in a hurry before a session. The coach does not need a diagnosis. The coach needs availability status and a training recommendation. The doctor needs everything. That has to be enforced at field level, with access rules, retention periods and audit logging designed in from the start, not added when someone asks.

The dual programme problem is quieter and costs availability directly. An academy player trains with the first team on Thursday, plays for the under twenty ones on Saturday, and goes to a national camp for ten days where different staff load him with no visibility to you. Squad scoped systems handle a stable roster and become awkward the moment an athlete belongs to two programmes, yet those are precisely the athletes at highest risk, because their total load is the sum of two plans neither of which sees the other.

The design that solves it is making the athlete the primary object and the team a dated relationship rather than a container, so load aggregates across every programme the athlete belongs to.

Should you build custom or configure what you already own?

If you are a single senior squad with one hardware supplier, a performance staff of two or three and no academy pathway to integrate, configure Smartabase or Kitman Labs and stop. They are competent, they will be running next week rather than in four months, and a build would consume attention you do not have. If your real problem is coordination across staff rather than analysis depth, Teamworks is a reasonable answer. When the product fits your methodology, use it.

Before assuming a build, do one exercise that costs nothing. Write down the three metric definitions your staff argue with most, and ask your current vendor to show you the exact arithmetic behind each one and whether you can change the threshold yourself without raising a support ticket. If you can see and adjust them, the gap was configuration knowledge and you have saved yourself a project. If the arithmetic is not visible, you have measured the constraint.

Build when two or more of these hold: your staff argue with vendor defaults rather than accepting them, someone reconciles three or more sources by hand every week, athletes move between academy, first team and loan spells, you have changed hardware suppliers once and lost history, or your methodology sits in a spreadsheet maintained by one person whose contract ends in June. The last one is the real trigger and clubs consistently underrate it.

How do hidden costs get into a performance software quote?

Five places, and an experienced team names them before quoting.

• Number of hardware vendors. Each ingestion is its own work, and the ones that deliver files rather than documented interfaces cost more, not less.
• Live in session data. A sideline tablet showing load during training is a different engineering problem from processing a session afterwards, and it is often assumed rather than specified.
• Medical module scope. Rehabilitation pathways and return to play protocols are detailed and clinically sensitive, and they attract the most stakeholder opinions per screen.
• Video synchronisation. Jumping from a load spike to the clip sounds small and involves clock alignment across systems that were never designed to agree.
• Methodology extraction. Getting your model out of one sport scientist's formulas is discovery time. It is worth every hour, because it is usually the first time the club has written its methodology down, but it belongs in the plan rather than in the margin.

What keeps it down is starting with one squad, the two sources that already drive decisions, and the morning board. Not the medical module, however loudly it is requested.

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

Working builds are designed around the coach's morning rather than around the data. One screen, the squad as a list, a colour per athlete, one sentence of reason and a recommendation phrased in training terms, meaning full session, modified with no maximal sprints, or gym only. It arrives on a phone before the staff meeting rather than waiting behind a login. A platform that asks a coach to choose a report and interpret a chart gets used for about three weeks, and that is a product failure rather than a failure of coaches.

Working builds also make flags explain themselves and record overrides. Amber because deceleration count is well above this athlete's own four week baseline while sleep duration has dropped for three nights, not because a dot changed colour. The head of performance can override any flag with a reason, and the override is stored, because the override is frequently the most valuable data in the system and it is the record you will want when you review a soft tissue injury in April.

Failing builds usually delivered a good aggregation layer that nobody trusted, because the thresholds were vendor defaults and the flags fired wrongly twice a week. Run the new board in parallel with the existing spreadsheet through a pre season, compare flags every morning with the staff, and tune thresholds against what actually happened. Every threshold change should be dated, so when you review an injury months later you can see what the system was saying at the time and whether anyone acted on it.