HR & Employee Management Portal

Large organisations handle a constant flow of employee requests and HR records. In this initiative, the HR portal application came from an external supplier. Our in-house team's job was to make it work inside the organisation: preparing the environment, connecting it to corporate systems, organising acceptance testing and running the project with the supplier and HR stakeholders.

HR and employee-related processes needed digitalisation, better integration and stronger self-service. Many interactions between employees and HR depended on manual steps, and HR data did not flow easily between systems. Employees had limited ways to handle routine requests themselves, so simple tasks often meant contacting HR directly.

The organisation wanted employee-facing HR interactions to move into a self-service portal connected to its corporate systems. Buying a supplier product solves part of that; the rest is making it fit an existing organisation, with its own systems, data and processes. Much of that fit was the in-house team's responsibility, and it is the focus of this case.

Two kinds of work came together. The supplier provided the portal functionality: employee self-service and structured HR and employee data workflows. The in-house team provided what the portal needed to run in the organisation: the application environment, integrations with corporate systems, user acceptance testing and project coordination. This page describes delivery and readiness work; it does not describe adoption figures or claim a completed organisation-wide rollout.

The portal software was built by the supplier, not by us. Our in-house team prepared the environment, worked on the integrations with corporate systems and organised user acceptance testing with business users. My responsibility was the project and dependency side: coordinating the supplier, aligning HR and technical stakeholders and steering release-readiness decisions.

Working with a supplier product shifts the trade-offs. Customising the product too much creates long-term cost; customising too little leaves gaps in how the organisation works. Every integration also depends on the supplier's timeline and the readiness of internal systems, so the plan had to treat those dependencies, and acceptance testing, as delivery decisions rather than final checks.

Buying software does not remove delivery work; it changes it. Integration, environments and acceptance testing decide whether a supplier product becomes something an organisation can use. I learned to make the split of responsibilities with a supplier explicit from the first day, and to treat user acceptance testing as a product decision with clear exit criteria.