How do you produce requirements for an unknown solution? Prototyping is a slow and time consuming process, but in IT projects--especially software development--it is often the only solution that works.
Early communications is essential if you want requirements documentation success. Don’t enter requirements documentation without making these effective communications moves first.
We often see change as something that detracts us from the work we need to be doing to deliver requirements. But the truth is that if we don’t adapt the deliverables to changing situations, it's like we never gathered requirements in the first place--and we end up with a solution that doesn’t deliver.
Denying the voice of stakeholders, particularly at the beginning of the requirements process, poses considerable risk by creating situations where great product and service releases are marred by the redevelopment, correction and upgrade processes that follow.
|
"If you must play, decide on three things at the start: the rules of the game, the stakes and the quitting time." - Chinese Proverb |
