Arquivo da categoria: Riscos

1º Seminário de Gestão de Projetos do PMI-SE

Ocorreu no dia 24/11/2012 o 1º Seminário de Gestão de Projetos do PMI-SE na Faculdade de Negócios de Sergipe. O evento contou com a participação dos alguns membros da diretoria do PMI-SE e também de dezenas de profissionais atuantes em Gerenciamento de Projetos no estado de Sergipe. O presidente do capítulo abriu o evento com o anúncio da posse do novo Diretor de Eventos, Luciano Passos.

Leia o resto deste post

Anúncios

Resultado da Enquete – Na sua opinião, qual é a área de conhecimento mais importante do Gerenciamento de Projetos?

Análise

Pelo resultado da enquete é possível observar que a maioria dos leitores desse blog que votaram (28% – 27 votos), acreditam ser o Escopo a área de conhecimento mais importante do Gerenciamento de Projetos.  Isso deve-se ao fato de que um escopo mal definido, pode por em risco todo o sucesso de um projeto. Em segundo lugar, figura a área das Comunicações como sendo a mais importante com 25 votos (26%). Não basta ter um escopo bem definido, é preciso que os stakeholders tenham uma boa comunicação durante o decorrer do projeto. Saber o que comunicar, a quem, através de que meio é fundamental para garantir que as informações sobre o projeto cheguem as interessados de maneira adequada. Isso pode ser apoiado com a definição e uso da Matriz de Comunicação. Logo em seguida, a área de Integração aparece como a mais relevante obtendo 9 votos (9%) . À área de integração cabe a tarefa de articular as partes interessadas para que objetivos do projeto sejam atingidos. Mais atrás e não menos importantes, aparecem empatadas as áreas de Gerenciamento de Riscos e Gerenciamento da Qualidade com 8 votos cada (8%). Gerenciar os riscos do projetos, eliminando-os ou mitigando-os, é fundamental para evitar que o imponderável coloque em xeque o sucesso do projeto. Do mesmo modo, gerenciar a qualidade é garantir que o produto seja desenvolvido corretamente segundo suas especificações e dentro dos padrões exigidos pelo mercado, cada vez mais competitivo. Por fim, aparecem as áreas de Custos, Tempo e Aquisições com 6 (seis), 6 (seis) e 0 (zero) votos, respectivamente.

Gerenciando os riscos do projeto com a matriz de probabilidade e impacto

“Risco é um evento ou uma condição incerta, que se ocorrer, tem um efeito em pelo menos um objetivo do projeto” (PMBOK, 2008). Entende-se por objetivos do projeto as áreas de escopo, cronograma, custo e qualidade. Essas podem ser afetadas negativamente ou positivamente, a depender da natureza do risco. Achou estranho? Um risco afetar um objetivo do projeto de forma positiva??? Exatamente! Vamos imaginar a situação em que o tempo de duração de um projeto de construção de um shopping foi definido em 1 ano e orçado em R$2.000.000,00.

Devido à alta qualidade da equipe contratada, o projeto foi encerrado em 10 meses consumindo 80% dos recursos planejados. O impacto foi direto nos objetivos de custo e cronograma do projeto, porém o cliente ficou imensamente satisfeito pelos resultados alcançados. Investiu menos recursos e o produto idealizado irá começar a gerar valor mais rapidamente!

Por outro lado, os riscos negativos estão diretamente associados a impactos não desejáveis em algum objetivo do projeto. Por exemplo, o atraso na concessão de uma autorização ambiental para inícios das obras do shopping. Impacto negativo direto no cronograma do projeto.

Os riscos podem ter maior ou menor grau de impacto e probabilidade de ocorrência. Diante disso, se torna necessários priorizá-los a fim de aumentar o desempenho do projeto. É necessário se concentrar nos riscos de alta prioridade, porém sem ignorar os riscos com prioridade inferior. Estes, por sua vez devem compor uma lista de observação.

Mas essa análise de impacto e probabilidade dos riscos não é bastante subjetiva? Ora, afinal para mim um risco X pode ter um impacto ALTO no projeto, enquanto que, para outra pessoa esse mesmo risco é considerado apenas MODERADO. A fim de mitigar esse risco da subjetividade da análise, o PMBOK afirma que o estabelecimento de definições dos níveis de probabilidade e impacto pode reduzir a influência de parcialidade. Uma sugestão é a definição de uma escala de impactos para os quatro objetivos do projeto. Observe a figura abaixo.

As definições dos níveis de probabilidade e impacto podem ser adaptadas a cada projeto de acordo com o ambiente organizacional. Vale ainda ressaltar que tabelas semelhantes podem ser definidas para os riscos positivos do projeto.

