It's not the discount double check, but I am a fan of processes that are built to check other processes. When I have a process that runs, or data quality that should be checked, or some other system where I can potentially have a failure, I like to write a separate check, as an independent process, that ensures work is done correctly.

Why? Because things go wrong. Most of us schedule a process, like an ETL job, and we assign failure notification (and potentially success notification). If the process succeeds or fails, we get notified. However, what happens if the process doesn't run? In our busy lives, we might not notice that the success email is missing. What if the process runs incorrectly? Do we have some other process that looks for data to be correct, or even present?

A second (or third) check can make all the difference in the world between operations that appear to run smoothly for our clients, and those processes that always seem to fail. Even if the process fails, if you get notified quickly, you can potentially fix it before your clients notice. That makes you look more professional, but it's also what should happen. You should ensure things run smoothly.

An independent check is also a good security check. Brian Kelley wrote a piece about people tampering with your processes. Would you be aware if that happened? Most people would not, unless they have some auditing, or independent processes that looks for potential security issues.

There are all sorts of mechanisms to perform checks for you, such as GPOs, Policy Based Management, and more, but have you enabled or scheduled them? Anywhere you have automated processes, you should consider writing separate checks and scheduling them to be sure your processes are running correctly.