When Documents Meet Reality

Charles Drayson

Sep 21 · 2 min read



Process Failures

Last month, I made a claim for my wife under a health insurance policy. It was a stressful situation needing quick treatment. We called the claims number to begin the process. The claims handler said my wife was not covered under the policy; the relevant hospital consultant was not recognised by the insurers, and the procedure was outside the scope of cover. We arranged the procedure without their help. Time was pressing.

It later transpired that all three assertions were incorrect. They asked if we wanted to make a complaint. We did. They stated their procedure for handling complaints, and then missed their self-defined timescales for investigating.

I am surely not alone in experiencing a situation where an organisation says one thing and does another. Why does that happen?

I suspect process failures cause many mistakes. I further suspect that many process failures arise because there is no reliable connection between a promise in a document and organisational readiness to deliver on the promise. We are too accepting of that disconnect. It’s the same reason why business teams sometimes talk proudly about signing a contract and then putting it in a draw (never to be used). If we can make promises in documents without being accountable for performance, no wonder we end up with lengthy policy documents that are ignored and protocols that probably wouldn’t survive a first contact with reality.

Decisions, decisions

If we see fit to make promises, plans and decisions in accordance with a document, it is possible to flow documented commitments into a delivery process that aims to comply. Moreover, if we at least try to connect the documents to the delivery process, we might discover glitches before we disappoint the customer or do damage somewhere in the supply chain. If we find we cannot connect the commitments to the delivery process, we must invoke a manual intervention to bridge the gaps, or maybe stop making promises that are not achievable.

Some documents should be part of a workflow

My past experience working as a lawyer for a large business process outsourcing company, revealed a consistent root cause when we retrospectively reviewed occasional service failures. In almost all cases, the root cause of failure could be traced back to a customer asking us to do something non-standard, often in a hurry as a favour, and our teams did what the customer wanted without the guard rails of a procedure that trapped errors.

Unless you are documenting a service that can be truly bespoke, such operational documents should not be an opportunity for artistic flourish in the hands of your employees. If they find the ‘system’ doesn’t let them do what they want to do (“Computer says no”), provide an escalation route that ensures a human checks whether the non-standard items are sensible. A system that doesn’t cater to infinite options is your friend.

When Documents Meet Reality

Charles Drayson

Sep 21 · 2 min read

Process Failures

I am surely not alone in experiencing a situation where an organisation says one thing and does another. Why does that happen?

Decisions, decisions

Some documents should be part of a workflow

Some documents, if they are intended to create action, should be part of a reliable workflow. The workflow doesn’t have to be automated, but automated workflow are dependable. Integrating documents within a workflow means documents should be created in a way that ensures they are tailored to finite, known boundaries – with options that match what you can deliver. Unless you are documenting a service that can be truly bespoke, such operational documents should not be an opportunity for artistic flourish in the hands of your employees. If they find the ‘system’ doesn’t let them do what they want to do (“Computer says no”), provide an escalation route that ensures a human checks whether the non-standard items are sensible. A system that doesn’t cater to infinite options is your friend.

More Weekly Articles