For many companies, consultants are frequently used to fill in their ranks when their own staff couldn't perform a particular project or task. The consultants are employed mainly because they are the perceived experts in their fields and the companies they represent. Surely you will not go wrong when you are willing spend a small fortune to outsource your project to a team of people from a well known large local IT company ?
It didn't take me very long to find that the people who came on board didn't knew anything except for the software solution itself. That means they didn't know about a lot of other things, and how their software interfaces itself with the rest of the world. In other words, it's like being an expert in cooking steamed rice but know nothing else about cookery. Unfortunately, the rice is only part of a meal, and has to be paired with the appropriate dishes to complete the meal.
In the brief interaction time I have with them, they committed so many deadly sins in IT and uttered so much garbage that I found myself resisting really hard to laugh out loud in their faces and strangle them with mouse cords. So the rant begins here, and it might be quite technical for the layman out there.
Most of the story evolves around the apparent team lead of the software engineers, which I will refer to him as "S".
I wish I could do this to relieve my anger
The forgetful software engineers
Local user accounts were created for each of the computers provided to the team of software engineers. S wasn't happy with our standard default password, so he opted for another password which the software engineers conveniently managed to forget every couple of days, causing an account lockout each time. And so we kept unlocking their account several times a week, until I had to stand next to S, as he key in their passwords right after I had unlocked his account.
Guess what, trying to act impressive and stylish, S keyed in his password really fast and wracked the enter key in less than 2 seconds. Windows rejected his password and prompted him to try again. S did the same thing again, and got exactly the same result. He started to get annoyed and started protesting that the password he had just keyed was correct. I noticed the problem and pointed to the CAPS LOCK indicator. It's on. Passwords are case sensitive. It didn't take a miracle to get him to logon successfully on the 3rd attempt.
It didn't stop here. The software engineers still got themselves locked out because they kept entering the wrong passwords. Finally they relented and pasted the password on the LCD monitors they are working on. But it didn't help. They still get locked out every now and then. Hopeless hopeless hopeless.
Bad migration practices
When they didn't understand the existing customised codes in the system which they were trying to migrate, they simply overwrite the portion with their own code ignoring the much needed customisations without backups of the existing codes ! It didn't take long for the end users to find out that their familiar functions creased to work. The ugly consequences involved angry users hunting down the software engineers who had to work from grounds up because there were no codes to fall back on.
Cannot transfer data
While troubleshooting on a user's computer, they decided to save some log files for further analysis. S claimed that they couldn't do so because their thumbdrive didn't work on the Windows 2000 PC and there was no floppy disk drive. My customer's project supervisor told me about this and I was perplexed by S's unfounded claims. I proceeded to demonstrate Windows 2000 ability to support my thumbdrive and pointed to the floppy disk drive on the computer. I could almost imagine my customer's project supervisor tearing S apart when she confront him.
Remote printing
While troubleshooting a printing problem on the PC mentioned above, they wanted to isolate the problem by asking the user to do a test print on another computer. However, they couldn't see a obvious physical parellel printer cable linking the computer and the printer. In other words, the printer is not shared and thus can only be used with the computer in question. My puzzled user came looking for me and I had to go to tell the noobs that the printer is not shared and this can also be checked in the printer settings. Our dear software engineers are not only blind, they also didn't know how to check the configurations of a Windows printer.
Paper type and paper source
On the same printer problem, I had to demonstrate and explain how Windows printing works when I realised that S and his guys didn't understand the concept at all and thus it's no wonder that they couldn't troubleshoot the problem. Because of their ignorance, they couldn't come up with proper test cases and didn't know how to interpret the results. Despite after a couple of rounds of see and tell, they still didn't get it. I finally gave up and told them that obviously, their print job is using the wrong paper type and source. All they have to do is to modify their print job to do that and yet they refused to do so. I asked him to show me the properties page and S couldn't do it. Now not only he does not understand the Windows print system, he don't know things in his own turf too. At this point, I gave up and left them to rot on their own.
Lack of testing : Phase 1
One of the most glaring mistake they made was to go live without going through proper testing. The only tests they made were apparently on their test servers, and they assumed that their code will work flawlessly in production. The rollout included the automated of configuration files to the over 200 machines which spectacularly failed in most of the cases.
I was summoned to help troubleshoot the problem and it didn't take me more than a moment to point out that they not included a crucial updated configuration file. This could have been caught if they had done a limited rollout on a test group. Initially, the deployment team and the software engineers went through with the process of denial, pointing fingers everywhere except for the missing configuration file, until the truth sets in at the end of day one. The fallout took a whole week to clear, wasting much of the helpdesk resources.
Then the kicker came soon after. The application failed completely under VPN (Virtual Pirvate Network). Clearly they have forgotten what I have brought up a week before the rollout : test the software under VPN.
Lack of testing : Phase 2
Apparently they didn't learn. The second phrase of their implementation also failed completely under VPN. This lead to another round of furious troubleshooting which concluded with the disabling of a portion of the software.
However, they couldn't do it right either. The software engineers gave wrong instructions which resulted in chaos. I had to perform overtime at Jurong island to help troubleshoot the problem with no pay till 8.30pm. I wasn't surprised when we found that they actually didn't know how to disable the portion of the software which we figured how to shortly by trial and error. This just displayed their incompetency in their own product and lousy troubleshooting skills.
Customers troubleshooting your product ??? Give me a break !
... and there are many more incidents like those I mentioned. My impressions is that their IT knowledge is at best, on par with normal end users, and thus I cannot assume their technical expertise is of a high level. Their insane rate of spouting nonsense and vain attempts to act professional is really detestable and terribly annoying. I will not be surprised when the project gets slapped and penalised with liquidated damages.
Oh ya, their project manager bailed out early September by quitting his job. Smart move, I will say.
From the looks of things, this fiasco deserves an entry into http://worsethanfailure.com .
No comments:
Post a Comment