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?"

Comments

Re:my $0.02

[drob]

I think this is really unethical. If you take the job, then do the work. Doing a lousy job not only going to hurt you, it's going to hurt your reputation.

Re:My $.03

[trmj]

So what you are telling me is that you, when taking a consulting job for three different clients, will spend that same amount of time explaining things to:
Client #1: A new upstart company whose owner wants a network put in, but wants to know what the best way to do it is and why. Pays $750.
Client #2: An established company whose owner routinely gets advice from his/her close friends and family, and wants you to use FormMail for requests on their website, even though there are hundreds of better applications and simple 10 lines of PHP will do it better and faster. Pays $2300.
Client #3: A large corporation who has hired you as a temporary drone to do some tech work for their latest sattellite office along with the other temps. They already have three others that work perfectly fine with their 10Mbps networks and ISDN lines, even though there are DSL and Cable lines running to the building that cost about the same price. Pays $800.

These aren't hypothetical situations, these are real things that happen to real consultants. I am showing class to those who deserve and ask for it. If somebody doesn't care, then don't waste your breathe. If somebody is paying for a job and a little bit of background information, that's what they get.

I never said I was altruistic. Those people only get far when working for others that abuse their abilities. I do show self-respect though, and the first way I do that is by knowing how much my time is worth.

Every Time the Direction Changes

[IBitOBear]

The answer is simple.

Stratigic errors are invariably traced back to moments when the group/project changed direction. The small daily things are just that, small, they are dealt with and things carry on. Tactical mistakes on Tactical issues are just the day to day part.

One of the most important pieces of information being bought by anybody employing anyone for any purpose is the employee's "list of known bad things."

Pointers:

0) TAKE RESPONSIBILITY for EVERY MISTAKE YOU MAKE. Don't make a bid deal over them, don't "fall on your sword" just say "my bad" and move on. Hell take the casual fall for others if necessary to get the repairs started. To the greatest extent, who is at fault is the last thing that matters once the mistake is out. Most people have already decided anyway and almost everybody almost always knows the exact truth before the showdown anyway. As long as enough was learned to prevent a repeat, the issue is over.

1) Teling your boss "no" is your most sacroscant duty, but it should be approached the way you would tell him his fly is down (or there is toilet paper hanging out of her skirt band.) That is TACT and URGENCY are at war. A timly rescue of face in an emergency is more important than tact and will be remembered positively; but in the absence of extreme pressure, being less-than-tactful will be remembered negatively.

2) Know the difference between the stratigic and the tactical, NEVER let a issue or mistake you know is stratgic get treated as a tactical issue. "I didn't think it would matter this much" is the lament of the under informed. "I could have told you it would" is the response of the guy who most needs to be fired. 8-)

3) State your position as a recommendataion, especially if your boss is well invested in ego games. "I would reccomend against because..."

4) The next step is to banish "ok, but..." assume any positive assertion will be processed only up until the "but" and that the but, and all the following words will be. "We could do that but it will have problems when..." will feel like a vote in favor.

5) Learn the prefix phrase "I have no informed opinion", stress the "informed" as necessary. This phrase will, up front and attached to what you really want to say, easily and professionally presage that you would be guessing, are willing to guess, or not willing to guess about. Advice given in known ignorance is not a crime, it's a sin...

6) Finally, be willing to be out voted or overruled, and never let the fact that you were so overruled or outvoted color your ego or implementation. Presume there are factors you may not know or have control over and be part of the team once the team moves.

Many people suggest getting everything in writing. Don't do that. Just get the important things in writing. It's only important to get things into the record at whatever level "the record" belongs. Overstressing the "I want it in writing" vibe makes you look either weak willed or un-trustworthy. Depending on the type and nature of the circumstance being discussed there are lots of ways to get on the record. (for instance... 8-)

1) Get it in writing as a direct order if you must.

2) Send it in email with a request for confirmation or clarification.

3) Send an "unless otherwise directed" email. (especially when others are unwilling to make any decision at all, time is being wasted, and you know there is no inescapable harm. Fait Acompli can be outstanding mojo.)

4) (in casual company on minor matters where the relationship is good) just say "I reserve the right to laugh at everybody when the thing catches fire." (but don't over use this unless it's family 8-)

