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.
Minhas congratulações
Foram ótimas as suas dicas para preparar o meu canvas
Muito obrigado
Oi José Ricardo,
A Declaração do Escopo do projeto em geral inclui exclusões do projeto para ajudar no gerenciamento das expectativas das partes interessadas. A diferença é que as restrições são impostas pelo cliente (ou outros) e as exclusões são determinadas pela equipe do projeto.
Abs,
Mauro
Olá Prof. Mauro Sotille,
Podemos colocar o não escopo como uma restrição para o cliente ter ciência que temos consciência que há algo a mais, porém não fará parte do escopo do projeto?
Obrigado
Olá Marlon,
Obrigado. Esse e outros artigos podem ser encontrados em http://www.pmtech.com.br/artigos.html
Abraço.
Excelente artigo Mauro, conseguiste demonstrar de forma clara os conceitos de requisitos, restrições e premissas.
Parabéns!
Olá Mauro! Como sempre uma ótima leitura.
Como faço para obter cópias dos artigos? onde forma publicados?
Sucesso!
Caro Mauro,
José Finocchio, eu e mais dezenas de pessoas acabamos de debater o tema que você magistralmente resumiu:
http://www.linkedin.com/groupItem?view=&gid=1812399&type=member&item=117539972&commentID=83353629&goback=%2Egmp_1812399&report%2Esuccess=6_qqZww9BgRpLEAcA4ibK8xU7-FmkBJAfr76ACUxcZZQM6GVpnkg6-CRS2FmIGJd588tk-teScmI1aNKNu#commentID_83353629
As perguntas que Finocchio colocou foi: “As premissas devem ser ESCRITAS somente sobre o mundo EXTERNO ao projeto ? sobre o ambiente não controlado ou gerenciado pelo GP? Premissas devem ser escritas somente sobre o mundo fora do controle do gerente e da equipe? Existe exemplo de premissa dentro do ambiente de controle do GP? você pode dar exemplos?”
O que você acha?
Favor postar também sua resposta no Linked-in.