Although prototyping is useful in any situation where a requirement is not clear, there are several reasons why prototypes are often disregarded as a valuable methodology in many software-development projects, for example:

• Cost-saving measures. Requirements prototypes are usually throw-away products and are not expected to evolve into the finished product (Robertson & Robertson 1999). It is therefore likely that project managers save on their development, especially when the role of look and feel and usability is underestimated or misunderstood, and stakeholders are used to textual descriptions of requirements.
• Form of contract. If an external IT supplier is assigned to design and code the software system, the production of prototypes is usually deferred until the specification sheet has been produced (Schrage 1999). The consolidated specification is usually necessary for forming a contract between client and supplier. It is unlikely that the supplier will start working before the specification is finalized.
• Delaying influence. Even if prototypes are created during early stages, the chance of them having significant impact on the consolidation of written requirements is very low. Depending on the complexity of the software that has to be built and factors such as time and budget, building a first prototype can take (the IT supplier) several weeks, or even up to a month (Schrage 1999). This is mainly due to poor responsibility assignment and excessive up-front processes. Results are not likely to be received until there is no longer any opportunity for extensive changes.

Consequently, software developers tend to produce first prototypes very late in the overall process, if at all, although well-established lifecycle models do recommend it for the earlier stages.