Since 2025 I have chaired the Programs Committee at Kuwait Municipality, as listed in my CV. This side of my work ties in with a long-standing interest in systems development, including the Transaction Flow System, the Contractors Classification Program and the Safety and Storage Program. In this article I set out an approach I propose for discussing development requests and setting their priorities.
A development request starts with a problem that can be described
A request may arrive in the form of adding a button, a screen or a report. I would rather we take a step back: who is the user? What task are they unable to complete? And what outcome is needed? Once the answer is specific, more than one solution can be compared, and it may turn out that reordering the work or improving existing information is enough to meet the need.
My suggestion is that the request card should include a real example stripped of personal data, a description of the current situation, the entity that owns the procedure, and the systems affected. This level of documentation helps the scope to be discussed before time is estimated, and reduces mismatched expectations between the technical team and the requester.
How is priority set?
In my view, priority comes from combining the impact on the service with the urgency of the need and the feasibility of delivery. Early attention can go to an obstacle that prevents an application from being completed, or to a fault that forces data to be entered repeatedly. Requests that involve multiple integrations, on the other hand, need their dependencies and participating entities clarified before a realistic date can be given.
- Identify the service users and the task that will improve for them.
- Estimate the impact of delay and any documented time commitments.
- Establish whether data and permissions are ready, and who is responsible for operation.
- Agree on acceptance evidence that can be tested after implementation.
Trialling is part of the decision
Suppose there is a request to make it easier to follow up on delayed applications. A limited prototype could first be shown to a group of staff, who are then asked whether it explains the reason for the delay and the next step. If they still need to refer to separate files to understand the status, the problem may lie more in the available data than in the format of the report.
The work does not end at technical handover. It helps to decide who reviews reported issues, how changes are documented, and which indicator will be monitored during operation. With these steps, the move into daily use becomes part of the project rather than a stage left for after delivery.
What I care about in this area is that a system stays tied to the service it was built for. When the problem, the priority and the acceptance criterion are clear, the discussion becomes more precise, and each party can explain what has been achieved and what needs another phase.