Rethinking Administrative Software Procurement in Medium-Sized Universities: A Socio-Technical Case Study of Embedded In-House Development

Highlights

Please indicate how your work links to systems science via your contributions to systems practice, theory, and or methodology.

• The article treats university teaching planning as a socio-technical system in which regulation, data, software, organisational routines, and professional roles interact.
• It contributes the mechanism of embedded adaptive governance, showing how shorter feedback loops among rule interpretation, workflow coordination, and software modification can improve systems practice.

What are the main findings and/or the implications of the main findings?

• In the case examined, an embedded system whose source code was institutionally accessible was associated with earlier process completion, improved data consistency, more systematic regulatory verification, and greater staffing readiness.
• The findings suggest that administrative software strategy should be evaluated by contextual fit, maintainability, auditability, and institutional capability, not only by procurement scale or enterprise functionality.

Abstract

Universities increasingly rely on administrative information systems that combine proprietary third-party software, legacy applications, and in-house tools adapted over time to changing regulatory requirements. Such changes are frequent, cumulative, and cross-cutting, and may contribute to fragmented socio-technical systems characterised by limited interoperability, inconsistent data, weak feedback mechanisms, and increased administrative burden. This paper examines these dynamics through a practice-based single-case study at a medium-sized European university. The case focuses on the annual preparation of the institutional teaching plan, a regulation-intensive process that determines teaching assignments, workload calculations, staffing needs, contracts, leave management, and compliance with applicable constraints. It analyses a targeted intervention involving the development and deployment of an in-house system designed to integrate previously dispersed data, encode regulatory constraints explicitly, support iterative user feedback, and enable rapid adaptation to institutional requirements. In the subsequent planning cycle, the process finished earlier and showed improved data consistency, more systematic regulatory verification, and greater staffing readiness. The paper shows how software architecture, embedded institutional knowledge, managerial coordination, and short feedback cycles jointly altered the governance conditions of a complex administrative process. Its contribution is to conceptualise administrative software procurement and development as a systems governance problem rather than merely a technical or purchasing decision.

1. Introduction

Universities increasingly depend on digital information systems to support core administrative functions [1,2], including academic planning, staff management, and regulatory compliance. These are no longer peripheral tools but integral components of institutional governance, shaping how decisions are made, how responsibilities are allocated, and how accountability is demonstrated, affecting entire communities of students, teachers and administrative staff. Higher education administration can therefore be understood as a complex socio-technical system in which software platforms, data structures, regulatory frameworks, organisational routines, professional roles, and user practices interact continuously, exhibiting similar dynamics to other public-sector digital contexts [3,4].

This framing is particularly relevant in higher education because administrative information systems must operate under conditions of continuing regulatory change. While the digitalisation of higher education administration is often discussed in terms of innovation or transformation, much of the day-to-day operational reality is characterised by incremental adaptation to changing legal, organisational, and procedural constraints [5,6]. Administrative processes are closely coupled with legal frameworks at national, regional, and institutional levels, which evolve asynchronously and often require rapid local interpretation. As regulatory requirements expand and expectations for transparency and efficiency grow, the capacity of administrative software to adapt to institutional needs becomes a strategic concern rather than a purely technical one [7,8]. Thus, system effectiveness depends less on advanced functionality in isolation than on the capacity of the wider socio-technical arrangement to accommodate continuous change without excessive cost, disruption, or administrative burden. The established socio-technical systems engineering literature similarly emphasises that information systems must be analysed in relation to organisational structures, work practices, stakeholder value, and the institutional settings in which they operate [9].

The case of medium-sized universities1 is challenging. Their administrative needs are typically moderate in scope, but they operate within regulatory environments that are as complex and dynamic as those faced by larger universities. Unlike very large institutions, however, medium-sized ones often lack the scale and resources required to justify or sustain comprehensive enterprise-level administrative platforms. Frequently, their internal information technology units operate under conditions of structural strain, maintaining heterogeneous systems, supporting legacy applications, and responding to urgent operational demands linked to regulatory deadlines. Such responsibilities leave limited capacity for proactive redesign of workflows or for systematic development of new administrative tools. Patching existing systems and implementing workarounds can be a rational response to immediate pressures, but they may result in longer-term fragmentation and technical debt [10].

Within this context, procurement-driven software models introduce additional constraints. Commercial administrative systems are typically developed under assumptions of relatively stable requirements, clear upfront specification, and predictable update cycles [11]. These assumptions do not align well with the adaptive, exception-driven nature of many university administrative processes. When requirements evolve rapidly or are only partially articulated at the outset, external systems may lag behind institutional needs or require costly and time-consuming customisation. From the vendors’ perspective, such limitations are often a rational consequence of serving diverse clients under contractual and regulatory constraints. From the institutional perspective, however, they can result in reduced flexibility and increased dependence on external actors for even minor changes.

The interaction among regulatory volatility, limited internal capacity, and procurement rigidity can create a perfect storm for administrative planning. Fragmented information systems, inconsistent data, and awkward user interfaces increase the effort required to coordinate across departments and to verify compliance with applicable rules [12]. Under such conditions, planning processes may rely on partial validation and informal assumptions of correctness, increasing operational risk and reducing institutional confidence in the outcomes. From a systems research perspective, these difficulties cannot be attributed solely to external providers or internal shortcomings; rather, they stem from structural misalignment between institutional pace, regulatory demands, and prevailing models of software acquisition and development.

This paper examines these dynamics through a practice-based case study conducted at a medium-sized European university. The study documents the development and implementation of an in-house academic staff management system, based on open-source software componentes, to address recurrent deficiencies in preparing the annual teaching plan. The term “teaching plan” refers to the institution-wide administrative process and resulting allocation that determines which academic staff teach which courses, in which programmes and periods, with associated workload calculations, contractual implications, and verification of applicable regulatory constraints. We focus on governance-related factors, particularly the role of embedded institutional knowledge, iterative co-design of workflows, and internal digital capability.

Accordingly, the study addresses three research questions:

• RQ1: How did fragmentation, regulatory volatility, and procurement constraints shape the preparation of the institutional teaching plan before the intervention?
• RQ2: How did an embedded, in-house development approach alter the governance conditions of the teaching-planning process?
• RQ3: What transferable mechanisms can be derived from this case for administrative software strategy in medium-sized universities?

The paper’s contribution is threefold. First, it provides an empirical account of how a resource-constrained institution addressed structural challenges in administrative planning by building internal digital capability. Second, it specifies a transferable mechanism of embedded adaptive governance: the shortening of feedback loops among regulatory interpretation, workflow coordination, and software modification. Third, it discusses implications for governance and policy by showing how administrative software procurement and development can be understood as a systems governance problem, particularly with respect to interoperability, adaptability, feedback, and the strategic use of open-source software components together with institutionally transparent development in medium-sized universities.

The remainder of this paper is structured as follows. Section 2 explains the case-study design, evidence sources, analytic procedures, and researcher positionality. Section 3 presents our institutional context and describes the initial situation, including the limitations of the pre-existing methods and the challenges observed during the 2024–2025 teaching plan preparation process. Section 4 details the diagnostic phase from an embedded management perspective, highlighting how operational insights informed the identification of key problems. In contrast, Section 5 outlines the design principles and development approach adopted for the in-house system. Next, Section 6 describes the development process, testing, and user co-design. Section 7 reports the implementation and main changes observed during the 2025–2026 planning cycle. Finally, Section 8 and Section 9 discuss the broader implications for governance, procurement, and software strategy in higher education, and present the main conclusions of the study.

2. Methods

This study is designed as an explanatory, practice-based single-case study. A single-case design was appropriate because the case offered unusually detailed access to a regulation-intensive administrative process before, during, and after a targeted socio-technical intervention. The purpose is not to estimate the isolated causal effect of a software artefact, but to explain how changes in software design, organisational coordination, embedded expertise, and feedback mechanisms jointly altered the governance conditions under which the teaching plan was prepared.

The case was selected because the preparation of the institutional teaching plan constitutes a critical and demanding administrative process. It connects teaching allocation, workload calculation, staffing needs, contract initiation, leave management, and compliance with multiple layers of regulation. It is therefore analytically useful for examining administrative software strategy in medium-sized universities, where functional complexity and regulatory volatility may be high even when institutional scale and internal technical capacity are limited.

