Michael Krigsman over at ZDnet has a good article up discussing the predictability and prevention of project failures in IT riffing off of some of the basic principles of Agile Development. While this is a subject near and dear to my own heart, Michael has a different take on it and the article is well worth a read for CIOs and project managers of all stripes.

Essentially, Michael takes the tenets of brutal objectivity, end-user engagement, and early pruning and comes up with a number of factors which can influence IT project success, including feasibility, honesty, and transparency. He goes on to say that the earlier these factors can be weighed, the sooner potential failures can be averted.

But something I think that he misses is the role of the methodology in achieving these goals. Having previously stated his objection to agile approaches in IT projects it seems that he doesn't make the connection between the fact of rapid iterations of small project components (with the attendant risk of small failures, coupled with a willingness to rapidly adjust them system to deal with them) and the ability to judge the factors which he identifies as crucial. The most fundamental concept of agile methodologies is that you cannot predict things over the broad scope of major projects; drawing, then, from agile development to say that IT projects should have their scope defined and their ROI calculated misses the point that doing so is next to impossible at the outset. Although there are a substantial number of projects that fail because no one has taken time to run those basic numbers before commencing, there are also plenty where the attempt has been made to do so in good faith, but the outcome has been dismal simply because of the vagaries of developing large systems. The more complex IT projects become, the more they resemble the software projects that agile was developed to deal with, and the more applicable those lessons.

I can't disagree that brutal honesty, accountability, and closer relations with the project end-users and stakeholders are not very significant factors in project success, but simply saying it is so doesn't hand the prospective project leader a toolset for accomplishing any of them. They're well-known tenets of project management, clearly delineated in a text I happen to have close to hand, and hardly a mystery to anyone with any project management experience.

In fact, these things become difficult in large, traditional projects simply due to the time and scope involved. It is far too easy to brush things under the rug when they won't come to light until months hence; too difficult to hold anyone accountable on project teams that will churn over the years that might pass before the outcome is clear; impossible to maintain relations with stakeholders who have next week's work in mind and can't commit to clear discussions about next year's.

Those are the sorts of issues that the agile approach is designed to deal with. I'm not sure if Michael's post indicates a change of heart or simply a different perspective than I presumed him to have, but I'm glad to see the issue getting some more exposure.

For my part, I believe that the judicious use of agile approaches in IT management, something I call Agile Operations, can have real and positive benefits on the IT side of the house as well as for the development staff. To the extent possible, mega-projects should be broken down into stand-alone units for which the ROI, feasibility, and so forth can be adequately predicted; project teams should include users, and the duration of the project should be short enough so as not to preclude this by removing them from their normal duties for excessive periods; objective review by independent steering committees should be exercised to prevent pet project stakeholders from pushing limits. These are things that all follow more or less directly from agile concepts of rapid iteration, merciless refactoring, pair programming, and customer availability. If the jury is still out on Agile Development as a whole, I think these at least are fairly clear steps toward things that everyone can agree on... to quote Michael, "honest, transparent, and accountable IT implementations rarely fail."