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 believe the answer to this lies in the price point.
Simply stated, if a client is paying cheaply (well, as close as that gets in consulting), they deserve the minimum information and just get what they ask for.
If a client pays well or tips well or has been a long time repeat client, they deserve that extra time taken to show which judgement would be best and why.
Note those last two words: "and why." That is the single most important piece of information that is needed when questioning any decision. If you have that ready, your ideas will go much farther.
Also, take into account how much the client knows about what they are dealing with and how stubborn they are. If you've ever been in sales, then you (hopefully) have some idea as to how to "read" people and present ideas in the way that will relate to them the most. If not, then I would recommend lookng into this type of "people skill," as it comes in very handy when in a bind.
Just make sure that you don't give them so much information that they feel they no longer need your services, as that could also be a dangerous move. Overall, if you know something they don't, they will pay for that knowledge. And they will continue to pay you as a valuable source of information for a long time.
Work sucked, until it became unemployment, when it became slightly more tolerable. -Tet
... on the reaction you get the first time you try it. As an employee or contractor I would feel obligated to point out why something may be a bad idea. If I get my head bitten off after that I would default to "Yes sir, here you go, exactly what you asked for." Fortunately I have a boss who listens when I point things out. Sometimes he acts on my recommendations. Sometimes his response is "You have a point, but we're still doing it this way."
Yeah, I know - a lousy answer, but it's the only one I've got.
"An unarmed man can only flee from evil, and evil is not overcome by fleeing from it." Col. Jeff Cooper
"It's ridiculously expensive, terminal services are free."
evil adrian
I would say always make your fears known. It's called CYA (Cover Yer Ass), you don't want to be blamed when what you feared comes to pass.
If for whatever reason you can't then it's tough luck for the customer. Any company that doesn't keep an open dialog is doomed to failure I would think.
I wear pants.
Presumably, companies hire consultants because they need technical expertise.
I'm not sure if I'd make that assumption. A company may hire a consultant because they want an outside opinion. Everyone at the company gets so used to thinking the same way they lose sight of the forest for the trees. If I were a consultant, one of the first things I would make sure I understand is exactly why I'm being hired. It is entirely possible that the company may claim to want an outside opinion but there actions seems to indicate that they do not. In such cases, you may need to remind them periodicially what you were hired to do.
If, for some reason, you don't have this initial discussion with them, I think you still have to assume that they want you to critically examine their decisions. If they finally get fed up with you questioning their every move, I'm sure they'll let you know. At that point you can decide whether you want to continue to work for a company that disregards your opinion.
GMD
watch this
if a client is paying cheaply...they deserve the minimum information and just get what they ask for...If a client pays well or tips well or has been a long time repeat client, they deserve that extra time taken to show which judgement would be best and why
Nice work ethic there, Sparky! Nothing like doing a good job for the sake of doing a good job. No sir-e! Show me the money!
Tip: You should go into medicine. There's tons of money to be made off of pesky poor people and, hell, since they aren't paying well you can just throw a bottle of asprin at them and save your best work for people who are worthy (rich).
Please. You are hired to do a job. When you were brought on, if you had a problem with the rate, you could have said something. Hell, you could still say something. That's called negotiation. But it isn't blackmail. "Oh, I'll only work hard if you keep meeting my demands." Show some class. Show some self-respect. Demonstrate you have a moral sense of right and wrong and you aren't just a high tech whore...
I would have to say that explosives are the most abused technology in all of history.
I hardly ever do consultant involving coding unless it's something simple, like creating a web based front end for database entry or something. But when I am providing these types of solutions I always suggest FOSS. Alot of small busineses get duped into thinking that they need to go with Win2k, IIS, and either Access or MS-SQL. I always suggest Linux, Apache, and MySQL - and not one of them (OK, there was only two, but still) decided to waste over $1,500-$4,500 on the MS bundle (If they choose SQL it adds quite a hefty chunk of change onto the total).
I'm assuming the poster is in the US. I'm from Sweden myself, and I'm currently working in USA (since 6 years). I can clearly see a big cultural difference here. In Sweden (at least in the companies I've been working for), you're always assumed to question whatever management ask you to do, regardless of your position in the company. They are always grateful if you find a better solution and count on you to express any doubts or questions regarding the proposed task.
While I've been in the US, I've been asking questions in the same way and this sometimes lead to real frustration. People don't want to be told that they might be wrong. The response is typically, "well, it's nice of you to express your opinion, but this is how we do it" without even be willing to discuss the matter.
This is just my experience and hopefully not typical in the US workplace.
Jim in Az
My belief is that a consultant should do two things when looking at a client's needs.
You analyse where they are and then where they want to be. The bit in the middle is what you're hired to do.
If doing a proper job you should have a good idea of the overall goal of the project. Not just upgrading xxx, but the reasons why your upgrading it. It is this that makes you truly see if they are making a poor decision or not. It also helps you immensely in putting in the right solution.
You may have issues with their direction, and this is I believe what your getting at. Your treading a fine line as unless you've been brought in to consult on the direction then people are going to be hurt.
Sometimes you need to go up where the air is thin and lay out your case for A vs B and why you believe B is a better solution / strategy. At worst you can get someone to have a quick look and see if you have a point; if they don't even offer you this, then its not worth your time.
You should always let them know if they are making a bad decision. They may not always take your recommendation, and may even get to the point where they EXPECT you to argue (like they did with me) -- but otherwise you are just a seat filler.
You are hired for your technical expertise. If they say, "It must be done like this", then I have no problem speaking up with a "that will be extremely slow".
But here's the key: Be prepared to provide an alternative. If you critisize, but don't provide a solution, they may just see your comment as non-productive. However, if you get in the habit of providing better solutions, they may start asking you to find a solution to begin with.
Malachi
http://www.google.com/profiles/malachid
Aside from the other very insightful comments here, I'd also judge wether to speak out based on the risks involved
Is this a pacemaker or space shuttle? I'd probably speak out louder.
Is this an "I'm on the web" website? I'd probably just mention my misgivings.
What's wrong with TightVNC? It isn't exactly as fast as Cirtix over dialup, but it comes damned close and the price is right.
1. Don't "unsell" anything that your sales team has sold. It doesn't matter that they dont need that particular widget - don't tell them that.
2. Make recomendations for how they could do things better. They will expect this. This is the difference between a consultant and a contractor.
3. Don't make the customer feel like an idiot for having designed/implemented something in a less-than-perfect manner. Politely suggest the necessary changes and give them good reasons why they need said changes. And don't make the customer feel like an idiot.
These 3 should get you started...
I'd rather be a conservative nutjob than a liberal with no nuts and no job.
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.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
First, whether you are a consultant or an employee, the issue is still the same, and they have the same expectations.
When faced with something I find dubious when first starting a project or taking on a consulting task, I do not assume an air of 'I know everything and this *will* fail'. I find it is actually more effective to ask questions that will lead them in the direction of figuring out the flaw for themselves. Also, it is not infrequent that there is *something* they neglected to mention that actually reveals what they want to be reasonable in context of the situation, and when that comes out in such a discussion, it doesn't make you look like a presumptious ass. If they figure out the flaw and where your questions where going, they appreciate not only your foresight, but helping them to understand the issue at a more fundamental level. If they reveal a piece of the puzzle that makes their request reasonable, or even if you end up having to point out the flaw yourself, they appreciate your effort to understand more about the big picture and how your piece fits in before just jumping in with a 'yes, sir' or flat out rejecting it without trying to understand why they might not be idiots.
XML is like violence. If it doesn't solve the problem, use more.
There is a form of consulting that is distinct from the kind you are discussing. Often a consultant is working with a consultancy company. In that case, the consultant must consider the relationship between the company and the client. It is always correct to discuss any such major issues with your company in this case -- and be guided by how they want to deal with it.
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.
Which is why the firms I've worked with NEVER bid fixed-price, always time-and-materials. If you did an ethical job, fixed-price was always a loser because you'd lose the bid unless you underestimated the work.
Babysitting the billing is the job of the contract administrator of a multi-man shop, not of the consultant. That way you can play good-consultant/bad-administrator if the client has an issue. (Of course if you're a one-man-band you have to wear both hats, so you're stuck.)
My algorithm for dealing with the original question:
During the project definition phase:
- Research the customer's problem to figure out what he needs. (Because when you ask him what he needs, he'll tell you the new stuff that he wants, completely skipping the core of the problem as an uspoken "of course".)
- Suggest a design that gives him what he needs. Try to convince him that THAT is what he wants. Then.
- Build what he now WANTS.
Sometimes the customer will now want what he needs. Sometimes he won't. In the latter case maybe he's right, maybe you are. Doesn't matter. Now that he's informed, if he overrules you, it's his money so do it his way.
If you go down a rathole at this point, it's his problem. But if you didn't tell him IN ADVANCE that he'd taken a wrong turn, you didn't do your job.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Well, keep in mind one fairly important thing...
Assume you do go ahead and give a "yes sir" answer, against your own best judgement. Now assume that $5 million later, something blows up. When the finger pointing starts to happen (and it WILL happen), the phrase "the consultant said it was ok" will probably be uttered, and often.
Should the lawyers get ahold of this, you would be minced meat. ESPECIALLY if they find out that you thought your advice was wrong.
Stick to your guns, if you disagree with something the boss is doing, then say so (and preferably document both your disagreement and the reasoning). If you loose the account, so be it. Would you rather be sued for malpractice?
Ron Gage - Westland, MI
I was hired by the build manager of a certain PDA manufacturer (think "* of your hand") to automate their build processes. He told me they had these amazing build scripts, but the build engineers required hours to sit and run the script. (!) Therefore they needed some kind of automation server to run the scripts... Yeah, right. When I poked holes in his theory, he claimed that this is what SW Eng wanted, so I should forgive him if he got it wrong. As stupid as he turned out to be, I was just as stupid for thinking "I'll meet the engineers, find out what they really want, and everyone will be happy." I took the job. What a moe!
Long story short: my boss didn't know squat about software (he thought you could run Mac programs on a Windows box) and he hired friends from previous jobs to be build engineers (all they could do was memorize steps given them by the developers). His lauded build scripts simply ran variations of the builds (different langs, debug/release, etc.). It was a big deal to these momos because they hadn't even had that level of automation before. Processing a request, checking out the code, verifying the build, copying built files to the network, and sending emails were all done manually; yet my boss continued to believe the scripts were wonders of automation and if I simply built his nonsense server (and other crackpot schemes he came up with later), SW Eng would finally take him seriously. I wrote memos, made presentations, drew pretty pictures, and tried to enlist the help of people I thought he might respect, but ultimately I stayed too long, the economy changed, I no longer found good job leads, and I got laid off.
I'm working now, but the thing that irks me, and hurt me, is that my boss bad-mouthed me to my co-workers, apparently over my attempts to pull his head out of his ass. Despite what I say happened, I got the reputation for being trouble and refusing to obey orders. When I left, I had few friends, no references, and little to show for the time I spent there.
My point (and I do have one) is that questioning or pushing won't get you very far. Sooner or later, they'll remember that they have all the cards and you're just some guy on a contract. Your question suggests you're not happy with your company's decisions. If you can get around to being happy, more power to ya. But if it's going to continue to bother you, get out and do it sooner rather than later. You have to remember that 1) not all jobs are good for you, and 2) sometimes people really are crazy and if you're in the line of fire, it may hurt you long term.
A contractor does as there told, and in the absence of being told anything, may do nothing. (Although this would be considered poor even for a contractor). A contracter is contracted to perform a service, code for example. Given a set of specifications, they code well, debug well and implement well.
A consultant is a value add. They are a contractor plus, they provide additional expertise and insight gained from experience that is sometimes difficult to find within a company. Many companies that hire consultants have an in-house staff consisting of "big fish in a small pond." This is not demeaning as it sounds. Consider a tennis player who only plays high school students. With few exceptions the best they will become are as good as their experience. Development is the same way. I tell people when I leave, their people will know as much about what I bring as I can pass along.
This was all leading into the question. If you are unable to explain the reason to take an action, or to select a different path, one of several things may be occurring.
I am not explaining the options well. An issue for you to deal with and not your client. My inability to explain a situation sufficiently to be convincing, is my issue not theirs.
I am working against "it cannot be done this way" mentality. On the last two sites I worked at, I was told they could not, or specifically, it was impossible to do what I was asking. As it turned out, it was impossible because they had never done it and did not know how. In two situations at the last client, I was able to remove a full time manual process (30+ hours per week) by automating it in less than one week. A miracle? No. I knew it was possible.
You don't know the politics. A good read for Developers and Leaders alike is Rapid Application Development - Taming wild software Schedules. It gives insight into this aspect. In many cases a project cannot get approval to do it "right", but can get approval to "do it" then "do it right" in support. Logical from the outside? No, but understandable.
You are missing something and they may not want to tell you. I have seen projects were they were approved to the dollar. If it went over, even by a few hundred dollars, it was killed. Even if it lost thousands. The logic(?) being that it is better to kill a project that is over budget immediately, rather than let it continue on. This may be the case or it may simply be you do not know all the players, policy, and interfaces involved.
In some of these cases you can keep trying. Hoping to add value. The attempt, given it has good business sense behind it, will keep that client happy, even when they do not choose your ideas. At least they see new ones coming and maybe the next one will hit.
Personally, I think that's doing your job. You say "It's a bad idea. I won't do it unless I have it in writing that I was opposed so I don't get blamed for doing what I think it is going to do"
If anything, it might convince the higher-ups that maybe it's not such a smart idea if the expert is so adamant about assuming responsibility for what he expects to happen.
If you show that you're happy to do something you disagree with (albeit not without avoiding misrepresentation of your actions) then you'd look a lot better in management's eyes.
Karma: Non-Heinous
This is one of those things that can get you on both sides. First, the customer gets you by asking, "Why didn't you tell me this was a bad idea?" Second, the customer gets you by saying, "Look, this is the way we do it, we've always done it, and we aren't changing." Sometimes you get both responses from the same customer.
I can't speak for contract programming, but in networking I used to consult in a company that preferred Linux/NetWare solutions on the server side with a Windows NT/2000 desktop--this was a little more than a year ago. We understood that each platform had pros and cons and the systems proposed varied widely depending upon the needs of the customer--we even recommended Windows only environments sometimes.
However, we lost one customer because we didn't bid a Windows 2000 server solution and argued against it because it was simply not in their best interest to use 2000 file services. They got a bid from another company that bid a 2000 solution and gave the bid and the rest of their business to them. In the end, we had to reevaluate how we refused a customer's desires and when we were really willing to turn them down--this is a 3 man shop, so loss of customers who had us on retainer was a serious consequence.
I'd say making sure the client knows your mind is probably good. But, knowing that they make all the decisions is priority. As with any form of persuasion, the best is the kind that gives them the facts and makes the persuadee think he made the decision himself.
Anyway, walk a fine line. Hopefully, if you're good enough, you can avoid and/or afford to turn down the really easy-to-tick-off customers that are never happy.
Cheers,
Sterling
It sure sounds like you're asking us to define your personality for you. Grow a pair, make a decision, and live with it.
Basically, if they're paying the bill, you have a responsibility to deliver what they want (if possible). And if you can't or won't, you have a responsibility to tell them.
'What they want' is the question. They may want opinions, or they may simply want hands typing. It's okay to ask. And if you don't like the answer, then you can decide how important 'being right' is to you. Keep in mind that 'Right' is often relative. And sometimes it takes people time to come around, longer if they've been forced into a corner.
I've been lucky that most of my clients have wanted my opinions and experience along with actual code. They haven't always listened and it has often been frustrating. But even though I may know certain aspects of 3D optimization (in my case) better than them, they know their business and their overall needs better than me. In many cases, I was probably right about 'what we should do' and they were undoubtedly more right about 'what they could afford to do.' It's their company, afterall.
Sorry if that isn't as specific as possible, but the thing I've learned after 10 years is that every case is different and flexibility is key.
That is to say, if you've signed a contract stating that you'll implement X, Y, and Z, then sure, you implement X, Y, and Z, and walk away.
If your role is truly that of a consultant, then you have a responsibility to speak up. If your client is looking to satisfy a requirement, and they're considering doing it in a completely half-baked way, that will only marginally address their concern, and create a number of additional problems along the way, you have to say something. That's a fundamental difference between the roles of contractor, and consultant.
It's true that you need to exercise a certain degree of diplomancy, and you need to be able to deal with people, many of whom will see you as a threat... You can be absolutely certain that at least one guy (The one that came up with the half-baked scheme) is going to be bitter.
That's the job...
As far as covering yourself, you need only document your recommendations. Email is sufficient for this... Put your recommendations and your objections in email, and get a delivery confirmations. You cannot be held liable for poor results if your client chooses to disregard your input...
Quite the contrary, if you are in a consulting role, and you don't speak up, that's probably the bigger risk. If everything goes to hell, they can turn around and say "Why didn't you tell us? You're the expert..."
It's entirely possible that you'll end up in an environment that's impossible. You're told not to raise objections, or make waves... Essentially, you learn that you've been brought in simply to give a piss-poor project the air of legitimacy... If you do this long enough, it's inevitable. If you find yourself in that position, walk.
I'm not just saying that... I've done it twice in the past 12 years.
For those that would die defending it, Freedom
has a sweet taste that the protected will never know.
I have found that when i go into a contract/consultant situation, I almost always have some differing opinions with management. Sometimes voicing those opinions are welcome, sometimes it isn't. Everytime it has been welcome, I have been aware that it was welcome. In those cases I have been an ad hoc advisor to the project, not just a developer implementing a clear path. Occasionally I have voiced my opinion when I wasn't sure if it was welcome, and, (guess what?) it wasn't. In one case it even resulted in my quick, quiet dismissal.
Geeks (like myself to some extent) are generally bright and very opinionated. Use that brightness to realize that there is a time for putting in that extra effort and there is a time for simply just shutting up, working and drinking after work.
-Sean
You can never sa "no." You can only say "yes," then lead them to the conclusion that really isn't the best option.
Presenting options, explaining the risks, and showing why something isn't the best way are certainly valid (and expected) actions. If done appropriately and tactfully, it is certainly worth doing. If the person telling you to do this significantly outranks you (i.e. their CIO, you would match do a junior level), take it to your leadership.
Be sure to listen to what you are being told before acting (and even after). You may find that, while it doesn't make sense in the abstract, but, in the context of the clients business, it may make more sense (for technical, legal, political, or financial reasons).
Also, make sure that whatever opinion you are going forward with has the client in mind. For instance, don't push a certain tool just because you personally favor it.
If they still insist on whatever it is you have a problem with, you have two choices: just do it, or quit.
As someone with technical expertise in a small company, I find that one cannot always trust their consultants. Often enough, the consultants have another reason for providing the advice that they do. Sometimes it has to deal with special deals that they get from various vendors, as well as their own bias.
In this day and age, it's not the easiest thing to do, finding a completely unbiased consultant. There are consultants that feel an MS solution would be best, and some that would push for the Unix solution. Their own personal preferences can often taint the opinion that they provide.
A consultant is not always paid to provide a final decision, a consultant is very often hired to provide advice. So should my company hire a consultant, and we don't necessarily prefer the decision that consultant makes, we'll pay her/him for their time, and go with the solution we find to be better. We know our company better then they do most often, and as well know what we want.
After all is said and done, it's not the consultant's job to make the final decision unless that is what the company was looking for. I most often find issue when a consultant gets insistant and sometimes outright rude when stating the way they feel a company should go. And I've both rejected plenty of bad advice from consultants, as well as fought through fixing the solutions that came about due to accepted bad advice.
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
----
Open mind, insert foot.
I read through some of the comments here, and thought I'd put in my $0.02....
First off, you have your integrity. If you see something wrong, you have a duty, more than your job, to mention it. Measure the response.
Personally, ethics is a very important part of my job. I don't always win, and sometimes, I'm thought of as a troublemaker.
That's not what I'm doing, though. I feel that whatever job you do, you should do it to the best of your ability....
Abe Lincoln said it best... "Whatever you are, Be good at it..." (I paraphrase.)
Be responsible, be good, and be right. In the same breath, also recognize when you are wrong.
Don't be afraid to be wrong, and *don't afraid to take a chance to be right*. Nothing we do is certain.
If we all give in and compromise our ethics, then what have we become? Worthless, in my humble opinion.
Our country is built on people who take chances. Sometimes they succeed and sometimes they don't.... But they never know until they try.
"Never give up, Never surrender!" -- to quote Galaxy Quest. This is not only a silly saying, but really a mantra that we all should aspire to.
Otherwise, what are you trying to accomplish? Money? It's simply pretty paper. It will not last... And in the end you will be left empty, void and dead.
Behave like individuals, and work well with others in teams.
Okay, I'll step off my soapbox now. I hope you
get what I'm trying to say...
Chris
Nothing in this life is certain, except for truth.
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.
I do not fail; I succeed at finding out what does not work.
The BCS, IEEE and ACM all have codes of ethics. The response to this situation is clearly laid out.
Yes, I have done this at least three times. The first time, the customer backed off. The second time we got to the written response stage and the customer ultimately respected the professional approach. The third time, they wanted to break the law and I walked.
It is possible to have an ethical career. Read 'Ethical Ambition' by Derrick Bell.
* those you pay to justify what internal IT has done ($);
* those you pay accomplish a task ($$);
* those you pay to take the blame for something internal IT has done ($$$$$);
Which are you?
-- Before you do anything you can't undo, always understand all the things you can't do once you've done it.
At the beginning of the assignment, you must determine if you are there to accomplish a goal or to prove the point of the hiring manager.
During the interview phase determine if the assigment is "prove the manager's point", then decide to take the assigment or not.
A consultant is paid for well thought out opinions based on facts. Document everything, and preface it with "in my opinion" either written or verbally.
A consultant does real work also. Actual bit flipping.
The difference between a consultant and contractor? About $60/hour.