6 ways CIOs sabotage their IT consultant’s success

Once upon a time my consulting company offered a “Take the Blame” service. Our pricing varied with what we were to take the blame for, from a few thousand dollars for small project failures to several million when an enterprise software implementation was going south.

Understand, this service wasn’t for situations where we were at fault. It was for situations where our client was at fault and needed a convenient scapegoat. Our logic: As consultants we’d probably be blamed anyway. This way we could at least turn a profit on it. Strangely, we had no takers. A few chuckles, but no takers.

Consultants do make convenient scapegoats. But really, wouldn’t it be better for everyone if they succeeded in their efforts so you don’t need a scapegoat? It’s a self-answering question, which leads to the next question: Why don’t more IT organizations do their best to help make this happen, instead of sabotaging the folks who should be their best allies with undercuts like what follows?

Flighty assumptions

Consulting contracts or statements of work include a section titled “Assumptions.” It’s a list of conditions that must be true for the project to succeed — everything from the client staff needed to work on the project, to the client sponsor having sufficient authority to negotiate contract changes should they be necessary.

Often, it turns out that many of the assumptions included in the contract were wishful thinking, jettisoned with the first project speed bump, leaving the consultant to decide whether to: (1) walk away from the impending mess immediately; (2) hang on in order to bill as much revenue as possible while the situation slowly erodes; or (3) formally document the assumption changes and insist on renegotiating the contract based on them.

Recommended project management practices would suggest door #3. If you want the project to succeed, #3 it is. But #3 is often politically impossible.

What to do? Now that it’s too late to do things the right way, CIOs can at least muddy the waters enough for everyone to come out whole by asking the consultant’s project manager what it will cost to make the worst-violated assumptions true enough for everyone to muddle through.

Information underload

That’s assumptions in general. Here’s a promise made during negotiations that’s often DOA once the project starts: The client will provide the consultant with the information necessary for the project to move forward. Of course, once the project starts, it turns out that nobody in the client organization can provide that information.

Why would the client make a promise like this? One reason: Whoever in the client organization is responsible for providing the information isn’t willing to admit that they can’t, either to their boss or to the consultants.

In the short term it’s safer to make the promise and kick the can down the road, until the project has been going on long enough to shift the blame to those damned consultants who keep on making unrealistic requests of IT staff who are already overworked and underpaid. (Take a deep breath.)

There’s another reason some clients can’t deliver information on demand: They’ve outsourced the IT functional area responsible for the information needed, and the outsourcer isn’t willing to help out consultants they see as likely competitors.

And for some unaccountable reason, many IT managers aren’t willing to tell the outsourcer that the “request” isn’t really a request in the sense of being optional. Providing the information is (well, should be) a condition of the outsource, assuming (there’s that word!) the outsourcer doesn’t want to become a former outsourcer.

Refusing to let the consultants consult

Consultants aren’t just supposed to be smart people. They’re supposed to provide expertise. That expertise includes frameworks, methodologies, and techniques. These aren’t three synonyms for the same subject, either: Frameworks organize knowledge; methodologies provide the means for collecting that knowledge; techniques are what are in the consultant’s bag o’ tricks — street-smarts that complement the book smarts of their frameworks and methodologies.

Some clients, not satisfied with specifying the results they’re looking for, also insist the consultants make use of the client’s templates, practices, and processes, even when they aren’t a good fit for the engagement; even when they’re the reason things have gone wrong — the reason the client needs consulting help in the first place.

Assigning the worst and dimmest

Consultants can’t succeed without active participation on the part of their client’s subject matter experts — the employees who know how to navigate the organization, whom to interview and receive briefings from, and who understand how things have been put together and how they operate (or are supposed to operate).

Smart clients assign their best and brightest employees to the consulting effort.

But these are the employees who are hardest to free up from their day-to-day work, and so less-wise clients often take the easy way out, assigning the employees who are easiest to do without.

Even the best consultants will have a hard time overcoming the limitations of subject matter experts who aren’t experts at all.

Grousing

Sometimes, and especially when a consulting engagement hits speed bumps, the temptation to badmouth the consulting team can be overwhelming.

That’s especially true when the consultants have been trying to overcome obstacles put into their path.

IT managers need to resist the temptation, for three reasons. First, everyone in earshot knows who chose the consultant in the first place. Second, not everyone in earshot will be naïve enough to accept one-sided blamestorming at face value.

Third, and most important: To succeed, consultants need client management’s cooperation in all areas and levels. Should IT succeed in discrediting the consultants it reduces everyone’s willingness to work with them.

Missing the point of post-negotiation work

It’s an uncontroversial truism that effective leaders and managers see their job as helping employees succeed.

For some unaccountable reason many IT leaders and managers don’t see their relationship with the consultants they bring in to complement their in-house expertise in the same light.

It’s true that outside consultants are more likely to have an intrinsic conflict of interest in the form of wanting to maximize margins and increase the scope of the work they take on.

But smart managers and leaders do everything they can to keep their consultant interactions on the right side of the line that separates collaboration from negotiation.

They understand that negotiation is what happens before the project starts. After that, if collaboration isn’t possible, it means you chose the wrong consultants.