Pistas para Identificação de Riscos do Projeto

Identificar os fatores de riscos de um projeto nem sempre é uma tarefa fácil, especialmente quando o gerenciamento de riscos não faz parte da cultura de uma organização.

 

 

O plano de gerenciamento de riscos inclui a identificação dos riscos, a análise dos riscos identificados, a definição de estratégias de tratamento desses riscos e o controle dos riscos do projeto. O guia PMBOK, na sua 5ª. edição, defende que cada projeto deve desenvolver uma abordagem aos riscos que seja consistente e a comunicação sobre os riscos deve ser aberta e honesta. As respostas aos riscos refletem o equilíbrio entendido pela organização entre correr riscos e evitar riscos.

 

O plano de gerenciamento de riscos é iniciado pela identificação dos riscos do projeto. Nessa fase de identificação, não é feita a análise de riscos.  Aqui estamos buscando pistas para identificar os riscos. Após a identificação dos riscos o processo continua e passa para a fase das análises qualitativa e quantitativa dos riscos identificados. Mas que pistas são essas? É isso que veremos ao longo desse post. Entender essas pistas nos ajudará identificar os riscos, como parte do planejamento, e também a controlar esses riscos quando estivermos executando o projeto.

Assim sendo, nos parágrafos seguintes veremos algumas dessas pistas que nos auxiliam na identificação dos riscos do projeto.

Falta de apoio ou suporte da alta direção – o gerente de projetos deve pedir apoio e comprometimento da alta direção em situações específicas. Quando isso é negado, o gerente de projetos deve registrar isso como um risco.

Baixa qualidade das estimativas (por exemplo, estimativas de duração e custo) – uma estimativa que é feita na base do “eu acho que” gera um risco. Se a equipe não está confiante em relação a uma estimativa o gerente de projetos deve registrar isso como um risco.

Mudanças em excesso – muitas mudanças podem dar a sensação que o projeto está falhando em função de constantes acréscimos nos custos e atrasos no cronograma. Se na especificação dos requisitos do projeto há partes que só serão fornecidas mais tarde o gerente de projetos deve registrar isso como um risco.

Atitude negativa de stakeholders – uma atitude negativa de stakeholders importantes pode colocar obstáculos no progresso do projeto. Ao notar que existem conflitos ou falta de cooperação entre stakeholders o gerente de projetos deve registrar isso como um risco.

Disponibilidade de recursos – problemas com recursos (pessoal que deixa a empresa buscando novos desafios em outras empresas, pessoal que é demitido, novos e inexperientes colaboradores) podem atrapalhar o projeto. A perda de um especialista é sempre um risco. Se o gerente de projetos tem pessoas inexperientes na equipe, que precisam ser treinadas, deve registrar isso como um risco.

Problemas com o Design – os projetos criam produtos, serviços ou resultados únicos. Esses produtos, serviços ou resultados precisam ser concebidos no que se refere a forma física e funcionalidade. Essa concepção é o design. Um design de baixa qualidade é um risco para o projeto. O gerente de projetos deve anotar todos os componentes complexos (mais difíceis de fazer) e experimentais (menos conhecidos) do design, e registrar isso como um risco.

Problemas com a tecnologia – esse caso se refere a possível má qualidade nos componentes usados no projeto. Há vários fatores (estabilidade, disponibilidade, usabilidade, escalabilidade, etc) que podem comprometer tecnicamente um componente. Procure identificar e registrar os riscos de qualidade nos componentes que usar no projeto.

Problemas de integração – um projeto necessita integrar vários aspectos de uma organização como, por exemplo, processos, sistemas e cultura. Por isso, os problemas com a integração representam riscos para o projeto.  Muitas vezes o resultado do projeto tem impacto direto na organização e se a integração não é bem feita pode resultar em prejuízo. Isso ocorre quando, por exemplo, o projeto não alcança os custos orçados, por estouro de orçamento, e isso faz a organização ter prejuízo. Pode haver o caso de um sistema não funcionar como esperado após sua implantação e isso causar problemas operacionais para a empresa, e consequentemente mais prejuízos. Procure identificar e registrar os riscos na integração do projeto com os processos de negócio da organização.

