Compliance Options: The Power of Rules

When my brother, sister, and I were kids, we loved to play Three Stooges. We’d walk into ladders, carry boards so they’d smack into things, and yell, “Nyuk, Nyuk, Nyuk!” as we twisted each others’ noses and tried to poke out each others’ eyes.

The problem with this game was our mother. If we were indoors when we were playing, the chaos and screams would eventually get her attention. She’d then speak those dreaded three little words: “No roughhousing indoors!”

And that was it for Three Stooges time. We Thomas kids were loud and energetic, but we weren’t stupid. We knew which rules could be broken and which ones couldn’t.

We knew that “no roughhousing indoors” wasn’t a law, like “no stealing.” We knew it wasn’t a community rule, like “don’t leave toys on the sidewalk.” It was a policy—Mama’s policy—and the fact it was arbitrarily enforced wasn’t important. If it mattered enough in the moment for Mama to utter those words, then we knew it was time to pay attention. Something was going on that made the policy important, and it didn’t matter if we were privy to the details. We knew that, for now, compliance wasn’t optional.

Maybe it was those years of dramatic tension between structure and chaos that lured me to the world of data management. On the one hand, we have the beauty of architecture. On the other hand, many practices are still pretty rough-and-tumble. There are those who strive to evolve Three Stooges antics into precisely choreographed dances, but the truth is most IT shops operate somewhere in between. Sure, there are laws and regulations that must be obeyed. There are policies that sometimes seem to be arbitrarily enforced. And then there are those good practices we want to enforce—and the people who shout them down, taking advantage of chaos to slip through bad work, uncontrolled processes, or non-standard data.

Here’s where compliance can be your friend. Compliance requires adherence to a set of conditions; these may be spelled out as regulations, policies, or rules. Rarely will these conditions be specific enough to describe your hour-to-hour activities. Instead, it’s up to you and others to interpret how those conditions map to your processes and practices.

For instance, Sarbanes-Oxley compliance requires formal, consistent, documented, and auditable controls over financial data. These controls were initially spelled out at a very high level, based on universal good practices such as checks and balances. Then they were spelled out in more detail appropriate for different job areas. For financial clerks, it meant the person who entered a vendor’s information into a system wasn’t allowed to issue a check to that vendor. In your arena, there was probably a policy—or at least a departmental rule—constraining activities in development environments vs. production environments. If you (or others) didn’t like that rule, chances are the mantra, “It’s required for SOX compliance” was enough to win the argument for compliance.

So, why can’t you take advantage of similar situations? I’ll bet you would like to be able to enforce certain good practices. Maybe your project teams have a habit of overloading data fields; putting more than one type of information in the same container. Or, maybe they like to create new data fields rather than research whether data exists and can be repurposed.

Why don’t you consider drafting your own departmental rules? Put them in a small document with a commanding name. Get them blessed as far up the line as possible. Then you’ll have something authoritative to pull out when someone is breaking the rules. Who knows? Maybe your stern, “No roughhousing indoors!” will be enough to stop some trouble at the source.

Perhaps your document will contain only a series of succinct policy statements. However, it may be useful to turn it into a more robust policy document. If so, consider including the following:

• An easy-to-remember name

• One or more short policy statements

• A purpose statement where you tie the best practices you want to promote to the acknowledged regulations they support

• A scope statement

• Definitions

• Roles and responsibilities.