Improvised Explosive Consultants - neutralising a bad consultant

One of the challenges I often have is where a company employs a consultant to give 'independent' advice and the individual employed is a total snake-oil salesperson.  They've read a couple of books and websites and see their only job to lob in a 'bomb' in a meeting and sit back.  I categorise a bomb as a piece of input that is

• Completely and utterly wrong
• Contains a grain of truth that has been warped and distorted but can be made defensible 
• Said with conviction and patronisation as to how you can't see their point

So its the person who says 'Where are the WSDLs, this is an SOA project I expect to see WSDLs' and then follow up with an accusation that you don't have enough detail as you haven't done to WSDLs.  Or someone who in an MDM project asks 'why aren't you storing transactions in the Master, how are we expected to get them?' or questions to which answers are so obvious you don't bother putting them on the slide deck 'how on earth can you say you are doing a global implementation if you aren't using HTTP for the user interface'...'Err we are'.... 'Well you should have said, its a critical point'.  You know the sort of thing.  Dumb questions.  The reason they are dumb questions is that this person is meant to be an expert.  People who don't know can't ask dumb questions, they ask questions and you help them understand but when the person is put forwards as an expert then you have an issue.  I think of these people as Improvised Explosive Consultants as they are normally doing a specific thing, taking a small grain of knowledge and improvising it into a bomb to derail the project to show their value.

You see they are there to keep their fees up and to do that they need to demonstrate 'value'.  One of the easiest ways to do this is to undermine others and doing this in a technical area just means you have to seem smart to someone who doesn't understand the subject area.  One of the problems this causes is that you can't just call 'bullshit' on the bomb as often it sounds plausible to the layman while being rubbish and because doing so creates an antagonistic environment which is counter-productive and often leads to the IEC being seen as 'scoring a hit' with their insight.

This sort of consultancy often leads to bad decisions being made, the bomb is used to confuse and thus a confusing solution is then created.  The bomb maker, the IEC, is of course not going to be doing any of the actual delivery but can continue to stand at the side throwing bombs to demonstrate their 'value' and superiority.  So how do you defuse an IEC?

• Don't lose your temper - they are after this as it shows the bomb has been effective and makes you look uncertain, even though you've probably lost your temper because of the level of stupidity
• Get the specific objections down on paper - after the meeting where the bomb is thrown get the IEC to write a clear email listing their 3-5 points.
• Attack the facts not the person - don't debate the person keep on the facts.  Use terms like 'I'm a bit confused by number 3 because wouldn't that mean....' rather than '3 is just rubbish, don't you understand.
• When you finish knocking down the points send an email confirming that they accept that all of their 'challenges' have been addressed.
• Then send their reply of 'yes' (probably including some phrase like 'its important to check these things') to the whole group making clear that you've addressed all the points and the solution hasn't changed at all
• Repeat this every time. 
• When you get to the third bomb, add a statement to the reply that 'while you appreciate that IEC is just trying to get to the right solution, as we all are, I'm concerned that the team is being delayed addressing these concerns.  So far we've addressed 15 points and none have resulted in a modification to the solution.  Could I please ask that anyone who has specific challenges to the solution at this stage please email me (or add to the bug/CR/etc repository if you have one) before the meetings to speed up this process.

Hopefully during this process the IEC will quickly be identified with delay and your documented history of their comments producing nothing but additional work will result in them being defused.

If you are on the other side and think you might be employing an IEC there are a few key ways to check

1. Do they talk about their delivery successes or just their advising successes
2. Do they use patronising tones when people whose opinion you think is worth something explains stuff to them. 
3. Do you find that people with a history of successful delivery say they are 'confused' where these challenges are coming from.
4. Does the person talk about problems without out talking about simple clear solutions

If you've answered yes to 3 or more of the above then take a long hard look, you might have an IEC.

Technorati Tags: SOA, Service Architecture