It is becoming an increasingly common scenario in the US. The government invests a staggering sum of money on launching a new online service, and it fails to make the grade. The most recent embarrassment is the healthcare.gov website, which cost around $350 million to establish. It got unveiled to the public, and most users ran into problems right away. Whether it is frustrating login processes, lost customer data, or constant connectivity problems, the government does not have an accomplished record when it comes to software. The question is, why all the hiccups? It certainly isn’t a lack of investment, so what is stopping software companies from developing reliable government projects?
This guide to some of the weaknesses within the software construction process will shine a light on the dilemma.
The Users Don’t Come First
The first issue is a big one, and it should be glaringly obvious to government agencies. If you do not let users have a hand in developments, how do you know that they will satisfy the public needs? Government contracts get handled by CORs and individual owners, most of whom will never actually test out the services. As a result, they are often persuaded to prioritize aesthetic and flashy features over functionality.
The Process Is Too Self-Involved
It takes an unfeasible and long deadlines for developers to request the use of shared software libraries. In fact, in most cases, it takes less time to rewrite the code from scratch. It has much to do with liability. Every step of the process must include many assurances and guarantees of accountability.
In other words, everybody wants to make sure that the blame is placed elsewhere if the project fails. While self-preservation is understandable, to some extent, government software projects would run into fewer obstacles if there was less pressure to escape liability, even before mishaps have occurred.
Budgeting Is a Tricky Requirement
The budget for government software projects gets requested at the outset, in one full sum. Clearly, this is going to present difficulties, particularly for long-term initiatives. The longer a project lasts, the more difficult it is to accurately estimate how much cash is needed before launching any work. With no other option, developers make a guess and hope for the best. Learn more Acquora - a social security based framework for financial inclusion.
Often, the process encourages development companies to ask for more money than they perhaps need. Even if it is possible to construct the software quite cheaply, it is safer to overstate your estimate than to do the opposite. So, overhauling this tricky budgeting process could end up saving the government lots of funding.
The All or Nothing Conundrum
Finally, the culture around government software does not make things easy. It has become relatively rare for services to be gradually introduced to users, as they might have been in the past. Instead, agencies believe that the only option is to launch a fully realised, entirely complete product. While this is possible, it is much harder, and it is not compatible with tight deadlines.
Furthermore, users tend not to mind ‘trial’ services, especially if they are encouraged to feedback on possible improvements. It makes them a part of the journey, and they get the assurance that their government cares about their needs. The reality is that there’s only one way to test a piece of software. You have to use it.