On 11 March, DWF Group under the leadership of CEO Andrew Leaitherland and Chairman Sir Nigel Knowles became the first law firm to IPO on the London Stock Exchange’s main market at market cap of £366 million. The 300 page prospectus[1] makes useful reading about the intersection of technology with the market for legal services in the UK.
The information in the prospectus on the size and shape of the market is about as accurate as you can get at the moment: it says that the global legal services is growing at 4% per year, and was worth £653bn in 2017, with the USA (£218bn or 33% of the whole) and the UK (£33.3bn or 5%) holding the top two spots, and France and Germany next up at £20bn or 3%). From The Lawyer UK 200 2018[2], we know that the top 200 UK law firms generated total revenues of £25.68bn in 2017, so when DWF, as the no. 23 firm with revenues of £235 million, say they’ll be investing up to £10 million from the IPO in new IT systems, you realise how powerful these technology drivers in law are becoming. As the DWF prospectus notes (at page 8):
“The legal services sector is becoming increasingly complex as traditional law firms, alternative legal service providers and technology firms increasingly compete and collaborate. Technology is increasingly viewed as a strategic enabler to proactively offer client-centric solutions. This ongoing evolution is a response to client-led demand and the increasing disaggregation of service delivery.”
With all today’s excitement around LawTech, it’s easy to overlook the pivotal role across the top 200 UK law firms played by core IT practice (PMS), case (CMS) and document (DMS) management systems, and it is into these systems that much of the law firm investment in technology is going right now. In many ways the beating IT heart of the practice, these systems are undergoing rapid change as familiar products reach end of life, firms migrate their IT to the cloud and user requirements become more demanding
So when you’re procuring or implementing a system like this what are the key things to look out for?
Providers generally divide the contract into three pieces – the software piece (covering the platform), the services piece (covering the implementation) and the more statement of work (covering the nitty gritty detail). Providers’ standard form agreements tend to be long on customer duties and provider rights, and short on customer rights and provider duties. The provider will have any number of contracts in the field, so will see each as probability theory and a risk reduction tool. The customer however sees the world through the other end of the telescope: it will only have one of these systems, on which it will be dependent, and so will be looking for granular, specific, measurable commitments about what the provider will do during implementation and how the system will work after go-live.
The contracts and SOW are where these two different views of the world are mediated, risk assessed and balanced. In the tables below, we’ve tried to capture our ‘3 x top 10 points’ for the software agreement, the services agreement and the SOW as key, project-specific areas where the customer can seek more meaningful contractual commitments than the provider may initially offer. (We should add that we haven’t focused here on technical ‘legals’ like confidentiality, intellectual property, warranty, indemnity, liability and termination, although it goes without saying that these will need to be appropriately addressed).
- The Software Agreement
| No | Issue | What the Customer Needs: |
| Where the software is provided on premises, ‘as a licence’ | ||
| A.1 | definition of ‘seat’ | · licence fees generally determined by seat; who counts as a seat? does it include admin staff in the legal team? who outside the legal team counts? |
| A.2 | payment start date | · providers generally want licence and maintenance fees payable from when the software is delivered.
· can you arrange a retention against milestones and acceptance? |
| A.3 | licence scope | · is any use of the software covered by the licence fee? Or is (for example) ‘indirect use’ (e.g. ‘talking to’ other systems) charged in addition? |
| A.4 | support and maintenance: | typically in the range of 18-22% per year, the customer should seek commitments:
· that maintenance will be provided during the project lifecycle (e.g. 10 yrs); · that maintenance charges will be held for a number of years, and then subject to maximum annual increases; and · that the software will conform to spec; · around KPIs and service levels, with a defined service credit regime escalating to termination for multiple outages. |
| A.5 | escrow, DR/BC | consider from the security perspective
· escrow arrangements; · business continuity arrangements; · disaster recovery arrangements; |
| Where the software is provided in cloud, ‘as a service’ (‘SaaS’) | ||
| A.6 | price and payment | · pricing will generally be per seat (see A.1 above) based on annual subscription charges (licence & maintenance rolled up), so watch out for deal duration, charges increases, etc; |
| A.7 | service levels | · define service credit/escalation regime on (i) availability, (ii) response times and (iii) other KPIs; |
| A.8 | GDPR | · GDPR is more complex in SaaS deals – if the provider is a processor only, check that the GDPR-mandated controller/processor terms are adequate; check whether the provider is also a controller to any extent. |
| A.9 | return of data | · to be able to access/get return of data at will; |
| A.10 | cloud migration in lifecycle | · the customer should be paying no more for software over lifecycle (e.g. 10 years) than if the software had stayed on prem;
· this is less easy than it looks, bearing in mind: (i) you’re comparing [perpetual licence fees + upgrade fees + annual maintenance] with [annual subscription fee + maintenance rolled up]; and (ii) there will be a paid-for services element for the cloud migration. |
- The Services Agreement
| No | Issue | What the Customer Needs: |
| B.11 | warrant RFP responses | · the provider’s RFP responses are warranted as true, complete and accurate; |
| B.12 | governance | the agreement has workable processes and procedures around:
· change control; · governance; |
| B.13 | acceptance | · set out consequences of failure to pass acceptance tests, e.g. right to terminate (and get money back) if no acceptance by longstop date; |
| B.14 | customer responsibilities | · set out in reasonable detail a statement of the customer’s duties;
· provider will ‘fix first, fight later’ and try to avoid/remedy the breach; |
| B.15 | modifications | · will software be installed ‘out of box’?
· if software is to be customized/modified: who is authorized to make these? will they be part of standard maintenance? will they be supported in the next version/release? who owns the rights to them? |
| B.16 | compliance with laws | · provider in performing its duties, and provider’s services and software, will each comply with all applicable laws; |
| B.17 | conversion | · specific commitments around data conversion from prior system; |
| B.18 | completeness | · there is no other software (proprietary or open source), hardware or services that the customer needs except as expressly set out; |
| B.19 | compatibility | · the solution is, and will remain, compatible/integrated with named other key systems of the customer; |
| B.20 | new versions | clarity around: |
- The Statement of Work
| No | Issue | What the Customer Needs: |
| C.21 | project management | · the provider is at its weakest in a competitive tender at the moment of signature, and will use its project management office (PMO) to claw back after signature what it lost before; |
| C.22 | security assessment | · customer should carry out its normal security assessment on the provider to verify that the provider’s solution aligns with the customer’s data protection and information security policies, etc; |
| C.23 | continuity | · contractual commitment around continuity of provider’s key personnel; |
| C.24 | resource levels | · provider will meet resource levels stated in the SOW; |
| C.25 | resource swap out, etc | · swap out/replacement at no cost to customer; |
| C.26 | price/payment | |
| C.27 | timesheets | · invoicing (whether monthly or by milestone) to be supported by timesheets with agreed information; |
| C.28 | implementation process | · provider to follow agreed, verifiable implementation methodology/ process |
| C.29 | project plan | · initial, then detailed, project plans (and timeline) will be completed/signed off as stated in SOW |
| C.30 | project documentation | · customer may freely use and disclose to other contractors/providers all project documentation; |
LawTech is developing quickly, procurement and implementations are on firms’ radars, and systems on offer are becoming more complex. The DWF IPO confirms that law firms are looking to build up war chests for technology acquisition in what they regard as a key area of strategic and competitive advantage. Attentiveness to the detail of the software and services agreements and the statement of work, and reducing gaps between the provider’s standard documentation and where the law firm customer can hope to get to can play a large role in successful implementation.
