Without the appropriate procurement methods, e-Government and digital transformation initiatives are doomed to failure. Why?
Tldr:
It is estimated that around 20–30 percent of government software projects are total failures and abandoned. Around 30–60 percent partially fail, with time and cost overruns…
- Government software projects continue to have high rates of failure because issues are misdiagnosed
- The diagnosis is that government software is complex to build and so requires a different approach to project management, and in turn, government procurement practices
- Agile project management methods are better suited to software, but government procurement processes are structured towards traditional project management methods. Results in high failure rates in government software projects, if not reformed
- The solution is to explain to government officials why software projects need to be treated differently and to reform procurement processes to take into account agile methods for software development
The problem
At the heart of the issue is that the problem has been misdiagnosed. If you go online and read about why IT projects in government have such high failure rates, none of the articles point to the root cause issue. Which is why, for decades, the problem has continued to exist. As various assessments have found, information technology (IT) and system (IS) project failures are almost so common as to be expected by planners. It is estimated that around 20–30 percent of projects are total failures and abandoned. Around 30–60 percent partially fail, with time and cost overruns or other problems with the minority of projects succeeding. A recent Standish Group study found success in only 29% percent of projects, which drops to 13% with tech projects over $6M. How can you fix a problem that you don’t understand?
So the first step is accurately diagnosing what the root cause of the problem is. The root cause of the problem is that large government software projects are extremely complex to write. There are so many unknown unknowns, so estimating the time, effort, and resources required in implementing government software is almost impossible.
What most non-technical government people dont understand is that large software projects in governments can have hundreds of millions of lines of code that all need to work perfectly. One single error in those millions of lines of code can lead to failure across the system or security vulnerabilities. I’ve personally worked on government information systems where the code base was over 200 million lines of code. Its also commonplace for software developers to encounter problems that they’ve never encountered before and are only discovering these as they’re implementing the systems (unknown unknowns). It is very difficult to estimate timeframes for solving something you’ve never encountered before.
Hence, over time, the software industry developed its own approaches and methods for dealing with these challenges. These approaches tilt more towards the research spectrum rather than towards the engineering spectrum and are typically flexible and iterative in nature. The approaches are classed as agile methodologies and are distinct from the traditional methodologies that came before. These agile methods enable teams to “learn” what the problems and solutions are as they implement the project.
This is in direct contrast to how government procurement systems are set up. Governments have a more traditional approach to project management, and in turn, their procurement processes reflect this. Which means they work on the assumption that there are no unknown unknowns and that the solutions to the problems are all known ahead of time. So, procurement is structured around these assumptions with projects created with fixed time frames, fixed budgets, and fixed outputs all to be delivered at the end of the project.
This approach to procurement dooms government software projects to failure even before the project begins. This is because when it comes to software, the characteristics of software described above typically require more agile approach. This continued approach to procurement by governments is the single biggest reason that despite decades of continued failre, a large amount of software projects in government will continue to fail.
What’s the solution?
The following is a list of 3 x practical things that governments can do immediately to fix the issues:
- Break the implementation of the system into smaller parts. The smaller the better because it has lower risk. Don’t try to do everything at once.
- Structure of the projects in an agile manner and have the procurement processes reflect this. In government speak, that means that you shift projects from an output based approach to an input based approach.
- Don’t try to build everything from scratch. Leverage existing e-Government solutions like Govcrate (https://www.govcrate.com) that already have ready-made solutions available.
How would Agile methods work in practice?
Heres a quick breakdown of how this would work in practice. First, project resources (time, money, and people) would be split up into phases and resources allocated in fixed blocks. The initial phases would be geared towards “discovery” of the unknown unknowns. At the end of the discovery phase, the implementation teams report back on progress. At each phase of the project, a decisions are made on the following
- Whether to preserve with the current approach or to pivot to another approach based on what is learned.
- If the decision is to preserve, then another decision needs to be made on whether to move onto the next phase or stay in the same phase to work out any additional issues
As the project progresses through the various phases, the amount of resources allocated to the project increases. This helps governments control costs and de-risk procurement. The approach that we’ve successfully adopted for various governments is to phase projects as follows:
- Proof of Concept: Restricted to lab environment to work out if something is technically feasible.
- Prototype: Restricted to staging environment & staff to work out key features.
- Pilot: Restricted to a subset of customers and deployed to production system to work out user behaviors and tweak key features.
- Minimum Viable Product: Deployed to production and to all users with the bare minimum features that provide a solid base for additional features to be added.
- Scale Up: Additional features prioritized based on user feedback and added. Roadmap developed.
Conclusion
By reforming the processes and procedures through which governments procure goods and services in the information technology space, governments gain better outcomes in their digital transformation and e-Government initiatives. This makes them better equipped to allocate their resources in the most efficient & effective manner. It can also result in better contract management, as well as more accurate budgeting of projects and programs related to e-government initiatives. When these types of projects are broken into bite-sized phases, they are easier to manage, carry less risk, and provide continuous feedback during the implementation period with the flexibility to pivot when needed.
In conclusion, reforming government procurement processes is an important step to ensuring the successful implementation of e-government initiatives. This leads to better service delivery to citizens and a stronger relationship between governments and their citizens. At Govcrate, we’ve structured our offerings in a phased manner to make it easier for governments to take an iterative approach to software procurement. Listen shows that they are able to do risk their investments and reduce costs. You can get in touch with us for more information using the form below.