olá a todos, sou um jovem gerente de projetos que está atuando na área de sistemas em TI. Minha equipe e eu estamos desenvolvendo várias coisas antes do prazo até, entretanto nos deparamos com as premissas e restrições em nosso sistema... temos a seguinte situação problema " a equipe terá como configuração dos computadores um processador i7, windows 7 e 3 gb de RAM" isso é uma premissa ou restrição... creio eu que é uma restrição pois eu estou dizendo que se algo tiver que ser desenvolvido em outro SO, será feito por terceiros pois minha equipe utiliza windows... Podem me ajuar?
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:
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:
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: clay_susini@yahoo.com.br
Comentários (8)
-
|196.46.76.xxx |27-06-2011 06:09:35 João Vicente Matamba - Relação Laboralconflitos nos ultimos 30 anos do sec. XX, ................
-
|187.0.216.xxx |25-10-2010 11:25:21 José da Silva - Retrição x PremissasSintéticamente posso dezer que:
Premissa está fora do escopo do produto, pois depende de terceiro ao projeto.
Restrição é uma condição data ao contratante do projeto para que o planejamento do escopo do projeto seja executado dentro das expectativas esperadas.
José da Silva - MBA em Projento pelo FGV e Administrador.
61 9997-5566
Gostaria de receber seu comentário a respeito das minhas definições, através do e-mail josesilva@cnc.com.br
-
|201.7.114.xxx |29-06-2010 10:33:35 Antonio Ricardo - Não concordo com uma parte."Premissas = Suposições + Ambiente externo ao Projeto"
Exemplo: Em um projeto de pequeno porte de desenvolvimento de sistema, posso ter a premissa de que minha equipe de desenvolvedores estará disponível 16 horas por semana para executar as atividades.
É um premissa? Sim, apesar de usar um tom afirmativo "estará", esta premissa será utilizada para efeito de planejamento de prazo e custo, mas pode não se realizar em virtude do surgimento de outras prioridades internas, compartilhamento de recursos com outros projetos, etc.
É ambiente interno do projeto? Sim. Pois as ações para garantir que essa premissa se concretize, e não comprometa o alcance dos objetivos, serão executadas pelo gerente do projeto.
E, como toda premissa, é fonte para a identificação de riscos (incertezas). Neste caso, o risco é a equipe não ter a dedicação de 16 horas semanais e comprometer o cumprimento do prazo e custo planejados.
Conclusão: Os conceitos de Premissas e restrições ge...
-
|189.125.38.xxx |20-07-2010 22:05:54 Clay Susini - Resposta ao Antonio RicardoAntonio Ricardo, obrigado pelo comentário. Com base no seu exemplo: existe trabalho dentro do projeto (declaração do escopo do projeto / wbs) para garantir que a equipe toda fique disponível 16 horas? Acredito que não. Sendo assim, conclui-se este fator não está no ambiente interno ao projeto, e sim externo. Reiterando o artigo, no seu exemplo, trata-se de uma premissa, pois manter as 16 horas da equipe não é algo que está declarado no escopo do projeto e não depende do ambiente interno. São ações externas ao projeto que afetarão os profissionais da equipe e não há "trabalho declarado ou atividade na wbs" para transformar essa premissa em restrição. Grande abraço!
-
|200.174.154.xxx |17-06-2010 16:38:38 Renato Borges - Premissa X RestriçõesÓtimo artigo. Ouvi meu professor falar na última aula sobre Gerenciamento do Tempo: premissa é definido pelo Gerente de Projetos. Restrições é definido pelo cliente.
Achei bem interessante e simples essa colocação.
Forte Abraço
http://qualidademanaus.sopixel.com.br
