One of the universal truths about data management is, wherever possible, avoid managing to the exception. What I mean by this is to avoid developing any process that is designed to catch some arcane or unusual circumstance. Instead, the process should capture what happens the vast majority of the time, and then let staff manage the exceptions manually.

One of my favorite examples came from a client who had designed their membership join process to include a step for approving membership, and then once membership was approved, an invoice was sent. They had added this step because, in some instances, new members would join and pay their dues, and then it would turn out the individual was not actually eligible for membership in the association. So staff would have to cancel the membership and provide a refund. Staff didn't want to have to cancel and refund, but as a result, their current process meant that membership joins often took 60 or more days to complete!

But the reality was this: Of the hundreds of new joins this association received each year, only two or three were from individuals who were not eligible for membership. Their process for membership joins had been built around the exception, not what most commonly happened.

It's too easy to fall into the trap of designing our processes to address every possible contingency or possibility. But more often than not, managing to the exception creates more problems than it solves.

So take a look at all of your processes and ask yourself: Was this designed to address the majority of cases, or the exceptional ones?