Do you trust the Work-Around

In the past I already made a post related to workarounds March 23rd, 2008: Start managing your Workaround's!

In that posting I advice to start with documenting workarounds and managing them based on their lifecycle. We should avoid that workarounds get normal desired functionality by just using it; the next step would be that that usage become normal expected activities.

An article I read a while ago is related to functionality which is default in MS Outlook, auto complete e-mail addresses, only that functionality is often not embedded in processes. It is there, only organizations often don't tell you to use it or not.
CNet new: February 5th, 2008: Lilly's $1 Billion E-Mailstrom;
The New York Times, January 30th, 2008: Lilly Considers $1 Billion Fine to Settle Case.

In this example you see that functionality available in the system can be used. Workaround are often also defined because the system missing some functionality and tells you how to use parts of other functions to get your job done.

Most of us know that when defects are found, workarounds are defined; we also test the work around. Only after a while it is forgotten what the workaround actually was. Therefore we should manage the workarounds we define in systems.
We should ask ourselves each time: do we trust the workaround?