When Should a Consultant Question Decisions?
bay43270 asks: "Presumably, companies hire consultants because they need technical expertise. At some point (if not on a daily basis) a consultant is asked to do something that isn't in the best interest of the company (and therefore may not be in the best interest of the consultant in the long run). The consultant must ask 'do I just say "yes sir" and go to work, or do I try to explain things? If so, how hard do I push?' When should a good consultant question a decision, and how does the situation differ with contract programmers?"
The money is good..thats a plus. The company in question has zero clue on anything computer related, IE why im hired... however, the programmer... wants citrix for remote administration to a domain controller.. citrix, for remote admin...cause he does not like terminal services.. How do you fight this?
If you are truly a consultant, then you are paid your fee for doing what your contract stipulates. One of the critical legal distinctions between being an employee and being a consultant is that an employee has a stake in the company's future, whereas a contractor is strictly a temporary resource being used to fit the particular needs of the company at that time.
I've always been very careful to stay out of such things unless they are directly covered under what I am supposed to be doing. For example, back when I did SAP consulting, my job was to devise the role assignments so as to avoid collusion between employees. When some group (I believe it was Finance), wanted to create combined roles just to 'make it easier', I stepped up. My job was to ensure that the new roles had a minimal risk of collusion and Finance wanted to do something directly contrary to that. In that case, I took it to my contact person (note, NOT my boss) and explained. He then had the Finance group meet with the consultants to justify their need (they were shot down).
However, if it's a question of implementation or something, like where the client is bringing you on to do 10 tasks, if those tasks are the wrong tasks to be doing or incorrect - too bad. You get paid to do your contractual assignment.
Look at it this way - the company went out of their way to bring you on as a consultant rather than a regular employee. (Note I did not say 'hire you') There's a reason for that - they believe that you have certain talents and skills that can directly impact one of their objectives. You weren't brought on to create the objectives.
Things can get very ugly, legally, if you and your client begin to act as if an employer-employee relationship exists.
Microsoft had this sort of problem a few years ago where they had all these permatemp contractors. Basically people they didn't want to hire full-time so they just called them consultants, but continued to use them over and over on different assignments. The permatemps argued that they were really full-time employees and sued for a fair chunk of change, and won. Consequently, if a company brings you on as a contractor, they want to do everything possible to make sure that the distinction exists, lest you sue them for backpay, overtime and benefits. For that reason I think you'd be totally out of line speaking up.
You're a consultant, finish your job there and move on to the next client.
One of the biggest problems for any consultant on projects is "scope creep". A good project manager will ensure that the client gets all that he has paid for, and no more. If the fee wasn't enough - too bad. The consuitant loses. If it was accurate or generous, he makes some money.
What the original poster is describing is the "extra mile" above and beyond the agreed scope. Consultants who do this for free too much go broke.
Sometimes though, if the fee was generous and the client is a regular, it's worth it to keep their business.
We aren't talking about saving the world or doing good deeds here. we are talking about business.
The labourer is due his hire.
If my call is important, why am I talking to a recording?
Trackable info is GOLD. Take the following which happened to a guy I know at the same company I'm contracted to:
.doc files .doc .docs .docs .doc .doc
Guy I know got fired from [US printer company], then hired back as a contract. When working the contract, a full time employee complained about the quality of his test matrix, so they scheduled meetings and re-wrote it. Both of them kept notes, and both emailed the other with their copy of the notes to make sure they had all the same info. She complained again, then they did the meetings, re-wrote the notes, etc etc. It went on like this for about 7 iterations:
1)need more test cases
-doubled # of test cases
2)need test overviews seperated into different docs
-seperated into 3 different
3)need more test cases
-added test cases to each
4)need fewer
-combined to 2
5)too many test cases
-reduced test cases in each
6)don't like formatting of
-used different fonts, spacing, etc
7)too many test cases and docs
-combined docs; reduced test cases
8)[yelling] you are a terrible engineer (I kid you not)
-take it up the butt because you can't talk that way to employees but they can to you.
The result of this month of run-around that she gave the guy was that she didn't like him and wanted his project canceled and delayed (ie no work for months) so that a different contractor could be brought in to do the same job . . . one that would do the work just how she wanted it (YES MAN) but with out her actually doing the work.
At meetings with the VP of the contract agency, and meetings with the [US printer company] bosses the guy presented 300+ pages of printouts including each iteration of the test spec, the notes from each meeting, and all emails between them (he auto logged all emails). The VPs concluded that the guy did an excelent job of fulfilling the job requirements, but that because she didn't like him his contract would be canceled. The contract firm VP admitted privately later that this is very common with [US printer company] and there is absolutely nothing that could be done about it. Since both bosses agreed, the guys record was not adversely affected, but he still can't work in her division ever again.
When you offer your trained expert opinion to an idiot, expect nothing less that idiocy in return.
Hopefully this isn't a common experience with other companies and other contract workers.
robi
I think there is a critical difference between a contractor and a consultant. The former is hired to complete a specified task (the more specific the better). The latter is hired to provide information, knowledge, expertise, etc. in order to make better decisions.
In my experience working as a consultant and contractor, the terms are used interchangably. I always went by what my contract said I was brought on to do, not the title that was attached to my position. Titles really mean nothing - it all comes down to the bottom line: What are you being paid to do? I wish I would've had a chance to read the original posters contract, but it sounds like he is the code-monkey type who doesn't like something in the project, not directly related to his task. It would be TOTALLY different if he was hired as a project management consultant.
When you hire a lawyer, you are explicitly seeking her advice and guidance. When you contract with a programmer to develop something from *your* requirements, it's questionable whether that type of person should be questioning the objectives, regardless of what you call them. That programmer's relationship with, and obligations to the client is entirely and only defined by the written agreement between them.
I'm a canadian who worked for a swedish company in the US. Conflicts between the US and Swedish management were amazing ...
...
US : "The customer wants this feature in the product"
SW : "We shall discuss starting a pre-study then"
US : "When when that be ?"
SW : "We will get back to you next week"
US : "So next week we will know if our feature will be in the product ?"
SW : "Next week we will know when we can get together to discuss starting a pre-study on that feature"
Of course the rest of the conversation cannot be repeated
Sweden had a very inclusive management style which was great, but slow - no single point of blame. The US had a very individualistic aproach, which was empowering and exciting and quick - and you knew who to fire !!
Let me lay out the scenario I was in, and then give you my advice:
I was consulting for a medium sized ISP on the East Coast, managing their Unix servers, helping with their Sybase system, as well as keeping their web presence up. One day, the guy in charge of the HTML development decided that they wanted to stream audio and video from the site (it was associated with a newspaper, and had a radio station as a client). Well, they came up with an inflated number of streams that would need to be served simultaneously, and thus they wanted these expensive SGI boxes that were tops in serving streamin media.
I did an analysis on their presentation, came up with more realistic numbers, and showed the manager that using a more mundane Unix server (a Sun box), they could easily get two Sun boxes for the price of one SGI box, and feed the streams that way. In addition, we had three flavors of Unix in house, and adding a fourth flavor would be exponentially harder to support.
Manager took my advice, chose to go with the HTML guy's choice, and I got the grand job of getting these SGI boxes going. Well, I did, I got them going and kept them going. They never got the number of subscribers that they projected, and the project eventually got shut down.
In short, let them know your points, but let them know that you're flexible and willing to work with them in any way that they want.
Find out what the Client needs.
Convince him that's what he wants.
Convince him that it was his idea in the first place. (This is important. The Client is the smartest guy in the room--just ask him!)
Deliver what the Client needs while meeting the requirements of budget, functionality, and schedule.
Make sure the Client's looks like a f***ing genius in front of his bosses.
None of these are optional. If the consultant fails to do any of the above, the consultant does not get invited back to do the next job!
Having said that, I have the good fortune to work for a Client (for the past year and a half) who actually is the smartest guy in the room. If you ever have a Client who knows what he wants, lives in reality, and is committed to doing what is needed, cherish him! A Client with a full CNS (both a brain and a spine) is a rare jewel.
Most clients will sit the consultant down and say "Please shoot me in the foot.". When they do this, the consultant must explain that "this is going to hurt; do you really want to do this?" If they insist, the most you can do is be ready with bandages.
Some clients will ask you to shoot them in the head. By this, I mean doing things that will cause any safety concerns/violations or catastrophic financial consequences. Best you can do there is refuse to do the work.
I happen to have the good fortune to work for a Consulting company where the President stands by such decisions. I (and the Engineers working for me) have had the rare occasion to tell a Client "No, we won't do that. "It's unsafe" or "the liability is too great". In every instance, the President has stood behind us.
One final word: Pride. Forget about it. The Client is always right. There is nothing that will get you banned from the jobsite faster than embarassing the Client in front of his boss.
"Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick