When a consultant give bad advice

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.

If you aren’t the decision-maker … if the consultant has been inflicted upon you … you have some additional considerations to take into account. Here’s the first, and you aren’t going to like it: It might be that your manager is trying to save you from yourself.

I’ve been brought into this sort of situation and it can be quite frustrating for all concerned. The consultant is there to help an underperforming manager or employee learn better ways to get things done.

Sometimes the employee recognizes that it’s an opportunity, and the results are productive. At least as often, though, the employee figures he/she is doing fine and it’s the manager who’s the idiot. The employee keeps on doing what hasn’t been working, continues to blame everyone else for the poor results, and ends up looking for employment, convinced that all problems were political.

So before you do anything else, be brutally honest with yourself about what’s going on.

If you pass that test … if, after reflection, you’re confident the consultant really is just pushing the “book” solution whether or not it fits the situation, then what you have to do is to separate recommendations into two piles: Harmless and harmful.

Accept the harmless ones with a shrug. The one you’re complaining about is an example. If the verification environment truly is static, for example, then document it once and include it by reference in every project that requires it. It’s an annoyance, not a problem.

For the few you think will prove actively harmful, first discuss them privately to make sure you fully understand the consultant’s logic. Then, if the two of you can’t find common ground, meet with the decision-maker. Be entirely business-like in the meeting, which means making sure the entire conversion is about choosing from among alternatives, not about your complaints regarding the consultant.

So: “We need your help resolving an issue. The two of us have different perspectives about it and we haven’t been able to get to an answer we can both agree to. What I’d like to do is to lay out the issue, have each of us explain our perspectives on it, and have you make a decision. Once you do, we’ll both abide by it and move forward.”

The relationship between consultants and in-house experts easily becomes tense. Consultants figure companies bring them in to provide expertise that’s lacking within the company. In-house experts often feel resentful as a result, figuring (often with considerable justice) that management discounts their expertise specifically because they are employees rather than outsiders.

It’s too bad, because when each respects the other’s expertise, there is often a lot of opportunity to make great things happen.

– Bob