> One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
Having worked with both this approach and agile, I'm not surprised by these results. However, I will also say that writing clear requirements is easier said than done - when those requirements are vague or of even mediocre quality it can very easily send a project off-course immediately.
Part of this stems from, in my view, a lack of accountability when it comes to waterfall approaches. If the BAs responsible for drawing up the requirements burn through time and budget that ultimately gets felt by the development team. It requires Engineering Managers to carefully vet those requirements to ensure they're appropriate start work, which results in a tremendous amount of back-and-forth.
Yep. And my favorite is when developers spend far too much time discussing the story point estimate, having long discussions about why something is higher or lower...and then not writing any of it down other than "3" or "5".
Having worked with both this approach and agile, I'm not surprised by these results. However, I will also say that writing clear requirements is easier said than done - when those requirements are vague or of even mediocre quality it can very easily send a project off-course immediately.
Part of this stems from, in my view, a lack of accountability when it comes to waterfall approaches. If the BAs responsible for drawing up the requirements burn through time and budget that ultimately gets felt by the development team. It requires Engineering Managers to carefully vet those requirements to ensure they're appropriate start work, which results in a tremendous amount of back-and-forth.