What is the problem? It has been common knowledge since the dawn of business computing that IT people have zero social skills, talk in jargon, and generally get their kicks by making users feel stupid. It is also well known within IT that users are hopelessly illogical, will blame IT for their own mistakes, and are purposefully vague about requirements so that they can claim IT didn't deliver. The two sides don't communicate well and this inability to communicate has (1) formed an industry, the Business Systems Analyst industry (a.k.a. the people who can translate between the business and IT), and (2) resulted in layers of red tape so that everyone can cover their backs, often referred to as the software development life cycle. This is a huge expense--time, money, and health.
What is the solution? Teach the business to speak IT! For 50 years we tried it the other way, and as Dr. Phil might say, "How's it working for you?." Why pay the higher wage earners to understand the lower wage earners? Doesn't it make sense to at least try the alternative?
No one really wants or expects the people in marketing, sales, finance, etc. to speak in IT terms. In fact it is almost never a good idea for a non-technical person to state what they want in actual technical terms. If they do they just might get what they asked for and not what they need. This caution applies to other technical disciplines like law, for example.
So, practically, what would help? How can the 'users' (and their managers) learn to communicate with IT and begin the dissolution of the Business Systems Analyst industry and the destruction of 'cover your back' bureaucracy?
The Dirty Secret. When speaking with IT it may help you to know that the technology you have been supplied is not there to make you happy. Any 'user friendliness' was a cost/benefit decision to increase your effectiveness. IT gets paid to give you the least (in cost) amount of technology you need to do your job, not to make you happy. If technology could replace you entirely, then management would direct IT to do so.
Never lie! If your notebook starting making that grinding noise right after you checked it in as baggage instead of carrying it on the plane or you know you entered the wrong data then own up to it. If you lie you will be found out. If you are found out after the IT department has gone to great expense, perhaps even exchanging threats with suppliers, you will likely become the IT poster child used to explain to the executives why IT has trouble delivering the important things.
Help the Help Desk. If you get an error message write it down (or better, make a screen shot). Be ready to describe everything you were doing when the error happened. IT doesn't ask you what you were doing to be nosy or trip you up, they ask you so that they can try and recreate the problem-about the only way to find a fix. The software you are using has been tested and used to do just what you were trying to do, but you have, through no fault of your own, found some rare combination of key strokes and clicks that have caused a failure. IT will not find the real problem unless they can reproduce this rare set of conditions.
"The system doesn't work." is no help. "I was entering customer data, and funny enough, they all had the same street name but different cities! The error happened on the fourth customer." will pin point the problem. Err on giving IT too much information.
Communicate your requirements. If you have the opportunity to help define a new or enhanced software product then you will be asked for your requirements. This is a tough job and one where the Business Systems Analyst industry makes a bundle. To talk IT in this case is to be clear, precise, and thorough in what you need.
We (IT) used to laugh at the manager we called Generally Speaking. We might say, "So, if we now understand, when the customer has no receivables over 60 days, the order is for less than $100K, open orders amount to less than $500K, and the customer has paid for an order in the last 12 months, then we should accept the order and give the customer a confirmation number?" Generally Speaking would then say "Yes, exactly," but before we could lean back in our chairs he would add "generally speaking." The money might just be poured down the drain, but happily it went in our pockets.
One tool everyone should learn just a bit is the Decision Table. You can learn this enough to never have to speak generally again. It is useful in many areas, not just IT, but if you use it it will surely take a bite out of the Business Systems Analyst industry. Check it out http://en.wikipedia.org/wiki/Decision_table.
Senior management is just as bad. About 10 years ago a COO told me he wanted to "get into eCommerce." I said that that was great and we should have a meeting with the CFO to lay the ground work, like what products, markets, etc. The COO said "Glen, can't I just tell you I want eCommerce and then you go away and come back with it?" The short answer was "No." The slightly longer answer was "Yes, but you wouldn't like what I produced. It will be much better if we talk through some of the details first." This COO would never have approached an initiative outside of IT in such a cavalier manner. What was blocking him from seeing that IT initiatives need justification, scopes, organization, stakeholder management, etc.? Why did he prefer to pay me to interview him about these fundamentals?
It may be a lost cause, expecting business management to realize that it would be more cost effective if the user side learned how to talk to IT, rather than continuing to pay IT to hire people to talk to them. But it's worth a shot.
Mr. Gage is an independent consultant with extensive international and cross-industry consulting and line management experience. Getting the highly unlikely done is the hallmark of his career. Contact information can be found on http://www.linkedin.com/in/glengage.
http://ezinearticles.com/?Save-Money!-Learn-How-to-Talk-to-IT&id=4861354
What is the solution? Teach the business to speak IT! For 50 years we tried it the other way, and as Dr. Phil might say, "How's it working for you?." Why pay the higher wage earners to understand the lower wage earners? Doesn't it make sense to at least try the alternative?
No one really wants or expects the people in marketing, sales, finance, etc. to speak in IT terms. In fact it is almost never a good idea for a non-technical person to state what they want in actual technical terms. If they do they just might get what they asked for and not what they need. This caution applies to other technical disciplines like law, for example.
So, practically, what would help? How can the 'users' (and their managers) learn to communicate with IT and begin the dissolution of the Business Systems Analyst industry and the destruction of 'cover your back' bureaucracy?
The Dirty Secret. When speaking with IT it may help you to know that the technology you have been supplied is not there to make you happy. Any 'user friendliness' was a cost/benefit decision to increase your effectiveness. IT gets paid to give you the least (in cost) amount of technology you need to do your job, not to make you happy. If technology could replace you entirely, then management would direct IT to do so.
Never lie! If your notebook starting making that grinding noise right after you checked it in as baggage instead of carrying it on the plane or you know you entered the wrong data then own up to it. If you lie you will be found out. If you are found out after the IT department has gone to great expense, perhaps even exchanging threats with suppliers, you will likely become the IT poster child used to explain to the executives why IT has trouble delivering the important things.
Help the Help Desk. If you get an error message write it down (or better, make a screen shot). Be ready to describe everything you were doing when the error happened. IT doesn't ask you what you were doing to be nosy or trip you up, they ask you so that they can try and recreate the problem-about the only way to find a fix. The software you are using has been tested and used to do just what you were trying to do, but you have, through no fault of your own, found some rare combination of key strokes and clicks that have caused a failure. IT will not find the real problem unless they can reproduce this rare set of conditions.
"The system doesn't work." is no help. "I was entering customer data, and funny enough, they all had the same street name but different cities! The error happened on the fourth customer." will pin point the problem. Err on giving IT too much information.
Communicate your requirements. If you have the opportunity to help define a new or enhanced software product then you will be asked for your requirements. This is a tough job and one where the Business Systems Analyst industry makes a bundle. To talk IT in this case is to be clear, precise, and thorough in what you need.
We (IT) used to laugh at the manager we called Generally Speaking. We might say, "So, if we now understand, when the customer has no receivables over 60 days, the order is for less than $100K, open orders amount to less than $500K, and the customer has paid for an order in the last 12 months, then we should accept the order and give the customer a confirmation number?" Generally Speaking would then say "Yes, exactly," but before we could lean back in our chairs he would add "generally speaking." The money might just be poured down the drain, but happily it went in our pockets.
One tool everyone should learn just a bit is the Decision Table. You can learn this enough to never have to speak generally again. It is useful in many areas, not just IT, but if you use it it will surely take a bite out of the Business Systems Analyst industry. Check it out http://en.wikipedia.org/wiki/Decision_table.
Senior management is just as bad. About 10 years ago a COO told me he wanted to "get into eCommerce." I said that that was great and we should have a meeting with the CFO to lay the ground work, like what products, markets, etc. The COO said "Glen, can't I just tell you I want eCommerce and then you go away and come back with it?" The short answer was "No." The slightly longer answer was "Yes, but you wouldn't like what I produced. It will be much better if we talk through some of the details first." This COO would never have approached an initiative outside of IT in such a cavalier manner. What was blocking him from seeing that IT initiatives need justification, scopes, organization, stakeholder management, etc.? Why did he prefer to pay me to interview him about these fundamentals?
It may be a lost cause, expecting business management to realize that it would be more cost effective if the user side learned how to talk to IT, rather than continuing to pay IT to hire people to talk to them. But it's worth a shot.
Mr. Gage is an independent consultant with extensive international and cross-industry consulting and line management experience. Getting the highly unlikely done is the hallmark of his career. Contact information can be found on http://www.linkedin.com/in/glengage.
http://ezinearticles.com/?Save-Money!-Learn-How-to-Talk-to-IT&id=4861354
No comments:
Post a Comment