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