A growing portion of an IT departments job is setting the rules by which the network runs, applications access resources and users can do their jobs. Rule breaking takes different forms, and each circumstance requires a different solution.
Regular Rule Breaking
Cause 1: Ignorance
Regular rule breaking may be occurring simply because employees do not know the rules. The solution in this case is either training of the individuals or a wholesale review of the training process and documentation.
Cause 2: Standard Operating Procedure
Regular rule breaking is sometimes the result of standard operating procedure. This often occurs when the rules change but people stay with their old processes. The solution in that case is better training.
Another cause, though less common, is when IT rules conflict with business processes. Perhaps drawing control used to issue new drawing numbers and approve drawings, but new IT rules separate those two tasks, assigning them to different individuals. Or roles are now consolidated whereas users are still assigning tasks to the old team roles. Either business processes need to change so that it is in accordance with the rules or IT rules need to change. A combination of the two may be necessary.
Cause 3: Exception Handling
Users sometimes run into problems when they run into the exceptions to the rule. They may break the rules trying to find a way of handling the exception. Or they may be struggling to get through a task for which there is no documented standard operating procedure. The rules appear to be broken, but only because there is no clear process to follow.
Rare Rule Breaking
Rare rule breaking has several possible causes. Let's look at each in more detail.
Cause 1: Training
Rare rule breaking can occur when someone simply doesn’t know the rules. A new manager may not have fully trained a new hire, or the new rules weren’t taught when the employee changed job assignments. This sort of event needs to be monitored in case it is a sign of a larger systemic breakdown.
Cause 2: Just Get It Done
The product manager was told to just get it done. A key quality signatory is on vacation and the alternate hasn’t been identified. Instead of delegating to a second or third person, the product manager assigns the role to him or herself and approves the item themselves. Formal approved processes existed, but the push to get it done led to a violation of the separation of roles. The solution in these cases is usually a mixture of better processes, more communication and stronger impressions made on managers that rules aren’t there to encumber employees but meet business objectives.
Cause 3: Using Exception Handling to Bypass Rules
Perhaps finance requests that IT change the sign off date of a digital document so that it shows as completed on time when management runs the reports. Or a ticket is put in to give someone permissions they really shouldn’t have, because a product manager won’t give it to them. Rare rule violations may occur as a result of exception handling, where users use exception handling processes to get around the rules.
The solution in this case is better training of those who handle exceptions and teaching employees how to get things done within existing processes.