The unit of analysis is the socio-technical teaching-planning process rather than the software system alone. Evidence was drawn from several sources: chronological records of the 2024–2025 and 2025–2026 planning cycles; operational knowledge generated during the 2024 diagnostic phase; system design and development records; structured internal testing activities using mock data; pilot feedback from administrative and academic users; system access records from the 2025–2026 deployment; and administrative observations concerning process timing, staffing readiness, user support, and the handling of regulatory constraints. These sources were used to reconstruct the sequence from diagnosis to deployment and to compare the governance conditions of the two planning cycles. Because the new system was developed for operational use rather than research, more detailed usage analytics, validation-rule execution statistics, and systematic incident databases were not part of its design.

The analysis followed a process-tracing logic:

• First, we reconstructed the pre-intervention process and identified recurrent bottlenecks related to fragmented data, shallow validation, manual reconciliation, and late recruitment initiation.
• Second, we traced how design principles and implementation decisions responded to those bottlenecks.
• Third, we compared the 2024–2025 and 2025–2026 cycles across timing, data consistency, regulatory verification, responsiveness to user feedback, and staffing readiness.
• Finally, we distinguished between changes directly observable in records and logs, such as process timing and system access, and interpretive claims based on participant feedback or informal estimates, such as perceived burden and trust.

Researcher positionality is important in this case. The first author was the vice-rector responsible for supervising the 2024–2025 teaching-plan process and subsequently led the development of the proof-of-concept system for the 2025–2026 cycle. This embedded managerial and development position provided close access to tacit organisational knowledge, informal routines, and practical constraints that would have been difficult to capture through external observation alone. It also creates a risk of confirmation bias and over-attribution. To mitigate that risk, the analysis distinguishes observed process changes from broader interpretations, reports approximate estimates as such, includes limitations explicitly, and draws on evidence generated by additional participants, including two internal IT engineers who conducted structured testing and users who participated in pilot and operational use.

The before-and-after comparison should therefore be read as evidence of plausible contribution rather than as a controlled causal evaluation. Earlier process initiation, managerial attention, altered coordination practices, and changes in the recruitment environment may also have contributed to the observed improvements. The contribution of the study lies in explaining the mechanism by which embedded development and internal digital capability can support administrative adaptability and auditability under regulatory volatility, not in claiming that the software alone caused all subsequent changes.

3. Institutional Context and Initial Situation

The case examined in this paper is situated in the University of Vigo, a medium-sized Spanish public university with a diversified academic offering and a multi-department organisational structure. As in many comparable institutions, preparing the annual teaching plan is a critical administrative process, as it determines teaching assignments, workload distribution, staffing needs, and the initiation of recruitment and contracting procedures. The process is subject to multiple regulatory frameworks, including national and regional legislation, collective agreements, and internal institutional policies.

To give a sense of the operational scale of the process, Table 1 summarises the numbers of database entries for the main types of data entities from 2025–2026. (The numbers would only be slightly different for 2024–2025).

Table 1. Operational scale and key data entities from 2025–2026.

Entity Type	Count
Internal academic staff	1770
External academic staff	954
Authenticated user accounts during operational use	1232
Teacher categories	36
Faculties	35
Departments	49
Knowledge areas	180
Degree programmes (undergraduate and postgraduate)	172
Subjects	4462
Teaching groups	13,026
Teaching assignments	18,713
Subject coordination assignments	4842
Hiring requests	565
Typologies for new contracts	43

3.1. Pre-Existing Information Systems Landscape

Prior to the intervention described in this study, there was no dedicated information system for preparing the teaching plan. The process was instead coordinated through spreadsheets distributed by the vicerrectorate to departments, complemented by a central database that stored historical teaching assignments after departmental decisions had been made. More broadly, the university’s administrative information systems functioned as a loosely coupled system of systems, consisting of a heterogeneous combination of third-party software and internally developed tools. Commercial systems were used to support specific administrative functions but offered limited flexibility in adapting to regulatory changes or local organisational practices. As a result, internal tools had been progressively developed and patched over time to address gaps in functionality and implement rules or constraints not supported by external platforms.

This hybrid arrangement aimed to reconcile compliance requirements with operational needs but resulted in a fragmented data landscape. Information relevant to teaching planning, staffing, and workload calculation was distributed across multiple systems, with partial overlaps and inconsistencies. Data exchange between systems was not seamless, and existing third-party tools provided limited support for exporting data in reusable formats. Conversely, importing newly produced data for subsequent planning cycles was similarly constrained, leading to additional manual work and an increased risk of error.

User-facing interfaces compounded these difficulties. Administrative and academic staff in departments were required to use spreadsheets, document templates, and system interfaces that were widely perceived as awkward and unintuitive. In roughly half of the departments, directors, deputy directors, or secretaries filled in the spreadsheets directly after contacting individual teachers about available teaching groups and unassigned hours. In the remaining departments, those same roles gathered information in local formats, such as text documents or department-specific spreadsheets, which were then processed by staff from departmental support units and uploaded to the historical assignments database. The burden of assisting users, validating inputs, transforming formats, and reconciling inconsistencies fell largely on internal technical and administrative staff, who were already operating under significant workload pressure.

3.2. The 2024–2025 Teaching Plan Preparation Process

In May 2024, a new management appointment initiated a diagnostic phase to understand existing administrative workflows and identify recurrent sources of difficulty in preparing the teaching plan for the following academic year. As shown in Table 2, the formal process to define teaching assignments, identify staffing gaps, and initiate recruitment was launched in the first week of June 2024.

Table 2. Comparison of the timelines of the teaching plan preparation processes for academic years 2024–2025 and 2025–2026.

Stage	2024–2025 Process	2025–2026 Process	Measurable Difference
Data preparation	Mid January–end of May	February–end of March	Approx. 2 months shorter
Process launch	First week of June	First week of April	Approx. 2 months earlier
Departmental inputs	June–mid July	April–mid May	Approx. 1.5 months earlier
Formal approvals	Mid July–end of July	End of May	Approx. 1.5–2 months earlier
Public calls for new contracts	Mid July–mid October (with staff working in the holiday period of August)	June–July	Ends approx. 2.5 months earlier
Start of the academic year	Numerous staffing gaps	Fully provisioned (practically)	Qualitative improvement in staffing readiness

The long data-preparation stage in the 2024–2025 cycle was not simply a matter of elapsed calendar time. It reflected several practical restrictions: relevant information had to be retrieved from multiple systems with limited export facilities; previous-year data could not be reused directly without manual checking; some staffing, leave, and workload information was represented differently across systems; and the central administrative team needed to prepare spreadsheets, documents, and instructions that departments could use without direct integration into the existing software landscape. The spreadsheets initially provided to departments contained several concrete defects: 474 research associates from 43 departments were missing, teaching groups were missing for 277 subjects, the number of teaching hours assigned to 224 professors was incorrect, and the templates offered no way to allocate hours to staff who would need to be hired for the following academic year. Comparable system-access logs are not available for that cycle, but the process involved the same institutional perimeter later represented in Table 1: 49 departments, 35 faculties, 172 degree programmes, central management and administrative staff, and academic coordinators responsible for validating or supplying teaching-allocation information.

Departmental submissions were received between the end of June and mid-July. During this period, internal staff were required to consolidate inputs from multiple sources, resolve inconsistencies, and perform basic checks against applicable regulations. Given the fragmented nature of the underlying data and the limited validation capabilities of the existing tools, verification focused primarily on the absence of major complaints or evident anomalies rather than on systematic enforcement of all regulatory constraints. In practice, it was tacitly assumed that if the departments raised no significant objections, the resulting plan would be sufficiently accurate for approval. Departments and departmental support units also had to create documents communicating teaching assignments to research associates and newly hired teachers. These documents were produced with ordinary word-processing templates, which were not always updated after regulatory changes. In the end, 426 such documents had to be checked by the vicerrectorate; 181 were returned to departments or support units for correction before the corresponding public hiring calls could be launched.

The teaching plan for the academic year 2024–2025 was ultimately approved in the final days of July 2024, immediately prior to the summer holiday period. This timing left an insufficient margin to initiate and complete recruitment and contracting procedures for newly required academic staff before the start of the academic year in September. As in previous years, the institution entered the academic year with unresolved staffing issues and a reliance on short-term or provisional arrangements.

The 2024–2025 planning cycle illustrates how structural conditions described in Section 1 materialised in operational practice:

