Better information systems — VPEC-T (contd.)
Different language, different mindset
Another of those flashes of clarity came as I read a table comparing the language that the business user and IT use. This was not about the gulf between business jargon and technology jargon. That's something that is well understood - as a problem, even if the jargon itself is not.
The table shows how the language of business users must of necessity be different from that of those developing IT solutions.
Business users work in a constantly changing world. From necessity, not through oversight, they use ambiguous language when talking about their needs: It reflects the demands of their working environment. They expect employees dealing with a changed or new situation to understand the principles on which the business operates and either work out what to do, or refer to a more senior person if they cannot.
IT practitioners must resolve ambiguity before writing down what the business requires from the information system they are working on. There is no way (yet) to give a computer an ambiguous instruction. Every eventuality must have a path and defined action. Any that doesn't will almost certainly fail or perform a wrong action.
Business users understand how market forces and societal issues will force unpredictable and irregular change on what they must do, when they must do it, and how. For example, if a competitor adapts a service and shows every sign of taking market share as a result, the business must respond.
IT practitioners require certainty. Like their business counterparts they will likely understand how market forces change the business' needs, but they cannot make an IT solution process a new service after, say, a few training sessions and some new pages in the company's Operations Manual.
Business users assume tacit knowledge and adaptable behavior based on experience and instruction. For example, if a new kind of credit card fraud arises, and they receive information about characteristics to watch out for from credit card issuers, they can instruct sales staff and expect them to be vigilant based on the new instructions.
IT practitioners must work with explicit knowledge and pre-determined rules. IT solutions must be instructed on all the eventualities with which they are expected to deal. If a new pattern of fraud is to be detected, the criteria for detection must be programmed into the system. Clearly there's no human solution, like saying “use common sense, and ask if you are not sure”.
Business users embrace high change as can be seen from the forgoing.
IT practitioners expect low change.
The book presents this as a necessary difference of language, but it is much more - it is a difference of mindset, resulting from the different environments in which the two groups work.
Once again, understanding this and having it spelled out helps both sides. It provides a basis for discussion about where difficulties will arise (and they will).
VPEC-T may not be what you'd name your child, but it looks like a greatly improved mechanism for this change. It is strong on integration and determinedly pushes IT to the later stages of a project. It's hard to see how you could practice VPEC-T yet still find yourself sucked into technology discussions at too early a stage in an information systems project.
But how does it really work out? ⇒