Vale ressaltar que uma auditoria que conclui com uma lista de requisitos de negócios é trimestral. O desenvolvimento do design técnico da solução quase sempre envolve cerca de 20% da solução, e o esforço total também leva um trimestre. No entanto, esses períodos não são determinados pelo tamanho da organização. Esses períodos trimestrais são projetados para se adaptar às mudanças do mercado. Em outras palavras, assumimos, por exemplo, um trimestre para análise de negócios e só então ajustamos seu nível de detalhe para cobrir apenas um trimestre.
Não, é uma abordagem iterativa-incremental. Preceder cada etapa de implementação com o design evita a prototipagem, que é muito mais custosa (os custos de mão de obra de uma equipe de desenvolvimento são maiores do que os de um único designer).
A próxima pergunta: um sistema monolítico de um único fornecedor, implementado em etapas, ou subsistemas dedicados e específicos de cada domínio, adquiridos e integrados? Implementações abrangentes (para uma parcela significativa das organizações) levam bem mais de um ano e, como mencionado no início, o período mais longo de relativa estabilidade no planejamento é o ano fiscal.
Considerando a situação descrita na Introdução, as condições operacionais de uma organização Ágil e os Custos, a conclusão é bastante óbvia: grandes projetos devem ser divididos em projetos menores. Na grande maioria dos casos, um ano fiscal é muito curto para um grande monólito. Consequentemente, a questão não é se dividir, mas como dividir o escopo do projeto. Lembre-se de que requisitos são condições, e estas mudam; portanto, diante disso, não é possível escrever uma especificação de requisitos para um grande projeto. O que resta? Concentre-se na estratégia e reconheça que o ciclo de vida do sistema é fundamental, não sua especificação precisa — impossível de desenvolver.