Diagnosis module

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 symptoms. What is wrong? Why is someone calling you?

Describe existing process

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.

a. What outcomes do the business want to achieve? b. What are the legal/disclosure risks the current legal docs/disclaimers are addressing? c. How effective are they? (iii) What are the practical challenges/delays/inefficiencies in this process. a. What can go wrong? b. What unnecessary hand-offs and horizontal escalations are there? (iv) In a perfect world, what would be the optimal process? (ie ignoring tech/budgetary constraints) a. What would have to change to make that perfect world i. Things that are practically impossible ii. Things that are too expensive iii. Things that involve changes to policies and rules iv. Things you could change now. (v) Assuming that perfect word is unattainable, what would be the nearest practical scenario we could realistically get to? 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) 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?