IT strategy

Ground up IT strategy

What is technology?

It's not just about computers

• The primarily technology we deal with is legal technology. We need to simplify that before we can simplify the computer tech.
• The first step to simplifying legal technology is to simplify the source code on which legal technology is compiled: Language
  • Plain English isn't a fad or an optional extra. It's a fundamental design principle. It's easier and cheaper to code for plain English.

Constraints

Resources

There is a marked lack of financial and HR resources to implement new systems:

• To buy new IT (Bottom line expense)
• To package/maintain/install IT (Technology resource)
• To configure new IT for UBS (Technology resource)
• To configure for use by legal (Legal/Technology resource)
• To train users (internal Legal/Technology resource) - do not underestimate the importance and difficult of this

NB: users who are legally and technically literate are rare.

Institutional Problems

The Meatware

• User intransigence
  • technological: don’t understand/like new technology; significant change fatigue
  • Technical: Our skill is creating and articulating bespoke solutions, not commoditising standard ones.
  • Lawyers don’t write well. Legal drafting is convoluted, over-particularised and prone to negotiation and error
• User knowledge is imperfect
  • Individuals who don’t understand policies are incentivised to apply them literally (being institutionally short an option - see below)
  • Institutional Knowledge: Generally is good (UBS turnover is comparatively low) but we leak institutional knowledge and it is not tracked and captured.
• Institutional knowledge is poor
  • We don’t track our decisions - no MI kept on litigation close shaves; which issues come up and which don’t.
• Legal department’s institutional position: Being a control function, Legal is “short an option”
  • We are not rewarded for approving successful business;
  • We are criticised for approving business which encounters any legal issues.
    • Important to differentiate legal and commercial issues and allocate ownership correctly. (e.g.: indemnities are, ultimately, commercial and not legal issues)

The firmware

• Bad static data (inaccurate; unreliable)
• Bad legal standards (overcomplicated; commercially unrealistic; out of date)
• Bad templates (too many; overcomplicated; inconsistent; out of date)
• Bad taxonomies

Opportunities

• Data we don’t use: All historical departmental email: - a rich source of indexable institutional knowledge - this resource should not be restricted to use in conducting.
• Underused/misunderstood existing tools -
  • Sharepoint
  • Microsoft Word/Excel
  • Workshare
• Opportunities to enhance/improve existing tools
  • TADH
• Easy implementation to enhance interaction and connectivity
  • “Business Data Catalogs” to interrogate external databases from within Sharepoint
  • Application Interfaces (“API”s)
• Open source solutions - There is a lot of good, free software available (e.g. MEdiawiki)
• You have to spend to save: Some technology is worth investing in.

There are benefits to doing things differently

We are in a new world, and we should upgrade our practices to take account of it: e.g. Electronic execution,

• collects audited information about the time and date of execution
• documente assembly naturally stores documentation and collects key metadata about the variable content of the agreements

Challenge

• First: clean up: it is much easier to automate a simple structure than a complicated one. Simple structures are more scalable, less prone to error.
• Small projects: See above. Be unambitious. Small, unglamorous projects save resources incrementally and buy time for projects.
  • e.g., Confidentiality Agreements
• Co-ordinate: each project should be managed separately, but users should be encouraged to share technology, and build on each other’s work - centr