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!
