When a company just doesn’t get IT
I received a laughable email this morning, from the IT Group’s central administrative assistant. In fact, all employees here at the lab received this email. Well to be specific, its not the email that caught my attention but the attachment: a spreadsheet of acronyms and terms, with their respective meanings.
My first chuckle came when I reached “DDR SDRAM” which if you don’t know apparently means “Double Data Rate SDRAM”. Jump down to “SDRAM” to get “Synchronous DRAM”; scroll back up to “DRAM” to find “Dynamic RAM” and so on, ad absurdum.
The author’s failure to proofread is worthy of a chuckle, but that alone is not the essence of what makes this document funny. After wondering “Who wrote this list?”, I thought to myself, “More importantly, who were they writing it for?” It obviously was not intended to be a consummate list of IT terms — that much is clear not only because of what terms were left out, but because of the countless medical, and otherwise unrelated terms that were included. Here’s a sample:
4GL - Fourth Generation Language
ACT - Activated Clotting Time
BMP - Bitmap
CVVHDF - Continuous Venovenous Hemodiafiltration
FCIP - Fiber Channel over IP
MS - Microsoft (?)
OLTP - On-Line Transaction Processing
P - Pulse
SOAP - Simple Object Access Protocol
and my personal favorite:
USA - United States of America
Is this list for IT professionals, or for medical professionals? I’m sure that any medical professional would be equally as confounded with the included selection of medical terms as I am with that of the technical ones. I can’t think of any audience that would benefit from this spreadsheet. As far as I can tell, whoever compiled this list has successfully wasted their and my time. Of course, now I know that 1000mg is the abbreviation for 1 Gram.
This journey led me to a third, more important observation. The terms definition list includes several project management buzzwords that carry a negative connotation such as ‘in jeopardy’, ‘at risk’ and ’scope creep’. All of these mixed right in with other project management terms that make direct references to my IT group. The fact that these terms are the ones being identified for everyone to learn makes it obvious to me that IT is considered a hostile enemy.
What happened in the past 20 years that turned IT departments from proverbial ‘knights in shining armor’ into lepers that are a necessary evil? Twenty years ago user interfaces were barren and functionality was dictated by strict necessity. As hardware got cheaper, solutions got more robust. Users who were used to very limited systems started to get more functionality and even some niceties. Managers were increasingly happy because computers could replace some jobs altogether. Feed someone bread and water for a couple of years, and then see their eyes light up when you offer them jam, or peanut butter, or milk (mmm pb&j with a cold glass of milk!).
IT was in its heyday when direction still came straight from the needs of the end-users. Then some curious things happened to dramatically change the landscape of the industry. The first tragedy came when IT departments started turning into IT companies. Smart entrepreneurs realized that there was a huge ROI potential with their internally developed systems, when marketed to other companies. Great moneymaking idea, but unfortunately this displaced the end-user from their spot as the customer. IT departments became the new customers, translating and interpreting their own end-users’ needs to the software company. Everyone knows what happens when engineers talk to engineers, and to begin with end-user to engineer translation is not as simple as English to Spanish.
In this pivotal role, overweight IT departments and overpaid consulting companies have flourished. They’ve recreated almost every business practice including project management, resource planning, and customer relationship management, all in the name of doing things more effectively but in most cases to the detriment of the processes. Want to cripple a successful sales force? Manage them with Goldmine.
The bottom line is that IT shouldn’t be making business decisions. IT should only make implementation decisions. Sure the separation between the two can get blurry, especially with bad business decisions that call for you to put a square peg in a circular hole. These bad business decisions only happen when the business doesn’t have a good understanding of their environment, and that education is the responsibility of IT.
Educate, advise, but never direct. Play in your sandbox all you want because that’s what you’re there for and you’re probably really good at it. Maybe suggest to your company a finer grain of sand that would pack better with water. Feel free to implement a periodic sand-cleaning process. Never, ever interfere with how the sand gets there or who its bought from. I think my kindergarten teacher tried to teach me something like this… “Mind your own business”