Diante dos riscos a que qualquer projeto encontra-se exposto, torna-se necessário encontrar uma ferramenta que possilibite priorizá-los de forma, no mínimo, aceitável. É nesse cenário que surge a matriz de probabilidade e impacto. Elas especificam as combinações de probabilidade e impacto que resultam em uma classificação dos riscos como de prioridade BAIXA, MODERADA ou ALTA. Observe a tabela abaixo.

As células em cinza escuro com maiores valores representam alto risco, enquanto que as preenchidas com cinza médio são riscos baixos. As cinza claro representam riscos moderados. Por exemplo, um risco negativo com prababilidade de ocorrência estimada em 0,70 e impacto de 0,10 representa uma ameaça de valor 0,07, o que é considerada como MODERADA.

Através dessa ferramenta é possível ainda identificar áreas do projeto que sofram mais ameaças ou oportunidades. Para isso torna-se necessária a categorização dos riscos identificados no projeto, gerando assim uma estrutura hierárquica de riscos. Observe a figura abaixo.

_________________________________________________________________________________

Gráfico Burndown como ferramenta para avaliar riscos em Projetos Ágeis

O gerenciamento de riscos é uma disciplina fundamental utilizada durante todo o processo de desenvolvimento de um projeto. E você sabe por que, caro leitor? Porque, na verdade, tudo o que nós gerenciamos são riscos.  Vamos pensar um pouco: se preciso concluir uma tarefa no prazo estimado de um dia e planejo quais serão os passos necessários para concluir essa tarefa no prazo estabelecido, não estou gerenciando  meu tempo. Não se engane! Na verdade, o que você estou gerenciando é o risco de atrasar a conclusão daquela tarefa. Essa mesma linha de raciocínio pode ser utilizada em diversas outras situações.

Muitos acreditam que as metodologias ágeis ignoram completamente os riscos em um projeto. Nao é bem assim! O que acontece é que o manisfesto ágil aposta em valores que vão de encontro às crenças das metodologias tradicionais. Os riscos são vistos como inerentes aos projetos e são aceitos, mas nunca ignorados! Com suas pequenas iterações  e entregas constantes de produto potencialmente utilizável ao cliente, o time evita o maior risco que os projetos enfrentam: não entregar nada. Assim, as metologias ágeis buscam se antecipar à ocorrência dos riscos, o que prova que eles não são ignorados.

Hiren Doshi e Kane Mar publicaram, recentemente, alguns artigos sobre a análise do Gráfico de Burndown, apresentando que tipo de informações ou perguntas podemos extrair dele. Trata-se de “uma ferramenta importante para o acompanhamento do progresso de um time ágil e muitas informações podem ser extraídas do mesmo. Também podemos utilizá-lo para acompanhamento do projeto, produto ou releases” [HAZRATI, 2010].  A análise de Hiren Doshi foi baseada nas perguntas e no gráfico abaixo:

Em um gráfico de burndown eixo Y pode ter como unidade horas, semanas ou story points, enquanto o eixo X pode ser em dias ou sprints. É importante frisar que a unidade escolhida deve ser a mais adequada com a realidade de cada projeto ou organização, visto que cada unidade possui visões e objetivos diferentes.

“Burndown por horas e burndown por pontos tem propósitos diferentes!! Ninguém espera que um burndown por horas diga o quanto de valor foi entregue, mas apenas o acompanhamento do ritmo dirário do time. Os dois são importantes!” Alexandre Magno, CST

Podemos fazer uma análise do gráfico acima, o que nos trará subsídios para que possamos evitar que riscos futuros de projeto.

Observando a linha azul (linha 1) podemos visualizar um cenário não desejado. O time não conseguiu alcançar seus objetivos traçados durante a Sprint Planning, o que indica que o planejamento e/ou a execução não estão bons. Podemos citar algumas situações que podem contribuir para a construção deste cenário: planejamento de mais histórias do que a capacidade do time, alteração de prioridades durante o sprint ou uma falta de união do time. E quais são os riscos que este cenário apresenta?

  • Atrasos na entrega de partes potencialmente utilizáveis do produto ao cliente;
  • Desgastes com renegociação de prazos;

A linha roxa (linha 2) apresenta um cenário onde o time conseguiu atingir a meta, porém esteve longe do progresso ideal. A curva acentuada pode indicar que o time não atualizou suas estimativas de maneira adequada ou ainda que hisórias incompletas foram retiradas da sprint. Isso demonstra um time comprometido com o prazo, porém pouco interessado com a qualidade do processo e do produto gerado. O principal risco envolvido nesse cenário é a insatisfação do cliente com relação ao que foi prometido e o que realmente foi entregue. A consequência imediata pode ser desgaste na relação com o cliente, bem como eventuais quebras de contratos.

