Government Insight: Procurement in the age of Platform+Agile

Back
We are delighted to welcome Dr Steve Hodgkinson, Chief Information Officer for the Victorian Department of Health and Human Services (DHHS), to discuss his Platform+Agile strategy in the context of government procurement of ICT.
Steve Hodgkinson government procurement ICT
Dr Steve Hodgkinson, CIO DHHS

Government procurement of ICT needs to change – and is in the process of doing so. The main drivers for this are necessity and opportunity. The too-frequent failure of traditional procurement approaches is making it necessary to try something different, and the transition of the ICT industry to cloud services is creating opportunities for a fresh approach.

The problem – stupid digital stuff

Firstly though, what is wrong with government procurement of ICT? Or rather, what is wrong with the ‘traditional’ approach to implementing new ICT-enabled business solutions? It takes too long and too-often fails to produce a satisfactorily operational system at the end of the process.

Why? (Gasp! Don’t get me started!) The basic problem is that each project is usually treated as a one-off, application-sourcing, tryout. Define detailed requirements, write an RFQ, go to market, evaluate responses, select a vendor, stand up a project team, implement software and infrastructure, transition to operations, roll out the solution to users…

For a business system of any complexity this process can take years, and go off the rails at any stage. We have all experienced projects that have ‘gone bad’. Projects are often, in effect, a ‘mad science experiment’ – with unqualified or inexperienced practitioners mixing up unknown or poorly labelled reactants ‘just to see what happens’. Surprise! BANG!!

I have described this whole situation in the past as doing ‘stupid digital stuff’. Four key problems are common:

  1. It’s hard to fully articulate requirements ‘up front’ – projects fail to meet user expectations… but how could they succeed when users are unable to fully articulate ‘what they want’, and anyway their needs are evolving in response to rapidly changing strategy and service delivery imperatives?
  2. The Government procurement process is a minefield – the procurement process is inherently complex, over governed, and difficult to implement successfully… RFTs are difficult to write properly, evaluations are time consuming, contracting can be a nightmare… probity risks abound.
  3. There are too many unknowns involved – too many ‘surprises’ occur during projects… the software or infrastructure doesn’t perform as promised/expected or doesn’t integrate properly or skills are lacking in the project team.
  4. The process just takes too long – the project gets overtaken by events such as changes in leadership or changes in business needs following an election.

Platform+Agile to the rescue

My strategy for ICT projects in DHHS seeks to attack these four problems head on. I call it Platform+Agile. This means that we aim to make a strategic decision about preferred platforms and then use these platforms for multiple ‘applications’ which are implemented in an agile, iterative, manner upon a platform by experienced in-house developers. We seek to avoid ‘application-by-application’ projects and transactional procurement for new business systems whenever possible.

Procurement, in fact, is the exception rather than the rule. It is only necessary when we need to buy a new platform or procure a new platform element or a niche SaaS application to ‘plug a gap’ in our architecture… or to buy necessary infrastructure or to buy strategy or implementation services.

The Platform+Agile approach means that DHHS has significantly improved the productivity of our application development process. Starting with a platform encourages the reuse of standard modules, focuses in-house skills on known and trusted ICT environments, avoids nugatory procurement, builds inter-operable ecosystems etc. and enables application development teams to get started more quickly and deliver results in a more agile, iterative, dev/ops manner. It is faster, better, less risky and less costly.

The best platforms, these days, are the market-leading enterprise-grade cloud services, because they are already shared services being used by many different organisations and are hence proven to be able to meet diverse needs by configuration, while still preserving ‘evergreen’ upgrades. The platforms pool investment in functional and technical innovation, security and systems automation across large global customer bases. Interoperability is promoted by the use of modern application program interfaces (APIs).

These platforms also ‘save us from ourselves’, because the subscription charges fully embed a sustainable TCO inclusive of DR, backups, modern security controls, infrastructure upgrades, software patching etc. It is not possible to buy the system and then neglect its maintenance and upgrading. Good cloud services deliver as per their label… as I like to say “cloudy is as cloudy does”.

