Diferenciando Requisitos, Restrições e Premissas

O que são os requisitos e qual a sua diferença em relação às restrições? Como determinar quais são as restrições de um projeto e quais são suas premissas? Essas são dúvidas usuais dos alunos dos cursos de gerenciamento de projetos da PM Tech^®.

Requisitos mal definidos e incompletos estão entre as principais causas de falhas em projetos, uma vez que estes são a fundação do escopo do projeto e do produto e a base do orçamento, do cronograma e do planejamento da qualidade.

Nesse artigo busco esclarecer o que são os requisitos, as restrições e as premissas, explico as diferenças entre eles e comento sobre sua descrição no termo de abertura e na declaração do escopo do projeto.

Requisitos

Os requisitos refletem as necessidades e as expectativas das partes interessadas no projeto, principalmente do cliente, incluindo as condições ou capacidades que estes desejam que sejam cumpridas pelo projeto ou estejam presentes no produto. Por exemplo, se um cliente necessita reduzir os custos de pós-venda, um dos requisitos pode ser de que o projeto inclua um sistema para diagnosticar problemas do produto remotamente.

O desenvolvimento dos requisitos inicia com a análise das informações contidas no termo de abertura, passa pela análise das partes interessadas e sai como resultado do processo “coletar requisitos”. Os requisitos devem ser analisados e registrados com detalhes suficientes para serem medidos, uma vez que vão ser a base para definir as alternativas de condução do projeto e se transformarão na fundação da EAP.

Alguns pontos importantes sobre requisitos:

• Requisitos originam-se das necessidades das partes interessadas;
• O termo de abertura pode conter requisitos do patrocinador, porém outras partes interessadas podem ter outros requisitos, que inclusive conflitam com os do patrocinador;
• Requisitos que não serão atendidos devem ser listados como “fora de escopo” na declaração do trabalho;
• O produto do projeto é feito para atender aos requisitos aceitos e então é validado contra esses requisitos;
• Sem requisitos do cliente, não se pode validar o produto (mesmo que se possa testá-lo).

Como garantir que tenhamos requisitos abrangentes e suficientes?

Cada requisito deve ter uma fonte ou origem (necessidade de negócio, cliente, legislação, etc.), um proprietário (alguém na equipe do projeto) e uma prioridade, baseada em seu impacto no projeto ou produto. Devem ser mensuráveis e testáveis. Sua descrição não pode ser ambígua (ou seja, devem ser escritos de uma forma que tenha apenas uma única interpretação). 

Restrições

As restrições são fatores internos e externos associados ao escopo do projeto que limitam as opções da equipe de gerenciamento do projeto. Em geral são requisitos obrigatórios, impostos pelo cliente ou pela organização executora, que são oriundos do registro de requisitos e são incluídos na declaração do escopo com destaque especial. Quando um projeto for realizado sob contrato, em geral as cláusulas contratuais também se constituirão em restrições.

Exemplos:

• O projeto pode usar somente recursos internos;
• O projeto de reforma deverá ser conduzido com o laboratório em funcionamento;
• O projeto deve ser completado em 12 meses.

As restrições (e as premissas) são usualmente descritas na declaração do escopo, saída do processo “definir o escopo” no Guia PMBOK®.

Premissas

Segundo o Guia PMBOK® 4ª ed. “Premissas são fatores associados ao escopo do projeto que, para fins de planejamento, são assumidos como verdadeiros, reais ou certos sem a necessidade de prova ou demonstração”.

Note que “premissa” talvez não seja a melhor tradução do termo original em Inglês “assumption” (suposição, hipótese, conjectura, pressuposto, ideia ou teoria que assumimos como verdadeira, ainda que sem comprovação).

Para seguir adiante sem informação absoluta, nós necessitamos fazer suposições e temos de “assumir” que algumas coisas são verdadeiras. Nós assumimos que já que o dia está ensolarado, não vamos precisar levar um guarda-chuva para o trabalho. Que o ônibus vai sair em determinado horário, então vamos para a parada nesse horário. Se esperarmos toda a informação estar disponível, talvez nunca iniciemos o projeto. Tipicamente assumimos que os recursos vão estar disponíveis, que os usuários conhecem seu negócio e que os recursos financeiros estarão disponíveis.

Frequentemente, as equipes de projetos validam as premissas como parte do seu processo de planejamento. Toda a premissa tem um risco associado, uma vez que a mesma pode não ser verdadeira e, ao mostrar-se falsa, pode causar um impacto no projeto. 

Dica: Em geral podemos descrever uma premissa iniciando a frase por “Parte-se do princípio que …” ou “Supõe-se que …”.

Exemplos:

• O funcionário José vai estar disponível para trabalhar nesse projeto;
• Serão disponibilizados cinco Analistas da Área de RH em período integral;
• O cliente disponibilizará até o dia 01/02/2008 toda a infraestrutura necessária para o desenvolvimento e instalação do sistema.

Termo de abertura vs. Declaração do Escopo

Note que, embora o termo de abertura e a declaração do escopo possam ter certo grau de redundância, ambos contendo requisitos para aprovação do projeto, estes são diferentes no nível de detalhe. As informações contidas na declaração de escopo devem ser detalhadas e progressivamente elaboradas. As informações contidas no termo de abertura podem ser de mais alto nível.

Espero que ajude. Um abraço.

Mauro Sotille

Mauro Sotille possui certificação PMP - Project Management Professional (desde 1998) e PMI-RMP (Risk Management Professional). Foi Mentor do PMI para o Brasil, Presidente do PMI-RS, membro do PMI Chapter Member Advisory Group, do PMI Board Volunteer Advisory Committe e da equipe que desenvolveu o Guia PMBOK®. Tem treinado profissionais e acompanhado organizações na implantação de cultura corporativa de projetos. Autor de livros sobre gerenciamento de projetos e professor convidado da Fundação Getúlio Vargas (FGV), já ministrou mais de 180 cursos de preparação para certificação PMP e CAPM que proporcionaram a aprovação de centenas de alunos. É Diretor da PM Tech, onde orienta profissionais na capacitação em Gerenciamento de Projetos.

Siga-me: