Why whole-of-government platforms?
Whole-of-government platforms help governments deliver better solutions to citizens, while also reducing costs significantly by consolidating multiple, disparate services (i.e. websites) onto one platform. This greatly reduces the support and maintenance burden borne by individual agencies.
How to make a whole-of-government platform work
Whole-of-government digital platforms require vision, rigour, experience, scale and flexibility to deliver. Successful implementation usually involves a multi-disciplinary team blended across government and vendor(s). Flexibility is delivered by employing an agile methodology.
One great example of a whole-of-government platform is the Federal Government’s . GovCMS launched in 2015 to provide a unified web platform for government departments across Australia.
Delivering the second-generation GovCMS
In 2018 Salsa Digital and implementation partner amazee.io delivered the second-generation GovCMS (read our blogs Salsa Digital and amazee.io to build next generation GovCMS platform and 102 GovCMS SaaS sites live on the next generation open platform for more information).
Salsa designed a multi-stream, multi-disciplinary, blended team with experts from Salsa, amazee.io, VSHN, CyberSec and Finance. These teams were spread across the globe, with three ‘satellites’ in Canberra, Melbourne and Switzerland (VSHN). It covered:
- Project managers
- Application architects and engineers
- Platform architects and engineers
- Security officers
- Other experts such as business analysts and scrum masters
Four parallel streams with centralised program governance were designed:
Platform stream — This stream designed and implemented the technical platform for the GovCMS program, using amazee.io’s open source platform Lagoon. A base platform was needed to host the existing GovCMS customer base as well as cater for year-on-year growth. High value feature enhancements were also delivered back to the public Lagoon project as part of this stream.
Migration stream — This stream analysed existing GovCMS sites on the legacy architecture and then planned, built, tested and executed a process to migrate these sites to the new platform. Tools and automated scripts were created, including automated testing, to move sites from the old platform to the new platform. A complex set of dependencies needed to be managed between the migration and the platform streams.
Services stream — This stream analysed existing GovCMS services and determined how the service offerings could be rolled out with improved GovCMS customer experience and/or new services added to the GovCMS program. A prime example was the introduction of a consolidated and unified service desk, which allowed more rigorous SLA monitoring and reporting and improved collaboration and communication processes to GovCMS clients and internally within the Finance/Salsa service desk team. Other services to be re-engineered included documentation, client on-boarding support and more focus on community engagement. Dependencies between the platform and services streams required careful management.
Security stream — The security stream needed to maintain the GovCMS security accreditation, in fact the intent was to elevate the level from Unclassified to U-DLM (under Information Security Registered Assessors Program as part of ISM). The program was granted Authority to Operate at the unclassified level, with work continuing to reach U-DLM. This was a complex exercise when considering the platform technology was completely re-engineered as were much of the people and processes and so a series of complex dependencies needed to be managed between the three streams.
Flexibility and agile methodology
The GovCMS program had a hard deadline. The 100+ legacy GovCMS sites needed to be migrated by a non-movable date, the services underpinning the program needed to be in place by the same date, and the platform needed to have the requisite security accreditation for the launch date. Flexibility was essential. A coherent, yet distributed, multi-entity team needed to deliver the program.
This flexibility was met using agile methodology. In general, agile methodology delivers flexibility, and building agile into your processes is also a good way to mitigate risk.
Projects generally have three key parameters — time, budget and scope. In the case of GovCMS, the date was set in stone so one of the other two project parameters needed to be flexible (e.g. scope or costs). There were requirements that were non-negotiable, but using agile allowed us to do discovery, capture and groom backlog user stories (including estimates) and then prioritise to deliver the “must haves”, ahead of the “should haves” and “nice to haves”. So lower priority tasks that couldn’t be achieved within the timeframe were out of scope.
If there’s a high requirement in a stream but more time/resources are required this can be done by either increasing the budget or by re-prioritising the backlog so something of lower priority is dropped off or deferred.
The GovCMS project’s four streams all had sprints running in parallel, each with scrum masters running daily stand-ups across each stream. Weekly program check-ins allowed us to align across all streams. Jira was configured to allow for tickets to be cross-referenced across streams where there were dependencies.
Sprint planning and user story prioritisation allowed us to align on sprint priorities ahead of each sprint and make sure there were plans in place to deal with cross-stream dependencies. Regular product backlog prioritisation was conducted to review priorities. In this case the MVP (minimum viable product) was used to classify the requirements that must be achieved before go-live.
The product backlog, which consists of all stories making up all the requirements, evolved over time with some new requirements discovered along the build. These were groomed to include acceptance criteria, validated by the client (Department of Finance), and then estimated.
Using agile, as long as the product backlog is prioritised new requirements can be accomodated. New requirements may end up being prioritised ahead of original requirements, which can then get moved to future phases, if necessary. There’s an ongoing process to keep prioritising the backlog. If new requirements need to be delivered along with original requirements before the hard deadline, then these will have an impact on costs (e.g. more sprint capacity is required), then we can have this discussion with the client. For example in GovCMS new feature requirements for the new platform were added after the original MVP (minimum viable product) requirements were defined in discovery. This meant that some of these new requirements were prioritised over the original requirements and there was also some additional sprint capacity added to cater for more complete requirements ahead of go-live.
The agile delivery process
Salsa Digital’s take
Whole-of-government digital platforms deliver on Salsa’s key focus — to help governments become more open, more connected and more consolidated. And using agile methodology gives us the necessary flexibility to deliver large-scale whole-of-government projects like the second-generation GovCMS.
