Digitising a regulated public-sector process is mostly a question of rules and agreement between institutions. The software is the part that goes to plan.
Over the past year we have been replacing a paper record that a public-sector regulator relies on when it decides whether people have met the requirements to complete their internship programme. The paper version passes through several hands and authorisations before it reaches the regulator, collecting signatures along the way. When it is lost or late, somebody's registration waits.
The software for a process like that is not unusually difficult. Everything around it is, and most of what follows we learned by doing it.
Commercial systems encode business rules that someone chose. A statutory process encodes rules someone legislated: time limits, required sequences, and specific people who must sign at specific points.
Those rules cannot be approximated, and they cannot be changed in a sprint because a user finds them inconvenient. Our requirements specification went through several versions before it was stable. Each one brought the written rules closer to what the regulations require, and closer to how the paper process really works, which is not always the same thing.
The most useful early measure of complexity was the number of roles that act on a single record. There were more than we expected, and each saw the process differently. The person in training wants their record accepted. The person supervising them wants to confirm competence without an evening of administration.
Every role added approvals, notifications and exceptions. Once the roles were understood the screens were straightforward, and before that they were very difficult.
Public-sector work runs on procurement rules and formal governance, and the people involved change. Only signed documents survive a change of project coordinator.
So we ran the engagement on signed milestones. The discovery workshops were recorded and closed with an acceptance certificate, and each group of sprints closed with another. The client's own quality team tested every sprint against a traceability matrix and sent back formal feedback. Changes to production will follow a written request for change, with a rollback plan, and a change advisory review.
It is slower than working on trust. It is also why the project could absorb new people on both sides without reopening decisions that had already been made. When more work was needed, it was contracted formally, which is how a public body is supposed to buy it.
We did not choose it for the client. We set out the options, from static code analysis as a baseline through to dependency scanning and dynamic testing, with what each catches and what each costs, and left the level of investment to them. Public bodies are accountable for how they spend, and a decision set out in writing puts the choice on record.
Start with the regulations and the forms, not the wish list. Map every role that touches a record and what each one has to sign. Expect the requirements to move while the written rules meet practice, and make acceptance formal from the first milestone.
Plan the handover early too. The system will be run by people who were not in the room when it was designed, which is why this one ships with a support plan, an operating procedure, a user manual and a short demonstration video for every role.
More on our public-sector work is on the government and public sector page.
Companies with one foot in Mauritius and one in South Africa get described as having two offices. The useful description is what each base does for an initiative in another African country, and what the partner on the ground gets back.
For many automotive suppliers a TISAX label is a condition of trade. What a readiness baseline found, and why the gap is usually between a control being designed and a control being switched on.
Wellbeing products are full of impressive numbers. Most of them measure how people feel about themselves. That is worth measuring, as long as everyone is clear that it is what is being measured.