While we have a large range of legacy systems in a diverse range of platforms, looking forward, DHHS’s strategic platforms (at the moment) are Salesforce, Microsoft .NET/Azure, ServiceNow and Oracle. We have implemented multiple new business systems in these platforms in the past year and have developed strong in-house skills and partnerships with ecosystems of vendors (including CenITex) so that these are ‘known and trusted’.

The Platform+Agile approach tackles the four key problems one at a time:

  1. It is (no longer) hard to fully articulate requirements ‘up front’ – when the platform is already available as-a-service, then prototype systems can be quickly created and iterated in an agile manner to ‘demonstrate the art of the possible’ and to shape user requirements to the ‘sweet spot’ of functionality that can be efficiently delivered. Time that used to be spent writing requirements documents is now spent building and iterating prototypes and discussing them with users – who love seeing early results and being able to visualise more clearly what the system will do.
  2. The Government procurement process is (no longer) a minefield – if the platform is already available then no procurement is required.
  3. There are (no longer) too many unknowns involved – once the platform is established and the development team gains knowledge and skills in its use, then the number of unknown variables is significantly reduced. New solutions reuse existing modules and templates and are deployed using pre-established security and operational protocols.
  4. The process just (no longer) takes too long – Platform+Agile projects can (and are) delivered in weeks and months… not months and years. Speed is safety.

Compounding organisational learning

The most significant benefit of the Platform+Agile approach is, however, nothing to do with an ICT project. This approach enables the organisation to LEARN more quickly. It enables what I call ‘compounding organisational learning’. In banking, compounding interest is all about the accumulation of money. Compounding organisational learning is all about the accumulation of knowledge about ‘things that work’ (and, of course, things that don’t). The Platform+Agile approach accelerates the cycle time of organisational change. Iterative system releases deliver multiple cycles of learning through the iteration of prototypes and the phased evolution of solutions over time. Traditional ‘big bang’ projects, in contrast, can often take years to deliver one cycle of learning.

Implications for ICT vendors

The Platform+Agile approach, however, clearly creates some challenges for companies seeking to sell into the government ICT market. In some ways this is a rerun of the ‘integrated ERP’ vs. ‘best of breed’ solution debates of the 80s and 90s. Is it better to have a small number of large systems or a large number of small systems? A small number of strategic cloud service platforms or 1000 SaaS apps?

The local ICT industry would no doubt prefer that government continued down the best of breed path – many small systems create more RFT opportunities. The cloud services model, however, is a game-changer when combined with the four key problems noted above. Platform+Agile is a necessary response to the failure of past projects. While it is good for government procurement to benefit local industry (all of our children need jobs…) this cannot come at the expense of the ability of department and agency ICT functions to successfully deliver projects and provide affordable and sustainable business systems.

The key implication for ICT vendors is the imperative to understand and align with platform ecosystems. If your solution isn’t, or can’t become, a platform, then you need to become a value-adding part of a platform provided by another vendor. Scale matters. Interoperable ecosystems matter. Speed matters. Delivery is strategy.

2 comments in this article

  1. Jeff Smoot

    Hi Steve,
    I have read with interest your article above and agree whole heartedly with your message. I have had previous roles as MD Cerner APAC and Regional VP Allscripts and left the big EMR provider segment, in agreement to the 4 key problems you articulate. I am now CEO ANZ Vitro software. I was introduced to the organization 3 years ago and joined because the value of the solution clearly addresses the Plarform+Agile approach you define. As you would be aware Bendigo Health chose our solution as the DMR which has been recently implemented in the existing facility and will be migrated across to the new facility later this month. LMRHA is evaluating the potential of leveraging what Bendigo Health have done as they decide on a solution for their region. My mobile is 0400 080 630. My email is jsmoot@vitrosoftware.com. You can view my profile on LinkedIn. I would appreciate it if you would contact me as I would like to meet with you. I would like Vitro to be in a position to provide a consistent message around the Plarform+Agile approach globally as we continue to grow our business.

    1. Deirdre Diamante

      Dear Jeff, thank you for your comment. I have forwarded your note to Steve Hodgkinson in case he doesn’t read it here.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.