Dealing with Agile Requirements Uncertainty
Mike Griffiths is a consultant and trainer who help organizations improve performance through shared leadership, agility and (un)common sense. He maintains the blog LeadingAnswers.com.
Agile approaches are often used on projects where the end goals are not fully known or may change during the life of the project. This seems unusual to my engineering PM friends who manage the fabrication of facilities. To them, not knowing what it is you are supposed to be building or letting things change along the way is a sign of poor scope definition, requirements gathering and change control. I hear quips from them along the lines of: “You guys need some rigor and decent specifications, maybe then you could build IT systems that work and don’t go over budget!”
They are right of course, for their domain of defined repeatable projects--first establishing a well-formed scope definition and complete specification--is the way to go. However, many IT projects are not defined, repeatable endeavors, but instead design explorations into unchartered territory for that organization. The mix of technology has not been used that way before. Sponsors have a vision of the end state, but not a lot of specific detail. No matter how much upfront work is done, there seems a host of unknown issues that surface during the journey to the destination. Build/feedback cycles with adaptive plans and progressive elaboration of requirements is the way to deal with these inevitable uncertainties.
These intangible, unprecedented, emergent, evolving characteristics of IT …
Please log in or sign up below to read the rest of the article.
|
"Life is a great big canvas; throw all the paint you can at it." - Danny Kaye |
