Playbook: Difference between revisions

1,083 bytes added ,  2 November 2018
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
   
   
Playbooks derive from the belief that business is a heuristic<ref>See {{author|Roger Martin}}’s {{br|The Design of Business: Why Design Thinking is the Next Competitive Advantage}}.</ref>.  
Playbooks derive from the belief that business is a [[heuristic]]<ref>See {{author|Roger Martin}}’s {{br|The Design of Business: Why Design Thinking is the Next Competitive Advantage}}.</ref>.  


In {{author|Thomas Kuhn}}’s conception of it<ref>{{br|The Structure of Scientific Revolutions}}. It's a brilliant book. Read it. </ref>, [[normal science]]: There are no mysteries or conundrums. The landscape has been fully mapped, boundaries have been set, tolerances limited, parameters fixed, risks codified and processes fully understood. Playbooks are algorithms for the [[meatware]]: a means of maximising efficiency when operating within a fully risked environment.
In {{author|Thomas Kuhn}}’s conception of it<ref>{{br|The Structure of Scientific Revolutions}}. It's a brilliant book. Read it. </ref>, [[normal science]]: There are no mysteries or conundrums. The landscape has been fully mapped, boundaries have been set, tolerances limited, parameters fixed, risks codified and processes fully understood. Playbooks are algorithms for the [[meatware]]: a means of maximising efficiency when operating within a fully risked environment.


