Você conhece a força das restrições do seu projeto?

Uma restrição é algo que limita a liberdade de ação de um gerente na condução de um projeto. Limitações normalmente não são coisas muito agradáveis e podem afetar o desempenho de uma iniciativa. Seria interessante, portanto, que sempre conhecêssemos a fundo as restrições que nos são impostas, certo?

Imagine por exemplo o projeto que tem como entrega a realização da cerimônia de abertura dos Jogos Olímpicos. Será que alguém cogitaria a possibilidade da ocorrência de um atraso neste caso? Certamente não. Isto significa que há para este projeto uma restrição de tempo fortíssima.

Agora pense na seguinte situação: uma empresa do setor automobilístico contrata uma empresa de tecnologia para desenvolver um software para controle de alguma operação industrial. Além de esperar um software que atenda às suas necessidades, a contratante exige que a contratada siga um processo de desenvolvimento de software específico definido por ela. Em princípio esta é uma restrição do projeto. Mas seria esta uma restrição forte? Tudo depende do contexto e do motivo pelo qual ela foi imposta. Pode ser que a contratante tenha tido boas experiências com esse processo proposto e queira por algum motivo padronizar a forma como seus fornecedores produzem seus softwares. Mas pode ser também que alguém na empresa automobilística tenha ouvido falar que tal processo é bom e sem nenhum conhecimento de causa tenha estabelecido a restrição. Pra piorar, vamos assumir que a contratada dispõe de um processo de desenvolvimento muito melhor do que o imposto pela restrição. Será que é certo simplesmente aceitar a situação? Ou seria melhor tentar mostrar ao cliente que o caminho a priori escolhido por ele não é o melhor. Na segunda possíbilidade, (situação em que a escolha pelo processo imposto foi baseada em opiniões vagas) a restrição não tem bases “fortes” e poderia com um pouco de empenho ser eliminada para o bem do projeto.

Já vi também algumas restrições de tempo criadas de forma equivocada. Em um determinado projeto o sponsor, que era um cliente externo à organização, havia definido que o projeto deveria ser finalizado em 4 meses. A equipe fez o planejamento e chegou à conclusão de que o tempo mais adequado para o atendimento de todas as necessidades seria em torno de 6 meses. O sponsor não aceitou e o cronograma foi comprimido para se adequar à restrição de 4 meses. O problema é que a compressão pode gerar riscos para o projeto, que se materializados podem ter o efeito inverso: uma data fim ainda mais distante que a original. E foi o que acabou ocorrendo neste caso específico. Tempo final de execução: 9 meses. Mais tarde descobriu-se que a finalização do projeto em 4 meses não era uma restrição de fato. O sponsor queria apenas dar uma pressionada no fornecedor, porque achava que de outra forma o produto esperado demoraria demais para ser finalizado.

O grande problema é que normalmente informações sobre a verdadeira força das restrições não estão disponíveis facilmente. Não caem em nosso colo de graça. Para conseguí-las, é preciso que o gerente de projetos se dedique a entender a fundo o contexto que cerca o projeto. E que seja corajoso o suficiente para questionar e negociar aquilo que parece não fazer muito sentido, independentemente de quem tenha imposto.

Conhecer a força das restrições é bastante útil também para que decisões importantes possam ser tomadas no decorrer do projeto. Em uma situação extrema, em que custo, qualidade ou prazo terão que ser sacrificados, qual deles escolher? O ideal seria nenhum, mas em alguns casos sabemos que as coisas não são tão perfeitas assim.

Portanto, ao assumir um projeto, antes de aceitar tudo aquilo que lhe é imposto, analise, questione, argumente. Pode estar aí a diferença entre seu sucesso ou fracasso.