Buy-in from management (or the funder) is key. They need to understand that more than 50% of the schedule may be taken by the documentation process. This is no

Buy-in from management (or the funder) is key. They need to understand that more than 50% of the schedule may be taken by the documentation process. This is not Agile nor Scrum, by any means. Answering the hard questions will be agonizing. E.g. - I once spent 3 hours with a UI/UX dev/designer working out the state machine for the key feature of a commercial product. She was frustrated working through the process - i.e. "Can't we just start with something!". And we were literally perspiring from thinking so hard. I explained that multiple versions of the state machine running at the same time was a bad idea. We persevered and that piece of code never had to be modified through the product lifecycle. Prototyping features to vet user acceptance is quite common and recommended. Pick a prototyping language unsuitable for production ;) That way prototypes can't "accidentally" be turned into production software. Consider reading "Toward Zero-Defect Programming" (1st Edition) by Allan M. Stavely.