83,580
edits
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
(13 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{a| | {{a|gsv|{{image|Magrathea|png|}}}} | ||
=== | ===[[GSV questionnaire]]=== | ||
==The general systems unit== | |||
*A resource for optimising legal and ''human'' processes and systems. | |||
*In scope: design, language, legal, psychology, client experience, technology | |||
What it ''isn’t'' | |||
*A plain-English drafting service | |||
*A legal technology platform | |||
==Metaproblems== | |||
How to get people to engage. How to get people be step outside their paradigm and rethink something they might not think is broken. | |||
==Purpose== | |||
*What is the ''[[purpose]]'' of the legal department? Wider: what is the purpose of any part of the [[federation]]? | *What is the ''[[purpose]]'' of the legal department? Wider: what is the purpose of any part of the [[federation]]? | ||
==The “client”== | |||
The Client may not be who you think it is. | |||
*What is the problem: distinguish between problems and symptoms. Inanimate objects — like documents, and templates — are rarely problems: they are ''symptoms'' of problems. Formal structures are rarely problems (or even all that relevant). Problems arise in interactions For example: a crappy document | ==='''''What'' is a “client”?'''=== | ||
Someone who gives you things to do. | |||
'''Business clients''': Clients may be imposed by business imperative to sell stuff — in which case your internal client is the internal representation of the client to whom the firm is selling something — Sales — or the internal representative of the firm in that transaction with the client — Trading. | |||
'''Infrastructural clients''': Client relationships are also imposed by the formal infrastructure of the firm. Here you may be “service provider” to another “client”, or you may be “client” to another “service provider”. | |||
==='''''Who'' is your client?''' === | |||
The “business” — front office; sales and trading; the revenue generators are not your only client. In fact, it is barely a client at all. It would rather it ''didn’t'' give legal anything to do, since legal only slows it down: “Sure, do whatever you must do, but just be quick about it and don’t upset my client”. More important client [[stakeholder]]s : | |||
*Line management. | |||
*Other horizontal siloes who hold a stake in your work product: credit, tax, compliance etc: here you need their consent to carry on your task for someone else (usually the business). | |||
*Other horizontal siloes whose work product you hold a stake in: [[operations]], [[chief operating office]]. Here, ''they'' need ''your'' consent to carry on ''their'' function. | |||
'''Who, ''within'' your client, is your client'''? | |||
Are you getting calls from contractors in Hyderabad? Rather than throttling legal demand by charging for it, why not do that structurally, but limiting who — what grade — is allowed to seek it? | |||
==The “product”== | |||
The product may not be what you think it is. The product is the task to be achieved; the problem to be solved. | |||
'''Where are you going''': Thought experiment, to separate the essence of the product from its [[substrate]]: imagine all today’s limitations and technological, conceptual constraints no longer apply. Imagine you are an undefined point in the future where logistical problems have been ''solved'': you know, when there are flying cars, teleportation, we live in a virtual matrix and the analogue world has been conclusively proved to be an optical illusion. | |||
You don’t need paper, you don’t need email, you don’t need humans — this is a thought experiment, remember: The [[AI]] embedded in the General Systems Vehicle ''Just Because You’re Paranoid Doesn’t Mean No-one’s Following You'' can automatically configure agreements by itself. | |||
Now: in that scenario, what would your process look like then? What, in other words, is its [[Platonic form|Platonic essence]], that cannot be reduced by optimising [[Legal services delivery|legal service delivery]]? That is your product. Once you know that, then, considering everything you know now, and all [[adjacent possibilities]], and recognising the infinite number of useful things you don’t know, that if you did know, might send you in a different direction, what practical step can you take ''today'' that would lead in the direction that today looks like the optimal one? | |||
What wasteful processes or componentry can you remove? | |||
What new processes can you instill that will make the machine run better? | |||
Tomorrow, having taken that step, ask yourself that question again, afresh, based on the information and the [[adjacent possibilities]] open to you tomorrow. | |||
Rinse, repeat. This is [[iteration]]; this is super-forecasting: continually cleansing, reconsidering and rebasing, based on currently understood state of affairs. | |||
What do we have available to us to imagine that future: | |||
'''Where did you come from''': How did your process/problem get to where it was? Did it spring, fully formed, from the brow of the superbrain, or is it the result of a long, iterating, series of feedback loops: i.e., a malfunctioning system? If it is, you can’t fix the problem without fixing the system. | |||
=== ''Tools'' and ''expertise''. === | |||
Do not confuse tools and expertise. Tools ''facilitate'' expertise. They ''amplify'' expertise. They cannot replace it. | |||
=== Expertise === | |||
==== Lawyers ==== | |||
A [[lawyer]] is not the product. What do lawyers want, and how do lawyers function best? Autonomy, mastery, purpose. | |||
How do your tools deliver Access to knowledge. | |||
==== Knowledge ==== | |||
=== Tools === | |||
==== Documents ==== | |||
We call it work product but a legal ''document'' is not the product. It is evidence of the product. Likewise, a bad document is not the problem. It is a ''symptom'' of the problem. | |||
==== Technology ==== | |||
[[Technology]] is not the product. It is a tool for solving the problem, or delivering the product. Technology cannot replace expertise | |||
==The problem== | |||
*What is the problem: distinguish between problems and symptoms. Inanimate objects — like documents, and templates — are rarely problems: they are ''symptoms'' of problems. Formal structures are rarely problems (or even all that relevant). Problems arise in interactions For example: a crappy document | |||
*Is what we focus on really the problem? | *Is what we focus on really the problem? | ||
=== | ===Tools=== | ||
*[[Problem solving module]] | |||
*[[Process analysis module]] | |||
*[[Escalation threshold]] | |||
{{Sa}} |