Build an isolated prototype solution
Build an isolated prototype solution whose purposes are to understand requirements, to validate requirements with customers, to explore the cost and benefits of design decisions and, where necessary, to explore new technology.
You need knowledge to proceed on development, but requirements (or your understanding of them) are always changing. Requirements that are gathered once at the beginning of a development cycle with the hope that they can drive development are usually too ambiguous. You want to get requirements changes as early as possible. Designers and implementers must understand requirements directly, and for designers and developers to understand requirements implies that they must understand the implementation ramifications. New technology needs to be investigated before committing to design using it. For all of these concerns, one solution may be to build a prototype. There may be other solutions.
One of the traditional presuppositions for building a prototype is that it will be thrown away once it has served its purpose. This presupposition has its own presupposition that the prototype will not ‘get it right’ and the cost of putting it right will be higher than that of starting again, retaining only the knowledge gained. Modern techniques, especially ConstantRefactoring, have addressed the cost of change. If this is feasible, a better approach may be EarlyAndRegularDelivery.