• Fragmented systems and limited interoperability constrained the availability and consistency of data at the outset of the process.
• Awkward interfaces and manual consolidation increased the workload placed on internal staff and slowed down iteration with departments.
• Verification of regulatory constraints remained necessarily shallow due to the absence of integrated validation mechanisms and the time pressure under which the process unfolded.

Importantly, in line with the analysis of Abdelilah et al. [13], these outcomes were not the result of isolated failures or exceptional circumstances. Rather, they reflected the cumulative effects of regulatory volatility, constrained internal capacity, and reliance on software systems ill-suited to adaptive institutional processes. Within this context, the preparation of the teaching plan functioned as a survival exercise rather than as a fully controlled and auditable governance process, with limited opportunity for systematic process improvement.

4. Diagnosing the Problems from an Embedded Management Position

The diagnostic phase that preceded the development of the new system differed from typical requirements analysis exercises in one key respect: rather than being based on formal documentation, interviews, or external audits, the diagnosis emerged through direct involvement in the coordination of the 2024–2025 teaching plan preparation process. The first author, who held the vice-rectorate position responsible for supervising that process, also had professional training and experience in software engineering and subsequently undertook the development of the new system as an R&I effort towards a proof-of-concept. Firstly, this embedded position provided continuous exposure to both formal procedures and informal practices, as well as to the frictions that arose when existing information systems failed to align with regulatory or organisational needs. Secondly, it enabled direct translation of observed operational problems into technical design decisions without the need for intermediate specification or external mediation. As a result, the diagnosis was tightly coupled with an assessment of what could realistically be implemented within existing institutional constraints.

The diagnosis revealed a significant gap between perceived and actual constraints. In several instances, operational limitations were widely regarded as unavoidable consequences of the existing software landscape or of regulatory requirements, when in fact they reflected historical design decisions, fragmented workflows, or the limitations of legacy tools rather than intrinsic technical or legal barriers. Because these assumptions had become internalised over time, staff rarely articulated alternative possibilities or requested functionality beyond the scope of familiar practices. Once the underlying workflow logic had been reconstructed, many of the perceived constraints proved straightforward to address within a dedicated application.

Table 3 summarises the process-tracing logic used in the case. It links specific bottlenecks observed during the 2024–2025 cycle to the diagnostic evidence that made them visible, the design decisions adopted in the 2025–2026 system, and the outcomes observed after implementation.

Table 3. Observed bottlenecks, diagnostic evidence, design decisions, and outcomes.

Observed Bottleneck	Evidence During Diagnosis	Design Decision	Observed Outcome
Fragmented staff and teaching-group information	Spreadsheets omitted 474 research associates from 43 departments, lacked groups for 277 subjects, and had incorrect hours for 224 professors	Unified data model for staff, subjects, groups, workloads, and staffing needs	Shared reference data; no large-scale manual reconciliation of divergent spreadsheets
No representation of staff to be hired	Spreadsheets could not assign hours to posts to be recruited for the following academic year	Placeholders for future hires linked to assignments and hiring requests	Departments planned assignments before named staff existed; hiring requests were generated from the plan
Manual regulatory verification	Compliance checking relied on complaints, evident anomalies, and late central review under time pressure	Automatic validation rules embedded in entry and review	Violations detected during entry; no departmental plans returned for correction
Heterogeneous submission formats	Departments used vicerrectorate spreadsheets, local spreadsheets, or text documents later processed by support units	Single interface for departmental entry, review, and validation	Two thirds of departments entered assignments directly; support units handled remaining plans more efficiently
Error-prone hiring documents	426 documents were checked centrally in 2024–2025; 181 were returned for correction	Automatic generation and routing of required documents	No separate word-processed documents prepared by departments or support units
Repeated upload to the historical database	Support-unit staff transformed submissions and uploaded assignments after approval	Automatic upload after approval of each departmental plan	Approved assignments transferred without a separate manual upload step

One limitation of conventional procurement and consultancy approaches became evident during this diagnostic phase. Fully specifying institutional needs would have required translating a complex and evolving set of practices into formal requirements suitable for contractual definition. Given the tacit nature of much of the knowledge involved and the pace at which adjustments were required, this translation effort would have been both time-consuming and error-prone, inadequate for conventional requirements elicitation processes. At several points, it became clear that implementing a working solution iteratively would require less effort than exhaustively describing the problem space to a third party in advance.

Rather than relying on a single upfront specification, needs were articulated progressively through daily interaction with administrative and academic staff as concrete issues arose. This supported close co-design of workflows, in which proposed changes could be immediately assessed against regulatory constraints and operational practice. Feedback cycles were short, and misunderstandings could be resolved through direct observation and iteration rather than through extended documentation.

The embedded diagnostic process also had implications for trust and engagement. Because the identification of problems and the exploration of solutions occurred in close collaboration with those directly affected, proposed changes were perceived as responses to shared difficulties rather than as externally imposed interventions. This facilitated access to the tacit knowledge, reduced resistance to experimentation, and created a basis for subsequent user involvement in testing and refinement.

These factors (summarised in Table 4) shaped the decision to pursue an in-house development approach following the conclusion of the management appointment. The aim was not to replace existing systems wholesale but to address a clearly delimited, yet critical, process whose deficiencies had repeatedly undermined institutional planning. The diagnosis suggested that the primary barriers were not technological complexity but the absence of a system capable of evolving in step with institutional practice. In this sense, the development effort that followed can be understood as a response to a governance problem as much as to a technical one.

Table 4. Analytical contrast between procurement-driven and embedded development approaches in the case context.

Dimension	Procurement-Driven Model	Embedded Development Model
Requirement definition	Upfront, formal specification	Progressive, practice-based articulation
Knowledge basis	Explicit and documented	Tacit and contextual
Adaptation to regulatory change	Contractual or release-based	Iterative and locally coordinated
User involvement	Consultative	Co-design with operational staff
Cost of change	Negotiated and contractual	Internalised in local development capacity
System transparency	Mediated by provider and documentation	Directly inspectable by internal staff
Institutional learning	Indirect and specification-mediated	Direct and practice-based

5. Design Principles and Development Approach

The development of the new solution for the management of academic staff and teaching assignments was framed as a systems intervention. Rather than optimising an isolated application, the goal was to improve the behaviour of the wider administrative system by strengthening feedback loops, reducing fragmentation, clarifying system boundaries, and aligning technical artefacts with organisational and regulatory constraints. It was guided by five design principles derived directly from the diagnostic phase described in the previous section and from the bottleneck–decision chain summarised in Table 3:

• Institutional fit meant that the system was designed around the mission of preparing the teaching plan. Its purpose was not to provide a generalisable platform for broader or hypothetical future needs, but to respond directly to the specific requirements of this context.
• Rapid adaptability meant that the system could be adjusted quickly as regulations and user requirements evolved, without requiring extensive reconfiguration or contractual negotiation.
• Simplicity meant avoiding unnecessary abstraction layers, overly generic components, and architectural complexity, so that the system would remain comprehensible to internal technical staff and amenable to modification as requirements evolved.
• Transparency required that data structures, workflow logic, and validation rules be made visible rather than hidden behind opaque system behaviour. This would reduce reliance on informal explanations and enable stakeholders to understand how specific decisions and calculations were derived.
• Auditability required that regulatory constraints be encoded explicitly and verified systematically, rather than being left to implicit assumptions or post hoc checks. In this way, compliance could become a traceable and reviewable property of the system itself.

These principles translated the practical lessons of the diagnosis into a coherent development approach, as illustrated in Figure 1 and explained in the following subsections.

Figure 1. Design principles and derived development strategies.

5.1. In-House Development and Source-Code Governance

The decision to pursue an in-house development strategy was not motivated solely by cost considerations, although cost reduction was an important secondary effect. More fundamentally, in-house development was seen as a way to retain control over the pace and direction of system evolution. Given the frequency of regulatory changes and the institution’s limited tolerance for delay, the ability to implement and deploy modifications without external dependencies was critical.

The implementation relied extensively on mature open-source software components, avoiding dependence on proprietary technology wherever practical. This reduced vendor lock-in and facilitated long-term maintainability through the use of widely adopted technologies.

A separate design decision concerned the accessibility of the application’s own source code. From the outset, the university adopted a policy that made the complete implementation available for inspection by members of the institution. This institutional transparency supported peer review, technical discussion, knowledge transfer, and confidence in the encoding of administrative rules. The governance benefits discussed in this paper therefore derive primarily from source-code inspectability and institutional openness rather than from public distribution under an open-source licence.

