IT strategy

From The Jolly Contrarian
Revision as of 13:56, 1 February 2017 by Amwelladmin (talk | contribs)
Jump to navigation Jump to search

Ground up IT strategy

What is your hole?

what do you want? In Management Consultant speak, what is your “key objective”?

  • The customer in the hardware store doesn't want a power drill. She wants a hole in the wall. (Theodore Levitt)
  • The question is not "could we have a chatbot" but what is the problem we are trying to solve?.

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