(The secret evil thing most people forget, if you bother to get it into the preminant record, * keep * a copy of that record somwhere you control, don't just leave it on the corporate email server... 8-)

In short, the three greatest failures in an employee of any sort are:

-- Failure to speak, to risk speaking, when others are in danger.
-- Failure to act when direction has been set.
-- Failure to balance both tact and urgency in any assessment.

Re:my $0.02

[khb]

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.

So I'm puzzled at the claim that "make a minimal number of decisions" is to be applied to a consultant. Surely when you consult a lawyer you expect advice, not someone to just file the papers you specify ;>

My Rule Of Thumb

[Gleef]

My rule of thumb for this is pretty similar whether I'm operating as a consultant, a contract programmer, or a just plain employee:

• As a professional, you have a duty to inform your client (or employer) when they have made a bad decision, or are about to do something to their detriment, provided the decision directly relates to your scope of work. Obviously, this should be done with some tact and diplomacy, but this is part of professional ethics
• You have no duty to force them to do the right thing. If you have informed them of their error and they persist, I suggest you make sure to inform them in writing, and make sure you save a copy the document you use to inform them and any response to this document. If they respond verbally, take notes at the time and save them with the file. File this on paper at home.
• You have no duty to inform them of past mistakes. If a past mistake is getting in the way of your work, it is often more constructive to ignore the fact that their judgement was flawed in the past, and just point out the ways that your work changes things so that their system needs to change in X way (which incidentally will mitigate their prior bad decision).
• You have no duty to inform them of a boneheaded decision outside of your scope of work. If you are hired solely to map out a network and program switches and routers accordingly, and you find out that half their users have blank passwords, that just isn't your problem. You don't have to get involved unless it touches on your scope of work. Note that a contractor usually has a much more limited scope than a salaried employee, so your mileage may vary on this point.
• You do have a duty to complete your scope of work. If their decision prevents that, or even increases the risk of failure or schedule slippage, you have an obligation to tell them that, explicitly and in some detail. Again, file this document and their responses.
• If you are a consultant or contract programmer, they have a duty to not violate their contract with you. If their decision violates the contract, you should tell them exactly how it does so. You might also want to tell them whether you would enforce the contract immediately, or reserve the right for later action, depending on the circumstances. File everything.
• You have a duty to yourself to keep yourself healthy and safe. They have a duty to you to not work you harder than appropriate labor laws allow. If any of these are threatened by their decision, you have an obligation to inform them of this, explicitly and in some detail. Again, file all.
• When you get home after finding out about a boneheaded decision is a perfect time for making sure your resume is up to date. Regardless of whether or not you intend to start hunting, it's always good to know it's up to date.
• If their decision will make your employment less enjoyable, that is the time to consider pushing beyond the above. There are three main risks to pushing: pushing itself can make your job less enjoyable, pushing can lead to retaliation that makes your job less enjoyable, and pushing can lead to you losing your job (fired, or put in a position where you must quit). You must examine these risks, and the risks involved in doing nothing, and then you can decide if pushing is right for you in that situation. There's no hard and fast rule for whether or not to press an issue, and don't be surprised or offended if your coworkers make a different choice here than you do, their risks and tolerances are different.

Disclaimer: I am not a lawyer, the above is not legal advice. Under some of the above scenarios, you should seriously consider retaining a lawyer

Consulting vs. Contracting

[msobkow]

You are correct that a "contractor" is typically hired to do a specific task, while a "consultant" is expected to provide expertise and guidance. However, the difference between those two is mostly in the mind of the one doing the work.

The general tone of the original article strikes me as argumentative and defensive. It is a consultant's job to offer options, advice, and approaches the client may not have considered. That information should not be presented as questioning the decisions of client management, but as an opportunity for the client to do things differently than they had planned.

When you are presenting those alternatives, it is critical that you present not only your preferred solution, but options which you might not like. Provide the client management with the pros and cons of different approaches, and let them do their job: making the final decision.

Remember that as a consultant you often do not have detailed information about enterprise licenses the client may have in place, knowledge of the corporate skillset, or even awareness of internal corporate directives.

As an example of why you should leave the client to make the final decision, consider a favourite Slashdot topic: Linux vs. Microsoft solutions. While you might "know" that Linux is a more cost-effective solution than one from Microsoft, the client might also be considering existing skillsets of the internal staff, existing contracts with data center support providers, etc. It is far from unusual for the retraining costs for internal staff and the costs of renegotiating third-party support contracts to absolutely dwarf the cost savings on the software itself.

Your job as a consultant is to advise, not dictate. If you have a good relationship with the client management, you might tactfully ask why they chose the solution they did, but you should not undercut their authority -- not if you want a long-term business relationship.