How we digitize labour disputes in Estonia – the challenges of creating a flexible system
In this article, we will take a closer look at an exciting ongoing project and talk about the new module of the Information System of the Labour Inspectorate, which will digitise the resolution of labour disputes in Estonia.
We ask those involved why such a system is needed, what makes the development more complicated than usual, and how the challenges are coped. We will also talk about how the people of the four companies manage to work as a single team and what long-term cooperation with a development partner gives to the client.
Madleen Mäe from the Labour Inspectorate, Maret Kuub from the Health and Welfare Information Systems Centre (TEHIK) and Helen Alasoo from Trinidad Wiseman share their thoughts.
Trinidad Wiseman has been a development partner of TEIS since 2019.
At Trinidad Wiseman, you can find all the competencies needed to create user-friendly digital solutions, from analysis to software development, in one place. We are one of the most recognized service providers in Estonia in the field of user experience design. If you would like to discuss how we can support your company's needs, please contact us.
Let's start by getting acquainted. What is your role in the development of the Information System of the Labour Inspectorate (TEIS) and more specifically the Labour Dispute Committees (TVK) module?
Madleen: I am the product owner of TEIS at the Labour Inspectorate. My main role is to clarify business needs and bring them to the table.
Maret: I work at TEHIK as a team leader for the services of the Labour Inspectorate and also perform the tasks of a project manager.
Helen: I'm a senior systems analyst at Trinidad Wiseman and I'm involved in the technical side.
Tell us more about the TVK project. Why and who needs such a system?
Madleen: A labour dispute is a situation that can arise between an employee and an employer for different reasons, such as loss of wages or working conditions. Employees can turn to the labour dispute committee, which is an extra-judicial body of the Labour Inspectorate, to resolve labour disputes.
The labour dispute process is regulated by law and has a lot of details. For example, whether it is an individual or collective labour dispute, an ordinary procedure with a hearing, a written procedure or a conciliation procedure. For a person who does not come into contact with it on a daily basis, the process can be complicated, especially in a stressful situation.
At present, there is no digital environment for submitting applications for labour disputes. Applications are submitted by e-mail or post, which leads to many errors in the applications. At present, about 3000 applications for labour disputes are submitted in Estonia every year, and this number is growing every year. As many as a third of them have defects and sent back for defect removal.
With the labour disputes module, we aim to make the labour dispute process simpler and clearer. In short, we have three major goals. Firstly, that a large number of applications would come through the self-service. Secondly, that the number of applications with deficiencies would decrease, i.e. the digital environment would guide the person in preparing the application.
The third goal is to simplify the delivery and administration of procedural documents for all parties – so far, the time spent on submitting documents has been very high for people and employers.
Helen: On the analysis and design side, we put a lot of emphasis on making the whole process as intuitive as possible, so that anyone with or without any technical skills, can come and submit an application.
It will be possible to submit an incomplete application in the future as well, but we will notify the person of the deficiency – for example, that they have an unsubstantiated claim in the application.
There is also a lot of manual work in the Labour Inspectorate at the moment. The delivery of documents, as well as the registration of applications received by email and physically, is a very time-consuming process. In the future, applications can also be sent by email and post, but we will automate activities through the system, so document management specialists do not have to do every move manually.
In addition, the self-service makes the labour dispute process more transparent, as it is possible to log in to the system and see all documents at any time.
How does the development of the TVK module differ from previous TEIS developments?
Madleen: One difference compared to the previous modules is that there are a lot of different parties involved in the labour dispute process – the chairman of the labour dispute committee and the document management specialist, the opponent and the opposing party, perhaps their representatives in the form of an attorney, and in the case of ordinary proceedings, lay judges. All parties must be able to access the system and see the documents intended for them.
Helen: Usually we have one specific process and maybe some edge cases that the system has to enable. In the case of labour disputes, each dispute is completely different, there is very little overlap. The system must be flexible enough to allow all this, but at the same time it must be limited enough so that only the right people can see the documents.
The TVK module is technically completely different from other modules because it is very flexible. And the more flexible the system, the more complicated it is.
Madleen: At the same time, if the system allows everything too flexibly, the helpful effect that would help the person through the process disappears. So a balance has to be found here.
Helen: Since applications can be submitted by e-mail and physically in the future as well, a situation will arise where we can systematically guide people in the self-service. However, it must still be possible to enter applications in the official application, which may be significantly more incomplete.
Therefore, we cannot make any data completely mandatory. Finding a middle ground is very complicated – how do we ensure that we always have the data we actually need for the proceedings, so that the number of applications with deficiencies actually decreases?
You pointed out several challenges, such as the abundance of parties and the need for flexibility. How do you solve them?
Helen: On the one hand, flexibility is needed, but on the other hand, we still want to create a process that would harmonise the procedure between different labour dispute committees as much as possible. We are trying to find solutions that would cover the needs of TVK managers and document management specialists.
We have a very strong cooperation with each other and a transparent analysis and design process. We hold regular analysis meetings where we show the designs, and the directors of the TVKs and DHS (Document Management Specialist) can give feedback, we can change direction accordingly and ask analysis questions on an ongoing basis.
We also conduct user tests, where different parties can test the prototype of their work process. Thanks to this, we get confidence that we are on the right track, or we can see what needs to be changed. Analysis and testing the design before we actually finish something is a very, very big part of the development process.
Madleen: We have a central role in the development of TEIS and the involvement of different users already in the analysis process. And when the first prototypes are ready, asking for feedback and doing user tests before going live. This helps to save time and money and avoid big mistakes where we develop a finished thing that is not really needed.
Maret: We also try to reuse data from other registers and our own system as much as possible, so that users do not have to enter the same data twice.
For example, the managers of TVK can now make an inquiry in the Commercial Register or the Employment Register with a single click – previously they had to extract the data from the register, make it a PDF and upload it to the system. We move as much data as possible, not documents, and move towards data-driven management.
Madleen: If obtaining some necessary data is limited, we are also engaged in legal negotiations in parallel with the development. We are trying to reach an agreement with the institutions so that we can make automatic interfaces so that accessing the data used in everyday work would be as convenient as possible for the user.
There are four parties involved in the project: the Labour Inspectorate, TEHIK, Trinidad Wiseman and Triple Dev. How are the roles divided and what does it mean for the team?
Madleen: Trinidad Wiseman does analysis, design and front-end development, Triple Dev back-end development and testing. TEHIK supports us with the technical side and project management. I from the Labour Inspectorate am in the role of a representative of the business side and a product owner.
Maret: The project team is quite large – about twenty-five people. With such a large development team, role clarity is crucial so that everyone knows what someone is responsible for. We support each other's roles, but do not interfere too much with someone else's work. We trust that everyone knows their job best. Roles and tasks have settled well over the years, but we also make changes if necessary.
Helen: In addition to the fact that the work processes are well established, we put a lot of emphasis on soft values in the team. We have two-week sprints where each sprint ends with a demo and retro meeting. We don't cancel a retro meeting because everything is fine – if everything is fine, then we talk about everything being fine.
Communication between them is very smooth and open – there are no information bubbles, but the necessary information always reaches everyone. The whole team is passionate about it, and since we have a common goal, if someone needs help, there is always somewhere to get help. There is no feeling at all that we are from four different companies.
Madleen: It's a very interesting feeling that we seem to be from different companies, but I don't perceive "you" or "I" at all. There is always "us", "our team", "we do".
Since we already have the process part in place, the abundance of different parties is rather an added value in the development of the service. If, for example, the business process managers of the Labour Inspectorate are perhaps guided more by the law or the official's view, then developers, analysts and people at TEHIK represent more of the view of ordinary people. Thanks to this, the service will eventually become simpler and clearer.
You all mentioned the importance of role clarity and processes. Describe your team's work processes in a few sentences.
Helen: We have two-week sprints. Usually there is a 15-minute daily standup with the whole team every morning, where we talk about what someone is doing and whether there are any obstacles.
Grooming meetings take place every other week, for which the analyst makes development tickets and the developers estimate how long they could take. This is necessary for planning the sprint so that all the planned tickets would be completed in two weeks.
At the end of each sprint, there is a demo showing what was completed in two weeks. And a retro meeting where we talk about what was good in the last two weeks, what maybe wasn't so good, and we discuss various issues.
Madleen: There are sprint deliveries every two weeks. We at the Labour Inspectorate then know that we will have to do acceptance testing. Everyone knows when something happens. In addition, we have very good documentation. Everything can be found even when people are changing or resting for a long time.
What solution do you use for documentation?
Maret: We have a Confluence Wiki where we store all the analyses, technical information and agreements made over time, such as UI and UX agreements or how to report bugs to the developer.
The whole team participates in the meetings. Since all parties sit at the same table at daily standups, demos and retros, we know each other very well. So if there is a question about a development ticket, I know which developer or tester to contact. In our project, there is no situation where there are only project managers at the table and there is an information blackout somewhere.
You might think that we spend a lot of time on these routines, but at the same time, we save time thanks to the fact that we are in the same information field all the time.
Madleen: Actually, also money. As we know, every hour of work of a developer costs. But we agree that we would rather sit together at the table and therefore correct fewer mistakes. We don't talk past each other, but we have jointly understood what we do and how we do it.
Maret: Over the years, a lot of good suggestions and ideas have come from retro meetings, thanks to the fact that the whole team is at the same table. Plus, I think it would definitely affect the motivation of team members if they only had to write code and never met the client they were working for. It is important that everyone in the team can see what they are creating value for.
You have been developing TEIS together for six years. What does such long-term cooperation with a development partner give from the customer's point of view? Could there be any disadvantages here?
Madleen: I feel like it's similar to other partnerships or personal relationships. When you are in a long-term relationship with someone, you know the person better, and there is more trust.
Cooperation is smoother because, as we have already discussed, processes fall into place. In addition, it gives a certain peace of mind that even if there is some misunderstanding or miscommunication, it will not lead to a breakup. You will have the courage to bring more difficult issues to the table and discuss more uncomfortable topics if necessary.
Maret: I would also emphasize trust and open communication. If we have a problem somewhere, no one will push it under the rug, because they know that it is safe for us to talk about when something goes wrong or something can be done better.
In the case of a long-term relationship, it could be a disadvantage if we fall into a routine and do things safely the same way all the time. But it seems to me that we are doing well in that regard as well, as the people in the team change from time to time.
There will be new developers and analysts, and if people dare to bring their ideas to the table, they will also continue to come up with fresh ideas on how to test things in a different way.
What is your recommendation on how to mitigate risks in similar complex development projects? What kind of surprises should you be prepared for?
Helen: On the development and analysis side, you should always be prepared for the fact that even if a preliminary analysis has been carried out, there may always be a "monster" that makes things much more complicated than expected.
When evaluating tickets, it is always worth putting a buffer at the end. And if a "monster" comes out, be vocal right away and let it be known that there is a problem that needs to be solved.
Whenever possible, I would recommend that the analyst validate their analysis with someone else, such as an architect or a senior developer. A tunnel view easily arises alone, something can be forgotten or overlooked. Take advantage of the team around you and ask them for help!
Maret: In our projects, we never finish the analysis of the entire system before starting the development. Thanks to the fact that we move in parallel with analysis and development, we have the flexibility to change something if the need arises.
On the customer's side, it is important to find people who will talk about their service and help with the analysis. For them, it is additional work that they do in addition to their main job.
If the specialists participating in the analysis meetings change, the needs may also change or a different view of the process may arise. Then you have to make the necessary changes and maybe move on in a different way. In this case, too, it is good if the entire analysis is not completed.
Madleen: Maret and Helen have already brought out my thoughts. Additional development needs, whether of a technical nature or arising from a business process, are definitely an unexpected occurrence.
And the change of people, especially in a longer project, always leads to a bit of confusion, for the same reason that people see the process differently. Good documentation can help here, so that you can go back in time and see what someone's idea or need was.
And certainly the time it takes. I've written down with an exclamation mark to always have an extra buffer. Practice has shown that even tiny interfaces can take much more testing and time than initially planned. Whenever possible, do not set dates in stone, unless there is a deadline arising from the law, but be flexible with the dates as a customer.
We would rather do it for two months longer but get a well-functioning solution than just rush and immediately start using a system that is inconvenient or does not serve its purpose.
