Ask Slashdot: How Do You To Tell Your Client That His "Expert" Is an Idiot?
Esther Schindler writes "It's a danger for any consultant, and for most inter-departmental internal project staff: To get the work done, you need to work with someone else who supplies expertise you lack. But when the 'expert' turns out to be the wrong person how do you tell the client (or boss) that you just can't work with that individual?"
Most experts are idiots at what they claim, but an expert at earning trust regardless of their knowledge. So be careful of these people, as they are quite aware of their lack of expertise and their fragility. Gain trust of the client first before taking on people your client trusts.
Terrible advice. There is always money in confusion as long as you write the contract properly, which should always be the case.
Because contract have never been torn up in court.
I used to know a consultant like this. Would write incredibly one sided contracts, still 100% legal but very one sided, which only idiots would sign. It worked for a while but when one project fell through this idiot client hired a non-idiot lawyer and he lost more than he earned in his career. House, investments, car, even furniture. The guy went from driving a Porsche 911 (not cheap in Oz) to a old Huyandai Getz in a matter of days and hand to declare bankruptcy just to keep the Getz.
Writing unfair contracts is an easy way to get sued. Even fair contracts can land you in a lot of shit.
Calling someone a "hater" only means you can not rationally rebut their argument.
As a consultant it is *my job* to work with the client and their people. Incompetent or not, it is still my job to work with them.
If you are complaining about this as a consultant, you have no business being a consultant.
So you go back to step 1: the problem is badly described. The Systems Development Lifecycle dictates that you, as the new help solve the problem. Start at wherever there is trouble. In the scenario you describe, it looks like we need to go back to step one fix the root problem: it is badly described. We cannot build any system to high user satisfaction that is badly described. One can only start over and build from scratch. If that's not possible, we will have to break the problem down into manageable parts and dig deeper for root causes and solutions.
It is like using references, I have learned that if a company asks for them, they are idiots. Nobody EVER calls them and if they do they are basically saying "I have no clue from interviewing how good this guy is, so I got to ask someone else". Stellar performance right there!
The solution is relatively simple, see job interviews as a two way process. They are interviewing you BUT you are ALSO interviewing them. And gosh darnit, you can reject THEM as an employer!?! Shocking ain't it.
When I read a site like clients from hell, (not linking because it has an annoying nag script) I can't help but feel that a lot of the time all the problems could have been avoided if the complainer had just said at the interview "you are an idiot, I am not going to work for you".
If you spend sometime in your field you should know the warning flags. If a client/employer for instance is looking for a lead developer, the existing code base is a pile of steaming shit such as you have only seen in every single job before where the existing lead had to finally admit he needed an extra hand (translation: needed to be taken outside and shot for the good of humanity). If they are looking for a replacement team for the software project, the existing code doesn't (exist that is, what is there is maybe some scripts that on some days, does something but nobody knows what). If they are considering a rewrite, the servers are on fire and the the sys admin has slaughtered the entire office and is sniping from the rooftop.
You get to regonize the signs after a while. Does the boss spent the entire interview bitching about what gone wrong before? Translation: He is to busy still raging and hasn't yet learned from the mistake which was HIS, for hiring the wrong people.
There is no handover period because the previous guy already left? Translation: Make a sentence with rats, ships, sinking. Question: Do you want to come on board? Consideration: At least the ship is rat free.
If the ship is on fire and they are haggling over budget with the fire-fighters, translation: they spend all their money on flammable lifeboats and have nothing left for you. Another form of this is if they talk about how much money already has been sunk into the project and/or whining about recovering investment. Fact of life: money sunk into a project that has failed is lost, deal with it. A projects worth is NOT measured by how much money has been lost on it.
And hey, you can ignore all of this and think YOU are going to be the perfect employee who can deal with idiots... and I will point to you and say "this guy is going to be on a rooftop someday, sniping at the police while chewing on someone's leg". Either that... or... you are one of them... got an MBA?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.