Posts in Category


4 things I think you should know about leading a systems development team in the South African public sector

My goal with this article is to share nuggets from my own experience and not add unnecessary complexity or oversimplify the issue of managing or being part of systems development teams in general (besides, there is a lot of that online already). Are you ready?

1.  Know how to build a business case, I mean it

This might seem like an obvious one, however with the competing priorities of government all looking for a piece of that budget, you have to make a good case for your project or it will never see the light of day. It will never be easy trying to argue for a server over a school feeding scheme because that is how those in office really look at things (understandably so).

They link money spent, to an actual outcome that impacts people’s lives. If you are not able to demonstrate how that piece of technology your team is trying to implement will add value and assist in service delivery, you have already put your team at a disadvantage. Move away from the tech jargon and learn to speak the language of service delivery. Learn to demonstrate in a very practical way, how the proposed project will add value to the pursuit of excellent service delivery.

For example, show how the extra storage capacity on your servers will reduce the incidents of “our systems are off-line” in a department or municipality. While I am on this, let me say that this is the era where “our systems are off-line” should never be heard from any public institution.

To get to that point though, you need to implement relevant technologies timeously, not be afraid of pilot or proof of concept projects and ensure your maintenance plan is on point. These will only come about if you know how to build a solid business case that makes budgetary and service delivery sense.

2.  You will often be technologically behind, face it

Let’s all face it, ICT in the public sector does not enjoy the luxury of research and development budgets. This often means public sector ICT every so often lags behind technologically relative to the private sector. Not all hope is lost nonetheless because there is still the option of free open source software (FOSS) which has been a topic of so many seminars and a viable solution in so many ICT conference resolutions. Albeit admittedly not without controversies, security stigmas and a bucket load of misconceptions.

All debates aside, the actuality is that there is a current Policy on Free and Open Source Software Use for the South African Government which was published in August of 2006 which enforces FOSS in government. It states that “the South African Government will implement FOSS unless proprietary software is demonstrated to be significantly superior. Whenever the advantages of FOSS and proprietary software are comparable FOSS will be implemented when choosing a software solution for a new project. Whenever FOSS is not implemented, then reasons must be provided in order to justify the implementation of proprietary software.”

Based on that policy it is clear that policymakers were signaling to ICT units in government to start looking at solutions that do not cost the government an arm and a leg. In order to successfully manage a systems development team in the public sector, you need to face this reality of technological lag and ensure that you always do your research on FOSS solutions. Establish a small research team within your own team that will experiment and test freely available tech solutions.

You cannot make budget constraints an excuse for technological lag because they will always be a permanent feature of any systems development team in government. Don’t succumb to this reality, find a way!

3.  Choose a technology stack with the future in mind

There is a stark difference between why a startup company would choose a technology stack and why a public sector ICT team would do so. For startups, getting to market is more important than having the perfect technology powering it. They mainly need to focus on their business and marketing rather than having all the technology pre-optimization necessary to handle the number of users Twitter or Facebook has for example.

On the other hand, in the public sector, things are different and the decision on which tech stack to choose will be highly debated in any case – so many people in your organisation need to be comfortable with the decision. The management (and hopefully the in-house / prospective developers) are probably the most important stakeholders to have on board, hence you need to choose your technology stack with the future in mind.

Here are some of the considerations to make in order to choose a future-friendly technology stack:

Go agile and keep it simple!

Whenever you want to build products from scratch, the best option is to go with the easiest solution. Choose a solution that is simple to learn and easy to scale. Do not lock yourself into technologies that make it difficult to adjust to technological advancements or are just painful to learn.

Keep the public sector problem space in mind

The technology you choose should depend on the problems you anticipate you will solve on a regular basis. Most government problems, at least in my experience, are process automation problems as opposed to computational and statistical ones. It would thus make sense to choose languages like C# and Java as your primary languages as opposed to python which is more ideal for computation and statistics.

Put your users before technology

Your solutions will ultimately be used by people, put them first in your mind before you choose technologies. Ask yourself questions such as: how can you create the best user experience? Who will be using your system? Will they work on desktops or tablets? Will they access things through a mobile connection (as more than 60% of all users currently do)? Should there be a desktop-style application? What browsers will be used most often?

Performance and Speed

There is no use investing in a Ferrari when you are banished to a town with 60km/h speed limit. Will the software be running on your intranet? If so, initial loading times could be less than optimal depending on how your connectivity is configured. Always think about your “SITA” situation before you commit to any technology.

Migrations and legacy systems

Legacy systems are a common feature in the public sector, always make considerations and evaluate whether you will be able to migrate your databases or data with the prospective technology or if it will be compatible with all the relevant legacy systems.

As I wrote this list, it dawned upon me that I was risking writing extensively about all these important considerations, which would make this article too long. The good news is that a more extensive list of considerations to make when choosing a technology stack will follow in a subsequent article – in the interest of conciseness.

4.  Be agile, be on time and deliver what you promised

The founder of the Global Business Network and well known editor of the Whole Earth Catalogue, on one occasion said “Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road” That is to say, those who are well prepared for changes that require technological adaptation and move swiftly in response, will never be casualties of those changes.

