IT strategy
Ground up IT strategy The innovation paradox
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. - See: strategic over tactical
- 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 the firm (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-particularized, prone to formalistic negotiation (for the avoidance of doubt...) and error (the inevitably missing “not”)
- 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 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
- 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