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

Consultant or contractor?

[Kysh]

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

They know not what they do...

[dot2dot]

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 :-)

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:You're missing the point

[DutchSter]

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.

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 ;>

Re:Im in this situation now..

[maxII]

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.

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.