Your University May Be Unique. Its PGR Problems Aren’t.
12th October 2026
Or why different doctoral regulations don’t always require different software
Universities are rightly proud of their individuality. Their doctoral regulations reflect academic traditions, institutional governance, disciplinary requirements and years of accumulated experience. But when it comes to managing postgraduate researchers, how much of that individuality represents a genuinely different problem? And how much represents a familiar problem being addressed through different rules?
This distinction has important implications for the way universities select, develop and maintain their PGR management systems.
Different regulations. Familiar processes.
Consider doctoral progression. Universities may use different terminology, require different evidence, operate different review schedules and assign approval responsibilities to different academic bodies. Yet beneath these variations lies a recognisable process.
A review must be scheduled. Evidence must be gathered. Appropriate decision-makers must be involved. An outcome must be recorded, communicated and acted upon. The same underlying patterns appear throughout the postgraduate research lifecycle.
Supervisors are appointed and changed. Researchers interrupt their studies, request extensions or change their registration status. Milestones are completed. Theses are submitted, examined and corrected.
The institutional rules may differ. The fundamental management challenges often do not.
The cost of treating every difference as unique
When universities assume that every variation in their regulations requires bespoke software, they can find themselves repeatedly developing functionality that addresses familiar PGR management problems. Initially, this may appear sensible. A system developed around existing institutional processes can offer a close fit. But over time, the consequences can become significant.
Regulatory changes may require further development. Similar processes can evolve differently across faculties. Reporting becomes more complicated when equivalent outcomes are recorded inconsistently. And maintaining institutional knowledge within custom software can create long-term dependencies on particular teams or individuals.
None of this means bespoke development is inherently wrong. It means universities should distinguish between requirements that are genuinely unique and those that can be addressed through the configuration of mature, specialist software.
Configuration is not compromise
A configurable PGR management system should allow universities to retain control over their regulations, terminology, approval structures and academic decision-making.
Take an interruption of study. The underlying event is a temporary change in candidature status.
But universities may apply different eligibility criteria, approval routes, evidence requirements and rules governing the effect on progression and submission deadlines.
A specialist platform should understand the underlying event while allowing those institutional rules to be applied appropriately.
This is fundamentally different from expecting every university to adopt identical processes.
The objective is not to standardise universities. It is to avoid unnecessarily rebuilding the technology used to manage familiar processes.
The real challenge lies in the exceptions
Straightforward processes are rarely the most demanding part of PGR management. Complexity emerges when ordinary circumstances overlap.
Consider a part-time doctoral researcher who changes supervisor, takes an approved interruption and subsequently returns under revised regulations.
Which rules apply? What happens to their progression and submission dates? Which approvals remain valid? How are those changes recorded and communicated?
A system that treats each activity as an isolated workflow may struggle to maintain a coherent picture of the researcher’s candidature. A mature PGR management system needs to understand the relationships between those events and preserve an accurate, auditable history.
That understanding is developed through sustained experience of the postgraduate research lifecycle.
Asking better procurement questions
Universities evaluating PGR management systems should look beyond conventional functionality checklists. Instead, they should ask suppliers to demonstrate how their software handles genuine institutional variation.
Can different approval routes operate within the same system?
Can terminology and review schedules be configured without custom development?
Can regulatory changes apply to new cohorts while preserving the rules governing existing researchers?
And can the system maintain consistent reporting when different faculties operate different processes?
These practical demonstrations reveal considerably more than a simple claim that a system is flexible or configurable.
Your university may be unique. Its PGR problems aren’t.
Universities should never have to compromise their academic standards, governance or legitimate institutional requirements to accommodate software.
Equally, they should not have to commission unique technology for every variation in a familiar process.
The challenge is knowing the difference.
At SkillsForge, nearly two decades of working with universities have helped us develop a specialist understanding of the postgraduate research lifecycle and the many ways institutions manage it.
Our latest white paper explores these issues and offers practical questions universities can use when evaluating their approach to PGR management.
SkillsForge provides specialist software supporting the postgraduate research lifecycle, including admissions, supervision, progression, researcher development, thesis examination and reporting.