Diagnosis module: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
← Older editNewer edit →
VisualWikitext
m Amwelladmin moved page Process analysis module to Diagnosis module
No edit summary
Line 1: Line 1:
{{a|gsv|}}Scratch pad on how to do the initial scoping of a process/documentation fix:
{{a|gsv|}}Scratch pad on how to do the initial scoping of a process/documentation fix:


First thing you need is [[symptom]]s. What is wrong? Why is someone calling you?  
First thing you need is to identify the [[symptom]]s. What is wrong? Why is someone calling you? Symptoms are usually the things you want to fix — but they are not the causes of the problem. They are its output; its ''manifestation''. If you address symptoms without addressing their [[root cause]], they will continue to recur as soon as you stop doing what you are doing.


===Describe existing process===
===Describe existing symptomatic process===
Understand how and why we got here in the first place.
Understand how and why we got here in the first place.
#Map out the ''symptomatic'' process that the client currently goes through that generate the symptoms.  
#Map out how the ''symptomatic'' process currently happens.  
a. What outcomes do the business want to achieve?
*What is the desired outcome?
b. What are the legal/disclosure risks the current legal docs/disclaimers are addressing?  
*What is typical path, including [[horizontal escalation]]s and expected hand-offs?  
c. How effective are they?
*What risks and unwanted outcomes are addressed and how are they addressed?
(iii) What are the practical challenges/delays/inefficiencies in this process.  
:*Are they the right things to focus on?
a. What can go wrong?
:*How effectively are they dealt with? (is it “day-to-day relationship management”, “enforceable legal remedies” or disclaimers and “disclosures”) ie are these effective [[coping strategies]]?
b. What unnecessary hand-offs and horizontal escalations are there?
#What are the practical challenges/delays/inefficiencies in this process.  
(iv) In a perfect world, what would be the optimal process? (ie ignoring tech/budgetary constraints)
*What can go wrong?
a. What would have to change to make that perfect world
*What unnecessary hand-offs and [[Horizontal escalation|horizontal escalations]] are there?
i. Things that are practically impossible
#Solutionising: In a perfect world, what would be the optimal process? (ie ignoring tech/budgetary constraints)
ii. Things that are too expensive
*What would have to change to make that perfect world
iii. Things that involve changes to policies and rules
*Things that are practically impossible
iv. Things you could change now.
*Things that are too expensive
(v) Assuming that perfect word is unattainable, what would be the nearest practical scenario we could realistically get to?
*Things that involve changes to policies and rules
i. What dependences/challenges/changes would we have to make to get there (e.g.: challenging the rule that we have to send out the “legal entity disclosure”; a decent file management system, harmonising us rules etc)
*Things you could change now.
#Assuming that perfect word is unattainable, what would be the nearest practical scenario we could realistically get to?
*What dependences/challenges/changes would we have to make to get there (e.g.: challenging the rule that we have to send out the “legal entity disclosure”; a decent file management system, harmonising us rules etc)
ii. Who would need to agree to it?
ii. Who would need to agree to it?
iii. What would need to be done and who would be doing it?
iii. What would need to be done and who would be doing it?
iv. How would you implement it?
iv. How would you implement it?
{{sa}}
*[[Coping strategy]]

Revision as of 13:07, 4 October 2021

A quixotic attempt to change the world, one iteration at a timeIndex: Click ᐅ to expand:
General Systems Unit
Design
Tell me more
Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

Scratch pad on how to do the initial scoping of a process/documentation fix:

First thing you need is to identify the symptoms. What is wrong? Why is someone calling you? Symptoms are usually the things you want to fix — but they are not the causes of the problem. They are its output; its manifestation. If you address symptoms without addressing their root cause, they will continue to recur as soon as you stop doing what you are doing.

Describe existing symptomatic process

Understand how and why we got here in the first place.

  1. Map out how the symptomatic process currently happens.
  • What is the desired outcome?
  • What is typical path, including horizontal escalations and expected hand-offs?
  • What risks and unwanted outcomes are addressed and how are they addressed?
  • Are they the right things to focus on?
  • How effectively are they dealt with? (is it “day-to-day relationship management”, “enforceable legal remedies” or disclaimers and “disclosures”) ie are these effective coping strategies?
  1. What are the practical challenges/delays/inefficiencies in this process.
  1. Solutionising: In a perfect world, what would be the optimal process? (ie ignoring tech/budgetary constraints)
  • What would have to change to make that perfect world
  • Things that are practically impossible
  • Things that are too expensive
  • Things that involve changes to policies and rules
  • Things you could change now.
  1. Assuming that perfect word is unattainable, what would be the nearest practical scenario we could realistically get to?
  • What dependences/challenges/changes would we have to make to get there (e.g.: challenging the rule that we have to send out the “legal entity disclosure”; a decent file management system, harmonising us rules etc)

ii. Who would need to agree to it? iii. What would need to be done and who would be doing it? iv. How would you implement it?

See also

Retrieved from "https://jollycontrarian.com/index.php?title=Diagnosis_module&oldid=59653"