Baixo engajamento dos stakeholders – o projeto necessita de apoio dos stakeholders mais importantes e isso é conseguido através de boa comunicação. Os stakeholders precisam saber, sem sombra de dúvida, o que exatamente o projeto está fazendo e que resultados serão obtidos em cada etapa. Os stakeholders precisam saber disso para não assumir falsas expectativas em relação ao projeto. É importante saber lidar com os stakeholders que tenham poder (porque se ficarem contra, podem atrapalhar o projeto) e interesse no projeto (porque serão, de algum modo, afetados pelo projeto). Se o gerente de projetos notar que algum stakeholder importante não está devidamente engajado ao projeto deve registrar isso como um risco.

Especificação de requisitos mal feita – em projetos vale a regra que diz que se entra lixo, sai lixo. Se os requisitos do projeto são mal feitos isso terá impacto direto na definição do escopo, ou seja, na definição do que precisa ser feito e entregue pelo projeto. O fato é que requisitos mal feitos poderão resultar em um detalhamento de escopo inviável ou desconectado da realidade dos negócios da organização, levando o projeto a falhar. Se o gerente de projetos notar que a especificação de requisitos está mal feita, resultando na inviabilidade de partes do escopo ou até mesmo de todo o escopo, deve registrar isso como um risco.

Qualidade na tomada de decisão – o processo de tomada de decisão pode ser um risco para o projeto. Se o gerente de projetos notar que a tomada de decisão no projeto é lenta, ambígua ou de má qualidade, deve registrar isso como um risco.

Viabilidade do projeto – o processo de identificação de riscos passa também pelo estudo da viabilidade do projeto. Esse estudo deve ser feito analisando se o projeto é viável de vários pontos de vista (financeiro, comercial, técnico, da disponibilidade de recursos humanos, etc).  Quanto mais complexo e caro é um projeto, mais crítica torna-se essa análise de viabilidade. Se o gerente de projetos notar que existem questionamentos ou dúvidas nos elementos usados na análise de viabilidade ou nos resultados encontrados deve registrar isso como um risco.

Problemas com compras – as compras em um projeto envolvem vários riscos. Por exemplo, existe o risco de não encontrar uma proposta aceitável que atenda os requisitos da RFP (“Request For Proposal”, ou Requisição de Proposta) elaborada para o projeto. Há também o risco de um fornecedor selecionado não entregar os pedidos para o projeto nos termos estabelecidos em contrato.  O conhecimento dos pontos fortes e fracos dos fornecedores será obrigatório no processo de identificação dos riscos e usado na classificação de probabilidade e impacto dos mesmos, quando for feita a análise qualitativa de riscos do projeto.

Problemas com a qualidade – o gerenciamento da qualidade e dos riscos é interligado. Afinal de contas, há o risco de aparecer defeitos no projeto ou, em outra medida, da qualidade alcançada não atender aos níveis mínimos desejados. Caso isso aconteça será necessário lançar mão de retrabalho, geralmente oneroso para o projeto. É evidente que se alguma coisa precisa ser refeita, isso implica em atraso no cronograma original do projeto. O gerente de projetos deve registrar os riscos relacionados aos problemas de qualidade nas entregas e pacotes de trabalho.

Falta de autoridade - as equipes de projeto, muitas vezes, não têm autoridade para completar o trabalho do projeto. Em muitos casos, espera-se que as equipes consigam influenciar para atingir os objetivos do projeto. Isto reflete a realidade dos negócios. Se o projeto usa uma equipe multifuncional, com pessoas que vêm de departamentos diferentes, é comum dizer que esse projeto está atravessando as fronteiras organizacionais. É óbvio que esse projeto dependerá muito, por falta de autoridade, do fator influência. Ter autoridade é dar uma ordem que será cumprida. Mas, se o projeto precisa influenciar para conseguir recursos, cooperação e prioridade, há sempre a chance dessa influência não ser suficiente para fazer acontecer o que precisa ser feito no projeto. Por conta dessa realidade o gerente de projetos deve registrar as situações de risco relacionadas com a falta de autoridade da equipe do projeto.

