Diferenciando Premissas de Restrições
Quando o assunto é gerenciamento de projetos, constantemente observo pessoas confundirem premissas com restrições e vice e versa.
A confusão entre essas palavras ocorre cedo, logo no processo de iniciação, em um dos primeiros documentos do projeto: o Termo de Abertura (Project Charter). Esse documento, utilizado para o Sponsor (patrocinador) aprovar o início do projeto, requer que sejam expostas as premissas e as restrições. Apesar de cometido no começo do projeto, o erro de conceito é percebido comumente apenas no processo de execução, onde eventuais mudanças já requerem alto grau de esforço e validação política junto ao Sponsor.
Mas afinal: Qual a diferença entre premissas e restrições?
Basicamente premissas são hipóteses e restrições são deveres. Porém, essa definição não basta para apresentar claramente a diferença entre os dois termos. A chave da questão está na pergunta: “Quem executa o trabalho está no ambiente externo ou interno ao projeto?”.
Premissas são suposições dadas como certas sobre o ambiente externo ao projeto. Sobre elas é baseado o plano e a promessa de tempo e custo.
Podemos resumir a afirmação acima na equação:
Premissas = Suposições + Ambiente externo ao Projeto
Já restrições são limitações impostas internamente ou externamente ao trabalho executado pela equipe de projeto.
E a equação para a afirmação acima seria:
Restrição = Limitações + Ambiente Interno ou Externo ao Projeto + Trabalho Executado pela Equipe de Projeto
Para exemplificar, segue um organograma padrão, pertinente a quase todos os tipos de projeto:
{gallery}GP{/gallery}
Com base na visão deste organograma, vamos supor a criação de um projeto referente a uma luxuosa e grandiosa festa de casamento ao ar livre em um sítio no período da manhã. E na Declaração de Escopo do Projeto há a seguinte descrição:
A luz do sol será refletida nos prismas colocados à margem do lago situado atrás da capela, produzindo um arco-íris.
Para que esta ação ocorra, não há dependência única de trabalho executado pela equipe do projeto, mas sim de um fator externo ao controle do projeto: o clima. Se não houver sol, não haverá luz refletida nos prismas e consequentemente não haverá arco-íris. Conclui-se que se trata de uma suposição dada como certa referente ao fator clima que está externo ao controle do projeto. Sendo assim, trata-se de uma premissa. Essa premissa poderia ser declarada da seguinte forma no Termo de Início do projeto:
Haverá sol pela manhã incidindo no lago situado por de trás da capela.
Uma premissa nunca possuirá um termo de obrigatoriedade como a palavra “deverá”. Seria errado reescrever a frase acima da seguinte forma: “Deverá haver sol pela manhã incidindo no lado situado por de trás da capela”. Não é possível obrigar uma premissa a ocorrer, pois ela não está sob o controle do projeto, mas apenas sob monitoramento, consequentemente, não se pode impor a palavra “deverá”.
O fato de não escrever palavras que transcendam o sentido de obrigação em premissas pode parecer capricho, mas não é. Utilizar termos desse tipo pode ser um termômetro para saber se o que está sendo escrito é uma premissa ou uma restrição. Se realmente houver necessidade de inserir, por exemplo, um “deverá” na frase, este pode ser um indício de que a afirmação não é uma premissa, mas uma restrição.
Caso seja realmente obrigatório que uma afirmação aconteça, a atividade responsável para que esta afirmação ocorra deve estar mapeada na Declaração de Escopo do Projeto e incluída na WBS/EAP (Work Breakdown Structure ou Estrutura Analítica de Projeto), para então poder se “candidatar” a restrição. Reiterando: restrições são limitações impostas internamente ou externamente ao trabalho executado pela equipe de projeto. Quando um projeto, por exemplo, é feito sob contrato, as cláusulas contratuais geralmente serão restrições.
Mas continuando com o exemplo do projeto da festa de casamento, uma restrição poderia ser “Todos os garçons devem falar inglês”. Esse item pode totalmente ser atendido apenas com a o trabalho da equipe do projeto através de uma atividade como “Recrutamento e Seleção”, que deve estar mapeada na WBS e descrita na Declaração de Escopo.
E ainda citando o fator clima, caso o projeto incluísse a procura por um local para realização da festa, uma restrição poderia ser “O evento deverá ocorrer em um sítio no Estado de São Paulo, no município que apresente o menor índice de chuva no mês de maio dos últimos 5 anos”. Esta ação pode ser sanada através de uma atividade de pesquisa completamente passível de realização pela equipe do projeto. Não está sendo exigido que haja sol, mas apenas que o evento seja realizado em um local que historicamente possua a menor incidência de chuva no mês desejado.
Convém ressaltar que tanto Premissas como Restrições, além de serem expostas no Termo de Início, também devem ser descritas na Declaração de Escopo do Projeto ou em um documento específico. A diferença é que o trabalho responsável por satisfazer uma Premissa não existe na Declaração de Escopo, nem na WBS, pois não se trata de uma atividade que está sob controle da equipe do projeto, ou seja, não há trabalho dentro do projeto. Ao contrário, uma atividade responsável por atender uma Restrição deve estar na Declaração de Escopo e na WBS, pois é um trabalho da equipe do projeto.
Clay Susini Aquino Junior possui MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas e é Bacharel em Sistemas de Informação com Ênfase em Planejamento Estratégico pela Universidade Presbiteriana Mackenzie. É membro do PMI (Project Management Institute) e ministra palestras e aulas sobre Gerenciamento de Projetos, Metodologias de Projetos de Desenvolvimento de Software e Gestão Financeira.
Contato: [email protected]
Autor
-
Gerente de Programas e Projetos da BM&FBOVESPA, certificado Project Management Professional (PMP), MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas, Bacharel em Sistemas de Informação com enfase em Planejamento Estratégico pela Universidade Presbiteriana Mackenzie, membro do PMI (Project Management Institute) e do IFPUG (International FunctionPoint Users Group).
Todos os posts