Diferenciando Requisitos, Restrições e Premissas

Transcrição

1 Diferenciando Requisitos, Restrições e Premissas Author : Mauro Sotille Date : 4 de junho de 2018 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. (adsbygoogle = window.adsbygoogle []).push({}); Requisitos Os requisitos refletem as necessidades e as expectativas das partes interessadas no projeto, 1 / 7

2 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. 2 / 7

3 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. Premissas presumem que o que você está planejando ou confiando é verdadeiro, real ou certo. Por exemplo, seu projeto pode exigir que alguém tenha habilidades especiais de programação do departamento de TI. Sua suposição é que essa pessoa estará disponível quando necessário e exercerá sua habilidade na atividade que você designar. Documente a suposição de que essa pessoa estará disponível quando necessário. 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: 3 / 7

4 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 Você desejará verificar e validar essas premissas ao longo do processo de Planejamento e sempre que necessário durante a Execução e Controle do projeto. As premissas devem ser examinadas, visando garantir que estes dados não sejam tendenciosos e possuam precisão. Tomemos um exemplo: Imagine que você vai para a guerra. Qual o maior risco que você corre? Se você julga que o mais crítico é ser alvo da ação do inimigo, veja abaixo a estatística do Departamento de Defesa dos EUA: Perdas do Exército dos EUA em Conflitos II Guerra Coréia Vietnam Iraque Acidentes 56% % % % Fogo Amigo1% 1% 1% 5% 4 / 7

5 Ação Inimiga % 55% 45% 20% Fonte: Departamento de Defesa (EUA) Ou seja, historicamente os Americanos têm sofrido mais perdas de vidas humanas em acidentes do que pela ação do inimigo. Então não se deixe levar enganar por suposições equivocadas. As premissas identificadas devem ser testadas quanto à estabilidade da suposição e consequências no projeto se a premissa for falsa. Claro que nem sempre os dados, ou sua fonte, são confiáveis. Desse modo, suposições alternativas, que possam ser verdadeiras, deverão ser identificadas e suas repercussões nos objetivos de projeto deverão ser testadas. (adsbygoogle = window.adsbygoogle []).push({}); 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. 5 / 7

6 Mauro Sotille 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 6 / 7

7 Powered by TCPDF ( da PM Tech ( 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. 7 / 7