Template:Waiting: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 5: | Line 5: | ||
How do these waiting periods arise? Well, it’s not hard to understand. | How do these waiting periods arise? Well, it’s not hard to understand. | ||
*'''{{wasteprov|Waiting}} on the client''': The [[negotiation]] process requires client input. {{wasteprov|waiting}} on that is largely but not entirely outside your control — if the client doesn't read emails, there’s only a certain number of polite, passive aggressive reminders before you just have to shut up and wait.<ref>But see {{wasteprov|overproduction}} — a client who isn't answering your emails is disinclined — or maybe isn’t under that much pressure — to respond to you. What does this say about how much it values your business? Is that really the million buck prospect?</ref> But let’s say the client ''is'' looking at the document: the ''shorter'', ''easier'' and ''less objectionable'' your document is, the faster the client’s review, all other things being equal,and the faster it will come back ''and with fewer comments''. Each comment requires action and implies more waiting. Right? | *'''{{wasteprov|Waiting}} on the client''': The [[negotiation]] process requires client input. {{wasteprov|waiting}} on that is largely but not entirely outside your control — if the client doesn't read emails, there’s only a certain number of polite, passive aggressive reminders before you just have to shut up and wait.<ref>But see {{wasteprov|overproduction}} — a client who isn't answering your emails is disinclined — or maybe isn’t under that much pressure — to respond to you. What does this say about how much it values your business? Is that really the million buck prospect?</ref> But let’s say the client ''is'' looking at the document: the ''shorter'', ''easier'' and ''less objectionable'' your document is, the faster the client’s review, all other things being equal,and the faster it will come back ''and with fewer comments''. Each comment requires action and implies more waiting. Right? | ||
So, how to make your client documents easier and less objectionable? '''Make it ''shorter''''': the fewer words there are to read, the faster the client will read it. '''Make it ''nicer''''': Don’t include terms you don’t ''really'' need.<ref>See {{over-processing}}.</ref> Do you really need that [[NAV trigger]]? Before you say yes, ask yourself, ''“how many times have I ever actually used a [[NAV trigger]]?”''<ref>The answer you will get is | So, how to make your client documents easier and less objectionable? '''Make it ''shorter''''': the fewer words there are to read, the faster the client will read it. '''Make it ''nicer''''': Don’t include terms you don’t ''really'' need.<ref>See {{over-processing}}.</ref> Do you really need that [[NAV trigger]]? Before you say yes, ask yourself, ''“how many times have I ever actually used a [[NAV trigger]]?”''<ref>The answer you will get is “I have absolutely no idea because we don’t keep data on that.” The actual answer, for the fiendishly interested, is ''never''.</ref> | ||
*'''{{wasteprov|Waiting on an internal [[escalation]]''': Eventually the client replies, and it doesn’t like that [[NAV trigger]]. Per policy, you must escalate this to [[Credit]] team. This involves composing and sending an email, then {{wasteprov|waiting}} for [[credit]] to reply.<ref>[[Credit]] will, eventually, be fine with dropping the [[NAV trigger]] — see {{wasteprov|over-processing}}.</ref> That is a 15 sec decision, but it will take 24 hours (on a good day) to achieve. Reduce this wait time (and improve data control) by: '''Standardising terms''' to pre-approve obvious giveaways empowering negotiators to approve common points of contention; '''recalibrating standards''' to reduce the gap between “starting offer” and “walkaway point”; '''standardising the escalation process''' to capture [[metadata]] about variations from the requested terms | *'''{{wasteprov|Waiting}} on an internal [[escalation]]''': Eventually the client replies, and it doesn’t like that [[NAV trigger]]. Per policy, you must escalate this to [[Credit]] team. This involves composing and sending an email, then {{wasteprov|waiting}} for [[credit]] to reply.<ref>[[Credit]] will, eventually, be fine with dropping the [[NAV trigger]] — see {{wasteprov|over-processing}}.</ref> That is a 15 sec decision, but it will take 24 hours (on a good day) to achieve. Reduce this wait time (and improve data control) by: '''Standardising terms''' to pre-approve obvious giveaways empowering negotiators to approve common points of contention; '''recalibrating standards''' to reduce the gap between “starting offer” and “walkaway point”; '''standardising the escalation process''' to capture [[metadata]] about variations from the requested terms | ||
:'''Post-negotiation approval, execution and storage processes''': Once the negotiation is finally agreed there is a lot of time preparing execution agreements, summarising terms and submitting them for final formal approval, obtaining signatures and filing approvals, execution copies and capturing key agreement metadata in the firm’s risk and trading systems. | :'''Post-negotiation approval, execution and storage processes''': Once the negotiation is finally agreed there is a lot of time preparing execution agreements, summarising terms and submitting them for final formal approval, obtaining signatures and filing approvals, execution copies and capturing key agreement metadata in the firm’s risk and trading systems. | ||
:*Currently this is a labour-intensive, manual task. Technology here offers an enormous capacity for efficiency and digital audit. | :*Currently this is a labour-intensive, manual task. Technology here offers an enormous capacity for efficiency and digital audit. | ||
Revision as of 13:43, 31 May 2019
Waiting
Headline: Over to you, Chuck
Whenever no-one is actively handling work in progress, in the sense of marking it up, or arguing with someone (internally or externally) about it, it is waiting. In a typical negotiation that is likely to be more than 90% of the time.[1]
How do these waiting periods arise? Well, it’s not hard to understand.
- Waiting on the client: The negotiation process requires client input. waiting on that is largely but not entirely outside your control — if the client doesn't read emails, there’s only a certain number of polite, passive aggressive reminders before you just have to shut up and wait.[2] But let’s say the client is looking at the document: the shorter, easier and less objectionable your document is, the faster the client’s review, all other things being equal,and the faster it will come back and with fewer comments. Each comment requires action and implies more waiting. Right?
So, how to make your client documents easier and less objectionable? Make it shorter: the fewer words there are to read, the faster the client will read it. Make it nicer: Don’t include terms you don’t really need.[3] Do you really need that NAV trigger? Before you say yes, ask yourself, “how many times have I ever actually used a NAV trigger?”[4]
- Waiting on an internal escalation: Eventually the client replies, and it doesn’t like that NAV trigger. Per policy, you must escalate this to Credit team. This involves composing and sending an email, then waiting for credit to reply.[5] That is a 15 sec decision, but it will take 24 hours (on a good day) to achieve. Reduce this wait time (and improve data control) by: Standardising terms to pre-approve obvious giveaways empowering negotiators to approve common points of contention; recalibrating standards to reduce the gap between “starting offer” and “walkaway point”; standardising the escalation process to capture metadata about variations from the requested terms
- Post-negotiation approval, execution and storage processes: Once the negotiation is finally agreed there is a lot of time preparing execution agreements, summarising terms and submitting them for final formal approval, obtaining signatures and filing approvals, execution copies and capturing key agreement metadata in the firm’s risk and trading systems.
- Currently this is a labour-intensive, manual task. Technology here offers an enormous capacity for efficiency and digital audit.
- Digital execution seamlessly captures necessary information and auto files storage
- Process maintenance:
- Template maintenance and approval, version control, storage, retrieval
- Template library complexity – too many models?
- Playbooks, negotiation manuals
- Legal opinions
Summary: Most of your negotiation time is dead air. Fix that.
- ↑ I totally made that up, but I think it is conservative. Over a three-month ISDA negotiation, if you aggregate actual time physically editing a document, typing escalation emails and speaking to internal stakeholders and the client on Skype about the content of the document, would that be 24 hours? Highly doubtful. but let's be a little crazy and call it 48 hours. Forty eight straight hours - six full working days — of doing nothing but typing, editing and discussing. Over a three month period, 48 hours is 2.1% of the total time. So waiting time is 97.9% of the process.
- ↑ But see overproduction — a client who isn't answering your emails is disinclined — or maybe isn’t under that much pressure — to respond to you. What does this say about how much it values your business? Is that really the million buck prospect?
- ↑ See ===Over-engineering===
Headline: Don’t design your plane to be waterproof in case it falls into the sea. Design it so it doesn’t crash.
In its original physical manufacturing sense, over-processing refers to unnecessary complication in design, whether brought about through carelessness or over-specification. The production cost of features that no-one will ever use is as much a form of wastage as any.
The chief production cost in contract negotiation is time and human resource. The longer a contract takes to read, and the more it invites challenge[1], the more expensive it is to produce. Any time taken over the bare minimum needed and any client challenge to a term that is not really vital the firm’s risk protection strategy is a waste in the contract negotiation process.
As we have seen, client challenges to credit terms create their own additional wastes (waiting, transport, as well as risking of overproduction and defects).
In contract negotiation, over-processing arises in two chief ways:
Risk controllers are short an option
Risk controllers are short an option. They are incentivised to err on the side of caution: they don't get a bonus if the client generates extra revenue, but they will be regarded as having failed if the client blows up owing the firm money[2]. So no wonder there are overreaches in the terms they require in general client documentation.
While credit teams do not typically monitor or collect data about the frequency with which they invoke specific credit terms, we know for sure that:
- Well over 90 per cent of client contracts never default at all,
- Of those contracts which are closed out, in nearly all cases the cause of default is a failure to pay or insolvency. Counterparties will generally not challenge these two events of default during the negotiation process (how could they? that you will pay what you owe when you owe it, and that, by extension you will be solvent enough to do it, are your counterparty’s most fundamental expectations. If you won’t commit to these, you should get your coat.)
Barnacles and the effluxion of time
Over time contract templates will inevitably accumulate what I call “barnacles” — ad hoc responses to historic situations, anecdotal reactions to unexpected risks, flannelesque flourishes to placate a truculent, obtuse or just downright stubborn counterparty — no-one likes them, but if your client insists on redundant (or misconceived) terms (“for the avoidance of doubt”; “without limitation”; “because it is our policy to require them” — that kind of thing) for the sort of fellow who prefers a short-term fix over long-term existential satisfaction, the pragmatic response is to agree them and move toward execution.
These barnacles have a habit of finding their way into, and encrusting, negotiation templates. And, as people move on, their original justification — if there even was one — becomes lost to time. The instinct of successive risk controllers, short an option as they are, upon encountering them will be, “I don’t know why that is there, but whoever put it in must have had a reason for doing that,[3] so the safest thing is to leave it there.”
This will lead more complicated templates, longer templates and a proliferation of different templates.
Summary: Over-processing arises through excessive caution in credit terms and through the natural, pragmatic process of getting negotiations across the line. If your counterparty insists on something misconceived, idiotic but basically harmless, then few negotiators will die in a ditch about it.[4] The length and convolution of documents creates significant over-processing wastage and, as a by-product, waiting and transport wastage as well, through unnecessary escalation."
. - ↑ The answer you will get is “I have absolutely no idea because we don’t keep data on that.” The actual answer, for the fiendishly interested, is never.
- ↑ Credit will, eventually, be fine with dropping the NAV trigger — see over-processing.