Prompted by some recent posts and the subsequent conversations over at Michael Krigsman's ZDnet Project Failures blog, I've dug in and written a lengthy treatise on consultants and incentives for failure in enterprise implementation projects on my blog Status.

I think that most of the observations made at Krigsman's blog, both in the articles and the comments, amount to fairly well-known but unspoken facts of the CIO/consulting relationship. The question I have, which I took a stab at addressing in the Status post, is why it is that we, as a profession, haven't come up with better approaches to addressing these issues?

The solution I am proposing (which I make no claim for as a universal or comprehensive solution, merely an approach with some potential) is the adoption of Agile development methodologies for managing these projects.


Briefly, I believe that some of the things that Adrian Sannier, CTO for ASU, was recently pilloried for could be used to help align the interests of consultants and implementors better with the organizations they are working with. I think that the shorter cycles, the emphasis on immediate utility in deliverables, and the built-in expectations for problems and failures (as well as the reduced scope of their affect, as per the more discrete deliverables) in the pricing model can, in some cases, help reduce the vulnerability of businesses to rapacious or malingering consultants.

I'm interested in other perspectives on the issue. I think that the discussion over at Project Failures pretty well illustrates the more conventional and shop-worn thoughts and attitudes about it, but I am hoping to get some alternative options from people, if possible. I'm well aware that the responses, if any, are likely to follow the same lines as Krigsman got. But I would welcome either well-reasoned critiques of the agile approach or some out of the box alternatives for accomplishing the same ends.