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.