Discussion on:

10 really dumb mistakes to avoid in the field

I can attest that # 7 can really cause problems. I used to do work for Teksystems out of the New Orleans office. Typically what would happen would be that I would get the project plan ahead of time, look it over and ask any questions I might have before going to the client site. Well I took a project on and got busy and never got a chance to look over the project plan. The job was to go in to Hall mark stores, do an inspection on the system setup to see if the merchant was all set up to transmit data to VISA and if necessary run phone line from their card reader to their phone system. There was one problem. I had never punched down phone cable. To make matters worse, our time was being billed to the owner of the Hallmark store. Because I had never punched down phone cables, I took longer than I should have and the owner was not happy. Needless to say that was the last time I ever went into a project with out reading the project plan.

Back a few years, we were preparing a proposal for a customer who we worked closely with in the past. In the proposal, we referred to a component, the "BFR", on several occasions, but never clearly stated what was meant by the acronym.

We thought it would be funny, when the customer would ask "what's a BFR?", we would say "Big F*ing Router", and we'd all laugh.

Well, the customer never asked. And in the end, it came out that they never asked, and therefore didn't really know what they were getting... but got it anyway.

I learned a lesson that day... don't create an opportunity where you make your customer look foolish, unprepared, or incompetent.

It shouldn't need to be said, but thank you for saying it, Mike.
We in IT take for granted what is funny or obvious to us and don't think about how non-technical or even different-technical people feel about that.
I let out a snicker when a CEO misused an IT term, instinctively thinking she was kidding, but she didn't know better and I made her feel small (though she was bigger than that so it turned out well). I won't make that mistake again, hopefully.

Once I was working for this company where the manager had quit. They were having difficulty finding a replacement so one day, the VP came to a team meeting and said that he was taking the manager position in interim.

One of my collegue raised his hand and asked if he would be telling us when he was in the manager role and when he was in the VP role because he wanted to be sure not to tell the VP to go to hell.

Needless to say my collegue was looking for another job that afternoon. But we did get a pretty good laugh about it.



TCB