Problemas com a burocracia interna – a burocracia de uma organização é sempre um fator negativo para o projeto. A burocracia afeta a tomada de decisões. Se, por exemplo, o gerente de projetos consegue identificar que a burocracia da empresa poderá causar um atraso na aprovação do início do projeto, deverá anotar isso na sua planilha de identificação de riscos.

Mudanças organizacionais – planos de reestruturação organizacional, fusões e aquisições poderão tirar o projeto dos trilhos. Qualquer instabilidade na organização deve ser registrada pelo gerente de projetos como um risco.

Forças externas à organização – forças externas como, por exemplo, leis, regulamentos, mudanças de mercado, novas tecnologias, ações de concorrentes e ações de fornecedores, poderão, em maior ou menor grau, impactar o projeto. As forças externas não são controladas pela organização. Se o governo cria um novo imposto, isso pode aumentar os custos do projeto. Se o projeto precisa de mais tempo e tem que gastar mais dinheiro para atender um novo regulamento, isso afeta o projeto. Uma nova tecnologia lançada pela concorrência pode tornar o resultado do projeto obsoleto. Se um fornecedor informa que terá que aumentar seus preços para compensar a variação cambial relativa aos custos de matérias-primas importadas, isso pode onerar o projeto.  Em suma, se o projeto é sensível a qualquer uma das forças externas mencionadas, isso deve ser registrado como um risco.

Falhas no gerenciamento do projeto – se a sua organização, através dos principais gestores, decide que a metodologia de gerenciamento de projetos deve ser simplificada (com menos processos e documentação) isso deve ser registrado como um risco. Os processos do gerenciamento de projetos são importantes para auxiliar a garantir que tudo que precisa ser feito, seja efetivamente realizado. Por sua vez, a documentação serve de evidência para o gerente de projetos, quando alguém tentar mudar o que foi acertado inicialmente. Em outras palavras, se estiver registrado em um documento será bem mais difícil negar ou tentar mudar o que foi inicialmente combinado.

Esquecimento dos riscos secundários - os riscos secundários são o resultado de ações de mitigação e de transferência de riscos. O problema é que costumam ser frequentemente esquecidos. Por exemplo, digamos que um risco da organização ao executar uma atividade foi transferido para um fornecedor através de um contrato de preço global. Portanto, os riscos da organização foram transferidos e agora o projeto precisa lidar com os riscos do fornecedor.

Questões de aceitação – haverá sempre a chance de clientes e usuários rejeitarem o projeto. O projeto pode até mesmo criar o produto que atende aos requisitos, no prazo acordado e respeitando o orçamento. Todavia, se o cliente (ou usuário) rejeitar o produto criado pelo projeto, este será considerado falho. Se o gerente de projetos notar que existem questões latentes, incompreensões ou qualquer tipo de problema que possa levar o cliente (ou usuário) a rejeitar o projeto, deve registrar isso como um risco.

Falha comercial – se o projeto está criando um produto comercial para o mercado, como no desenvolvimento de um novo produto, haverá a possibilidade desse produto falhar do ponto de vista comercial. Por exemplo, se o produto criado pelo projeto não tem as características desejadas pelos clientes, ou ficou mais caro que o produto concorrente, ou usa componentes cujo nível de qualidade impossibilita o estabelecimento de um período de garantia superior ao do concorrente. Se o gerente de projetos notar que existem problemas que possam levar o produto a falhar comercialmente, deve registrar isso como um risco.

Bem, é isso aí! Até a próxima!