The Swiss Army Knife Problem: when “it can do PGR” isn’t enough
30th September 2026
Universities rarely set out to create a Swiss Army knife.
It tends to happen gradually.
A student record system acquires another workflow. A research information system gains a postgraduate module. A generic workflow platform is asked to manage progression. An internally developed application created for one problem expands to accommodate several more.
Each decision can make perfect sense.
The platform already exists. The institution understands it. Another procurement can potentially be avoided. And, technically, the system can do what is being asked of it.
But that raises a different question:
Just because a system can do something, does that make it the right system to do it?
Capability is not the same as suitability
The Swiss Army knife is useful precisely because it is versatile.
It contains a screwdriver. It contains a blade. It contains several other useful tools.
But if somebody needed to drive thousands of screws, repeatedly, accurately and safely, few people would choose the Swiss Army knife over a purpose-built screwdriver.
The Swiss Army knife hasn’t suddenly become a bad tool.
The nature of the job has changed.
The same distinction matters in university technology.
Modern enterprise platforms are extraordinarily configurable. Given sufficient workflow, forms, rules, integrations and custom development, they can often be made to perform functions far beyond the problems for which they were originally designed.
PGR management can initially look particularly amenable to this approach.
Create a progression form. Route it to a supervisor. Add an approval. Record the outcome.
PGR management, however, isn’t the form.
It’s everything that happens before and after the form.
What happens when a researcher changes from full-time to part-time? Which dates move? Which don’t? What happens when an interruption overlaps a progression point? Which regulations apply to which cohort? What happens when faculties operate legitimately different progression regimes? How does an apparently small change affect everything else that follows?
A feature can be reproduced.
A mature domain model is accumulated.
When flexibility creates another problem
Generic systems quite reasonably provide flexibility.
The university can define the workflows, create the rules, configure the forms and determine how the system should behave. But there is a consequence.
The more responsibility a platform gives the institution to define the domain, the more the institution itself has to become the product designer.
That may make complete sense for something genuinely unique to that university.
It becomes less obvious when universities around the world are repeatedly solving variations of the same problems: supervision, progression, candidature changes, interruptions, thesis submission, examination, supervisor management and researcher development.
The specialist-product argument isn’t that every university should operate identically.
It is that universities shouldn’t have to rediscover the PGR domain from first principles simply because their terminology and individual processes differ.
Faculty variation is a perfect example
Anyone who has worked deeply in PGR management will recognise this one.
One faculty wants a single progression review. Another wants two. Another uses a panel. Another has different outcomes or terminology. Initially this looks like a workflow-configuration problem.
Then those differences begin interacting with study mode, award type, regulatory cohort, candidature status, supervisor roles, evidence requirements and key dates.
The generic answer can be to create another workflow. And another. And another.
Eventually the institution owns a collection of locally correct processes whose interactions have to be understood and maintained indefinitely.
The specialist approach starts somewhere different:
Which things are genuinely different, and which are simply variations of the same underlying PGR concept?
Common rules can then remain common, with controlled variation introduced where it genuinely matters.
The exact faculty variation may be unique.
The problem of faculty variation is not.
Domain maturity isn’t a feature list
This also exposes a weakness in conventional software procurement.
Two suppliers can both put a tick beside:
Progression management ✓
One may have recently built a progression workflow.
The other may have spent years discovering what happens to progression when dozens of other aspects of the research degree interact with it.
On a conventional feature matrix, both answers can still be Yes.
Yet they represent very different levels of maturity.
A competent software team can build an enormous amount in two years. What it cannot automatically acquire in two years is decades of exposure to institutional edge cases, policy changes, implementation lessons, exceptions and decisions that seemed sensible at first but proved problematic in practice.
That experience teaches a specialist supplier not merely what to build, but what not to build.
What should be configurable? What should remain standard? Which differences actually matter?
Which apparently unique requirement is really another manifestation of a problem encountered many times before?
Software can be built surprisingly quickly. Domain maturity cannot.
This isn’t an argument against enterprise platforms
Universities need broad institutional systems.
Student record systems should be excellent student record systems. Research information systems should be excellent research information systems. Identity platforms should manage identity.
Nor is the answer to introduce dozens of disconnected specialist applications. The better question is where the boundaries should sit.
Modern integration allows an institution to retain authoritative core systems while using specialist platforms where a particular domain is sufficiently deep to justify one.
That leads to one of the central arguments in our new white paper:
Integration should allow systems to specialise, not force every system to become a Swiss Army knife.
A different question for universities
So perhaps the next time a university considers extending an existing platform into PGR management, the first question shouldn’t be:
“Can this system do it?”
Of course it probably can.
Instead ask:
How much PGR expertise will the university itself have to supply to make it do it well?
And ultimately:
Is managing PGR what this system was built to understand?
Our latest SkillsForge white paper, The Swiss Army Knife Problem, explores this argument in more detail and suggests some rather different questions universities can use when evaluating specialist and general-purpose platforms.
Use the Swiss Army knife where versatility is the requirement. When the same difficult job must be performed thousands of times, over many years and across many variations, use the specialist tool — and integrate it well.