James Smart, Maddocks - Practical tips on preparing effective IT contracts for police


Published on

James Smart, Partner, Maddocks delivered the presentation at the 2014 Police Technology Forum.

The Police Technology Forum 2014 seeks to address technology innovation, evolution and development within Australia’s law enforcement industry.

In two days, a panel of experts gather to examine opportunities, initiatives and issues facing organisations both in front line policing as well as in wider law enforcement industry, including transport, border protection and surveillance.

For more information about the event, please visit: http://www.informa.com.au/policetechforum

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

James Smart, Maddocks - Practical tips on preparing effective IT contracts for police

  1. 1. Practical tips on preparing effective IT contracts for police James Smart | Partner 13 March 2014
  2. 2. Introduction  Key issues for police to consider when drafting and negotiating IT contracts  How to ensure you can deliver a successful project: scope/time/budget  Understanding IT contracts in a police/emergency services context
  3. 3. Victorian Ombudsman report (2011) – key points  IT projects are often poorly managed and failures are common  The public sector does not manage IT-enabled projects effectively  Examined 10 major IT-enabled projects: each failed to meet expectations, most failed to meet delivery timeframes and all ran over budget  58 recommendations to improve the way IT-enabled projects are planned and delivered
  4. 4. Key reasons for failure in IT projects  Failing to understand the complexity and cost of a project  Poor business cases  Failing to identify and manage risk  Poor project management and governance structures  Poor procurement and evaluation processes  Poor contracts  Inadequate contract management and performance monitoring  Staff with inadequate expertise
  5. 5. Promoting good performance  Link payment to performance: link payment with the acceptance of milestones or KPIs. KPIs should be clear, relevant, measurable and reported against  Set-off clauses: which allow payments owing to the contractor to be set off against any amounts claimable as a result of the contractor failing to meet its obligations under the contract  Liquidated damages: this avoids the need to litigate and prove loss. Entitlements to LDs will be most useful in situations where you are able to calculate what the actual loss will be for breach of a contractual obligation. If the entitlement to liquidated damages is a ‘penalty’ it will be unenforceable
  6. 6. Liquidated damages: tips for drafting  Include a clear method for calculating LDs  Ensure that the amount of damages is not excessive or out of proportion to any damages that are likely to be suffered as result of a breach  Consider how payment will be received. A deduction by the government body on the next amount payable is generally the preferred option
  7. 7. Andrews v ANZ  Caution when drafting performance/abatement clauses  Need to estimate the likely loss or the clause may be unenforceable as a penalty
  8. 8. Contract governance  It is important to ensure the level of service you will receive is satisfactory – ‘normal’ service vs services required in emergency situations  Establish a clear governance framework, eg a steering committee and reporting protocols and a dispute resolution process  Ensure it is clear how rights and obligations will be performed
  9. 9. Step in rights  Step in rights ensure that if the contractor's performance becomes an issue, you can step in and take over their role  Step in rights should be included: – in major IT contracts – in contracts which are crucial to the performance of your statutory duties
  10. 10. Drafting step in clauses  When drafting step-in clauses, you will need to consider: – circumstances – the need for level of expertise – the costs and any necessary compensation – step out procedure – no liability
  11. 11. Indemnities  Why use them?  An indemnity is a primary obligation to provide compensation and operates like a debt  Consider and allocate risks: – what are the key risks in the project? – which party is best placed to manage those risks? – what types of loss will be covered by the indemnity and are all relevant losses covered? – what insurance does the contractor have in place to guard against the risks?
  12. 12. Indemnities  Contractor indemnity: key areas eg breach/negligence  Liability caps – exclude: – personal injury or death – confidentiality and privacy – third party IP rights  Circumstances in which the indemnity will not apply? – exclusion of consequential loss – actions by you or third parties  Indemnity by your organisation?
  13. 13. Insurance  Types of insurance  Evidence of insurance  Linking a liability cap to the amount that can be recovered under insurance
  14. 14. Variations  It is crucial that, when a supplier does not comply with a contract, you take proactive steps to manage the problem  Variations should: – be in writing – be in specific terms – identify all relevant conditions – identify all other consequential amendments that are necessary – obtain a benefit for your organisation where possible
  15. 15. Variations  Manage variations carefully  Conduct a risk assessment for each proposed variation – what is the reason for the change? – will it alter the parties’ obligations under the contract? – will it have any financial impact? – will it have any impact on timing?
  16. 16. Variations – will it impact on any key documents? – do you have authority to make the change?  Follow the specific variation procedure in the contract  Ensure you have not waived future rights  Ensure the contract is kept up to date following each variation
  17. 17. Planning an escape mechanism  When parties are in dispute and termination is being contemplated, it is important that the contract is clear about your rights  Consider whether the following types of clauses are sufficiently clear in your contract: – termination for convenience – termination for breach – transition out clauses
  18. 18. Termination for convenience  Based on doctrine of executive necessity – eg change in government or government policy  For reasons of flexibility, you should generally require a termination for convenience clause  Your sole discretion – no fault needs to be proved  To protect both parties, the contract should usually contain a clause requiring you to compensate the contractor for loss caused by the early termination: – capped amount – reasonable losses directly resulting from the termination – exclusions, eg consequential loss – requirement to mitigate
  19. 19. Termination  Before terminating, ensure you have complied with all of its obligations  Consider termination as a last resort  Does the contract involve a critical element of your functions?  Consider long term relationships/intra-government arrangements  Avoid wrongful termination as this might make you liable for damages  Termination takes time and costs money and an alternative supplier will still be required
  20. 20. Transition out  Consider what, if anything, you will require from the contractor at the expiry or termination of the agreement  Transition arrangements should address issues such as: – service continuity during transition to a new provider – access to the contractor's documents, software, IP, equipment, confidential information and data – access to personnel – co-operation with new contractors – a specified timeframe for the transition – provision of material to form part of a new RFT
  21. 21. Key legislative obligations  Privacy: contractors must protect personal information. Contracts should require compliance with the IPPs/APPs and contractors should be directly liable for any breaches  Freedom of information: contractors should be required to provide you with documents in accordance with FOI legislation
  22. 22. Key legislative obligations  Record keeping legislation: obligations on police to keep records – eg Public Records Act 1973 (Vic), Archives Act 1983 (Cth)  Audits: requirement for Auditors-General to access documents of contractors in some circumstances  Ombudsmen: power to review your actions or decisions which may extend to actions taken under contract
  23. 23. Conclusion  Plan and scope each IT project carefully  Understand the context in which the technology or software will be provided  Ensure the services or functionality are documented  Use a contract that is designed for the specific project  Ensure all key risks are identified and appropriately allocated under the contract
  24. 24. Conclusion  Aim is to minimise risk and deliver a successful project  Important to ensure that the technology or software is delivered under the contract as required  Also important to avoid criticism of the way the contract was managed
  25. 25. Practical tips on preparing effective IT contracts for police James Smart | Partner Direct 61 3 9258 3632 Mobile 0419 148 796 james.smart@maddocks.com.au