RETREATING FROM REQUIREMENTS
Stakeholders are resisting taking responsibility for their area of influence when it comes to program, project and product requirements. I see it every day and have been challenged to come up with a solution to this dilemma. My gut tells me it is because they are being rewarded for NOT making decisions. They are being allowed to focus on their wants, and they are not being challenged to filter those wants into actual needs.
I believe that the primary culprit, the reason this is happening more and more every day, is a direct result of the misuse of Agile techniques that then reward this type of behavior. Specifically, I am seeing requirement prioritization techniques wind up in the verbiage of the actual requirements. Words like "Must have", "Should have" "Could have" and "Won't have" (Moscow) are being written into the requirements themselves as opposed to being used as a way to prioritize the next round of enhancements. These are making "requirements" into "options", allowing stakeholders to never have to make real decisions on the tradeoff between scope, time and costs.
It is causing a massive shift to "activity" and away from "productivity" as developers are becoming real-time "proto-typers" as opposed to business analysts working those issues out with the stakeholders, forcing decisions and delivering requirements that are actually needed by the organization.
The solution is that the business analyst must push back against wants of the stakeholders and use effective communication techniques to extract the actual needs usually hidden deep within the wants. An easy approach is if the stakeholder isn't willing to pay for it, he doesn't need it. Anything given for free is worthless to the recipient.
The word "shall" shall be in every requirement, or it is not a requirement, and the word "No" shall be added to the Business Analyst's tool kit.