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, seja no em um documento próprio que as descreve, seja no termo de abertura ou na especificaçã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 em documento próprio, que contém as restrições e premissas, ou na especificação do escopo, saída do processo “definir o escopo” no Guia PMBOK®.
Premissas
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.
Suposições podem incluir qualquer um dos seguintes:
- Disponibilidade do membro principal do projeto
- Desempenho do membro principal do projeto
- Habilidades do membro principal do projeto
- Tempos de entrega do fornecedor
- Problemas de desempenho do fornecedor
- Precisão de uma data do cronograma do 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/2021 toda a infraestrutura necessária para o desenvolvimento e instalação do sistema.
Validando as premissas
Perdas do Exército dos EUA em Conflitos
II Guerra 1942-45 |
Coréia 1950-53 |
Vietnam 1965-72 |
Iraque 1990-91 |
|
Acidentes | 56% 1.007.704 |
44% 77.108 |
54% 270.608 |
75% 1.406 |
Fogo Amigo | 1% 15.839 |
1% 1.943 |
1% 4.678 |
5% 86 |
Ação Inimiga | 43% 776.105 |
55% 97.198 |
45% 229.239 |
20% 366 |
Fonte: Departamento de Defesa (EUA)
Termo de abertura vs. Especificação do Escopo
Note que, embora o termo de abertura e a especificaçã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 especificação de escopo devem ser detalhadas e progressivamente elaboradas. As informações contidas no termo de abertura podem ser de mais alto nível.
Especialista em gerenciamento de projetos, programas, PMO e riscos. Com 25 anos de experiência em gerenciamento de projetos, foi responsável por mais de 50 projetos em diversos países. Atuou em empresas como Hewlett-Packard, Saab Sweden e Dana. É Diretor da PM Tech (www.pmtech.com.br), onde fornece capacitação profissional e consultoria a organizações na implantação bem-sucedida de cultura corporativa de Projetos. Foi Mentor do Project Management Institute (PMI) para o Brasil, Presidente do PMI-RS e membro da equipe que desenvolveu o Guia PMBOK® e outros guias. Certificado pelo PMI como Project Management Professional (PMP) desde 1998, Risk Management Professional (PMI-RMP) e PMO-CC, é autor de livros sobre Gerenciamento de Projetos, Escritórios de Projetos (PMO) e Certificação PMP. Doutorando em Administração de Empresas, possui MBA em Administração, pós-graduação em Computação e graduação em Informática e em Engenharia Mecânica. É professor convidado junto à Fundação Getúlio Vargas e outras instituições. Entre em contato comigo clicando aqui ou siga-me nos links abaixo.