IT strategy: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
Created page with "Ground up IT strategy ===Constraints=== *Few resources **To pay for IT **To package/maintain/install IT **To configure for use **To train users *User intransigence ===Opport..."
 
No edit summary
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
Ground up 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


===Constraints===
NB: users who are legally and technically literate are '''rare'''.
*Few resources
 
**To pay for IT
===Institutional Problems===
**To package/maintain/install IT
====The Meatware====
**To configure for use
**To train users
*User intransigence
*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===
===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
__NOEDITSECTION__
__NOTOC__
{{c|Essay}}

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