Policy and procedure are the true core components of system design, not data and process. These two Ps of system design are joined by a third, if you include the inevitable pain.
Now raise your hands if you have designed or coded a system to handle policies or procedures that has also involved the fourth P, politics.
More and more I am seeing our customers focus on these four Ps and not the more fundamental fifth one, profit. It’s a dirty word in this country. Our tax laws show that we as a country hate rich people almost more than we are embarrassed by poor ones. The simple fact is that corporations are in business to make money for the shareholders. And most of them don’t care how the money is made, so long as they see a steady rise in share price. Government agencies exist because a law mandated or implied the need for services. Despite behaviour to the contrary, governments want to deliver a service that meets the legal requirements at the lowest cost.
So what does this have to do with IS?
IT systems excel at making a bad process worse. Most people, particularly our paying clients, look at policy, procedure and the sixth P, programming, as one conceptual bowl of spaghetti.
You know a system design meeting has gone astray when someone is mixing up a policy point like “All employees who smoke will do so in the designated areas” with “Access to and from the building will be monitored by swipe cards.” You can build a computer system to track swipe card usage, but not to enforce a smoking rule.
Normally policy is built in a closed room by worried senior managers with a minor amount of IT involvement. The policy is then handed over saying, “Make a system for this, eh?” The trick is to dissect the policy and extract the data and process components. It’s fairly easy to see what information the policy needs to track, and even in what order the data is collected, but here are the real kickers:
How are you going to collect the data? (E.g. how often do employees smoke, how many cigarettes in what time are puffed and how many times do they complain about taxes per pack during an average butt break? Or, how often do inappropriate sexual liaisons occur in the office? That would be an interesting one to figure out.)
What parts of the policy are actually enforceable without bankrupting the company? I have worked on systems where accurate tracking was a cost that the company did not care to bear. Instead, the data that was collected was queried for anomalies. A suspect was chosen and policy-breaking confirmed manually. This was soon followed by public humiliation. To simply know that we were checking up (Big Brother or what?) was a sufficient negative incentive for people to follow the policy.
How accurate is what you collect? I have worked on a system where a particular type of policy “cheating” was so hard to prove that a higher-than-policy tolerance level was set.
After all this, do you even have an IT project left? Before you start chasing the impossible client expectations, take the time to talk with your client to do the following:
Sort out the non-IT nonsense from the hard data to be tracked.
Change the policy to make it cheaper to automate. Change the policy?!? OK, sorry – interpret the policy so that you don’t go broke implementing it.
Remember that it’s about profit. Not policy, procedure or pain.
Ford is a Vancouver-based systems consultant. He can be reached at quokka@portal.ca.
