ABC – Always blame consultants

I was working side-by-side with an executive sponsor at a client once, and we were discussing a technology implementation that had been a disaster for them: took years (not months) to get in place, did less than what they expected, had less of an impact than promised–the usual stuff implementation horror stories are made of.

I said that it was a shame, because in my experience the software was a solid offering and should have provided real value to their organization. He smiled and replied that in his experience at the organization, when there’s been a problem with a vendor, it’s usually been the organization’s fault.

We laughed about it–after all, haven’t we all worked at that kind of place at one time or another? But later it got me to thinking, can a professional services vendor ever be “off the hook” for a project failure? Structuring and executing engagements is what we do, and adverse (or at least less than ideal) project conditions are the norm (or at least to be expected). Isn’t that why organizations shell out big bucks to bring in consultants in the first place, to accomplish difficult, challenging projects that the organization otherwise couldn’t?

The way I look at it, as a consultant I’m always on the hook for project success no matter how adverse the project space is, because ultimately all project challenges fall into one of two categories: those I should have known about and those I couldn’t have known about (but should have been ready for).

The first are things like competing projects, budget or resource constraints, political land mines, and so on. Missing these represents a failure of my engagement process, i.e., somewhere in the lifecycle from opportunity through qualification, negotiation, and contracting, to initiation and execution, I should have uncovered them and put a plan in place to respond to them. Or if I didn’t feel like I could overcome these, I should have walked away from the engagement because I knew I ultimately wouldn’t be able to deliver value to the client.

The second are things like new regulation/legislation, loss of team members, fallout from the failure of other initiatives or projects, and so on. And although you couldn’t have predicted these, you should have accounted for them with a risk analysis exercise early on in the project.

This is not to say, for example, that you could have planned for a specific kind of regulatory change–you almost certainly couldn’t have; but you should have put some thought around what kind of risk regulatory change in general posed to your project and the options for mitigation and response that were open to you. This way, even if there were no options to respond to this particular risk category, at least you’d be ready for that outcome from the get go.

It’s a lot like hiring a contractor to open up the floor plan between your kitchen and dinning room. She’s on the hook for scoping the effort accurately–or letting you know that she doesn’t have all the information she needs to scope accurately; she’s on the hook for thinking about what might go wrong during each phase, from demo (hidden pipes or electrical) to construction (appliances not built to the design specs for their dimensions) and closeout (inspection/zoning issues). If something goes wrong, you expect that the contractor will make it right and deliver a project you’re happy with. Why should we expect to be held to any less of a standard as consultants?