Humor can be a real minefield if you don't know your client well (or even if you do.) You don't want to be a humorless drudge either. Maybe it's best to keep humor self-directed. Don't make yourself look "foolish, unprepared, or incompetent" either, of course `;-)

Ahh. I dunno. There are always going to be emergencies, failures which generate them, RTFM tickets and products for which no manual was ever written anyway.

There are a few hard rules and a few common sense practices every "professional" should be quite familiar with before going into the field and conversationally pushing any social or political envelopes with one's employers' clients or vendors. Making the client/customer feel stupid over something they've done --even if it's the stupidest thing you've ever heard of-- is bad all around. My "canned" response is to lower my voice and say, "don't worry about it, Mr. Smith, I did the same thing myself once. I think I can have you out of this jam pretty quickly." I wouldn't go in, take my first assessment and then laughingly start asking the user how much vacation time they've got coming.

Meanwhile, back at the office... I've had the BEST experiences at workplaces where I see people whom I work with outside of the office as well. I'm not talking about romantically, but if you've ever worked at one of those young, engineering-based companies where everyone in development/engineering/support wears about three hats, you know all about the 16-18-20 hour days on either side of a build release. LEVITY CAN PREVENT INSANITY if used properly.

One of my favorite references read: "...is a great technician, one of the most welcome on any job. He dives right in with the rest of the team if that's what's required or he can independently work miracles with a small set of instruction(s). What you'll love about working with him is his ability to walk into a room with the best solution and the funniest joke. We always got both from him and that uniqueness sets him apart."

Let's face it... There is a plethora of pretty smart people who work in IT out there. An even larger group are LOOKING FOR WORK IN IT right now. Sitting in your corner of the world, purposely not drawing any attention to yourself is one extreme. The flipside of that would be total obnoxiousness. But in a day and age when those of us looking for a better job can use all the "extra credit" available to us, a positive attitude with a little bit of sarcasm about 'all the right things' may cast the deciding vote.

Sometimes, it is exactly what the Dr. ordered.

A prime example is when I was working with a client on a project and we were about to conduct the kickoff meeting. We needed all functional groups represented to accept tasks and had a timetable for deliverables for all to buy into.

As the attendees were filing into the conference room, I could see that they were still "at their desks", thinking about the work they left to come to this "meeting".

With the huge agenda and critical nature of this meeting, we needed all heads "in the room". The employee we were working with most directly, and who had called the meeting, gave me the perfect opportunity.

He said "I think we have all the functional groups represented now" and as he said "so we can get started.", I mumbled "yeah, and some of the dysfunctional ones too".

Everyone laughed, got in the room, and the meeting went off without a hitch.

To

I worked for a business helpdesk and had a lady call in says that her "hard drive" wouldn't turn on. Turns out she was refering to her "PC" specifically her Outlook wouldn't start up. Took several minutes to figure out what she was talking about. Then I took sevral more minutes trying to tell her the terms she was using were wrong. Still don't think she uderstood.

I have always enjoyed figuring out how things work so learning the parts by name and the interactions of each has been something of interest. Most users do not want to spend time learning terminology, they just want to read the "letter" their grandchild wrote or see the picture they took.

We often require multiple vocabularies for our usage when speaking with people of various technical abilities and a "special" vocabulary for listening to people who will ask about their broken cup holder. They are our customers and they ultimately pay our bills. If we tend to get frustrated and short-tempered with our customers, we are in the wrong field. Not only will we alienate them, we will also set a bad example and tarnish the reputations of all the other consultants in the world.

As mentioned by others don't forget spare parts and tools. You might not be expecting to work on hardware but when you arrive you realize the problem could be a faulty cable, or you need to open a case to reseat the RAM but you don't have a screwdriver.

I heard one story about a service tech who drove for 2 hours to install a hard drive. When he arrived he realized the drive didn't come with screws, so he drove back to the his office and complained. The fool could have easily stripped a screw or two from another component with no harm done. (or better yet, brought some spares just in case, or checked the parts over before leaving. Instead he made the company look bad, and the client was left waiting. He thought he was doing the right thing but he had no common sense.

Really you should avoid doing these mistakes otherwise it is gonna prove very dangerous.

Many of our installs are arranged by the parent company, over the phone and hardware is shipped to the site by them. Once the equipment arrives they are to contact the supplier and they in turn contact us. Our arrival on site consists of inventories of the equipment supplied and insuring it's all there and reviewing the installation details with the onsite contact. Because the actual details are not reviewed until we arrive, there are many situations that are unforseen until we arrive. Often, extra equipment needs to be sent out or sometimes longer cables and phone connections need to be supplied by the phone company before we will even attempt to start an install. We never-ever send out an inexperienced tech, always a senior tech with maybe one or two trainees if that's their planned positions. The last thing we want is for someone to learn on site by themselves.

The best advice to follow (especially ask your boss), then 30mins later when you've accidentally deleted all the Group Policies across the network because replication is buggered your in the clear ^_^

The problem with asking permission from the client is that, a good percentage of the time, he/she will have no idea what you're asking about, and will just give blanket permission for everything. This is just as bad as no permission at all.

There was a moment when I was working on a laptop deployment where I was beginning to walk the user through the particulars of the old and new applications installed. There was one specific multimedia application used by many of the higher-level users. Not even 3 seconds into me walking the user through, the user stopped me mid-sentence and said that whatever I was going to do that I am NOT to do. Then, the user goes on to tell me that they got an email from the person who was teaches a class where the multimedia application is paramount to the class; the person isn't affiliated with the users per se. And the user goes to show me the email that was sent to them. The assumption was that whatever I was going to do was going to uninstall the application. And the email was basically saying to not let anyone mess with the application.

Then, I go to explain, in a very nice way (as the user was being a little belligerent) that my reason for walk-through of the laptop was to show them how could use it with more flexibility than their workstation and how to use the laptop with the multimedia hardware that works with the multimedia application. The problem that the user and instructor didn't know was that the multimedia application that was installed on the user's workstation was an older version of the application. The version installed on the laptop is the current version of the application; and also it's the suite version of the application. Neither the user or the instructor knew that the updated version would be installed because the laptop deployment was not announced before hand.

I actually had to catch myself before I responded to the user because she came off being very belligerent. Which, I could understand because it was going to be their laptop, even though it wasn't officially their's until they signed-off on receiving it. So...users/clients will say No and not even have the full understanding or know what is going on.

Ray, the one thing that I noted especially in your story is that the version of the software on the laptop was not just a newer version of the software the client was already using, but actually a completely different version.

I am glad for you and the client that this apparently worked out well, but let me remind everyone that you can NEVER ASSUME that a newer version of the "same software" has the same features as the version the client is already using.

This caution is many times more critical if the software is being used in some sort of instructional setting, because even if all the same features are available, there is a very high probability that some of the details of how to use some feature will have changed.

Anyone who believes that the "newer version" always has all the features of the old version and that how to access those features will be obvious to experienced users, has never spent much time with users of any of the common business suites.

Anyone remember Office 2007 -- thousands of users are still struggling to find features that Microsoft SAYS are still in there somewhere.

If all our consultants did this, we would be 10 x happer...

Good steps, i'd like to add also : Don't forget ta take regular backup for your files.

Don't accidentally drop the live database on their production server

Good one...

well i think that this is a good practice for all

#9

When re-establishing a mirrored drive array after a drive replacement, make REALLY, REALLY sure you know which is the active drive, and which is the new, blank drive.

Sigh...

When ghosting a drive make definate you are imaging from the data drive to the new drive and not vice versa! Ouch!!

Seen something similar done with a failover pair of firewalls: replace the failed unit with a new one and let failover copy the config across from the now active secondary device.

Except it copied a blank config from the new one to the live... All systems down and a rapid sprint across town to recover a backup config and re-install on the primary device.

You forget to take a wired keyboard and mouse with you !

Arghh shoes people not boots Ouch!

How many times have I kicked myself because I didn't have a network cable in my pocket?

I keep cables in my car ALL the time... work vehicle and personal vehicle as I've been burned before and it's the pits

Really cool tips! For peoples like me which is a newbie on the job, can stay alert and avoid this ten really dumb mistakes, that I bet it is frequent around the field.
Certainly worth reading!

Very helpful

Just as a doctor shouldn't operate without diagnostics or use a set of x-rays with a "trust me, it's his"...
you shouldn't listen to a client who says: "Yeah, I've paid for that already - just do this - this is what it is." You may find out the results came from Computers for Dummies, or an About.com forum, and was "going to" save the client $1000 in "unnecessary" tech labor costs.

Good stuff even for someone with 12 years in the field. This is one of the best posts I've seen on TR in awhile.

A very basic dumb mistake is -Before starting a job, NEVER take the Client's 'word' that a Computer, Program, Drive, etc. actually works!- Turn on everything and check it out yourself before taking anything apart. Many times, Clients don't really know if something is working properly or is 'glitching'.

I normally ask the client to show me the error message themselves, this gives me an opportunity to observe where the fault actually lies. More than once I've been told "it's A", when in actuality it's B or even C that's at fault.

I've had plenty of occasions where someone would complain that "A" is not working. When I watch them go through the steps to recreate the problem, it's very often I find that they're doing something unexpected or it's "B" that is failing - but since they clicked on the icon for "A", that must be what's wrong, etc.

Upshot: Never trust your customer's self-diagnosis!! While you don't want to actually SAY this to the customer, you can just ask them to show you the problem while you watch over their shoulder.

Steve G.

When in the course of troubleshooting a software problem you find it necessary to uninstall and reinstall, MAKE SURE you back up the user's personal settings/configuration/files before you uninstall.

Most software written recently has options to leave user settings on the machine when uninstalling, but not all of them. Once in a while you find one that doesn't. Finding out too late the software you just uninstalled is one of those and not having the data backed up can be crippling to the user and damaging to you your reputation (and your paycheck).

I am a software developer, and my uninstall program provided in the programs menu is exactly the same as the one called by the Windows Add/Remove Tool. Why would you suggest it is any different for Antivirus software? Perhaps you mean that the uninstall should be done with the most recent uninstall tool available from the Antivirus vendor?

I agree. Sometimes if the av has an uninstaller, it would work just the same as using Add/Remove. In some cases, no matter whether it is the uninstaller or Add/Remove, you may still get some residual files in Program Files or left over keys in the Registry.

I recently had the experience of using the Windows Add/Remove tool for a virus update. (It was an older version with no direct upgrade path so a uninstall was required.) I could not install the new version nor the old version because the pc already had a version installed. I ended up talking with the vendor tech support for 45 minutes removing many hidden files. I used their uninstall after that and had no problems.

Agreed

AV programs purposely make themselves hard to uninstall as a defense against malware which usually goes after AV programs as the first thing. The vendor version may make it a little less accessible/harder for scripts and bots.

There are two vendors who you need to download their uninstal utilites to completely and properly uninstal their AV software. After which my suggestion is to find something else. (And years ago Symantec was a fav of mine).

Symantec
McAfee

McAfee surprised me yesterday actually. I had a client computer who had just purchased a McAfee business account for all their computers in the office. I was to install on all the systems the new version of McAfee. We decided to do this from the server and just push the McAfee service. Well the next day after the push we have one computer not getting the correct updates and bogging the system down. I found a link for McAfee on a cleanup tool for removing their service. After running it and reinstalling the service on that machine it worked like a charm. Come to find out that the McAfee was acting up because the older version had somehow corrupted the new version because there were hiddent files that had not been deleted. The cleanup tool fixed that.