Stop Blaming Changing Requirements for Your Project's Failure
I’m curious to know how many of you reading are surprised by the results of a recent Forrester Consulting survey which found that “only 39 percent of business decision-makers believe their internal IT organizations have the ability to regularly deliver projects on time and on budget.” Is 39 percent higher or lower than you expected?
Your level of shock presumably has a lot to do with whether or not you’re currently an agile practitioner.
Forrester’s survey revealed that of those 61 percent who have little faith in their IT organizations, “56 percent cite ever-changing business and user requirements” and “50 percent say they are trying to do too much at once.” Is it fairly safe to assume that very few of these “business decision makers” surveyed have made a decision that involved not doing agile? It sure sounds that way to me.
Those who are practicing agile know all too well that it is by no means easy. And just because you’re "doing" agile doesn’t mean that you’re guaranteed to always deliver projects on time and on budget.
John Sonmez, author of the Simple Programmer blog, recently listed five ways that an agile project can fail just as easily as one developed under waterfall—or any other method. What I found fascinating about Sonmez’s list is that each possible way agile can fail matches up identically with one of the complaints of those presumably non-agilists polled in Forrester’s survey.
Sonmez' first cause of failure is “not having a product owner.” Thirty-four percent of those polled by Forrester complained about lacking “clear executive direction.” Sonmez points out how those not iterating or breaking things down will become burdened with wasted time and “fatlogs.” Quite likely that is exactly what’s occurring within the organizations of Forrester’s whopping 50 percent who are “trying to do too much at once”— an ill-advised action that often results in a quick road to frustration, burnout, and a project’s ultimate failure.
Customers often get a bad rap for their constantly changing requirements, but how surprised should you be when those changes appear? In an ever-increasing agile world, those who choose to blame their failure on change will surely deal with a new change—being relieved of those projects altogether as those customers take them to other developers who don’t blame change; they welcome it.
How does your organization respond to changing requirements? Are your teams and workloads organized in a way that welcomes change, or is there resistance and discouragement? Let us know in the comments section below.
