Partindo da premissa de que o cliente tenha um total conhecimento das suas necessidades e por isso não solicite mudanças ao longo do projeto, então a equipe poderá fazer um bom trabalho de estimativa para que o escopo seja previsível. Correto? Não. Tendo em vista esse contexto, haverá ainda a dependência de que o cliente comunique todos os detalhes do seu processo para a equipe e que ela entenda com exatidão o que lhe foi transmitido pelo cliente. Sabemos que o cliente não expõe detalhadamente suas necessidades, já que elas possuem um alto número de detalhes que fazem diferença no processo de desenvolvimento. Mesmo considerando que todos os detalhes serão passados pelo cliente de maneira escrita, o desenvolvedor poderá interpretar o que leu de várias formas, e isso irá resultar em inadequações no processo de desenvolvimento.
Na grande maioria dos projetos de software, definir previamente um escopo de projeto de software, buscando obter seu prazo e seu custo, não possui qualquer validade, já que o cliente será enganado com prazos e custos irreais, e a equipe de desenvolvimento não terá noção exata sobre prazo, escopo e esforço necessário para desenvolvimento do software. É importante que o cliente saiba que fixar um escopo, na maioria das vezes, é inviável e poderá prejudicá-lo. Se mesmo assim o cliente optar por um escopo fixo, o mesmo estará assumindo que nenhum conhecimento lhe será acrescentado no decorrer do projeto e, além do mais, estará garantindo que não haverá mudanças no seu processo de negócio. Por isso, essa opção significa correr alto risco em relação ao software não atender as suas reais necessidades quando lhe for entregue.