The theme of the 2015 Budget encourages Australian Government entities to proactively reform the way they do business. Specifically, there is strong encouragement to maximise the opportunities available from digital innovation and emerging technology. In doing so, it is timely to consider options for improvements in current and past procurement and contracting strategies and mechanisms. 

Common problems you may have experienced include:

  • Technology innovation - contractual obligations that are so general that they are meaningless, so any new technology has to be negotiated as a change at additional cost, and you end up with a contract full of piecemeal obligations with no coherent story or outcome for customers.
  • Single service providers failing to take total solution or service responsibility, and multiple vendors failing to work together to offer a seamless solution for the customer. Without a focus on this in the contract, the customer is left with major risk for achieving the objectives of the project. 
  • Service providers failing to properly understand a customer's requirements for a significant ICT system, leading to delays, scope creep and change, additional resource effort and cost blow-outs.
  • Failure of both parties to recognise the complexity of an environment in which a system or service is being implemented, leading to disputes about responsibility, delays, and the customer having no choice but to accept a lower quality contract outcome, and at an increased cost.
  • Service providers failing to offer benefits that reflect the value of their aggregated Australian Government business, leading to multiple individual entity contractual arrangements with no whole-of-government benefits, such as strategic relationship benefits, volume discounts, or a coordinated approach to continuous improvement. 
  • Service providers creating loopholes in contracts to insert their own or third party overriding terms for example including hyperlinked terms on purchase orders issued under a contract.

These problems are not new, but many current procurement processes do not properly identify and manage them. Procurement strategists and contract drafters have to be agile to embrace new ways of solving these problems - indeed, some of the tools of the 90s may be worth reviving!

Here are some suggestions:

  • Technology change - embrace the future and build it in to your procurement process and your contract. It is possible to design and draft provisions that will allow both parties to follow a clear and well-understood path to the future, and there are lots of ways of doing this, and options for incentives to ensure this concept is actively embraced by suppliers. For example, consider including a transformation procedure to facilitate a move to cloud computing if this cannot be implemented at the outset, but may be of benefit in the future.
  • Procurement process - design the process to ensure the market gains the best possible understanding of your requirements. Consider incorporating tenderer due diligence or tenderer engagement provisions in your RFT. There are many ways of doing this, and as long as the process is properly and efficiently managed, it will be a benefit to all involved.
  • What really matters - identify what you really want to achieve from a procurement process. Consider revolving the process (and payment mechanisms) around achieving your broader outcome requirements, rather than burying yourself in the minutiae of technical service levels. This will require you to reconsider all aspects of your contract, but it is an opportunity to achieve a new form of service provider motivation.
  • Negotiation strategy - identify and target negotiations towards the major risks of the project, and resolve those before getting lost in the detail (or before you are stuck with one tenderer). Consider staged discussions focusing on key principles before tenderers may advance in the process. Nail those big picture issues properly before going further, and, if you have to reconsider your requirements or any other aspect of the process, do so (and reserve clearly explained rights to do so, so as to ensure the market is working with you and not against you).
  • Requirements drafting - don’t just focus on what you want done by the service provider. Think about your requirements from a service provider's perspective. What stakeholders will they need to deal with? Where are the blurry bits in the scope of the requirement? How can you clarify or resolve these? Add your objectives for these elements to your statement of requirements, rather than assuming they will be dealt with in general governance after the contract is signed. Remember contractors price in the risk, and customers then pay for that - even when the risk never crystallises.
  • Systems integration - do you remember this concept from the early 90s? It's back in favour - because customers now often seek their technology business solutions from multiple providers, as an alternative to the large-scale outsourcing approach of the late 90s and early 2000s. Include and explain specific systems integration requirements, to cover matters such as who has what responsibility for all the elements of the solution, how stakeholders will communicate and work together and how this behaviour will be measured as well as more objective performance requirements.
  • Overriding contract terms by words and conduct - strong contract protections against this risk may not be enough (e.g. because of the risk of estoppel). You need to build this risk into your management and performance measurement framework in the contract i.e. active, express protections. Avoid ending up with a contract full of multiple licence terms and metrics, with a significantly increased risk of licence non-compliance.
  • Coordinated procurement - make the most of piggybacking clauses in many Commonwealth contracts, and of whole of government procurement arrangements. It is not difficult to use piggybacking clauses, and whole of government arrangements can be built into major services contracts on a discretionary use basis.