Slashdot Mirror
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?"
I use citrix to admin remote boxes all the time. But only when I am subjected to very low abndwidth connections.
what I do is explain why my experience and expertese tells me it is a wrong thing to do. I give examples, and send it to the appropriet people. I tell them I feel its part of my resposibilty to the company to give them my opinion and expert analysy. then I do it how they want me to.
This tact has always been met warmly. They don't always go with my suggestion, but they always appriate my input.
The Kruger Dunning explains most post on
This can be generalized to any professional in any field, I don't see why it's limited to discussion of contract work (other than the fact that that's what the submitter happens to be right now). As a professional, you should view it as an obligation to provide as much information as is necessary and pertinent for your employer to make an informed decision. Given that information, it is their responsibility to make that decision or delegate it, to you or someone else. Once that decision has been made, given that you and others provided the relevent information, you just have to live with it, personal opinions aside.
The difference between a consultant and a contractor is just exactly that which you mention.
A contractor typically agrees to do a job, supplies the tools and expertise, and completes the project as agreed.
A consultant takes a problem, develops a plan of action, and is entrusted with providing an opinion on anything that is detrimental. As a consultant, it's your JOB to bring it up-- But if they say "We know, but we just want it done this way", well that's then your job.
A 'consultant' is someone who is brought in tooffer their advice, expertise and so forth.(Thus the word 'consultant', or 'one who is consulted')
Once they have done so, many bounce back and forth between consultant and contractor-- Writing the job tasks and then following through with them. By definition, the input of a consultant is wanted- She works primarily in the business/planning sense, almost as more of an adviser or planner.
I've done both extensively, myself,for your reference.
-Kysh
--=:: Wings and tail and snout and scales of blackest night
This happens regularly to me.
:-)
My general coping methodology is to identify my concerns (expressed in terms of business consequences) but ultimately, I will defer to the legitimate authority of the client who is retaining us and cope as well as I can.
There is always the possibility that:
(a) You could be wrong
(b) Your client's position is formed on the basis of additional information you don't have to hand.
On the other hand, that doesn't mean you shouldn't keep some sort of mutually visible (and emotively neutral!) audit trail of your concerns as a CYA mechanism
You were hired to do a job. You took the job and they pay you. You should ALWAYS tell the client if something is wrong. Not argue, mind you - just inform. If they want to know why, you tell them. If they don't, you don't.
If they are a "good client", you might want to argue the point more without their asking for it.
You have two responsibilities as a consultant:
1) To inform your client what options are available, as well as their associated consequences. (R&D)
2) To manage your client's expectations. (Process Managment)
If you have done your job correctly and communitated well, your client will be well aware of the consequences of making any decision by your advice (counter to your recommendations or not) and if they do something you don't agree with, they will probably have a very good reason, good or bad, for doing so.
It is important for you to realize that these really are not your decisions to make.
In the words of one of my former mentors, "I'll sweep your floors for $100/hour, but I will also advise you that this is not the best use of my time."
If you fear legal repercussions, keep records of your correspondence in a folder and consult an attorney about drafting appropriate liability release paperwork. Well-designed documentation at the start of a contract and/or relationaship will generally eliminate this issue altogether.
"Lawyers are for sucks."
- Doug McKenzie
Two scenarios:
1) Over the internet
-Have the programmer sign a contract saying you are not liable for subsequent hack attacks
-Tell them that TS is cheaper and more reliable for admin purposes
-Have the programmer sign a contract saying he understands Citrix is more expensive
2) Over a WAN/VPN
-Tell them that TS is cheaper and more reliable for admin purposes
-Have the programmer sign a contract saying he understands Citrix is more expensive
Having it in writing that you advised AGAINST it covers yours while exposing his/hers.
In general I like to give my opinion and possible suggestions. If your advice is accepted then great. If not, then give the client what they requested. In the end, it is giving the client what they want, not always what they need or what you feel is best for them. You might be surprised. Clients are not as clueless as what you think. They chose to contract with you, didn't they? Also sometimes, what you feel is best might not be better.
Judgement comes into play in dealing with the personalities. If your client is not the sort to want to listen to suggestions and advice, then keep quiet and give the client you best effort at what was requested.
Fun is all the more so when it shared
A wise consultant once told me this advice:
Yours is not to question why,
yours is but to bill them high.
Sure, it's not the way to engineer a perfect world,
but at some places (like AT&T), if you questioned
every poor decision, nothing would get done.
Working as a government consultant for the past 3 years has shown me the importance of having all decisions in writing. No matter how small it seems, e-mailing parties responsible for a confirmation to go ahead with objections noted is a must for consultants, then you can't be blamed for other incompetent peoples faults.
So yeah as div_2n says, get everything in writing, even if it's just an e-mail, it will be documentary evidence down the track if you find yourself as the scapegoat for bad decisions.
As a consultant/web developer I get clients always choosing the wrong way they would like something done. Almost to the point where I don't really want to put my name on the product. Granted the customer is always right, but we do have to attempt to enlighten them.
Communicating the Pros & Cons in non-geek-speak is a good start, but sometimes whey have their mind made up. Cost is usually the biggest factor they use to pick one development path over another.
The way I try to correct them is by trying to let them know that they will save money in the long run, or have a more reliable/useable/customisable product.
---
I tried to get first post. How did I go?
To me this is the point. When my employer does something I disagree with this is what I do. First I explain exactly why I think it is a bad idea and that in the long run we'd be better off doing it some other way. Then once the decision making phase is over I run with whatever my employer decides, and do my best to make it work. You see it's his money, but more than that it's his priorities, and I am not always aware of the overall scheme of things. The same is true when you're doing consulting work you should always express your misgivings, but then (assuming it's legal and ethical) do your best to make their bad idea work.
The question shouldn't be "When should a consultant question decisions", it should be "When should a consultant stop questioning a decision".
It's your duty to a customer to fight questionable technical decisions. However, once all the data has been examined, if the customer still insists on a poor course of action, you're left with 3 options:
1. Yes Sir!
2. I quit!
3. Do it the right way and don't tell anyone (if possible).
The important thing, though, it to make sure the customer has all the pertinent data for a correct decision. I've had problems in the past where consultants simply said "Yes, sir" to a technically poor request (from a manager, not me!), and caused a lot of damage to a system under construction. Had they explained the situation, we might have made a better choice.
This is exactly why anytime your client goes against your advice you should get it in writing. Otherwise it's your word against thiers. If you're a really GOOD consultant, you might even walk out if they do such a thing - after all, they hired your for your expertise.
Present your case to parties involved, have documentation and the potential problems with doing the project incorrectly.
If they ignore your warnings, consider not engaging in the project if it going to bomb. As the consultant, you might just end up as the fall guy. If it bombs and they use you as the scapegoat you will damage your reputation, causing you to lose work (It is after all a small "IT" world, and bad news does travel beyond the companies four walls)
If you end up engaging in the project be sure to document your concerns, document issues as the come up, so you have something to present when the project termination meeting occurs.
VNC absolutely sucks when compared to terminal services (I don't know about Citrix) for doing any real work on a machine...
I don't know how the two compare over 56k, but over 128 - 512kb WAN and VPN connections Terminal services wins every time, it's like you're sitting at the machine, and you never have to refresh the screen to see things that VNC didn't notice happen (Like java apps...ugh)
Of couse ssh wins over all of them, but theres limits to how much administration you can do with ssh on windows
Advanced users are users too!
After reading the story above, there are a few things that come to mind that we do where I am currently working:
:)
1. Maintain a Risk Register. Any project manager worth there salt would want to know what the risks, how to mitigate those risks and what they are going to cost. If you are being asked to cut corners, inform the PM to add your concerns to the register. The project is doomed to failure if the risks arn't known or mitigated.
2. Most consultants would have a formal reporting mechanism to the client, a client progress meeting for example. If you have concerns a very powerful way of communicating those concerns is to formally report it via the client progress meeting. If the Project / Programme manager is not taking your risk on board, the project sponsor and business should be in a position to bring pressure to bear and deal with the issue. I myself have been in several situations where problems have come to light, that we highlighted on the client progress report many months earlier and effectively covered ourselves by highlighting the risk.
3. If you are consulting, there is an air of professionalism to highlighting issues as you see them. Ultimately in the end you will get a good reputation and be offered more work. I have seen this happen in many places. Before anyone chips in with scope creep and people going out of business, if you are silly enough to bid for work without including sufficient contingency both in time and price to cover unforseen issues and not fully understanding the problem, then you deserve to lose money.
4. Microsoft, yep I know most of you hate them, but they have a very effective programme management framework called MSF. One of the features of it is a process called War Room. In this, All functional and technical leads, Business Analysts, Management and sometimes developers come together and quickly discuss what they are doing and the issues they are having. This is an excellent way for a consultant, or anybody in fact, to highlight issues that may not be making up to management and in many cases come up with a solution.
I could go on for hours but my fingers are starting to hurt
Well, gee, d00d, as a consultant/contractor/outsider you're going to be the scapegoat anyway regardless of paperwork. Duh.
Is this thing on? Hello?
they are "free" (included in Windows Server 2000) if you run in "administrative mode" (only one user can connect to admin the machine) as opposed to the "application server mode" you are talking about.
DO NOT DISTURB THE SE
He said TightVNC.. It has compression built in and works quite well over 56k
Normal people worry me!
The bottom line is that you should make your point clearly and ONLY ONCE. After you make your point, if they still wish to go forward with the "wrong" decision, do the work. Do NOT:
- whine
- drag your feet
- try to convince them again
Too many people try this and are a nightmare to work with. Unfortunately, this attitude is common in systems work, as many have the "everyone else is stupider than me" attitude. (e.g., Nick Burns, your company's computer guy)