At the time of writing, the choice of a public licence has intentionally been deferred pending potential inter-institutional interest in reuse or adaptation. Should other universities express interest in adapting the system, an appropriate open-source licensing model will be selected to support external reuse while remaining consistent with institutional policy.

5.2. Architectural Choices as Enablers of Adaptability

The need for rapid development, ease of maintenance, and clarity of behaviour guided architectural decisions. Rather than adopting a distributed or microservices-based architecture, the system was implemented as an integrated application with a unified data model. This approach reduced operational complexity and avoided introducing additional points of failure or coordination overhead that would have been difficult to sustain with limited internal resources.

The chosen architecture supported close coupling between data, validation logic, and user interfaces, which in turn enabled faster iteration during development and testing. Changes to regulatory rules or workflow logic could be implemented and validated end-to-end, without coordinating changes across multiple services or deployment pipelines. From an organisational perspective, this reduced the cognitive and operational load on internal staff and aligned the system’s technical structure with the institution’s scale and needs.

5.3. Temporal Alignment of Data, Regulations and System Design

A key design decision emerged from the recognition that regulatory frameworks governing teaching allocation and academic staffing change in ways that directly affect the semantic validity of administrative data. Rather than continuously updating the system used for one academic year to accommodate the new regulations of the next, the system was intentionally conceived as a self-contained deployment, with the codebase, database schema, and stored data remaining fully aligned with the regulatory context under which the data had been produced.

Managing each academic year as a coherent snapshot of code, data, and regulations was deemed a more robust approach than designing a single system to accommodate all regulatory variants simultaneously. This reflects an understanding of administrative software as temporally situated, where stability within a given regulatory context is prioritised over backward compatibility across divergent regimes. Attempting to incorporate the peculiarities of all regulatory regimes into a single, continuously evolving system would ultimately lead to increased complexity, reduced clarity, and higher long-term maintenance costs.

5.4. Positioning Relative to Comparable University Systems

The intervention should be situated relative to the broader landscape of university information systems, as the choice is not simply between proprietary enterprise platforms and isolated in-house development.

Large commercial platforms such as Oracle PeopleSoft Campus Solutions, Ellucian Student/Banner, and SAP Student Lifecycle Management are designed to support broad student-lifecycle or enterprise processes, including admissions, records, enrolment, advising, finance, curriculum, or related administrative functions [14,15,16]. These systems address institutional needs at a wider scale than the case examined here and can be appropriate where the priority is integration across established administrative domains, vendor-supported operations, and standardised process coverage.

Open-source and community-oriented initiatives occupy a different position. The Apereo ecosystem and related open-source higher-education initiatives emphasise shared digital infrastructure, community governance, and reuse across institutions [17,18]. Kuali represents a further hybrid model: a higher-education-specific platform and product family that includes academic operations, student information, research administration, financial management, and workflow automation, while retaining a strong emphasis on higher-education domain fit and institutional partnership [19].

The system analysed in this paper differs from these examples in its narrow scope and its governance logic. It was not intended to replace a student information system, ERP, or campus-wide platform. Its purpose was to address a specific process where regulatory interpretation, teaching allocation, workload calculation, staffing readiness, and local institutional knowledge were tightly coupled. Table 5 summarises the positioning. The point of comparison is therefore not product superiority, but fit between process characteristics and software-governance strategy.

Table 5. Positioning of the case relative to comparable university information-system strategies.

Approach	Typical Scope	Relevance to the Case
Large commercial SIS/ERP platforms	Broad student lifecycle, records, admissions, finance, curriculum, advising, and enterprise administration	Strong for standardised, cross-institutional administrative domains; less directly targeted at rapidly changing local teaching-plan rules unless configured or customised
Higher-education-specific cloud or platform suites	Domain-specific products for academic operations, student information, workflow, research, finance, or continuity planning	Relevant as hybrid models combining vendor support and domain fit; still require institutional translation of local rules and workflows
Open-source/community ecosystems	Shared components, learning platforms, collaboration, digital commons, and community-governed infrastructure	Relevant for inter-institutional reuse and shared governance, but require local capacity to adapt tools to specific regulatory contexts
Embedded in-house development	Narrow, institution-specific processes with high tacit knowledge and frequent regulatory adaptation	Relevant when local interpretation, rapid iteration, and auditability are more important than broad platform coverage

5.5. Framework Choice, Scalability and Appropriateness of Technological Complexity

This study does not provide a systematic evaluation of commercial alternatives, cloud services, or enterprise architectures. The comparison made here is conceptual and case-specific: it concerns the fit between different technology strategies and the needs observed in this institution. Within that boundary, the choice of development framework played a significant role in enabling the design principles outlined above. In particular, it highlights the importance of aligning technological complexity with realistic institutional needs rather than with generic assumptions about scalability, availability, or computational requirements.

• Scalability is frequently presented as a primary selling point of commercial administrative software and enterprise-oriented development stacks [20,21]. Such systems are often designed to accommodate rapid growth in users, data volume, or organisational complexity. In the context examined here, however, scalability was not the dominant design constraint. The relevant numbers of students, academic staff, and administrative units changed within bounded ranges, while the core difficulty lay in adapting the process to evolving rules, data definitions, and coordination requirements.
• Commercial and enterprise-oriented solutions also frequently emphasise high availability, continuous operation, and virtually unbounded computational capacity as core advantages [21,22,23]. Such characteristics are undoubtedly valuable in contexts where services must support uninterrupted access at a large scale or where computational demand is highly variable. In the process examined here, these requirements were less decisive. Staff typically operated within defined working hours; internal technical teams could establish resilient local infrastructure, and recovery from incidents could be planned within acceptable timeframes.
• Similarly, elastic computational capacity and large-scale cloud deployment were not central requirements in this case [23,24]. Teaching planning generated relatively modest volumes of data and involved bounded, time-limited patterns of concurrent activity.

In the context of this paper, adaptability to regulatory change, clarity of behaviour, and ease of maintenance under limited internal capacity were more central to sustaining day-to-day operations. As argued by Ayas et al. [25] and Bogner et al. [26], frameworks that prioritise integrated functionality over maximal scalability and, in addition, do not prescribe cloud-based deployments, can reduce the need for complex coordination across technical layers and allow development effort to focus on modelling institutional rules and workflows. Table 6 summarises these contrasts as design tendencies rather than as a ranking of specific products.

Table 6. Design tendencies associated with enterprise-oriented and proportionately scaled technology choices in university administration.

Dimension	Enterprise-Oriented Approach	Proportionate Approach
Primary design goal	Scalability, standardisation and generality	Maintainability and institutional fit
Typical architecture	Often distributed or service-oriented	Integrated, cohesive application
Handling of regulatory change	Absorbed through configuration or layered abstractions	Addressed through direct model evolution
Complexity management	Managed through provider tooling and specialised expertise	Managed through simplicity and local comprehensibility
Internal comprehensibility	May require specialised expertise	Prioritised for internal technical staff
Availability assumptions	Often oriented to continuous 24 × 7 service availability	Availability aligned with administrative workflows
Incident recovery model	Provider-managed or SLA-driven	Institution-managed, rapid local recovery
Computational capacity	Elastic or provisioned for peak demand	Sized to realistic and bounded workloads
Infrastructure model	Cloud-based or hybrid	On-premises or hybrid, context-dependent
Cost of evolution	Potentially cumulative through customisation and contracts	More predictable when internal capacity is sustained
Time to incorporate changes	Often tied to release or service cycles	Short, iterative cycles
Dependence on external vendors	Potentially substantial	Reduced but not eliminated
Suitability for medium-sized universities	Context-dependent	Context-dependent

Several characteristics of using an integrated framework were consequential in practice:

• Built-in support for administrative interfaces enabled the rapid availability of functional back-office tools with minimal development effort, facilitating early validation of data models and workflows.
• Explicit and readable approaches to data access and query construction supported transparency and ease of review, making system behaviour accessible to internal staff without extensive prior exposure.
• Integrated mechanisms for managing database schema evolution further supported incremental change by allowing regulatory updates to be reflected systematically over time.
• Features for rapid cloning, database migration management, adaptation, and controlled evolution of code and data structures facilitated the snapshot-based strategy explained in Section 5.3.

From a governance perspective, these features contributed to institutional autonomy by keeping the system comprehensible and modifiable by a small internal team. Rather than optimising for hypothetical future scale, the framework choice reflected an assessment of likely institutional trajectories and the need to sustain internal ownership of both the system and the knowledge embedded within it.

6. Development, Testing and Co-Design

The diagnostic process yielded a clear understanding and a stable vision of the desired workflows, data structures, and regulatory logic. On this basis, a first fully functional prototype could be implemented in a single continuous development phase. That was followed by internal testing and subsequent rounds of feedback from academic and administrative users who tested incremental prototypes. The process is illustrated in Figure 2 and explained in the following subsections. The role labels in the figure require one clarification: the management staff member shown in the diagnosis and vision stage was the vice-rector supervising the 2024–2025 teaching-planning process; after completing the diagnosis and vision in July 2024, he resigned from that position and returned to his regular academic duties in the Telematics Engineering department, which is why the same individual appears in later stages as one member of the academic IT staff.

Figure 2. Stages and people involved from diagnosis to operational deployment. The management staff member in the first stage is the vice-rector who supervised the 2024–2025 process; after July 2024, the same person appears as one academic IT staff member following his return to regular departmental duties.

Feedback was collected throughout prototype demonstrations, videoconference meetings, and subsequent operational use by academic and administrative staff. Comments were received either by email or documented during live demonstrations by videoconference, and subsequently translated into implementation tasks within the project’s development backlog. During successive development iterations, backlog items were reviewed jointly with users to determine whether they reflected regulatory requirements, workflow improvements or usability refinements. Most suggestions resulted in incremental refinements rather than major redesign. Several requests initially duplicated functionality already available in the system and therefore led to user-interface improvements that made existing features easier to discover. A small number of requested extensions were intentionally deferred because they fell outside the scope of the initial operational deployment.

6.1. Initial Functional Prototype

Following the completion of the diagnostic phase at the end of July 2024, development work has focused since mid-August on delivering a functional prototype capable of supporting the core elements of the teaching planning process. Priority was given to modelling teaching assignments, workload calculations, and key regulatory constraints identified during the diagnostic phase. By mid-September 2024, after approximately 200 h of development effort, the proof-of-concept was available and presented to the university’s senior management team. At this point, it was agreed that the software’s intellectual property would belong to the university. At the same time, it was agreed that the source code would remain fully accessible to members of the University of Vigo. This institutional policy allowed technical staff and other interested members of the university community to inspect the implementation, discuss design decisions, identify potential improvements, and contribute suggestions during subsequent development. The choice of a public open-source licence was deliberately deferred until there was evidence of interest from other institutions in reusing or adapting the software. This approach separated the governance benefits of source-code transparency within the institution from the later question of external distribution and licensing.

This initial prototype was not intended as a production-ready system but as a concrete artefact through which assumptions about workflows, data structures, and validation logic could be examined. Its early availability allowed institutional decision-makers to engage with a working representation of the proposed approach rather than abstract specifications, facilitating more focused discussion of feasibility and alignment with practice.

6.2. Structured Testing by Internal IT Staff

Following the initial validation of the prototype’s overall direction and the approval of the proof-of-concept, two academic IT staff (telecommunication engineers) were appointed to conduct systematic testing of the system. None of them had prior experience with the development framework used, which allowed the testing process to also serve as an informal assessment of code readability and approachability.

To avoid risks associated with handling sensitive personal or contractual information, all testing was performed using mock data specifically constructed for this purpose. The test datasets were designed to be sufficiently rich and diverse, intentionally covering rare, borderline, and atypical cases that were unlikely to appear frequently in real operation but were critical for assessing robustness and regulatory compliance.

Testing proceeded in three phases:

• In the first phase, black-box testing was conducted to simulate the behaviour of different categories of users, including inexperienced, average, and exploratory users, as well as intentionally ill-intended interactions. This phase focused on identifying unexpected behaviours, data integrity issues, and potential misuse scenarios under a wide range of conditions.
• In the second phase, white-box testing was performed, enabling the engineers to inspect the internal logic of the system and to assess the clarity, consistency, and maintainability of the codebase.
• In the third phase, an assessment of compliance with data protection regulations (European GDPR and national law) and a cybersecurity audit were conducted internally, documenting any issues to address them in parallel with the subsequent pilot activities.

Most reported issues resulted in incremental refinements rather than major redesign. Several suggestions initially appeared to duplicate functionality already available in the system; instead of adding alternative implementations, these comments led to improvements in the user interface that made the existing functionality easier to discover and use. A small number of requests were intentionally deferred because they addressed desirable extensions beyond the scope of the first operational deployment.

It is worth noting that many baseline security concerns were addressed from the outset through the choice and disciplined use of the development framework (see Section 5.5), which incorporated standard protections against vulnerabilities such as injection attacks, cross-site scripting, cross-site request forgery, and insecure session management. As a result, the subsequent internal review focused primarily on configuration, access controls, and deployment-related safeguards.

The tests were completed by the end of November 2024, with a total effort of approximately 50 h per person. In addition to identifying issues and suggesting improvements, the engineers rapidly familiarised themselves with the system’s structure and contributed to interface refinements and multilingual adaptation. They even refactored the code to facilitate localisation of the interfaces, and thereby made the system available in two languages to reflect institutional language practices.

6.3. Pilot Use and Co-Design with Real Users

Between December 2024 and February 2025, the system was deployed in pilot mode with a limited but growing group of administrative and academic staff (5 in the first round, more than 30 in the last). Unlike the earlier testing phases, this stage involved interaction with real users but was carefully scoped to avoid operational risk. The pilot focused on workflow validation, the usability and interpretability of system feedback, rather than on processing definitive institutional data.

User interactions during this period revealed additional opportunities for improvement, particularly in task sequencing, the presentation of validation feedback, and the reduction of redundant data entry. Because development and deployment were closely coupled, insights from pilot use could be translated into concrete changes with minimal delay. Approximately 50 additional hours of development were required to incorporate these refinements. This responsiveness reinforced user engagement and contributed to the perception that feedback was actively shaping the system, in contrast to previous experiences with external tools.

6.4. Responsiveness During Operational Use

The system was finally used to prepare the teaching plan for the 2025–2026 academic year. During the period when it was open to departmental inputs, several suggestions and requests for improvement were received, including interface refinements, minor workflow changes, and clarification of validation feedback. They were all addressed overnight or within a few days, requiring an estimated additional 30 h of development effort.

This level of responsiveness would have been difficult to achieve under a third-party provision model, where changes typically require formal requests, negotiation, and scheduled releases. In the present case, rapid iteration fostered a sense of institutional ownership and improved trust among administrative staff, academic departments, and technical support.

6.5. Summary of Development Effort and Validation

In total, the development and refinement of the system required approximately 280 h of primary development and adaptation work: around 200 h for the initial proof-of-concept, 50 h for refinements after pilot use, and 30 h for operational adjustments during the 2025–2026 process. This was complemented by approximately 100 h of structured testing by two internal engineers, plus additional localisation and user-support effort. Although these figures are necessarily approximate, they provide an order-of-magnitude indication of the effort required for the intervention.

Crucially, the use of mock data during intensive testing phases allowed the system to be stressed against extreme and uncommon scenarios without compromising data protection or institutional operations. Combined with subsequent pilot use and full operational deployment, this iterative validation process reduced both technical and organisational risk and supported systematic learning about workflows, regulatory interpretation, and data stewardship.

7. Implementation and Outcomes

The new system was used in full operational mode to prepare the teaching plan for the academic year 2025–2026. This section describes its adoption within the institutional process and summarises the observable changes, with particular attention to timing, data quality, regulatory verification, user effort, and organisational effects.

7.1. Overview of the 2025–2026 Planning Process

As shown in Table 2, preparations for the academic year 2025–2026 started in February 2025. In contrast to previous years, the initial data were available and correct from the outset, including the information about research associates. Thus, the 49 departments and associated administrative units could start entering and reviewing data in early April 2025 and were given a deadline in mid-May. To address the heterogeneous submission formats identified during diagnosis (Table 3), approximately two thirds of the departments had directors, deputy directors, or secretaries enter teaching assignments directly for all teachers in their departments, including research associates and placeholders for staff to be hired. In the remaining third, staff from departmental support units entered the assignments through the same system, avoiding the previous need to handle local spreadsheets or text documents and later upload the information manually to the historical assignments database.

