When a consultant give bad advice

Consultants and in-house experts don't always agree. Handling the disagreement properly can be a challenge to all concerned.

Dear Bob ...

How do you deal with a CMMI consultant who insists you must include a step because it is in the CMMI book, even if it would just create another layer of paperwork?

I am arguing that the steps he wants are not value-added to the customer or appropriate for our team, but it is like talking to a brick wall. For example, he wants every project to have a verification environment document that is cross-referenced to the requirements.

Except that the verification environment is not going to change between projects -- we do it the same way every time. So the document will be exactly the same except for the project name. (I'm sorry I am supposed to call them artifacts now ... slap my own hand.)
 
Of course it is not his problem. By the time all this hits the fan he will be safely away and I will be the one who has to clean up the mess.

- On the receiving end

Dear Receiver ...

The answer is: The same way you deal with any other consultant with whom you disagree.

That's the answer. Here's the question: Is this a consultant who has been inflicted upon you, or one you engaged because you needed some outside expertise? Which is to say, are disagreements settled by evidence and logic, or is this fundamentally a political situation?

If you're the decision-maker, this is easy. Give the consultant a fair hearing, which is to say, make sure you're having a discussion and not an argument, and then make your decision.

If the distinction isn't clear: In a discussion you're on the same side of the table, clarifying the problem you're trying to solve together and developing a solution you both like. In an argument, each of you is trying to win, which by definition means the other has to lose.

In a discussion you'll arrive at a solution that's better than what either of you could have achieved by yourselves; in an argument the solution will be a comprise, worse than either of your solitary approaches.

The consultant might have a better handle on things than you're giving credit for. I'm puzzled, for example, by how it's possible for the verification environment to remain static. I'd expect every completed project to change the production application portfolio and the IT infrastructure, which I'd expect would change the verification environment.

It's also entirely possible that the consultant might be the sort who views methodologies as religions, and considers any change to be heretical challenges to the proper orthodoxy.

So if it's your decision, give the guy the benefit of the doubt and a fair hearing -- he might be feeling just as not-listened-to as you are. Then, in the end, understand that you're the one responsible for the result.