Some of Cringley's The Truth About IT Consultants is good stuff. His Type "A" and Type "C" are both stories of consultants who are brought in because they have specific skills. In the "A" case, it's a technical skill, and in the "C" case it's project management.
In both cases, the scope of work is narrowly defined. Success and failure are finite and definite; it's easy to determine if the consultant is effective. Both cases involve known requirements.
Cringley has a "B" case, however, where the consultant is brought in to a situation characterized by "Sometimes a customer does not know what they want", which is a glib and useless summary of what really happens.
There are several variations on "doesn't know what they want", each of which dooms the project. With few exceptions, the customer has determined -- in advance -- that the project will be a FAIL. Most consultants can hope to choose between FAIL and EPIC FAIL. Cringley names one of those geniuses who can actually make a silk purse from a sow's ear. The rest of us can only hope to make something out of the sow's ear.
Liars
Some customers lie. It's a fact of life. You're brought in to do [X]. You write a proposal to do [X]. You present this to everyone, you go through elaborate sign-off rituals. Then the customer "changes scope." I call it lying, because it wasn't a surprise -- it was known by some and ignored by others. Sadly, you're last to know that all of the quality ritual around [X] was a waste of time.
In most cases, a scope change is a FAIL; the customer ejects you for failing to do [X]. Sometimes they even admit that [X] is impossible.
Customers lie at every step of the process, from inception to acceptance. What does a consultant do when they're brought in as type "B", but the customer is lying about the problem?
The consultant has two choices: call them out on it, or muddle through until being ejected. If you call them out, they might acknowledge the change in scope, and -- best of all -- treat scope change as learning, not failure. [The odds are small, a C|net blog suggests that 62 percent of IT projects fail . This means that most "learning" is still labeled "failure".]
If you muddle through, you wind up in Cringley's type "B" category of consultants who appear to be more problem than solution. You'll be blamed for "running the meter" while the project crashed and burned. But really, the project was already dead; the project was dead as soon as the customer admitted they didn't know what they wanted. It isn't possible to "take a long hard look at the ROI" when at least some of the folks are lying.
Problem-Free Problem Solving
Some customers have an iron-bound process. They insist on [X]. You provide [X], and they confess that [X] didn't solve their problem. 'You did an excellent job and built exactly what we asked for; it’s just not what we really want.' TC quotes. Essentially, the customer demanded technology, independent of the problem being solved.
This has a lot of FAIL in it. If you deliver the technology, the problem isn't solved. If you attempt to solve the problem, you aren't following the agreed-upon scope or approach. Both paths are FAIL. EPIC FAIL.
Helpless Flailing
Some customers like to paint their situation as one in which they are helpless or powerless. They just don't know what to do next. The situation is so dire, that they demand a type "B" consultant to help them decide what to do. This is actually a composite situation, with two parts, both with a lot of FAIL in them.
They are lying about the scope and nature of the work. "Help us decide" isn't true, and "help is implement" can't be true until the decision part is finished. The situation is usually a conflict where someone in power wants the wrong solution and someone without a lot of power or influence is only able to raise doubts, but can't actually change any minds.
To get to agreement, someone must be rewarded for doing the right thing. Consultants rarely shape the cultural and financial reward systems. The customer must elevate the value of cooperation, and must elevate the values of the right solution. The consultant can only point the direction, the customer has to actually move.
They are failing to confront the problem. Sometimes, this is because an executive made a bad decision in the past, creating the problem, and would like to have it solved without any shadow of blame. Other times this is because there's a favorite technology out there, and we don't want to document the problem just build a solution. No formal definition of a problem means endless back-and-forth on the technology. If you can't prove that it solves some (or all) of the problem, consulting won't help make a technology choice.
Again, to get to an agreement, you need some kind of reward for doing the right thing. If we don't have a problem, and we can't reward people for solving the problem, all we have left is waffling.
ROI
What about ROI? Isn't that a good measure for consulting success? Shouldn't we hold the type "B" consultant to an ROI metric?
Sure.
But only if you have a measurement system you can use to gauge the return. Rarely is this in place. "What?" you ask, "Aren't financial measures always in place?"
Sure they are, but do they apply to the technology you're playing with? Or do they apply to the business problem you're supposed to be solving? And if no one will clearly state the business problem, how can we make ROI metrics apply?
It's absolutely essential to clearly state the business problem. Then, picking a solution, is a facilitated discussion, done by a type "A" consultant. Then, the implementation is a project managed by type "C" consultants and staffed by type "A" consultants.
Cringley can complain about type "B" consultants. But customers create the situations in which consultants fail. And consultants hate to piss customers off by declaring a project full of FAIL before they even start.
The Fantasy Solution
Cringely describes a common customer fantasy. "The best consultants are the ones who come with a portfolio of products and tools. " While pleasant, this is rare. There are four common outcomes.
- The client has either chosen the solution -- or is open to change -- and found a consultant who can implement it. Good. Unless, of course, we're in Problem-Free Problem Solving mode. In which case, a great implementation solves nothing. It's still a FAIL.
- The client is a Liar about being open to change. Go ahead, install the solution AND solve the problem. You can still be labeled a failure if there's no "uptake" of the solution. It can stand out as an island of stuff that is repudiated because it's unique. There is no reward for learning the new technology, so it has to be removed. FAIL.
- The client is engaged in Helpless Flailing , but isn't actually open to the technology or admitting to the business problem (or both). Now you look like you're selling snake oil and making insane promises no technology can keep. They may like you, and you may have identified the real problem for them. But if your technology isn't what they want, that's a FAIL.
- The stars align. They are confronting the real problem, they like and embrace (or already use) the technology. Wait. That's the type "A" or type "C" consulting gig -- where the requirements and technology are known.
The basic rule is this: Cringely's Type "A" and Type "C" are places where the customer's done some homework, aligned solution with problem, and has a clear scope of work to actually solve the actual problem. Everything else has a lot of FAIL in it because the customer's unwilling or unable to do the work required AND the consultant is unwilling to make this clear before starting. It takes two to FAIL.