Institutional resilience was achieved not through redundant cloud-based infrastructure but through a combination of modest technical provisioning and organisational capacity for rapid recovery. Eventually, the system was accessed by 1232 authenticated user accounts, corresponding to 69.6% of the 1770 internal academic staff members shown in Table 1. These accounts represent users who logged into the operational system during deployment; they do not constitute a sampled evaluation cohort. They should not be interpreted as 45.2% of all internal and external academic staff, because the latter did not access the system: they were included in the data model for assignment and historical-record purposes, but were not directly involved in preparing departmental teaching plans. Comparable logs are not available for the 2024–2025 cycle because of how the process was conducted using spreadsheets distributed by email. The sustained concurrent access by hundreds of users took place without performance degradation, revealing no immediate need in this process for elastic scaling or continuous operation guarantees.

Because the system consolidated data previously distributed across multiple tools, departments, and administrative units, participants worked with a shared, consistent reference. Responding to the manual verification bottleneck identified in Table 3, validation rules reflecting applicable regulatory constraints were applied systematically as data were entered, allowing issues to be identified and resolved incrementally rather than during a final consolidation phase. This reduced the need for extensive manual reconciliation and clarification between departments and central administration. No departmental plans had to be returned by the vicerrectorate for correction, and the documents required for public hiring calls were generated automatically and routed to the responsible service. The new system also uploaded approved assignments to the historical database automatically. Based on administrative monitoring during the process, the number of emails and phone calls about related questions decreased from hundreds to tens —this figure should be treated as an operational estimate rather than a formally logged metric.

7.2. Timeliness and Process Reliability

The most immediately visible change in the 2025–2026 cycle was a substantial improvement in timeliness. As shown in Table 2, whereas the 2024–2025 teaching plan was approved only in the final days of July 2024, the 2025–2026 plan was completed and validated by mid-May 2025. This shift created sufficient margin to promptly initiate recruitment and contracting procedures for newly required academic staff, enabling the institution to enter the new academic year in September, fully provisioned from its outset. The timing improvement should be interpreted as the combined result of the new system, earlier preparation, and strengthened managerial coordination.

Beyond calendar effects, the process itself became more predictable and less reliant on informal assumptions. The shared visibility of planning data allowed departments to observe not only their own progress but also that of other units, facilitating implicit benchmarking of workload balance and completion status across the institution. This transparency made the consistent application of rules visible and verifiable, reducing perceptions of discretionary treatment and reinforcing trust in the process. Systematic verification of regulatory constraints further reduced uncertainty, and the early availability of consolidated data allowed potential issues to be addressed before they became critical. From an operational perspective, the planning process transitioned from a time-critical survival exercise to a controlled, transparent, and auditable workflow.

7.3. Effort Reduction and Perceived Bureaucratic Burden

A further observed change concerned the effort required from academic and administrative staff in departments responsible for providing input data for each degree programme. Compared with previous years, the time needed to enter, review, and correct information was substantially reduced according to participant feedback. As anticipated by the design response to heterogeneous submission formats in Table 3, contributors interacted with a single interface that reflected their actual workflows and received immediate feedback on the types of validation issues previously handled through manual checking, returned documents, emails, and clarification requests.

Although precise time measurements were not systematically collected, informal estimates across departments place the cumulative hours saved at the institutional level between approximately 1200 and 1800 h. This range is reported as a perception-based operational approximation, not as a measured productivity indicator. It includes several sources of effort reduction: directors, deputy directors, and secretaries no longer needed to coordinate teacher preferences mainly through email or manually familiarise themselves with all constraints before checking compliance; teachers who logged into the system could browse available subjects and unassigned hours directly and review the full departmental plan before approval; departmental support units no longer had to process heterogeneous local formats or manually upload assignments to the historical database; and vicerrectorate staff avoided repeated checking, correction, and explanation of defective documents. The perceived reduction in effort translated not only into lower distributed workload but also into a noticeable decrease in perceived bureaucratic burden. Contributors reported that the process felt more purposeful and less repetitive, as the system made explicit how their inputs were used and how they affected the overall teaching plan. Additional savings also arose from modifications of the teaching plan during the academic year, for example due to sick leave or other contingencies, but these later savings were not estimated for this study.

From a governance perspective, this reduction in distributed effort is very significant. Administrative burden is often experienced diffusely across departments and therefore remains underrepresented in formal evaluations of information systems [27]. By lowering the marginal cost of participation for individual contributors, the new system improved both efficiency and acceptance of the planning process.

7.4. Data Consistency, Transparency and Verification of Regulatory Constraints

The use of a single system with an integrated data model improved consistency across information on teaching assignments, workloads, and staffing requirements. Consistent with the fragmented-information bottleneck shown in Table 3, discrepancies that had previously arisen from divergent representations of the same data were largely eliminated, including the spreadsheet-level omissions and incorrect teaching-hour figures identified during the 2024–2025 diagnosis. Because validation logic was applied uniformly, exceptions and edge cases were explicitly identified rather than being implicitly absorbed through manual correction.

Transparency also improved at multiple levels. Administrative staff could trace how specific figures and allocations were derived, while departments had immediate visibility into the implications of their inputs. This shared visibility reduced misunderstandings and the need for repeated clarification, and it supported more informed discussion about workload distribution and staffing decisions.

Importantly, regulatory verification was no longer assessed solely through final checks or the absence of complaints. Instead, verification became an integral part of the data entry and review process. While human judgment remained necessary in interpreting certain rules, the system ensured that relevant constraints were consistently considered and documented.

7.5. Responsiveness and User Engagement

During operational use of the new system, as explained in Section 6.4, several user requests and suggestions were incorporated with minimal delay, often within a single day. The effort required was modest, but this level of responsiveness had noticeable organisational effects. Users reported feeling listened to and supported, and the rapid incorporation of feedback reinforced trust in the system and in the process more broadly. Participants frequently noted the contrast with previous experiences of requesting changes to third-party systems, which often involved formal procedures and extended delays.

8. Discussion

The implementation and deployment of the new in-house system illustrates how targeted internal development of administrative software can contribute to altered governance conditions under which critical institutional processes are carried out. The relevant unit of analysis is not only the software artefact, but the coupled socio-technical system through which institutional planning, compliance, and staffing decisions are produced. The discussion therefore separates observed case findings from broader theoretical and policy implications.

8.1. Observed Findings and Plausible Mechanism

The directly observed findings concern process timing, the availability of integrated data, systematic validation of regulatory constraints, system-access records, testing activity, and the completion of recruitment procedures before the start of the academic year. Read together with Table 3, these findings show how specific implementation decisions addressed diagnosed bottlenecks rather than simply introducing a new interface. Other findings, including perceived trust, lower bureaucratic burden, and hours saved, are based on operational estimates and participant feedback, and should be interpreted more cautiously.

The case nevertheless suggests a coherent mechanism shown in Figure 3, revealing that embedded development reduces translation loss between regulatory interpretation, workflow design, and software implementation, thereby shortening the feedback loops through which institutions adapt administrative processes to changing rules. Regulatory volatility increases the importance of tacit institutional knowledge, because applicable rules must be interpreted in relation to local staffing categories, workload conventions, departmental practices, and approval routines. When this knowledge is difficult to specify in advance, procurement and conventional requirements definition become vulnerable to translation loss. Embedded development changes this relationship by coupling rule interpretation, workflow redesign, and software modification close to the point of use. We refer to this mechanism as embedded adaptive governance: a socio-technical arrangement in which local knowledge, technical modifiability, and managerial coordination reinforce one another to make administrative processes more adaptable and auditable. This mechanism, rather than the software artefact alone, explains why the 2025–2026 cycle could proceed under more favourable governance conditions.

Figure 3. Mechanism linking regulatory volatility, embedded development, and planning capability.

8.2. Embedded Development and Institutional Capability

A central finding of the study concerns the role of embedded development in articulating and addressing institutional needs. The intervention’s effectiveness appears closely linked to the fact that the identification of deficiencies and bottlenecks, as well as the system design (from user interfaces to workflows), emerged from within the operational context of university management. This enabled access to tacit knowledge, reduced translation overhead between problem definition and implementation, and supported iterative co-design with administrative and academic staff.

