|
IT 101
Sept 20, 2006 14:22:44 GMT -6
Post by King Rat on Sept 20, 2006 14:22:44 GMT -6
I realize this is going to sound like an attempt to pick a fight but I swear it isn't. So here goes:
Why are IT professionals so hard to get along with? As a programmer who deals primarily with industrial automation I am constantly caught in the middle of squables between engineering and IT and it sometimes gets ugly. Almost always it is the IT manager who walks into a meeting with "Absolutely not" written all over his face. I am sick of hearing "can't be done", "not on MY computers", or "I don't have time". And the holier-than-thou attitude seems to be universal.
I always insist that engineering involve IT in the planning stages of new projects if a computer is involved in any form or fashion but it seems that the IT guy just can't be satisfied. Sometimes the objection is that THEY want to be the ones to do the programming even though engineering has been trying for years to get them to do it.
It isn't just me. Everywhere I go it seems that everyone who is not an IT professional HATES IT professionals.
In all of my years at this job I can honestly say that I have worked with only one IT professional who was cooperative, friendly, and eager to help.
Why is that?
|
|
|
IT 101
Oct 11, 2006 13:05:09 GMT -6
Post by themetermcse on Oct 11, 2006 13:05:09 GMT -6
King,
Its too bad that you have to deal with that. I work in IT in an educational environment. Before then I was doing other gov work and my experiences have always been that when I go into the meetings, I listen first, then pick out the key areas. I like progress, when its good progress, and when you are doing custom stuff, you have to have the programmers on board, engineering on board and IT on board. I worked for another company for a while as an IT Director/VP and watched many of my down-level engineers get furious because the programmers wanted to do something. Unfortunately, when it came to the engineers needing something from programming, their anger came back to bite them.
My opinion has always been, let the pros in each department map it out for you, then discuss not argue what the caveats are. Just the other day an outside programmer and I were working on a custom app for us. She proceeded to tell me that the way I had an SQL server running wasn't going to work with the way she was coding the app. We looked at what changes had to be made and came to the conclusion that because the way other apps and DB's were setup on the server, she needed to change some code for it to work. At the same time, I offered to bring the other companies on board and see if their products could work in the way she wanted to run the new app. She simply responded No, but appreciated the offer.
IT, so many times, is based on the principal of catching more flies with honey, than vinegar.
|
|
|
IT 101
Oct 11, 2006 13:35:52 GMT -6
Post by King Rat on Oct 11, 2006 13:35:52 GMT -6
Here is an example of what I am having to deal with: Last year our company submitted and won a bid to develop and install a custom application in a major manufacturing plant. The nature of the project was a system which controlled a specific machine used in the manufacturing process and reported inventory and production data to an Access database. Their project engineer was adamant that the system be a standalone control not connected to the plant network. So IT was not involved though I did request in writing that the project engineer bring them onboard anyway. IT provided the PCs used in the project and I immediately noticed that they were nowhere near what the project required. They actually stuck us with a Windows XP box with 128 MB of RAM. IT also delivered the PCs with user-only access so it was impossible for us to even install the software we were developing. It took months to gain temporary admin rights to them. After we delivered the solution and began debugging (since it involved machine controls there was no way to debug it off site) IT stopped us and said that it was against their rules for a PC to be in their plant unless it is connected to their LAN. But they refused to connect it to their LAN unless we switched from an Access database to SQL Server. So we did that. When we made another attempt to debug the system we were told by IT that, because we were outside contractors, we were not allowed to connect our laptops to their LAN (which prohibited us from connecting to the very equipment we had to debug). So we reached a compromise where they would load all the necessary software on one of their PCs and let us use it to debug the system. The catch was that they prohibited us from making any changes to the application we were developing unless THEY copied the updated files to the target PCs. The process was that we made our changes in the development environment, burned them to a cd, delivered them to IT and waited for them to install them. Since this was an out-of-state job that would require us to spend most of our time waiting on IT to copy files for us. But trying to get along and finish the project we agreed to give their way a try. I gave IT written details of the development software I would have to have installed on the PC they would let me use. When they contacted me and told me all was ready I traveled out of state and walked into the IT office. They had a PC stuck in a tiny corner (obviously meant to be uncomfortable) on a desk too small even to hold a notepad while using the keyboard and mouse. Even worse, they had not installed all of the required software and played dumb when I asked about it. But even if it had had all the software the PC was located on the other side of the plant from the machine I was supposed to be debugging so it was useless anyway. The IT manager finally relented and agreed to allow me to make changes on my laptop (provided I did not connect it to the machine or to their network) and copy the changes to the PCs using my jump drive. The going was slow but I was finally able to get at least part of the system functioning. About 11 AM we found a problem with the network configuration (IT's territory) and requested that IT come out and fix it. I went to lunch and returned to sit and wait on IT. The project engineer was finally able to persuade him to come out at 3:30 PM. Before he even looked at the problem he said that we must have made some unauthorized changes to their network. Then he proceded to unload his complaints against engineering. Two hours later he found that they had a bad switch. At that point he was overly friendly (probably feeling guilty for being such an ass). At present we are in a holding pattern again waiting for engineering to schedule another debug day. I can't wait.
|
|
|
IT 101
Oct 12, 2006 11:29:06 GMT -6
Post by themetermcse on Oct 12, 2006 11:29:06 GMT -6
One word, "TURF". All IT guys do it some point in their career. Even when I started out, I had a problem with outsiders coming in. Then I realized that they are being brought in for a reason. That reason is because I can't do what they are there to do. I worked for a company that used two outside programmers to do Paradox databases and programming to control plc's and incinerators. The PLC's used flavors of SAP, SAP1, and SAP2 that I had never dealt with. They had. It was one of the biggest career changing moments in my life. When I accomodated their needs, they acommodated my curiosities. How does this work? What happens if? Once I realized that my turf needed to be shared, my life got a lot easier.
Sounds to me like those IT guys need to get that through their skulls. Sure, its fine to have policies and rules, however sometimes you need to evaluate those in times of different needs.
|
|
|
IT 101
Oct 12, 2006 14:29:28 GMT -6
Post by King Rat on Oct 12, 2006 14:29:28 GMT -6
You know what is really funny about the entire mess, though? The IT manager who refused to allow us access to the PCs because we are outside contractors is HIMSELF an outside contractor. This particular plant, I learned, contracts its IT. Which makes me wonder if he is afraid we will compete with him for his contract. But the company I work for doesn't do IT.
I agree with you that it is all about turf. I can't tell you how many times I have been brought in to do programming that IT has refused to do or delayed doing for years. But as soon as I am brought in they want to be the ones to do it.
Another thing I think it is about is control. There seems to be this control-freak mentality among so many IT guys.
Recently a production manager and I were discussing his need for a printer on a project I am doing. I suggested he get the printer from his IT group. He said that he could either go to Office Max and buy a printer for $60 or get the same printer from IT and they would charge is department $300 - plus he would have to explain in triplicate WHY he wanted it and then, if they agreed to let him have it, wait three months to get it.
|
|
|
IT 101
Oct 12, 2006 20:11:58 GMT -6
Post by TF Admin on Oct 12, 2006 20:11:58 GMT -6
....... But the company I work for doesn't do IT. KR...if you're company ever does want to get into IT, let me know. TF
|
|
|
IT 101
Oct 13, 2006 7:20:16 GMT -6
Post by King Rat on Oct 13, 2006 7:20:16 GMT -6
....... But the company I work for doesn't do IT. KR...if you're company ever does want to get into IT, let me know. TF I would rather be beaten with barbed wire.
|
|