I served as Head of Contractors Section in the Engineering Systems Department at Kuwait Municipality from 2018 to 2021, and was a member of the Contractors Classification and Licensing Committee from 2018 to 2023. The work listed in my CV includes creating and developing the Contractors Classification Program. Drawing on this overlap between technical responsibility and software work, I look here at how to think about a system that supports classification and preserves the reasoning behind each decision.
What should the record represent?
In my view, a contractor's record should show the identity of the firm, the type of application, the documents attached to it, the status of each document and the date it was reviewed. These are different levels of information, and keeping them separate makes it easier to see what has changed over time. Updating a document as part of a new application should not erase the version on which an earlier decision was based.
Classification itself needs a precise definition of the data that supports it. When a requirement becomes a field in the system, its source and the body that reviews it should be stated. That link makes it possible to discuss redundant or duplicated fields, and reduces the chance that a screen design turns into an unintended interpretation of the technical requirements.
From the outcome to how it was reached
In the approach I favour, the authorised person can review the application's journey: when it arrived, which missing items were recorded, who completed the review, and which version was in front of the decision-maker when the decision was taken. Showing the final outcome matters, but it is tracing the stages that lead to it that allows queries to be handled and the reasons for returning an application to be understood.
- Keep a clear copy of the documents used at each stage.
- Separate the permission to enter data from the permission to approve it, according to job role.
- Record substantive changes with their time and reason, and make them visible to those with review authority.
- Attach comments to a specific application rather than scattering them across separate messages and attachments.
How I assess improvement
I start with indicators that can be interpreted: the time taken to resolve missing items, the number of times an application is returned, the proportion of records that need correcting, and the time it takes to reach the reference document. Comparisons become useful when we compare similar types of application and make clear whether the time includes waiting on the applicant.
When developing this kind of program, I find that defining the data well deserves as much time as writing good code. A good system makes expertise possible to document and review, and supports continuity when people change. That is the aspect I consider most valuable in linking technical classification with systems development.