Preface from Salsa’s founder
Salsa is exclusively focused on helping the Australian Government provide better information and services. We’ve been serving the Australian Government on a number of levels for many years now.
We’ve learned a lot along the way and we’re focused on our purpose-led vision to help Australian government at all levels become more open, more connected and more consolidated.
How can we continue to understand, continue to grow, continue to serve government even more?
We want to understand how government can better engage, better partner with, and better diversify to get true value from what it does. Who are the thought leaders and thought provokers and where do we see these leaders in government procurement trying to push the boundaries for better government technology information and services?
We found the De-Risking Custom Technology Projects ...and it inspired us…it rang true to our thinking, our practices and our vision. It validated where we have been and what we’re doing right now, and it inspired us to focus on what we could do better.
If we can take a truly open government, client-outcomes focus and put them first, we create authentic, lasting and trusted relationships that help us serve better/ partner better/ deliver better information and services for Australian government.
This publication is Salsa's review of 6 basic principles on how to better deliver IT projects based on the General Services Administration’s (GSA) guidelines and best practices for government agencies (and partners) across many jurisdictions.
The 6 basic principles are:
- User-centred design
- Agile software development
- Product ownership
- DevOps
- Build with loosely coupled parts
- Modular contracting
How we can make government better
“De-risking custom technology projects. A handbook for state grantee budgeting and oversight” was published by Robin Carnahan, Randy Hart, and Waldo Jaquith, of the General Services Administration of the US Government in August 2019. It’s a comprehensive review based on their collective experience and a year of exploring how to improve outcomes while driving down costs of federal technology grants.
As technology evolves globally, how individual governments harness technology for their citizens makes the greatest difference. Salsa has observed that the ‘one size fits all’ approach often used by Australian government agencies (that vary in size, development capability, and experience in delivering large complex ITC solutions) only increases the tension between the delivery expectation and reality of the end product.
Even though every project is different and varies in size and complexity, most of the concepts proposed by the handbook will apply. Applying as many of the concepts as possible for any given technology project will greatly reduce risk and increase the chance of success.
The big 6 concepts
The handbook by Carnahan et al covers the basic principles of modern software design and includes a comprehensive list of 14 best practices for budgeting and technology project management. These best practices are detailed and just as relevant to Australian Government technology projects as US Government. Including these in any technology project will both challenge agencies and improve outcomes.
Ideally applying all of these concepts to a project will help to effectively mitigate the inherent risks of major ICT projects. Government agencies need to understand and apply all of these concepts from the technical to the non-technical (which are normally ‘outsourced’ with the main project development). Investing in the experience to grow internal capability is critical for the ongoing success of complex systems.
Understanding these 6 concepts may be a steep learning curve for some agencies, but well worth the rewards over the longer term. The 6 concepts are:
- User-centred design
- Agile software development
- Product ownership
- DevOps
- Build with loosely coupled parts
- Modular contracting
1. User-centered design
Salsa sees user-centred design — building software based on the end user requirements rather than the organisation's needs — as crucial for successful projects, particularly public-facing systems and services. We strongly encourage and often help agencies in this early stage. It essentially prepares and provides a solid reference point for all future technical decisions, and guides the overall technical build of the project. Skimping at this stage can affect the success of a project, if the output doesn’t ‘connect’ with the end user in a way that makes them feel even a little joy in using the built system.
2. Agile software development
Agile development aims to build and deploy fast in many iterations called ‘sprints’. The agile team consists of the customer, the technical team and a scrum master that guides the team. Agile means you can deploy the product and begin realising benefits from development early rather than waiting long, non-productive development cycles.
Often the downfall of agile is its flexibility and agencies using waterfall-based processes that already exist in the organisation and then rebadging them as ‘agile’. Not having the key agile principles installed within a project will dilute the results of agile, leaving an agency believing agile has failed, rather than the project failing agile.
Salsa has found adapting agile methodology to suit the agency and the project greatly improves project success. We adapt agile to suit the size of the project and, most importantly, the size and construct of the team managing it so all stakeholders are part of the journey.
3. Product ownership
Product ownership is a concept used in agile where a single representative of the organisation has the delegation and authority to make decisions during the project sprints. The product can be any ‘thing’ the organisation wants to produce.
We strongly believe product ownership is one of the key ingredients to a successful project. Agencies should be aware of the importance of this role, and the expectations of this role within a project.
A product owner represents the business and its requirements within the project and so owns and is invested in the end product. They make decisions about how the end product will be delivered, all informed by the business requirements and inputs. This is distinctly different from other roles like the development team who are responsible for the technical delivery of the product.
If an agency wants to grow and mature its talent to deliver successful projects, it must empower and invest in those managing the project while also accepting (better still learning from) any failures. Of course this isn't a clause to set up product owners for failure, rather to find and agree on a balance that fits both the project and agency from the outset.
4. DevOps
Traditionally agencies have engaged external vendors to develop a solution or product, which is then ‘delivered’ to an agency. If defects or issues are discovered then the agency’s operational team responsible for ongoing management of the solution blames the development vendor. The next progression of development was vendors being made responsible for the developed solution and then having to host it on their own systems to put the onus of risk of the ongoing management and maintenance of issues back on the development vendor indefinitely, with the substantially higher vendor lock-in rates.
Thus ‘DevOps’ was born. In our experience of whole-of-government platform management, combining the Development team (‘Dev’) that builds the solution with the subsequent Operations team (‘Ops’) who would manage the solution post go-live, reduces overall risk and produces a better solution.
The combined team working as one will have less post-live ‘fixes’ as issues are tackled earlier in the development cycle, while automation and continuous improvement processes are also baked into the solution for ongoing improvements. Agencies tackling large-scale, complex ICT systems should consider investing in an internal DevOps capability to successfully manage longer-term projects.
5. Build with loosely coupled parts
The days of waterfall, monolithic, multi-year projects planned all upfront and then built in a point-and-shoot nature are (or should be) gone.
Modern software development should be much more responsive to changes in the landscape, user demands, shifts in technology, and especially shifts in government of the day to ensure the final solution or system isn’t obsolete before it goes live.
Delivering across a number of smaller, semi-independent software projects with an individual agile development team reduces this risk and allows for more control and the ability to respond to change. These series of mini-projects — complete with working, documented, and deliverable solutions — produce overall components that can be updated easily, or even swapped out if technology demands it. Following development using open standards and abstracting APIs development to allow interoperability increases forward-compatibility while reducing the ongoing risk for longer term projects reaching end-state obsolescence.
A considerable key factor for large and complex ICT projects is following a service-oriented architecture (SOA) approach, where each component can be standardised and built like Lego pieces. This allows development components to remain interchangeable, to maintain flexibility, and to pivot if needed to take advantage of new technology or technical approaches.
6. Modular contracting
If the above five concepts can be adopted, then de-risking the procurement of major projects can also be achieved by breaking up the overall procurement into smaller discrete contracts and smaller engagements.
The intention is that an agency should engage a vendor in the delivery of services, not software. This means a vendor will be responsible for achieving the objectives of the project, not a specific outcome. This allows flexibility and the ability to shift development approaches with user research inputs, changes in technology and even shifts in government direction. Therefore the project outcome is the focus, not a fixed solution of a software.
Firstly this reduces the overall complexity and requirements, leading to shorter procurement cycles (albeit somewhat more frequent) and engagement of vendors. There is the added benefit of being able to engage multiple specialist vendors throughout the project.
Secondly another strength of this approach for agencies is that non-performance of vendors is easier to manage, with simplified contracts being shorter and avoiding ‘vendor lock-in’. An agency should be able to walk away from an engagement to minimise overall project impact.
We believe Australian government agencies should strongly consider a wider vision of the entire process that includes pre-development phases and contract procurement. Australian government needs to be engaged and upskill internal resources, especially for larger, complex or longer-term projects.
Instead of outsourcing some of these functions to external vendors (or even in some cases internal IT departments), government and internal business areas as subject matter experts (SMEs) should be involved in the process and getting their hands dirty.
Salsa’s take
The handbook’s 6 key principles are crucial for delivering large and complex government ICT projects today.
Salsa knows government ICT departments will often be familiar with, and even proficient with, the technical aspects of software development. What should also be addressed to further reduce risk for complex or risky projects are the non-technical concepts to better consider a holistic ‘end-to-end’ (or better still pre-development-to-continuous-delivery) view of ICT projects.