It is a disadvantage if your systems development team is reactive to change as opposed to being pro-active. A team that anticipates changes and builds its whole strategy around being agile will often succeed in delivering solutions on time.

If the tools or methodologies you are using do not allow you to immediately adapt when policies or other requirements change, your team needs to make an intentional decision to mend this. The quick win here is to choose a systems development methodology which allows you to be flexible such as SCRUM and choose technologies which are friendly to an agile methodology such as Microsoft’s SharePoint, Alfresco, ASP.NET MVC or other RAD software just to name a few.

Much like the private sector, public sector problems require solutions with quick turnaround times, systems development teams that are agile and solutions that meet their needs. For this reason, be agile, be on time and deliver what you promised!


I wish I could tell you that if you knew these four things you are guaranteed success! But the reality is that managing or being part of a systems development team, in the public sector more especially – requires much more.

Knowing how to build a business case, finding a way around technological lags and adopting a future-oriented approach when choosing technologies are very important. On the same breath, it is also important for systems development teams to be agile, on time and deliver a solution that works! (It will make a huge difference on your next project!)

Although these fours things are not the golden bullet, the good news is that intentionally working on them, although you might already know them, allows you to evaluate where your team currently stands and highlights areas that need to be improved.

Is GovTech Dead?

FinTech, EduTech and a lot of other something-Techs are definitely alive, no postmortem needed there. But it is concerning that we cannot say the same with confidence about governance related technologies.  Apart from a pothole or complaint reporting app here and a services payment app there, it appears there is not much happening in that space. This is what made me wonder as I downed my coffee one afternoon after work, whether GovTech, also known as e-government is dead or alive.

There is disruption everywhere but not so much in government.  Innovation in government seems to be taking a nap at a time when players in other sectors can barely afford to blink. Perhaps a look at what usually drives innovation in a particular industry is necessary. Usually innovation is driven by business needs in an area. Tech-innovation is a good follower of Rands and Dollars. It goes where the money goes. It is unfortunate that the biggest consumer in most provinces in South Africa is the provincial government. This means that technological innovation tends to evolve around the present needs of provincial governments, which is not always the best thing.

The unavoidable consequence of competing financial priorities is that certain government programs can go without proper resourcing for years. Which means that the technological needs of a provincial government today, could only be met in 5 or 10 years’ time. This lag often translates into technological retardation. Even the most tech-savvy ICT teams are not immune to the legacy systems syndrome. They have one foot in the past, because of all the legacy systems, and a toe in the future, thanks to a few futuristic affordable technologies their budgets could afford them. Accordingly, it is not easy to just leap into the present. This combination of legacy systems and thin budgets, makes it even more difficult to experiment with futuristic technologies, a necessary component for innovating.

This notion of the effects of competing financial priorities on innovation is nothing inventive, it has been explored before. What is often not clear is: what are the low hanging fruits around this issue, which could breathe life into GovTech once more.

I do not see a political leader approving a big-data project over a township revitalization project at any moment, hence I would rate that if gov-innovation initiatives are to take off in such financial contexts, they would have to be as financially nominal as possible. So the first low hanging fruit is dealing with unfair pricing practices by the business community selling innovative tech-products and services to the government. This prevalent imposition of technologies originating from the business sector at a hefty premium would need to stop being looked at as innovation or some kind of leap forward. And be looked at as the enemy of progress it is.

As things stand, the business community looks at government as a cash cow. The same laptop you can buy for R10 000 at a mall, usually ends up costing twice the amount when government is the client. I call it the government inflation. The bidding process is usually fair for those who bid, but the government is usually dealt the short-end of the stick.  If everyone will charge a minimum of R15 000 for a laptop that retails for R10 000 for example, the process for choosing who eventually gets to supply the government, in an ideal situation, is fair to the bidders. However in retrospect, the government is the loser in this whole ordeal. It should not be paying such hefty premiums purely because it is government. As long as this unfair pricing practice prevails, ICT teams in government should make peace with the fact that most innovative products coming on the market will always be beyond their budgets.

Some of the best innovative solutions to government problems come from within government itself. A system called Reapatala by the Department of Public Works which ensures that invoices are settled within 30 days, is one good example. The main issue is that from a systems development perspective a lot of the government processes are not well documented, which translates into challenges not being well defined. This is understandable because traditionally government ICT teams do not have business analysts or anyone unambiguously responsible for modelling business processes. I submit that a lot of opportunities for innovation will present themselves when government business processes begin to be modelled and its challenges will become clear. This is a quick win which would only entail dedicating a knowledgeable member of the team to business process modelling or reskilling them because the business analysis learning curve is not that steep.

Innovation in government and its challenges are a very complex point of discussion documented abundantly in journal articles. I dived into writing this entry knowing very well that it was inevitable that I would not be able to cover all the issues and I intend on writing another one during my next ‘after-coffee-moment’. However, like a miniskirt, I hope I was able to make it short enough keep you interested but long enough to cover all the key issues. As a final point, I would say GovTech is not dead it is just sleeping and perhaps 2018 is the year when it will fully awaken!