IT strategy: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
Ground up {{tag|IT strategy}}
Ground up [[IT strategy]]
The [[innovation paradox]]
==What is your ''hole''?==
==What is your ''hole''?==
what do you want? In Management Consultant speak, what is your “key objective”?  
what do you want? In Management Consultant speak, what is your “key objective”?  
Line 14: Line 15:
*To buy new IT (Bottom line expense)
*To buy new IT (Bottom line expense)
*To package/maintain/install IT (Technology resource)
*To package/maintain/install IT (Technology resource)
*To configure new IT for UBS (Technology resource)
*To configure new IT for the firm (Technology resource)
*To configure for use by legal (Legal/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  
*To train users (internal Legal/Technology resource) - do not underestimate the importance and difficult of this  
Line 25: Line 26:
**technological: don’t understand/like new technology; significant change fatigue
**technological: don’t understand/like new technology; significant change fatigue
**Technical: Our skill is creating and articulating bespoke solutions, not commoditising standard ones.
**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
**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
*User knowledge is imperfect
**Individuals who don’t understand policies are incentivised to apply them literally (being institutionally short an option - see below)  
**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: Generally is good but we leak institutional knowledge and it is not tracked and captured.
*Institutional knowledge is poor
*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.
**We don’t track our decisions - no MI kept on litigation close shaves; which issues come up and which don’t.
Line 49: Line 50:
**Workshare
**Workshare
*Opportunities to enhance/improve existing tools
*Opportunities to enhance/improve existing tools
**TADH
*Easy implementation to enhance interaction and connectivity
*Easy implementation to enhance interaction and connectivity
**“Business Data Catalogs” to interrogate external databases from within Sharepoint
**“Business Data Catalogs” to interrogate external databases from within Sharepoint
**Application Interfaces (“API”s)
**Application Interfaces (“API”s)
*Open source solutions - There is a lot of good, free software available (e.g. MEdiawiki)
*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.  
*You have to spend to save: Some technology is worth investing in.  



Latest revision as of 13:30, 14 August 2024

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