…Or I Can Cancel the Project

Maybe it has occurred to you already that the opposite of requirements deducing is seeking explicit requirements. I agree. This does not mean you should hold out for 100 percent accuracy. Projects naturally progress by way of progressive elaboration. That is the requirements may provide answers for all the questions a team can ask, but things can change. This is acceptable — even expected, as change management plans are a best practice. But this should not be an excuse to accept fuzzy ansers. All answers must be explicit.
In addition, requirements must be unambiguous, so that a tester, developer, and all stakeholders will have no doubt about the meaning of any given test’s result.
To acheive the two qualities, explicit and unambiguous, the requirements gatherer must have a certain frame of mind and level of discipline. The frame of mind is like a busy house painter who gets instructions to perfectly match the color of the room’s curtains only to find out the curtains have not yet been selected. Maybe he should provide some curtain samples. Not good. Perhaps inquiring repeatedly would be good leadership. Bad idea. Maybe he could pick the curtains! Absurd! I think you’ve got it! The right frame of mind is wait until there is some certainty that the client or business representative will have complete requirements before the Design milestone, and then start the project.
About the level of discipline? Simply have the courage to cancel the project! In other words, don’t try to deduce requirements that are fuzzy.

Advertisements

About Bruce

Please see my LinkedIn profile: https://www.linkedin.com/in/certified-scrum-professional-scrum-master-bruce-bartram-563b915
This entry was posted in Requirements. Bookmark the permalink.