In terms of Figure 3, embedded development is the point at which tacit knowledge becomes operational capability rather than remaining an informal workaround. From a governance perspective, this suggests that digital capability should be understood as an institutional resource rather than a purely technical service, in line with the views of Kelder et al. [28]. The ability to observe processes in situ, identify misalignments, and implement changes rapidly contributed to improved coordination and trust across organisational units. These effects are difficult to achieve through external provision alone, particularly when institutional practices are evolving or only partially formalised [29].

At the same time, the case highlights the fragility of such capability when it relies heavily on a small number of individuals. While embedded expertise proved effective in this instance, it also raises questions about sustainability, knowledge transfer, and organisational resilience. These considerations are addressed further below.

8.3. Procurement Models and the Limits of Specification

The outcomes observed in the 2025–2026 planning cycle point to structural tensions in procurement-driven approaches to administrative software. Such models often assume that institutional requirements can be specified upfront with sufficient stability [30] and that regulatory constraints can be verified against relatively static definitions of correct behaviour. In environments characterised by regulatory volatility and exception-driven workflows, these assumptions may be difficult to sustain.

The case suggests that part of the cost and delay associated with third-party systems may arise not from technical complexity per se but from the effort required to translate evolving institutional practices into contractual specifications. This corresponds to the specification-problem stage in Figure 3. When this translation is incomplete or outdated, institutions may compensate through patching, workarounds, or parallel processes, increasing both technical debt and administrative burden. In this sense, the difficulties encountered in the initial situation reflect a possible misalignment between institutional pace and procurement logic rather than isolated vendor shortcomings.

8.4. Scalability, Adaptability and Appropriate Technological Fit

A further implication concerns the emphasis on scalability in selecting administrative software. Commercial systems and enterprise-oriented architectures often prioritise the ability to support rapid growth in users or data volume. While such capabilities are essential in some contexts, they may be overemphasised when applied to bounded, periodic administrative processes such as the one examined here.

For the institution examined here, the primary challenge was not scaling up operations but adapting continuously to regulatory change while maintaining clarity and control over workflows. Frameworks and architectures that favour integration and comprehensibility over maximal scalability appeared better aligned with these needs because they supported the shorter feedback loops identified in Figure 3. The decision to manage administrative systems as temporally coherent snapshots (regulations, code, data) further reinforces the argument that compliance is an ongoing institutional capability rather than a static software property.

This does not imply that scalability is irrelevant, but rather that it should be considered alongside factors such as maintainability, transparency, and internal capacity. Similar considerations apply to assumptions about continuous availability and computational capacity, which are often seen as indicators of technical maturity. Enterprise-oriented administrative systems often emphasise 24/7 availability and elastic computing resources as default requirements, implicitly treating administrative services as mission-critical infrastructures comparable to large-scale transactional platforms. While such characteristics are appropriate in contexts with round-the-clock operational demands or highly variable workloads, their relevance was more limited in the periodic planning process examined here.

The observed capacity of on-premises equipment to serve the concurrent load encountered in this process suggests that availability and computational capacity should be treated as context-dependent design parameters rather than as universal benchmarks of quality. In comparable contexts, overprovisioning infrastructure to satisfy abstract availability targets can introduce unnecessary cost, complexity, and external dependence, without proportionate gains in administrative effectiveness. For institutions facing bounded usage patterns, aligning infrastructure choices with realistic demand may support both sustainability and institutional autonomy. As with scalability, the critical question is not whether systems can operate under extreme conditions, but whether they remain understandable, adaptable, and governable under the conditions that institutions actually face.

8.5. Administrative Burden and Organisational Effects

The reduction in time and effort required from departmental contributors highlights an often-overlooked dimension of administrative digitalisation. Bureaucratic burden is experienced diffusely across institutions and is rarely captured in formal performance indicators. However, it has tangible effects on staff morale, compliance behaviour, and willingness to engage constructively with administrative processes [8].

By lowering the marginal cost of participation and making the consequences of input more visible, the new system appears to have altered how contributors perceived the planning process. In the mechanism proposed here, this is part of the transition from adaptive governance to improved planning capability: the process became easier to supervise, validate, and complete before downstream staffing deadlines. The observed reduction in distributed effort suggests that investments in internal capability can yield benefits that extend beyond efficiency gains at the central level. These organisational effects are particularly relevant in environments where administrative demands compete with core academic activities.

An interesting observation is that, for many departmental contributors, the time savings achieved with the new system did not lead to disengagement from the process. On the contrary, they were able to reinvest attention in supervising it, including validating inputs from other departments and ensuring that rules were applied consistently across the institution. System logs recorded frequent inter-departmental queries and cross-checks, reflecting a form of collective supervision that contributed to perceptions of transparency and fairness across the institution.

8.6. Limitations, Sustainability and Transferability

Several limitations of the study should be acknowledged. First, the intervention benefited from unusually close alignment between management responsibilities and IT systems engineering. In the case described, the first author was both the vice-rector supervising the 2024–2025 planning process and the developer who led the proof-of-concept system for the following cycle. This dual role enabled rapid translation of observed operational issues into technical design decisions, but it also concentrated interpretive authority and technical knowledge in one person. However, this effect does not depend on a single individual combining both roles. Comparable outcomes could be achieved through sustained, close collaboration between management staff and internal technical personnel, with only limited additional coordination overhead.

Second, the case focuses on a single institution and a specific administrative process, which constrains the direct generalisability of the findings. However, preparing the institutional teaching plan is among the most complex and regulation-intensive processes in university administration, as it intersects staffing, workload allocation, contractual arrangements, and multiple layers of regulation. Thus, the process examined represents a demanding test case rather than a marginal or atypical scenario.

Third, the evidential basis is not equivalent to a controlled evaluation. The deployed application was designed as an operational administrative system rather than as a research platform. Consequently, its instrumentation was limited to what was required for routine institutional operation, and detailed usage analytics, validation-rule execution statistics, and systematic incident databases were not collected. Precise time-use measurements were likewise not gathered before and after the intervention, perceptions of bureaucratic burden were not assessed through a formal survey instrument, and several organisational changes occurred alongside the deployment of the system. The study therefore relies on documented operational outcomes and institutional records rather than research-oriented usage analytics, execution statistics or incident databases. Thus, the comparison with commercial or enterprise systems should be understood as an interpretation of fit between observed institutional needs and alternative software-governance models rather than as a systematic market evaluation.

Fourth, the approach creates its own risks. Internal ownership increases autonomy but also transfers responsibility for maintenance, security governance, documentation, user support, and long-term funding to the institution. The embedded-development model depends on sustaining institutional capability beyond the involvement of individual developers; otherwise, internal ownership can become a new form of dependency rather than a governance capacity. Dependence on a small number of knowledgeable individuals can create continuity risks if key staff leave or if knowledge is not deliberately transferred. This is the most important practical vulnerability of the model: if the original developer leaves, the institution may retain the source code but lose the interpretive knowledge that connects regulatory rules, data structures, interface choices, and operational routines.

The sustainability of embedded adaptive governance therefore depends on converting individual expertise into institutional capability. At minimum, this requires institutional ownership of the repository and deployment environment; documented installation, backup, recovery, and release procedures; a decision log explaining why major data-model and validation choices were made; test datasets covering standard and exceptional regulatory cases; explicit allocation of maintenance responsibility to more than one person; and a planned handover period in which another developer or internal IT engineer can modify the system before the original developer exits. It also requires governance of security responsibilities, including access-control review, dependency updates, vulnerability monitoring, incident-response procedures, and periodic reassessment of compliance with data-protection requirements.

These requirements define important boundary conditions for the approach. Embedded development assumes some internal technical capability, institutional commitment to maintaining that capability over time, and governance arrangements that allow close interaction between technical and administrative staff. Universities lacking these conditions may obtain greater value from hybrid or vendor-supported approaches. Likewise, this study quantifies development and testing effort but does not include a formal economic cost–benefit analysis; future work should compare long-term maintenance, staffing, procurement, infrastructure, security-governance, and opportunity costs across alternative software strategies.

The snapshot-based approach introduces an additional sustainability issue. Separate annual instances preserve semantic consistency between code, data, and regulations, but they also multiply artefacts that must be named, archived, secured, and occasionally consulted. Institutions adopting this approach need explicit rules for which instances remain read-only, which security fixes are backported, how long each instance is retained, and who can access historical data. Without such rules, annual snapshots could themselves become a source of fragmentation. Thus, snapshot-based evolution is not a substitute for maintenance governance; it is a maintenance strategy that must be governed deliberately.

