CONTEXT
A government health programme in Africa needed the software that a health system runs on: clinical records, the working day of a practice, and the reporting that tells the people funding it whether any of it is working. I was contracted into the delivery team as the technical decision-maker.
The programme, the parties to it, and the technology are covered by an agreement that has not expired yet and that I still hold to. So what follows is the shape of the work, not its detail.
THE REMIT
Build the clinical records and practice management system, and the monitoring, reporting, operational and logistics systems around it. Make the technical calls for the delivery team. Get it into more than fifty clinics. And then leave it in a state where a company that had never met me could take over running it.
WHAT I DID
The systems themselves first: records, practice management, and the layers a programme is actually judged on, which are reporting, operations and logistics. A health ministry and the people funding it do not experience your software as software. They experience it as whether the numbers arrive, whether the stock is where it should be, and whether a clinic can work on a bad day.
I made the technical decisions rather than all of the keystrokes. There was a team, and my job in it was the calls that are expensive to reverse: what the data model owed the reporting, what had to keep functioning when the connection did not, and which conveniences were not worth their long-term cost in an environment where nobody was going to be available to fix them cleverly later.
Then deployment, into a clinical estate rather than a data centre. And then the part that most projects treat as an afterthought and that this one was structured around from the start: the handover. The system was documented and delivered to a separate company for ongoing application maintenance. Not briefed at them over a call, but written down well enough that another firm could take ownership of it.
WHAT IT PROVED
Two things that are hard to demonstrate any other way.
The first is that I have worked inside institutional delivery, not around it. A government client, a prime contractor, a delivery team, funders who audit, and a maintenance firm inheriting the result. That is the shape of most serious technology work, and it is very different from having strong opinions in a small room. I know how to be the technical judgment inside a structure I do not control.
The second is the handover, which is the thread running through everything on this site. A system that only runs while the person who built it is still answering the phone has not been finished. This one was built to change hands from the beginning, and it changed hands.