82,891
edits
IT strategy: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Ground up IT strategy | Ground up {{tag|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=== | ===Institutional Problems=== | ||
====The Meatware==== | ====The Meatware==== | ||
*User intransigence | *User intransigence | ||
**technological: don’t understand/like new technology | **technological: don’t understand/like new technology; significant change fatigue | ||
**Technical: | **Technical: Our skill is creating and articulating bespoke solutions, not commoditising standard ones. | ||
**Lawyers don’t write well. Legal drafting is convoluted, over | **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 | **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. | ||
*Legal department’s institutional position: Being a control function, Legal is “short an option” | *Legal department’s institutional position: Being a control function, Legal is “short an option” | ||
**Important to | **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==== | ====The firmware==== | ||
| Line 35: | Line 50: | ||
**Workshare | **Workshare | ||
*Opportunities to enhance/improve existing tools | *Opportunities to enhance/improve existing tools | ||
*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) | |||
*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__ | __NOEDITSECTION__ | ||
__NOTOC__ | |||
{{c|Essay}} | |||