For these reasons, the approach should not be read as a general argument against commercial systems, cloud services, or enterprise architectures. External systems remain appropriate for stable, standardised, high-volume, or legally specialised functions. The implication is more limited: universities should distinguish processes that benefit from standardisation and external provision from processes whose regulatory volatility, tacit knowledge, and local coordination demands make internal adaptive capability strategically important.

The system described in this study was developed using widely adopted open-source components and a web development framework with a strong emphasis on readability. Combined with a deliberately simple architectural design, this reduced barriers to understanding, inspection, and modification by internal staff beyond the original developer. As demonstrated during the testing phase, internal engineers with no prior exposure to the chosen framework were able not only to familiarise themselves with the codebase quickly but also to contribute substantially to its evolution by implementing new modules, refining existing functionality, and actively participating in testing, interface improvements, and localisation efforts. This suggests that transferability does not depend solely on replicating specific technologies, but on adopting development practices that prioritise transparency and comprehensibility over unneeded architectural sophistication. Avoidance of excessive abstraction layers, distributed architectures, or framework complexity can be particularly important in institutions with limited internal technical capacity. In such contexts, open-source solutions and readable codebases support knowledge transfer, reduce dependency on individual developers, and lower the long-term cost of ownership by enabling institutions to retain control over system evolution.

From this perspective, the case’s relevance extends beyond the specific institutional setting. While not all universities can replicate the precise conditions described, many face similar constraints in terms of scale, regulatory volatility, and staffing. For these institutions, the combination of embedded expertise, open-source software, readable implementation, and restrained architectural ambition represents a plausible strategy for enhancing institutional autonomy and sustaining internal digital capability.

9. Conclusions

Overall, this study highlights the value of systems thinking for administrative digitalisation in higher education. Treating administrative software as part of a wider socio-technical system makes visible the interdependencies among regulation, data, organisational routines, procurement models, and institutional capability. The case suggests that modest, targeted interventions can have substantial governance relevance when they shorten feedback loops among regulatory interpretation, workflow coordination, and software modification.

9.1. Implications for Governance, Policy and Procurement

At the institutional governance level, the findings suggest that administrative software should be treated as a strategic asset rather than a neutral commodity. Decisions about tools, architectures, and development models shape how institutions interpret regulations, distribute workload, and manage risk. For medium-sized universities operating under conditions of regulatory volatility and constrained internal capacity, flexibility, adaptability, and internal ownership may be more consequential than scale, feature breadth, or computational elasticity.

Procurement practices in higher education often prioritise compliance guarantees, scalability, resilience, and standardisation, with more limited attention to how systems will evolve once deployed or how their constraints will be experienced across the institution. The case discussed here indicates that such criteria may underestimate the long-term costs associated with rigidity, delayed adaptation, and accumulated administrative burden [31]. Policy frameworks that encourage institutions to retain some degree of internal control over critical administrative processes may therefore support more sustainable governance outcomes.

From a policy perspective, the findings also point to the need for a nuanced evaluation of digitalisation initiatives. Efficiency gains should not be assessed solely in terms of central administrative effort or direct financial cost, but also account for distributed effects across departments and academic units. Reductions in perceived bureaucratic burden, improvements in process transparency, and the capacity to respond rapidly to regulatory change are relevant outcomes that merit explicit consideration in policy discussions.

9.2. Implications for Software Strategy in Medium-Sized Universities

For institutional decision-makers, the study highlights the potential value of investing in internal digital capability, even on a modest scale. Such investment need not imply abandoning external systems altogether, nor does it require treating in-house development as an all-or-nothing alternative. Rather, the findings support a differentiated or hybrid strategy in which stable, standardised functions may be supported by third-party software. At the same time, processes that are highly context-dependent, operationally critical, or subject to frequent regulatory change may warrant stronger internal control or closer internal–vendor coordination.

The case also underscores the importance of aligning technological ambition with institutional realities. Source code transparency, readable codebases, and restrained architectural complexity can lower barriers to understanding and modification, enabling knowledge transfer and reducing long-term dependence on external expertise. In environments where internal IT staff are limited in number and frequently overstretched, avoiding unnecessary architectural sophistication can be a strategic choice rather than a technical compromise.

A further strategic implication concerns how universities manage the relationship between regulatory change and the temporal validity of administrative data. The case illustrates that regulatory frameworks do not merely add new constraints but can alter the meaning and admissibility of existing data. Under such conditions, attempting to maintain a single, continuously evolving system that accommodates all past and present regulatory regimes risks conflating historically valid data with current compliance requirements, thereby increasing conceptual and technical complexity. Table 7 summarises these alternative strategies for handling regulatory change in administrative information systems and their typical consequences.

Table 7. Alternative strategies for handling regulatory change.

Strategy	Description	Typical Consequences
Continuous evolution	Single system updated incrementally across regulatory changes	Accumulating complexity and fragile logic
Backward compatibility	One system supports all historical and current regulatory regimes	Semantic ambiguity and high maintenance cost
Snapshot-based approach	Separate system instances aligned with specific regulatory contexts	Internal consistency and reduced technical debt

Managing administrative systems as temporally coherent snapshots—each aligning code, data structures, and regulatory assumptions for a given academic year—offers an alternative strategy that prioritises internal consistency and interpretability over backward compatibility. This approach recognises that data correctness is inseparable from the regulatory context in which the data were produced and used. Rather than treating regulatory change as an exception to be absorbed through conditional logic and special cases, it is treated as a boundary between successive, self-consistent system instances.

For medium-sized universities, this strategy may be particularly advantageous. Limited internal capacity makes the long-term maintenance of highly generalised systems costly and fragile. At the same time, regulatory volatility undermines the assumption that a single unified model can remain semantically stable over time. By contrast, snapshot-based system evolution allows institutions to preserve reliable historical records, reduce cumulative technical debt, and adapt decisively to new regulatory conditions without destabilising existing operational processes. In this sense, restraint in system generality can be understood not as a limitation but as a deliberate governance choice.

9.3. Generative AI and Internal Capability

Recent advances in AI-assisted software development further sharpen the distinction between technical implementation and institutional understanding highlighted in this study [32]. While contemporary tools can accelerate coding, testing, and refactoring activities, they do not remove the need for deep comprehension of administrative workflows, regulatory logic, and organisational practice [33]. In contexts characterised by regulatory complexity and tacit knowledge, AI-assisted development may increase the value of explicit problem formulation, documentation of design rationale, and systematic human supervision [34]. Its relevance to this case is therefore not that it replaces embedded expertise, but that it may amplify the benefits of such expertise when institutional constraints are clearly articulated and critically reviewed.

9.4. Future Work

Future research could extend this analysis by examining similar interventions across multiple institutions and by treating collaborative open-source development as a systems governance problem in its own right. Universities with comparable administrative and regulatory challenges may be understood as autonomous but interdependent organisational systems that face structurally similar problems in teaching allocation, workload management, staffing, and regulatory adaptation. From this perspective, inter-institutional collaboration would not merely involve sharing software artefacts, but also coordinating data models, validation rules, implementation experience, governance practices, and feedback mechanisms [6,17,35]. Greater attention to such resource sharing may help reduce duplicated effort and avoid repeatedly reinventing solutions to common administrative tasks [18,36].

In this context, the architecture discussed in this paper may offer a useful foundation for socio-technical systems collaboration. Standalone applications with readable codebases, limited dependencies, and clearly bounded functionality may be easier to understand, adapt, and reuse across institutional settings than highly generalised or tightly coupled enterprise systems. Likewise, a snapshot-based approach to system evolution may support shared development by allowing institutions to preserve internally coherent versions aligned with specific regulatory contexts, while still exchanging design patterns, modules, and implementation strategies. This aligns with systems-oriented approaches that emphasise the joint optimisation of technical artefacts, organisational arrangements, and stakeholder practices rather than the optimisation of software components in isolation [37].

Further research could therefore investigate whether open-source collaboration on lightweight, modular, and temporally coherent administrative tools can complement existing institutional and vendor-supported systems where local adaptability is important. Such work could examine not only technical reuse, but also the governance mechanisms required to maintain interoperability, accountability, feedback, and adaptive coordination across institutions. In this sense, collaborative administrative software development in higher education offers a promising empirical setting for studying the governance of socio-technical systems of systems.