RSSBalance and agility in IT projects
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."
Scott,
While I cannot disagree with much of your analysis, you present a conundrum. On the one hand, agile pre-supposes small project chunks, since the entire mass cannot be known in advance. On the other hand, without evaluating the entire project up-front, then schedules, budgets, ROI and so on become meaningless.
Regardless of the difficulty, business project owners demand low risk and substantial upfront estimates before most projects will be approved for funding, and project managers must deal with that reality.
It’s a tough question, because at the end of the day, your left trying to predict the future and manage the unexpected, within a tight budget. Never an easy task, for sure!
Michael Krigsman
http://blogs.zdnet.com/projectfailures
Hi Michael.
As you said, no methodology presents a silver bullet, and that conundrum is exactly while agile isn’t globally applicable to IT projects… there are some that aren’t just the sum of their parts, such as infrastructure, or massive manufacturing systems, which have to be judged in whole before they can be started. On the other hand, if you do have a project which is amenable to being chunked out, then since each of those chunks in and of itself has to be worthy of completing based on the factors you mention, then it follows that the whole of them together also must be. If you have a whole lot of small projects that have good ROI, then that’s not going to go away when you stack them atop one another.
I see that as exactly the way to reduce risk and make estimates more viable. And fortunately, I think that SOA projects lend themselves to this approach, and as we see more of them come down the pipe, I believe that people will start to see the benefits of agility. The real conundrum may be how to decide whether or not your project CAN be chunked out or whether it must be more traditionally managed.