Dealing with Agile Requirements Uncertainty

PMI Southern Alberta Chapter

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.

ADVERTISEMENT

Continue reading...

Log In
OR
Sign Up
ADVERTISEMENTS

Information is not knowledge,
Knowledge is not wisdom,
Wisdom is not truth,
Truth is not beauty,
Beauty is not love,
Love is not music
and Music is THE BEST

- Frank Zappa

ADVERTISEMENT

Sponsors