Failure perspectives on consulting

Michael Krigsman over at ZDnet has an interesting pair of posts up on his Project Failures blog on the subject of consultants and failure. The posts, which have sparked a lively discussion in the Talkback section, revisit an oft-lamented but rarely discussed (except for here) fact of the consulting industry, which is that many consultants profit the most when their clients fail.

Krigsman's first post simply points this out--when projects go bad, they go over on schedule, and as most consultants bill per hour, this means more billable hours and larger profits. His advice is just as basic (though no less correct): negotiate deals that hold the consultants accountable for outcomes.

Commenters quickly point out the essential flaw in this, however; it's not always the consultant that is at fault. One poster says:

In EVERY consulting project that I've ever done where it went past the expected due date, the fault has always been with the customer. I want to go in, get the job done, so I can then move on to the next client. More often than not, when I'm onsite, the delays are the result of some individual not providing necessary information for me to connect, not being available, running off to meetings, etc.

Krigsman is a consultant himself and I have little doubt that he is aware of all this. It's a sentiment that rings fairly true to me as well--I certainly have had clients who are their own worst enemies when it comes to successful implementation projects, providing incomplete or incorrect information, not making key personnel available, and making requests or changes at the last minute. Those are also the only ones I have ever had complain about their bills, incidentally.

These days I ditch those clients as quickly as is convenient (which, believe me, is almost never quickly enough) but to be fair, the situation is always at least partially my fault as a consultant as well. And, as a consultant who now deals largely with other consultants as a strategic adviser, I can tell you and the above poster that you can avoid a lot of grief by making it clear exactly what requirements you have for the client as well as the more common obverse. And it has benefited my practice considerably to do just that--I have had successes with clients who have churned through other consultants. Not all of them are amenable to such an approach, but if you're a consultant, steer clear of those who are not.

Another poster says:

No consulting
firm benefits when their clients' projects fail. That's
just not a sustainable notion from a business
perspective.

This same poster claims to have broad experience from twenty years in the consulting industry, which I flat out don't buy--you either aren't in the industry or don't have much experience if you haven't come across a number of firms who flourish despite a trail of failed projects which are either papered over or glossed up, frequently taking advantage of the extraordinarily low expectations that executives of all stripes have for technology.

However, this same individual, in a later post, puts his finger on the real issue, inadvertently:

In my entire career, I have never heard anyone talk about any benefits of failed
projects.

I have no doubt that is true--I've never heard anyone talk about it either. But the fact that it is not explicitly identified as a business strategy in no way means that it cannot have significant influence in business practice... and I believe that it's more often simply the incentive to drag the engagement out, and to allow those little mistakes or oversights by the client as mentioned above to slide instead of pointing them out or tightening the terms, which creates the conflict.

The second post takes a more concrete approach from the client-side perspective on how to structure deals to avoid such situations. "Value-based consulting" where "...consulting prices are established in reference to value brought to the client by the services" is recommended. This is similar to my oft-made recommendation to align the consultant's interests with that of the client, but as several commenters point out, it's not so simple: consultants are just as wary of client-provoked failures as clients are of consultant-provoked failure, and no one is eager to be left holding the bag. In this relationship, the consultant typically holds a lot of the cards and that is why they command such favorable contractual terms and hourly-billing arrangements; after all, consultants have or purport to have rare expertise, and as Krigsman quotes Richard Weissberg as saying, "One of out ten consultants is the great one you want" and "...great consultants often have all the work they can handle." Those conditions, even if you dispute the specific numbers, make for great scarcity among reliable and worthwhile consultants, and leave the rest in a position to name their terms or walk.

I think it's easier in the managed-service market to demand such terms than it is in the implementation market that Krigsman is talking about, but I do think there are things that can be done by both parties--the worried potential client and the concerned consultant--to help manage this alignment regardless.

IT projects are notoriously difficult to define specificity in ahead of time and well-known for complicated but unforeseeable obstacles that arise mid-stream. So while the easiest admonition would be to negotiate a very tightly defined contract with very specific requirements and responsibilities, that is probably only applicable in very straightforward implementations.

A better technique is to structure a contract with requirements and responsibilities stated in terms of scaling rather than specificity, and with checkpoints and stops built in to prevent the gradual decent into madness that plagues many complex projects. By "terms of scaling" I mean that the flex of the scope--and it will flex--should be agreed upon ahead of time and allowances made for additional fees or commitment of resources required from each party along the way. Requiring the consultant to point out issues that will raise costs, instead of allowing them to wait until these are fait accompli, can go far toward checking the sort of subtle incentives to failure discussed above. Similarly, making it clear to the client the extent of the pain should they fail to fill their end of the bargain gives them incentive to keep reasonable plans and adequate resources for the project.

Still, even this is complex to negotiate and potentially full of holes for many projects. So my own personal preference, which Krigsman finds no favor for, is to use Agile methodologies to manage such projects.

I won't attempt to detail Agile approaches here (it's another post entirely) but I'll point you toward the post I made which prompted the original debate here and I'll tell you what I think the benefits are:

• No significant commitments required at any point in the process--neither the client nor the consultant needs to be tied heavily into the long-term outcome of the project, since any particular portion of it should be able to stand alone... and the previous portion or the next could be implemented by someone else or not at all


• The client receives some deliverable benefit in relatively short, discrete intervals, rather than having to wait until the end of the project to recoup the investment. For the consultant, no long payout or convoluted performance measurement is required, and the actual value of work done can be received as soon as it is done


• Because the project is broken into discrete chunks, it can be pursued as resources allow and with little risk to either party. With lower stakes, there is both less incentive for a consultant to fail and less to lose if they do


• Since there is, at some level, an expectation of failure built into the project, everyone involved has the costs and means of dealing with the issue built in to the deal--resources are budgeted prior to knowing exactly what may or may not fail, and this again removes incentives for consultants to fail... they are already being paid for the "failure" and their profits are maximized therefore not by extending the job but by completing it as quickly and satisfactorily as possible so they can get out and use the time on other jobs

This isn't a universal panacea by any means, and it's no place for half-measures--a botched project with a few agile techniques isn't going to do you any good--but it's something that conventional wisdom shuns and therefore isn't being explored nearly as deeply as I believe it deserves.