Por fim, a linha verde (linha 3) demonstra um cenário ideal, onde planejamento e execução foram bem feitos. O time é auto-organizado e bastante adaptável a mudanças. Porém, como diria o poeta,  nem tudo são flores! Sempre existe algo que pode ser melhorado e isso deve ser feito durante a Sprint Retrospective, que envolve uma análise dos pontos positivos e negativos apresentados pelo time durante a Sprint.

Bem o objetivo desse post foi demonstrar que o Gráfico de Burndown pode ser uma ótima ferramenta de apoio na gestão de riscos de projetos ágeis.  E para tanto, ela deve ser utilizada de acordo com as necessidades que o negócio ou organização necessita. Caso o leitor queira se aprofundar um pouco mais no assunto, existe um artigo publicado na LOCAWEB que faz uma outra análise sobre o Burndown focada em mudanças na sprint. Há também um outro artigo muito interessante de Kane Mar, Seven common Sprint Burndown graph signatures, onde ele separa o Burndown em sete categorias apresentando as nuances desses diversos cenários. Vale a pena conferir!

DOSHI, Hiren. Sprint Burndown says a lot about your scrum team... PracticeAgile  Software Development, 2010.
HAZRATI, Vikas. Analisando gráficos de Burndown. InfoQ, 2010.
Mudanças de Sprint. LOCAWEB, 2010.
MAR, Kane. Seven common Sprint Burndown graph signatures. 2006.

A subjetividade da análise de riscos em Gestão de Projetos de Software

Quero começar esse post propondo um desafio a você, caro leitor. Analise os riscos de um projeto de construção de um software para a locadora do seu bairro. Faça essa análise listando em uma tabela os riscos associados ao projeto com suas respectivas probabilidades de ocorrência e impactos potenciais. Proponha também soluções atenuantes para tratar esses riscos. Em seguida, peça para que um amigo do seu trabalho faça o mesmo. Mesmo que vocês listem os mesmos riscos, muito provavelmente a análise de probabilidade, impacto e soluções atenuantes feitas pelos dois será diferente. Isso ocorre porque todos os estágios do processo, incluindo as técnicas utilizadas, envolvem subjetividade. “Sempre há incerteza, necessidade de jugalmento e considerável espaço para parcialidade e inexatidão” [REDMILL, 2006].

O ILGRA (Interdepartmental Liaison Group on Risk Assessment), comitê de avaliação de riscos do Reino Unido, afirma que a análise de riscos é “uma ferramenta para fazer extrapolações a partir de dados estatísticos e científicos” até chegar a “um valor que seja aceito como estimativa do risco ligado a uma atividade ou evento em particular”. Portanto, penso que devemos tratar os resultados da análise de riscos como estimativas que buscam nos aproximar mais da realidade, como também nos auxiliar na tomada de decisões.

Fig. 1 – Processo de análise de riscos.

Apesar de possuir um workflow bem definido  (Fig. 1), a análise de riscos sempre permitirá a geração de diversas interpretações para um mesmo estudo de caso. Retornando ao software de locadora, poderíamos identificar o seguinte risco de projeto: queda do servidor que hospeda a aplicação. Esse é o típico risco que, no meu ponto de vista, é PROVÁVEL de acontecer e impacto CATASTRÓFICO, sendo necessário atenuá-lo procurando hospedagens alternativas. Porém para outro analista de negócio o risco poderia ser IMPROVÁVEL de acontecer! É aí onde mora a subjetividade da análise.

Embora possa ser subjetiva, a análise é uma ferramenta valiosa, e as normas de segurança modernas exigem que ela seja realizada [REDMILL, 2006]. A subjetividade presente na análise de riscos, apesar de ser uma vulnerabilidade, é também um dos seus pontos fortes, pois todo esse processo envolve racioncício e poder de investigação. Sendo assim, esse processo impulsiona o desenvolvimento cognitivo do ser humano.

Caso o leitor tenha interesse em conhecer mais detalhes sobre o assunto sugiro a leitura de um excelente artigo publicado no QSP (Centro da Qualidade, Segurança e Produtividade). Disponível em http://www.qsp.org.br/analise_riscos_artigo.shtml.

Referências:

REDMILL, Felix. Análise de riscos: um processo subjetivo. Centro da Qualidade, Segurança e Produtividade. 2006.
UK-ILGRA. United Kingdom Interdepartmental Liaison Group on Risk Assessment, Use of Risk Assessment within Government Departments, 1996.