They speak to the belief that ''the only material risk lies in not complying with established rules'': Playbooks are of a piece with the doctrine of precedent: When the playbook runs out of road, there is an [[escalation]] to a [[control function]]. the [[control function]] acts like a competent court, the idea being (in theory, if not in practice) that the the [[control function]] can develop the heuristic to deal with the new situation, and it can be fed back down and incorporated into the playbook as a kind of ''[[stare decisis]]''  to updating and building out the corpus of established process.<ref>This is rarely what happens in practice. [[control function]]s make ''ad hoc'' exceptions to the process, do not build them into the playbook as standard rules, meaning that the playbook has a natural tolerance (and therefore inefficiency). The heuristic is set inside the organsiation’s risk tolerance (this is a good thing from a risk monitoring perspective, but a bad one from an efficiency perspective, as [[escalation]] is a wasteful and costly exercise.
They speak to the belief that ''the only material risk lies in not complying with established rules'': Playbooks are of a piece with the [[doctrine of precedent]]: When the [[playbook]] runs out of road, there is an [[escalation]] to a [[control function]]. the [[control function]] acts like a competent court, the idea being (in theory, if not in practice) that the the [[control function]] can develop the [[heuristic]] to deal with the new situation, and it can be fed back down and incorporated into the playbook as a kind of ''[[stare decisis]]''  to updating and building out the corpus of established [[process]].<ref>This is rarely what happens in practice. [[control function]]s make ''ad hoc'' exceptions to the process, do not build them into the playbook as standard rules, meaning that the playbook has a natural tolerance (and therefore inefficiency). The heuristic is set inside the organisation’s {{tag|risk}} tolerance (this is a good thing from a risk monitoring perspective, but a bad one from an efficiency perspective, as [[escalation]] is a wasteful and costly exercise.


In theory the [[control function]] will have its own playbook, and the “court of first instance” is as bound by that as the baseline process is by the basic playbook. There is an algorithm, a recipe, and the main ill that comes about is by not following it.  
In theory the [[control function]] will have its own playbook, and the “court of first instance” is as bound by that as the baseline process is by the basic playbook. There is an algorithm, a recipe, and the main ill that comes about is by not following it.  
Hence the existence of an [[internal audit]] function. Two roles: (i) identifying the rule set, and (ii) seeking data as to compliance with it. It is a formal role only.
Note the behaviour that this encourages: following an if/then logic structure requires no understanding of the underlying subject of the process (you don't need to know how an internal combustion engine works to drive a car), and indeed such comprehension risks challenge or subversion of that process: [[subject matter expert]]ise might incline one to take a view on a formal, non material issue. This accelerates the particular item through the system, but at a cost to the integrity of the process.


The other thing about [[subject matter expert]]s is that they are expensive. The name of the game is cost reduction. The ideal process participant costs nothing, follows instructions with perfect fidelity, doesn't break down or make errors, and certainly doesn't think or question the process. One escalates within the process, one doesn't question it.  
Hence the existence of an [[internal audit]] function. Two roles:
:(i) identifying the rule set, and
:(ii) seeking data as to compliance with it. It is a formal role only.
 
Note the behaviour that this encourages: following an if/then logic structure requires no understanding of the underlying subject of the process (you don’t need to know how an internal combustion engine works to drive a car), and indeed such comprehension risks challenge to or subversion of that process: [[subject matter expert]]ise might incline one to ''take a view'' on a formal, non material issue. That might accelerates the particular item through the system, but at a cost to the ''integrity of the process''.  Integrity of the process is ''everything'' in modern risk management dogma.
 
The other thing about [[subject matter expert]]s is that they are expensive, also a cardinal sin in an industry where the highest calling is cost reduction. The ideal “[[process participant]]” costs nothing, follows instructions with perfect fidelity, doesn't break down or make errors, and certainly doesn't think or question the process: that is, it is ''a computer''. In the same way a machine doesn't question its programme (it can't), a [[process participant]] escalates within the process, but doesn’t question it. the difference is that cantakerous human process participants ''can''.
 
But therein the problem: if the process ''can'' be computerised, why ''hasn’t'' it been? 
 
There is a paradox here, though, because to get the best outcome within the playbook parameters requires a degree of advocacy, inasmuch as the process participant is facing the outside world (beyond the playbook control) - you can best negotiate if you understand your subject material.  
There is a paradox here, though, because to get the best outcome within the playbook parameters requires a degree of advocacy, inasmuch as the process participant is facing the outside world (beyond the playbook control) - you can best negotiate if you understand your subject material.  
The portfolio risk engine ascribes the same value to any outcome as long as it conforms to the playbook. The principle measurement is speed.


The theory is we operationalise a negotiation process. We divide into doers and thinkers. Wherever there is a playbook, the demands of fidelity and economy require a deskilling and deemphasis of [[subject matter expert]]ise.  
The portfolio risk engine ascribes the same value to any outcome as long as it conforms to the playbook. The principle measurement is ''cost'' (lack of) and then ''speed''.
 
The theory is we operationalise a negotiation process. We divide into ''doers'' — [[process participants]] and thinkers “[[process designers]]”. Wherever there is a playbook, the demands of fidelity and economy require a deskilling and de-emphasis of [[subject matter expert]]ise from the process participants.  


But we also operationalise the [[escalation]] process - the dogma of [[internal audit]] and the bottomline imperative see to that. As a result [[subject matter expert]]ise leaks out of the whole system.
The same does not hold for the [[process designers]]. BUT — and here's the thing: if we also operationalise the [[escalation]] process — and the dogma of [[internal audit]] and the bottom line imperative see to it that we do — we wind up with a series of nested playbooks stretching up and across the organisation, and the real expertise ([[internal audit]]s) becomes expertise in the operational parameters of the different layers and abstractions of operational playbook: reconciling them, testing them for consistency and compatibility, while in the mean time [[subject matter expert]]ise — of the actual substantive content of the operation — has leaked out of the whole system.


And are we even going to talk about the fact that the big shock risks that hit the systems are never ones that have previously been recognised, analysed and subjected to constant monitoring? [[Black swan]]s gonna be [[black swan]]s, yo.
And are we even going to talk about the fact that the big shock risks that hit the systems are never ones that have previously been recognised, analysed and subjected to constant monitoring? [[Black swan]]s gonna be [[black swan]]s, yo.