Confusão com Premissas, Riscos, Requisitos e Restrições?
Autor: Armando Terribili Filho da IMPARIAMO®.
Os temas premissas, riscos, requisitos e restrições geram dúvidas, e por vezes, erros entre estudantes e profissionais da área de gerenciamento de projetos. Mesmo com a expansão dos cursos de pós-graduação em gerenciamento de projetos, mesmo com a realização frequente de congressos estaduais, nacionais e internacionais na área, mesmo com o crescente número de profissionais certificados em gerenciamento de projetos é inacreditável a confusão que ainda se faz com esses quatro conceitos básicos.
Os conceitos de “premissas”, “riscos”, “requisitos” e “restrições” independem de técnica, ferramenta ou metodologia, sendo os mesmos para Cascata, Ágil, Lean, Six Sigma, PRINCE2 ou Prism.
Pior ainda, estudantes e profissionais experientes têm a definição textual desses quatro conceitos na “ponta da língua”, porém quando vão para a prática, não sabem distingui-los. Desta forma, a proposta deste artigo é conceituar cada conceito, confrontar e exemplificar com o objetivo único de esclarecer e informar.
Premissa versus Requisito
A primeira confusão que se faz é “premissa” com “requisito”. A 7ª. edição do Guia PMBOK® apresenta como sendo PREMISSA “um fator do processo de planejamento considerado verdadeiro, real ou certo, sem a necessidade de prova ou demonstração” (PMI, 2021, p. 250) e para REQUISITO “uma condição ou capacidade que deve necessariamente estar presente em um produto, serviço ou resultado para atender uma necessidade de negócio” (p. 252).
Desta forma, quando se fala em “festa para 50 convidados” trata-se de um “requisito” e não de uma “premissa”, como é usual encontrar esse tipo de erro em trabalhos estudantis. Outro requisito para este projeto seria: oferta de produtos sem glúten e sem lactose.
As premissas, por sua vez, devem ser apresentadas no Termo de Abertura do Projeto (ou similar, como Canvas, por exemplo) para que o Executivo do Projeto ou Comitê responsável pela aprovação do projeto analise e verifique se as premissas apresentadas são aceitáveis ou não, pois se uma premissa não se mostrar verdadeira no transcorrer do projeto, acontecerão problemas no plano do projeto, que podem comprometer sua execução/conclusão.
Seria exemplo de premissa para a festa: não haverá briga alguma. Isto representa que isto é assumido como verdade para o projeto, ou seja, se isso não se mostrar verdadeiro (ocorrer alguma briga), o projeto terá problemas de continuidade, pois nenhuma ação foi prevista de forma antecipada para evitar ou minimizar a ocorrência. Evidentemente que novas premissas surgem durante o projeto, devendo ser avaliadas com critério.
Premissa versus Risco
RISCO é “um evento ou condição incerta que, se ocorrer, provocará um efeito positivo ou negativo em um ou mais objetivos do projeto” (PMI, 2021, p. 253). Assim, um risco é algo que não ocorreu, mas que pode ocorrer. Para os riscos identificados deve-se analisar a severidade (em função de probabilidade e impacto), a fim de se determinar a prioridade dos riscos. Para cada risco pode-se ter respostas distintas; por exemplo, para riscos negativos pode-se ter cinco abordagens diferentes: prevenir (evitar), mitigar (a severidade), transferir, escalar ou aceitar.
Assim, pode-se tratar as premissas como riscos, para que tenham ações previamente planejadas caso a premissa não se mostre verdadeira no transcorrer da vida do projeto. No nosso caso, ao invés de se colocar como premissa “não haverá briga alguma na festa”, pode-se colocar o risco de “ocorrer briga na festa”. Com isso, o plano do projeto deverá contemplar ações para combater esse risco.
Resumindo: a “premissa” tem uma postura “passiva” (nada será feito), enquanto o “risco” tem uma postura “ativa” (algo será feito, mesmo que a resposta seja “aceitar”, pois neste caso, o risco foi analisado e a decisão por aceitar o risco foi tomada de forma individual ou coletiva).
E por falar em riscos, é oportuno que na própria definição do risco contenha (sempre que possível) o “gatilho” do risco, ou seja, quando se sabe que o risco virou realidade. Ao invés de apresentar o risco como “baixa adesão à festa” (o que seria baixa adesão?), deve-se optar por “adesão inferior a 70% do total de convidados”.
Restrição versus Requisito
A definição de RESTRIÇÃO contida no Guia PMBOK® é “um fator limitador que afeta a execução de um projeto, programa, portfólio ou processo” (PMI, 2021, p. 252). O erro comum é confundir o que é uma restrição de projeto com um requisito. Em geral, as restrições de projeto são de prazo (entrega) ou de custos (orçamento), ou seja, não se pode concluir o projeto após uma determinada data (por exemplo, abertura da Copa do Mundo em 12/06/2014 em São Paulo) ou não se pode gastar mais de um determinado valor.
Retornando ao nosso exemplo da festa, li em um trabalho de um grupo de estudantes, o projeto que tinha como restrição “os convidados só poderão entrar ao local do evento com convite”. Isso não é uma restrição do projeto, mas um requisito de execução. Assim como a oferta de produtos sem glúten e sem lactose, que comentamos há pouco, é também um “requisito” e não uma restrição do projeto.
Nota: neste momento de constante variação do valor do dólar norte-americano frente ao real, esse assunto pode ser tratado em projetos em premissas, riscos e/ou restrições. Como premissa, caso se queira assumir que “o dólar não terá variação superior a 10%, por exemplo” (nada será feito, mas se a variação exceder 10%, o projeto terá problemas financeiros); como risco, podemos citar “dólar poderá ter variação superior a 10%” (neste caso, que providências serão tomadas: antecipação de pagamento, contrato em real, etc.) ou como restrição “projeto tem orçamento máximo de 50 mil dólares, convertido no câmbio de uma determinada data”.
Para finalizar…
Mesmo que se confunda os conceitos, o importante é registrar e analisar criteriosamente as “premissas” para uma tomada de decisão segura; identificar e tratar os “riscos” com respostas compatíveis e deixando alguma reserva de contingência; conhecer e gerir as “restrições” orçamentárias e de prazo; e finalmente, registrar os “requisitos” do produto/serviço a ser gerado pelo projeto, preferencialmente com “critérios de aceite” quantificáveis, verificáveis e, claro, realistas. Mas o tema “critérios de aceite” é papo para uma outra conversa…
Referência
PMI – Project Management Institute. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®). 7. ed. Pennsylvania: Project Management Institute, 2021.
Notas:
- As definições de premissa, risco, restrição e requisito não sofreram alteração alguma da 6a edição (2017) para a 7a edição do Guia PMBOK (2021).
- É permitida a reprodução desse artigo, desde que citado o autor e a fonte (Impariamo® Cursos e Consultoria).