NSW Industrial
Relations
Creating a simple employee long service leave calculator using a complex dataset.
Project intro
Our client was looking for a simpler way to calculate long service leave for its employees – validating and improving an extremely complex and manual legacy system and removing key-person dependencies.
Their challenge
Their challenge
Our client had a challenge many organisations face: calculating staff members’ long service leave entitlements that accrued over time, under different awards, while they worked in different departments or divisions (in this case, agencies) that may have had different entitlements.
They depended on one knowledgeable person to do these calculations manually, based on their own understanding of the ways in which government agencies changed names over the years, and using a complex legacy database.
Government agencies change names and people move between agencies. Over time, leave arrangements change as well, so our client was finding it a significant challenge to accurately calculate and understand how much accrued long service leave someone who’d worked at different agencies, sometimes over several decades, would be owed.
They also needed a simple way for this database to be updated in future when agencies change names or cease to exist.
The solution
The solution
As our client had been finding the manual calculations of this complex task increasingly difficult, they asked us to develop a simple and accurate way of solving two specific parts of their problem: identifying all the links between agencies over time (which ones changed names and what their new name(s) became) and producing a specific calculation for the long service leave entitlements of a person who worked at those agencies between given dates.
They called this new system the OSRT: Online Service Recognition Tool.
As is the case in the development of many software solutions, we came up with concepts for several tools that we thought might solve the problem in an elegant way.
The client chose a simple front end that could be used by anyone in HR. This allowed for keyword searching to identify agencies, then, when dates of employment were entered for a given agency, the leave entitlement was displayed.
Agency names were configured in the user interface so they could be expanded to show previous and subsequent agency names, in order to maintain the links between these relationships and make this corporate historical knowledge visible.
One concept that we developed, but which wasn’t used, was an infographic (see image 1) that provided a searchable and clickable tree (hierarchical) structure showing all of the agency name changes through time, so anyone in HR could see the relationships and identify where an individual would have worked in a given time period, then calculate leave entitlements for given agencies in that time period.
Our process
Solution Design
“I’m often brought into a project when the architectural solutions have already been found, but there was a freedom with this project, as I was actively involved in developing the solutions.”
Jem Lopez – Senior Developer
Jem Lopez – Senior Developer
Read Process
I developed the architecture for both the back end and front end.
I was initially given only a spreadsheet to work from. This had 27 columns and 10,000+ records. It contained all the names of old agencies and what they used to be called, it was manually edited and contained inconsistencies. Also, all the agencies had different leave requirements.
“Deciphering data is the thrilling part of being a developer” Jem Lopez – Senior Developer
So, a key part of the puzzle I had to work with was understanding the business rules to make sense of this data, to clean it up and develop a calculator. We developed this understanding through many discussions with our client, which also helped us to work out what would best help to solve their problem.
The rest of the Symbiote team worked closely with the client to give me guidance about developing a user interface that was simple enough for anyone within a state government HR division to use.
“I’m often brought into a project when the architectural solutions have already been found, but there was a freedom with this project, as I was actively involved in developing the solutions.” Jem Lopez – Senior Developer
Front-End Dev
"We found that by breaking up scenarios into smaller chunks we were able to distill consistent rules for how, why and when agency roles were recognised or not. We continued this process for a few weeks and drew up a table of all possible permutations."
Amir - Front-End Dev
Amir - Front-End Dev
Read Process
I contributed to the UI design and the development of the front end of the OSRT tool. I worked directly with the client to work out what pain points existed for past users and how we could add features or remove hurdles to make the process of using such a tool easier.
One major challenge was a lack of clarity about identifying each agency’s recognition status.
To tackle this, we set up a few complex scenarios and broke them down with the client.
We found that by breaking up scenarios into smaller chunks we were able to distill consistent rules for how, why and when agency roles were recognised or not. We continued this process for a few weeks and drew up a table of all possible permutations.
Once the table was signed off by the client we got to work in developing this logic and continuously providing avenues for the client to test and provide feedback on edge cases where the rules didn’t always seem to apply.
We were patient and logical and managed to significantly improve their understanding of their data, clean up their database, and give them a fast, easy-to use and reliable tool to use for their leave calculations.
Secret ingredient
Our secret ingredient was patience.
Our clients knew they had a problem that was only going to get worse: a bottleneck of leave calculations that were being done by a few staff members using their own knowledge and a very old database. They knew what the problem was but they didn’t know how to solve it.
So, while we dove in to tackle the enjoyable puzzle of understanding the database, verifying it, cleaning it up and moving it to a new system, we made a lot of time to talk to our clients to give them options for new ways to solve this problem.
It’s totally normal for clients not to know what they don’t know. Sometimes they’re open to us looking outside the problem they arrive with, to try to solve it in a way that also simplifies some of their other processes. Other times they want a more robust version of what they’re already doing, but much easier to use.
‘It’s important to be patient when we’re defining a software solution. Clients know their business better than we do and we always give them the time they need to make decisions.’
Amanda Brown – Head of Strategy and Projects
