Negócio Arriscado (com Kiron Bondale da World Class Productivity)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa informático. Perdoem quaisquer erros tipográficos, pois o sistema automático não está correto a 100%.

Ben Aston:

Portanto, 15% dos projetos de TI têm derrapagens de custos de 200% e uma derrapagem do calendário de 70%. É assustador, não é? E talvez isso lhe seja familiar. A verdade é que os projetos são assustadores. Os projetos são inerentemente arriscados, e isso acontece porque estamos a provocar mudanças. Os projetos correm mal o tempo todo. E, enquanto gestores de projetos, somos o alvo mais fácil quando isso acontece. Por isso, deve ter medo. Deve ter medo de que os seus projetos falhem, porque quando tem medo, é muito mais provável que faça tudo o que for necessário para tornar os seus projetos menos assustadores. Por isso, continue a ouvir o podcast de hoje para descobrir como pode utilizar a gestão de riscos para tornar os seus projetos menos assustadores e conseguir dormir melhor à noite.

Obrigado por nos acompanhar. Eu sou Ben Aston, fundador do Digital Project Manager. Bem-vindo ao podcast DPM. Temos como missão ajudar os gestores de projetos a ter sucesso e ajudar as pessoas que gerem projetos a obter melhores resultados. Estamos aqui para ajudá-lo a elevar a sua gestão de projetos a um nível superior. Visite thedigitalprojectmanager.com para saber mais sobre a formação e os recursos que disponibilizamos através da adesão. Este podcast é-lhe apresentado pela Clarizen, líder em software de gestão empresarial de projetos e portefólios. Visite clarizen.com para saber mais.

Hoje junta-se a mim Kiron Bondale. Kiron é consultor sénior da World Class Productivity, que disponibiliza serviços de formação e consultoria. Geriu centenas de projetos diferentes. Tem uma vasta experiência em gestão de riscos, tendo publicado trabalhos em diferentes revistas, e também fala bastante sobre Agilidade. Por isso, vamos abordar esse tema no podcast de hoje. Muito obrigado por se juntar a nós hoje, Kiron.

Kiron Bondale:

Obrigado, Ben. É um prazer participar.

Ben Aston:

Estamos em 2020. É um ano novo. E estou curioso, Kiron: isso significa que haverá novidades para si relativamente ao que está a fazer com a World Class Productivity, nomeadamente no que diz respeito à sua formação e consultoria? O que há de novo para si?

Kiron Bondale:

Claro. O que há de novo para nós é que, no final do ano passado, como certamente sabe e os seus membros também saberão, o PMI adquiriu o Disciplined Agile Consortium, ou melhor, a sua propriedade intelectual. Existe bastante interesse por parte do PMI em integrar as suas ofertas, incluindo algumas das suas certificações. Assim, enquanto organização, vamos começar a disponibilizar cursos alinhados com o Disciplined Agile. Diria que se trata de um conjunto de ferramentas que consideramos uma excelente resposta para as empresas que pretendem avançar com uma transformação ágil. Portanto, diria que esse será o principal foco, pelo menos no primeiro e no segundo trimestre deste ano, tanto para mim como para a nossa organização.

Ben Aston:

Muito bem. E, relativamente à disponibilização dessa formação, pode dar-nos uma ideia de como é a sua formação?

Kiron Bondale:

Sim, claro. Existe uma oferta padrão do PMI chamada Disciplined Agile Lean Scrum Master. Diria que é um workshop com duração entre dois e quatro dias, dependendo da experiência e da formação dos participantes. Estamos a disponibilizá-lo num formato de três dias, abrangendo Lean e o próprio Disciplined Agile. O excelente desta formação é que dá aos formandos a oportunidade de fazerem gratuitamente uma tentativa nos exames de Certified Disciplined Agilist. Assim, de certa forma, faz o curso e tem uma oportunidade gratuita de obter a certificação.

Ben Aston:

E estou curioso quanto à sua opinião sobre este tipo de certificações Ágeis. Tenho a minha certificação de Scrum Master, que é obviamente um curso de dois dias, e a minha opinião é que se faz a formação durante dois dias e é divertido e interessante. Mas certificar alguém ao fim de dois dias parece-me talvez um pouco prematuro. Por isso, estou curioso — obviamente, é o senhor quem ministra a formação e não quer prejudicar demasiado o seu próprio trabalho —, mas diga-me: em que medida esta formação será diferente relativamente ao Scrum Master e qual é a sua opinião sobre certificações, particularmente no mundo Ágil?

Kiron Bondale:

Sim, é uma excelente pergunta, Ben. Na verdade, um colega meu e eu — um dos meus amigos virtuais no espaço da Agilidade e da gestão de projetos — tivemos exatamente esta conversa hoje mais cedo. Com a entrada do PMI nesta área das certificações Ágeis através do Disciplined Agile, estão a tornar uma área já muito confusa ainda mais confusa.

Ben Aston:

Sim.

Kiron Bondale:

Existem mais de 300 certificações no espaço ágil. O que gosto no que o PMI está a fazer é o facto de estar a posicionar-se bem: está a oferecer opções de certificação para todos os níveis de experiência. A que mencionei, Certified Disciplined Agilist, destina-se a pessoas que talvez tenham apenas a componente académica. Ainda não têm a componente prática.

Ben Aston:

Certo.

Kiron Bondale:

Mas se tiver alguns anos de experiência prática a trabalhar no domínio Ágil, poderá optar pela certificação Certified Disciplined Agile Practitioner. Em alternativa, poderá manter-se nas certificações originais do PMI e obter a PMI ACP, se tiver experiência suficiente para corresponder aos requisitos de formação.

À medida que avança para níveis cada vez mais elevados, existem também ofertas do Disciplined Agile destinadas a esses níveis. Se analisar a maioria das organizações bem estabelecidas que oferecem certificações, verá que tendem a ter este tipo de estratégia hierarquizada —

Ben Aston:

Sim.

Kiron Bondale:

… e é precisamente isso que o PMI está a fazer: oferecer uma opção dependendo do ponto em que se encontra. Penso que ninguém dirá que, só por ter o CSM, o CDA ou outra credencial ágil de nível inicial, já possui a experiência necessária para trabalhar numa equipa ágil ou apoiá-la. Mas, pelo menos, já consegue falar a linguagem. O passo seguinte é, sem dúvida, adquirir experiência prática; só então poderá considerar algumas destas credenciais de nível superior.

Ben Aston:

Sim. Muito bem. Portanto, as credenciais estão a mudar e o envolvimento do PMI no mundo ágil é também uma tendência emergente. Existem outras tendências importantes às quais irá responder em 2020 no mundo da gestão de projetos?

Kiron Bondale:

Penso que a outra grande tendência que nós, e praticamente todos os outros fornecedores de formação registados no PMI, estamos a acompanhar são as alterações que o próprio PMI está a fazer relativamente ao processo de certificação PMP. Como você e os seus membros provavelmente sabem, o exame PMP vai mudar no final de junho de 2020. Em conjunto com essa alteração, o PMI está a passar para um novo modelo de cursos de certificação, enquanto anteriormente os representantes do PMI podiam criar os seus próprios conteúdos e diferenciar-se com base na qualidade dos materiais que criavam individualmente.

O PMI está agora a avançar para um modelo em que será o fornecedor único dos materiais do curso. Assim, praticamente todos os representantes do PMI irão comprar os materiais ao PMI, ou licenciá-los junto do PMI, e disponibilizá-los. Todos os formadores terão de frequentar uma formação de certificação ou uma formação de instrutores através do PMI. A diferenciação passará sobretudo por fatores como o preço, mas também pelo valor acrescentado que cada fornecedor de formação registado conseguir disponibilizar para além do que o PMI oferece.

Penso que isto criará condições mais equilibradas e poderá afastar alguns dos operadores mais pequenos que se encontravam, diria eu, no nível inferior do espectro de qualidade. Mas, para algumas das organizações maiores, que fazem este trabalho há décadas e tinham materiais de elevada qualidade, foi um grande golpe. No nosso caso, uma decisão inteligente que tomámos há muito tempo foi, em vez de criarmos os nossos próprios materiais, estabelecermos uma parceria com um dos melhores fornecedores de materiais de preparação para o PMI e utilizarmos os seus materiais. Portanto, temos de decidir se continuaremos a fazê-lo ou se iremos trabalhar diretamente com o PMI e utilizar os seus materiais; pelo menos, não temos um investimento próprio que se tenha tornado inútil.

Ben Aston:

Sim. Muito bem. E, olhando para 2021, uma das tendências na gestão de projetos de que ouço falar cada vez mais são as ferramentas de gestão de projetos com inteligência artificial e a própria inteligência artificial assumir a gestão de projetos, tornando o gestor de projetos redundante. Lembro-me de ler um artigo do Gana sobre algo semelhante. Qual é a sua opinião sobre o aparecimento de ferramentas mais inteligentes e o seu papel na gestão de projetos, bem como sobre a forma como o papel do gestor de projetos está a mudar nesse contexto?

Kiron Bondale:

É uma excelente pergunta, Ben. E é um tema em relação ao qual tendo a ser bastante otimista quando se trata do valor da IA para a profissão de gestão de projetos. Há pessoas que dizem: “Em breve ficaremos sem emprego.”

Ben Aston:

Sim.

Kiron Bondale:

Eu vejo a situação de outra forma: a IA permitirá que os gestores de projetos sejam mais eficazes, porque, se analisarmos o trabalho de um gestor de projetos, existe uma distinção muito clara entre os aspetos administrativos do projeto e os verdadeiros aspetos estratégicos da gestão de projetos.

Ben Aston:

Certo.

Kiron Bondale:

Grande parte do trabalho estratégico de um gestor de projetos está relacionada com a interação com as pessoas, o envolvimento das partes interessadas e outros aspetos semelhantes. Mas, para se poder concentrar verdadeiramente nisso, é necessário encontrar uma forma de nos libertarmos da pesada carga administrativa.

Assim, tarefas como elaborar relatórios de estado, produzir relatórios, fazer previsões e outras atividades semelhantes são áreas em que acredito que a aprendizagem automática e a IA podem ajudar bastante. Também estabeleceria um paralelismo com Star Trek: na ponte da Enterprise, tanto na série original como na nova geração, o computador estava sempre presente e era extremamente inteligente. Mas nunca se via uma situação em que a tripulação humana ou alienígena deixasse todas as decisões nas mãos do computador.

Ben Aston:

Certo.

Kiron Bondale:

O computador estava presente como um recurso. Faziam-lhe perguntas, ele apresentava probabilidades e fornecia boas estimativas. Mas ficava-se por aí, e é isso que penso que a IA poderá fazer por nós. Atualmente, se uma empresa tiver realizado centenas de milhares de projetos, no futuro poderá ligar uma IA a esse repositório de informação dos projetos.

Poderia fazer-lhe uma pergunta: quantas vezes, nos últimos dez anos, ao executar projetos semelhantes, ocorreu esta situação? E quantas vezes o resultado foi favorável? Poderia obter respostas. Penso, portanto, que será uma excelente capacidade de apoio à decisão.

Ben Aston:

Sim.

Kiron Bondale:

Libertará os gestores de projetos de grande parte da pesada carga administrativa e aborrecida. Mas penso que também os libertará para se concentrarem muito mais nos aspetos verdadeiramente estratégicos da gestão de projetos, o que, para mim, se traduz diretamente numa proposta de valor mais elevada e numa maior satisfação profissional para os gestores de projetos.

Ben Aston:

Sim. E então, falemos dessas partes mais estratégicas da gestão de projetos. Que parte do papel considera mais estratégica? Está a diferenciá-la, suponho, da parte mais administrativa, sendo a elaboração de relatórios de estado um exemplo que mencionou. O que considera ser a parte mais estratégica do papel de gestão de projetos que nós, enquanto gestores de projetos, podemos começar a assumir e desenvolver mais, à medida que estas ferramentas começam a ganhar importância? Falou do papel que desempenhamos na comunicação e na colaboração; fale-me desse aspeto estratégico e de como o vê a evoluir.

Kiron Bondale:

Eu abordaria essa questão em quatro níveis. Existem quatro domínios diferentes nos quais penso haver uma enorme oportunidade, caso seja possível libertar o gestor de projetos da carga administrativa. O primeiro é o envolvimento geral das partes interessadas. Em qualquer projeto maior do que uma caixa de sapatos, haverá vários tipos de partes interessadas, e um gestor de projetos tem de manter contacto com elas com alguma regularidade.

É necessário compreender o que está a mudar do ponto de vista das atitudes, dos interesses e da influência. Essa é, por si só, uma oportunidade. Quanto melhor for o trabalho de compreender o que está a acontecer com as partes interessadas e de as envolver, maior será provavelmente a possibilidade de sucesso do projeto. Essa é a primeira área.

A segunda, diria eu, é o próprio caso de negócio. Um dos desafios é que um gestor de projetos pode ser envolvido numa fase inicial do projeto pelo patrocinador para ajudar a elaborar o termo de abertura. Assim, poderá ter uma boa compreensão do caso de negócio original do projeto. Mas, quando chega a altura de executar o trabalho e começam a surgir problemas, quando tem de arregaçar as mangas e mergulhar em tudo o que está a acontecer no projeto, por vezes perde de vista a questão principal: por que razão estamos a fazer este projeto e ainda vamos obter o valor esperado? Ainda vamos obter o retorno que esperávamos deste projeto? Isso pode, por si só, ser uma grande fonte de risco. Pode ter um projeto cujo âmbito está a ser entregue perfeitamente, dentro do prazo e do orçamento, mas, adivinhe: a proposta de negócio já não existe. Já não deveríamos estar a investir nesse projeto, e um bom gestor de projetos será a primeira pessoa a levantar a mão e dizer: “Penso que este projeto deve ser interrompido. Não vai gerar qualquer benefício.”

Penso que essa é outra área de oportunidade. A terceira está relacionada com a própria equipa: ajudar a desenvolver uma equipa de elevado desempenho e tornar as pessoas excelentes. Se utilizar a terminologia do Disciplined Agile, penso que existe uma grande oportunidade quando analisamos a atenção que tem sido dada nos últimos anos a temas como a segurança psicológica e a franqueza radical. Daniel Pink, com os três fatores abordados no seu livro Drive.

Ben Aston:

Sim.

Kiron Bondale:

Existe uma excelente oportunidade para um gestor de projetos enquanto líder servidor ou anfitrião de líderes, que é uma das novas expressões utilizadas neste contexto. No entanto, para isso, o gestor de projetos precisa de tempo. Precisa de ser libertado para poder passar esse tempo com a equipa e desenvolvê-la. Mais uma vez, penso que a IA pode ajudar o gestor de projetos nesse domínio.

A quarta e última área que vou mencionar — e esta é a que, na minha opinião, está diretamente relacionada com o nosso artigo — é a gestão de riscos. Um dos desafios que identifico, e que se aplica a todas as partes interessadas, é dizerem: “No fim de contas, o risco é incerteza. Existe uma probabilidade; pensamos que isto pode acontecer, mas também é provável que não aconteça. E, se não vai acontecer, por que razão devemos gastar energia com isso?”

Muitas vezes, vejo gestores de projetos seguirem esse mesmo raciocínio: “Sim, temos conhecimento destes riscos, mas tenho tanta coisa para fazer, tenho de produzir relatórios para todas estas partes interessadas e simplesmente não tenho tempo para me preocupar com riscos.” Ora, se conseguirmos libertá-los desse trabalho pesado, poderão começar a investir verdadeiramente algum esforço na compreensão dos riscos e na análise mais profunda dos mesmos. Sabemos que, em projetos de grande complexidade, a gestão de riscos é muitas vezes a diferença entre um projeto bem-sucedido e um projeto falhado. Por isso, permitir que os gestores de projetos se concentrem um pouco mais na gestão de riscos é, para mim, algo muito positivo.

Ben Aston:

Sim, é excelente. E é uma ótima transição para aquilo de que deveríamos estar a falar hoje: como gerimos os riscos. E as diferentes formas de abordar a gestão de riscos para garantir que os nossos projetos são mais bem-sucedidos. Voltando ao início, quero fazer uma recapitulação sobre a importância da gestão de riscos. E, Kiron, pode acrescentar algo. Uma das coisas que acabou de mencionar é que os projetos correm frequentemente mal porque não gerimos os riscos corretamente. Gerir os riscos de forma eficaz pode ajudar a evitar que aconteçam coisas negativas. E falaremos dentro de pouco sobre as diferentes formas de o fazer. Mas também mantém a equipa alerta.

Mantém a equipa e as partes interessadas conscientes de que as coisas podem correr mal e ajuda as pessoas, incluindo a equipa, a reduzir a probabilidade de acontecimentos negativos. Mantém as partes interessadas informadas, cria transparência e confiança, para que não existam grandes surpresas quando algo corre mal. Além disso, se fizermos uma boa gestão de riscos, ajudamos a construir a história do projeto.

Os nossos relatórios de estado são úteis, mas, quando utilizamos ferramentas como o registo RAID e mantemos um registo dos riscos, da incerteza ou da probabilidade de ocorrência de acontecimentos negativos, depois de termos registado essa informação e criado um histórico das decisões tomadas e dos resultados obtidos, conseguimos recordar o que aconteceu. Assim, quando as coisas correm mal, temos um rasto documental que, por vezes, pode ajudar-nos a não ficar na linha de fogo, quando a opção mais fácil é obviamente responsabilizar o gestor de projetos pelo fracasso de um projeto.

Kiron, no seu artigo falou de diferentes tipos de resposta aos riscos: evitar, transferir, escalar, mitigar e aceitar. Temos aqui algumas técnicas diferentes que podemos utilizar na gestão de riscos, mas como sabemos quando utilizar cada tipo de técnica? Pode indicar-nos alguns princípios que possamos seguir?

Kiron Bondale:

Claro, Ben. A gestão de riscos tem sempre de começar pela apetência pelo risco da sua organização. É necessário compreendê-la. Também é importante compreender a apetência pelo risco ou a mentalidade das principais partes interessadas sénior do seu projeto. Uma organização que tende a ter um elevado grau de aversão ao risco poderá inclinar-se mais para a prevenção do risco como estratégia padrão, em vez de optar pela mitigação ou aceitação do risco. Por outro lado, uma organização que opere num mercado dinâmico e muito competitivo, onde é necessário assumir riscos para ter sucesso, poderá estar menos inclinada a evitar riscos, porque, por vezes, evitar riscos significa dizer não a determinadas coisas. Poderá reduzir o âmbito de uma parte do projeto ou até cancelar um projeto para evitar um risco.

É por isso que precisa de compreender qual é a apetência pelo risco da sua organização, do patrocinador e de quaisquer outras partes interessadas sénior importantes. Depois de compreender isso, trata-se de analisar o risco em si. É aí que pode utilizar as suas ferramentas de análise qualitativa e quantitativa dos riscos e começar a avaliar, com base na forma como classificaria esse risco, qual é o grau de preocupação. É necessário compreender a probabilidade de ocorrência, o impacto nos critérios de sucesso do projeto e a probabilidade de conseguir detetar que o risco está prestes a concretizar-se. É preciso compreender todos esses aspetos e depois fazer uma análise de custo-benefício. Tal como acontece com a qualidade, deve fazer-se sempre uma análise de custo-benefício. O mesmo se aplica aos riscos.

Se houver uma probabilidade de 1% de perder 1 000 $, não quero gastar 1 000 $ para prevenir esse risco. Mas se houver uma probabilidade de 50% ou mais de perder 1 000 $, talvez faça sentido gastar algumas centenas de dólares para me proteger contra esse risco. É por isso que a análise de custo-benefício se torna realmente importante. Já vi os dois extremos. Já vi organizações que, devido ao setor em que operam, às influências regulamentares externas ou simplesmente à filosofia ou cultura da própria organização, são extremamente avessas ao risco.

Envolvem os seus projetos e equipas de projeto em tantas camadas de proteção que as equipas ficam praticamente paralisadas. Isso não é positivo, porque nunca conseguirá obter retornos elevados dos seus projetos se fizer pender demasiado a balança para uma estratégia de mitigação ou prevenção de riscos elevados. Por outro lado, também tenho visto empresas no extremo oposto, essencialmente ignorantes em relação aos riscos. Assumem todos os riscos e não parecem preocupar-se minimamente. Em que momento deixou de me ouvir?

Ben Aston:

Deixei de o ouvir quando estávamos a falar sobre os diferentes tipos de resposta aos riscos e lhe pedi para explicar que técnicas utiliza, basicamente.

Kiron Bondale:

Está bem, isso foi praticamente no início da minha explicação. Não há problema. Vou repetir. Ao analisarmos as diferentes respostas aos riscos, como referiu, existem cerca de cinco ou seis. Quando falamos de riscos negativos ou ameaças, é importante compreender qual é o perfil de risco e a apetência pelo risco da própria organização. É aí que deve começar. Se tiver uma organização extremamente avessa ao risco, a operar num setor ou domínio que tende a evitar riscos, isso poderá determinar a posição padrão, que poderá ser: “Sim, queremos evitar qualquer risco que nos preocupe.”

Ben Aston:

Sim.

Kiron Bondale:

Por outro lado, se estiver a analisar uma organização cujo perfil de risco seja: “Estamos num ambiente muito competitivo e temos de assumir riscos calculados para ter sucesso”, poderá estar menos disposta a adotar uma estratégia de prevenção do risco, porque evitar riscos muitas vezes significa dizer não a determinados elementos do âmbito que podem representar o maior risco, mas também a maior recompensa.

Começa por compreender qual é a apetência pelo risco da sua organização. Depois deve fazer a mesma pergunta ao patrocinador e às principais partes interessadas sénior: qual é a sua apetência pelo risco? Afinal, o risco é uma incerteza que importa. Se criarmos uma estratégia de resposta ao risco que não esteja alinhada com aquilo que as partes interessadas estão dispostas a tolerar, não obteremos a atenção necessária. Precisamos de fazer com que a comunicação sobre riscos seja relevante, para que cumpram aquilo de que necessitamos.

Depois de compreendermos as mentalidades e a apetência pelo risco da organização, podemos definir uma boa estratégia de resposta. Se compreendermos os detalhes do próprio risco — o potencial impacto nos critérios de sucesso do projeto, a probabilidade de ocorrência e a probabilidade de conseguirmos detetá-lo —, podemos considerar todos esses fatores qualitativos e decidir se queremos evitá-lo, mitigá-lo ou aceitá-lo. Um fator importante no planeamento da resposta aos riscos é a análise de custo-benefício.

Ben Aston:

Hum-hum.

Kiron Bondale:

Queremos garantir que estamos a tomar uma decisão de investimento sensata na resposta ao risco. Quando tento demonstrar o valor da gestão de riscos a partes interessadas que talvez não estejam conscientes da sua importância, utilizo sempre a analogia do seguro. Se comprar um automóvel de 40 000 $, provavelmente considerará razoável gastar algumas centenas de dólares por ano para garantir que o automóvel está protegido.

Ben Aston:

Certo.

Kiron Bondale:

Mas se a seguradora disser: “Para o seu automóvel de 40 000 $, vamos cobrar-lhe 10 000 $ por ano para o segurar”, penso que ninguém compraria o automóvel. Talvez nem sequer contratasse o seguro, porque o valor obtido com esse seguro não compensaria o custo da mitigação ou da redução do risco. Tem de existir uma análise de custo-benefício, tal como quando analisamos uma abordagem qualitativa à qualidade. O mesmo se aplica aos riscos.

Ben Aston:

Sim. Falámos da prevenção do risco, em que concordamos ou dizemos aos clientes: “Uma forma de evitar este risco é simplesmente não fazer essa parte arriscada.” Falámos da transferência, em que, por vezes, podemos comprar um seguro. Podemos fazer com que outra pessoa assuma esse risco, ou escalá-lo e dizer às partes interessadas: “Existe um risco elevado, com elevada probabilidade e elevado impacto; se continuarmos assim, algo vai correr mal e é necessário mudar.”

Também falámos da mitigação, em que tentamos evitar que aconteça algo arriscado. E falou da análise de custo-benefício: podemos gastar e investir dinheiro para tentar impedir que algo negativo aconteça. Também falou da aceitação do risco, quando dizemos: “Se este seguro custar 10 000 $, ou se tivermos de gastar 10 000 $ para impedir que algo negativo aconteça, talvez devêssemos aceitar que isso pode acontecer, porque não vale a pena gastar esse dinheiro.”

Kiron Bondale:

Exatamente. Mas há uma ressalva: existem riscos que simplesmente não queremos que se concretizem. Por exemplo, se estiver numa situação em que o exemplo clássico é o risco de o diretor executivo de um banco ir para a prisão, esse é provavelmente um risco que, mesmo que custasse algumas dezenas de milhares de dólares, talvez valesse a pena evitar. Ou, por exemplo, se houvesse más notícias na primeira página de um jornal nacional, uma organização provavelmente quereria evitar esse tipo de risco, se possível. Mas, deixando de lado esses riscos críticos, deve fazer sempre uma análise de custo-benefício, porque investir excessivamente nos riscos é tão prejudicial como investir pouco.

Ben Aston:

Certo. E falou em fazer esta análise de custo-benefício, mas relativamente à documentação que utilizamos enquanto gestores de projetos para gerir os riscos, o exemplo clássico é um registo RAID — um registo de riscos, pressupostos, problemas e dependências. Estes registos podem ter diferentes níveis de complexidade. Já vi alguns bastante complicados, com muita pontuação automática, em que registar cada risco demora talvez 20 ou 30 minutos. Qual é a sua opinião sobre os registos RAID, sobre o nível de complexidade que devem ter e sobre a forma de gerir os riscos em termos de documentação?

Kiron Bondale:

Defendo que a documentação da maioria dos projetos deve ser dimensionada e adaptada ao contexto do projeto que está a gerir. Se tiver um projeto pequeno, que ficará concluído em algumas semanas e envolverá três ou quatro pessoas, provavelmente precisará de muito menos documentação do que se tiver um projeto que envolva centenas de pessoas, fornecedores, subcontratantes e organismos reguladores externos durante alguns anos. Não existe uma solução única. É necessário dimensionar ou adaptar a documentação. Nas organizações que têm um modelo de nível empresarial, os próprios modelos devem ser escaláveis. Uma das formas mais fáceis de fazer com que as pessoas se tornem meros executantes de modelos é dar-lhes um modelo único e não lhes fornecer orientações sobre como o adaptar à complexidade de cada projeto.

Essa seria a primeira lição que daria. Em segundo lugar, é importante compreender que haverá informação no registo RAID ou num registo de riscos que é relevante para o gestor de projetos e para a equipa do projeto, provavelmente para mais ninguém. Depois haverá informação que pretende partilhar com um grupo mais alargado de partes interessadas.

Ben Aston:

Certo.

Kiron Bondale:

Lembre-se de que eu disse que o risco é uma incerteza que importa. Se sobrecarregarmos as partes interessadas com inúmeros pormenores sobre riscos, com vários campos relacionados com cada risco, ou com uma longa lista de centenas de riscos dos quais apenas três são realmente importantes, perderemos rapidamente a atenção delas. Normalmente, as equipas bem-sucedidas que conheço têm um registo de riscos com todos os detalhes necessários, mas, ao apresentar a informação sobre riscos às partes interessadas, simplificam-na.

Extraem a informação relevante e apresentam apenas aquilo que é significativo para essas partes interessadas. Utilizam uma linguagem adequada e transmitem as informações importantes de que necessitam para tomar decisões difíceis. Também é muito importante que o registo RAID, o registo de riscos ou qualquer outro local onde esteja a recolher a informação esteja atualizado. Tem de ser preciso e atual. Se consultar um registo de riscos e encontrar dados claramente desatualizados, que não foram revistos desde o início do projeto, toda a função de gestão de riscos perde credibilidade. Deixarei de lhe prestar atenção. É por isso que é tão importante que os gestores de projetos, não apenas no âmbito dos riscos, mas relativamente a qualquer informação que recolham e partilhem, garantam que, se vale a pena recolhê-la, também vale a pena mantê-la atualizada.

Ben Aston:

Sim. É um conselho sólido. Temos um registo RAID ou um registo de riscos. Vamos então falar sobre como o preenchemos. Muitas vezes, as pessoas sabem que existe um modelo que podem utilizar. Na verdade, como parte da adesão ao Digital Project Manager, temos um registo RAID com um exemplo e um modelo que pode ser utilizado. No nosso registo RAID temos um ID para cada risco, pressuposto, problema ou dependência. Temos um estado, datas, um nome, uma descrição, a probabilidade, o impacto, um plano de mitigação e ações. Depois atribuímos um estado para indicar em que ponto estamos. Atribuímos um responsável, mantemos um registo das decisões tomadas e registamos a data da decisão.

Temos, assim, um rasto documental dos riscos: quando foram identificados e o que lhes aconteceu. Explique-nos como utilizaria um registo RAID com a sua equipa. Enquanto gestores de projetos, tentamos escrever todos os nossos pesadelos e tudo aquilo que pensamos que pode correr mal no projeto, tudo o que é assustador. Mas falou do envolvimento das partes interessadas, e a equipa do projeto também é frequentemente constituída por partes interessadas. Como as envolve na gestão dos riscos ao longo do ciclo de vida do projeto?

Kiron Bondale:

Normalmente, o que faria seria tratar os riscos ao longo de todo o ciclo de vida, como referiu. No início do projeto, quando poderá ter apenas alguns participantes, o patrocinador, talvez o cliente e alguns responsáveis sénior, deve fazer uma primeira identificação e análise dos riscos. Depois, à medida que vai aprofundando o planeamento, deve voltar a analisá-los. A partir daí, recomendo considerar dois fatores desencadeadores. Por um lado, há uma revisão regular: queremos rever os riscos para identificar atualizações, perceber o que é novo e o que mudou.

Se nos reunirmos semanalmente com a equipa e as partes interessadas, talvez não seja necessário fazê-lo todas as semanas. Se o projeto for muito longo, talvez de duas em duas semanas. Nessa altura, abre o registo de riscos no ecrã e faz uma revisão rápida: houve alterações? Há novos riscos? O que pode correr mal e ainda não considerámos? O que pode correr melhor do que esperávamos? Registe essa informação e dedique 10 ou 15 minutos da reunião à sua análise.

Separadamente, sempre que um risco se concretizar, sobretudo um risco grave, e passar a ser um problema real, vale a pena parar e perguntar: “O que significa isto agora?” Talvez, se este risco se concretizou, existam outros prestes a concretizar-se. É preciso estar atento. Da mesma forma, se houver uma alteração no projeto, como uma alteração de âmbito, isso desencadeia uma revisão: alguns riscos podem deixar de ser válidos, mas outros podem ter sido introduzidos. Portanto, existem dois tipos de desencadeadores: um baseado no tempo, quando já passou algum tempo desde a última revisão do registo, e outro baseado em acontecimentos, como uma alteração, um problema importante, um marco significativo ou a conclusão de uma fase. Esse é um bom momento para rever os riscos antes de iniciar a fase seguinte.

Ben Aston:

Muito bem. Vamos falar sobre quando a gestão de riscos corre mal. Podemos discutir o que isso significa, mas onde vê a gestão de riscos a falhar? Falou que parte do processo consiste em construir a história para tornar o risco relevante e contextual para as partes interessadas, para que compreendam o impacto do acontecimento. Onde vê a gestão de riscos a falhar? Em que momento começa a desfazer-se?

Kiron Bondale:

Diria que existem dois exemplos, ou dois exemplos bastante comuns. Um deles é tratá-la como uma atividade pontual. Talvez exista uma exigência de governação que obriga a ter um registo de riscos, mas a equipa do projeto, o gestor de projetos e as principais partes interessadas não estão envolvidos no processo. Sabem que têm de preencher um registo de riscos, por isso fazem-no e introduzem alguns riscos genéricos que não são realmente específicos.

Ben Aston:

Certo.

Kiron Bondale:

Criam planos de resposta ao risco bastante genéricos, não os aplicam verdadeiramente, mas podem assinalar a caixa que pergunta: “Considerou os riscos do seu projeto?” Essa é uma forma de as coisas correrem mal.

Para mim, isso é praticamente o mesmo que não fazer nada. A outra forma de falhar é quando a equipa principal faz o trabalho de análise, identifica bem os riscos, analisa-os e cria boas estratégias de resposta, mas as pessoas responsáveis por implementar essas respostas deixam de cumprir o seu papel. Talvez os riscos não tenham sido apresentados de forma a captar a sua atenção, ou essas pessoas tenham demasiadas outras tarefas e não considerem que vale a pena investir na implementação das respostas. Mais uma vez, torna-se um exercício académico: recolhemos excelentes informações sobre os riscos, criamos estratégias maravilhosas, mas nada muda.

Ben Aston:

Sim.

Kiron Bondale:

Esse seria outro exemplo de falha da gestão de riscos. Talvez exista um terceiro: muitas organizações e equipas simplesmente não aprendem com o passado.

Ben Aston:

Certo.

Kiron Bondale:

Ao identificar riscos, pode utilizar o conhecimento especializado, consultores externos e estudos de caso para compreender o que pode correr mal e o que pode correr melhor do que o esperado. Mas uma excelente fonte de riscos é analisar os registos de problemas de projetos anteriores. Se teve projetos anteriores em que esses registos foram mantidos cuidadosamente e agora tem um projeto semelhante, é boa ideia consultá-los e perguntar: “Qual é a probabilidade de estes acontecimentos ocorrerem no nosso projeto e como poderemos evitá-los ou reduzir o seu impacto?”

Esse tipo de análise muitas vezes não é realizado. Portanto, não alargar suficientemente a pesquisa na identificação dos riscos é outra área de falha. Resumiria os problemas em três pontos: ou prestamos apenas um serviço aparente na identificação, análise e manutenção dos riscos; ou não atuamos sobre as respostas aos riscos; ou não alargamos suficientemente a pesquisa no momento de identificar os riscos.

Ben Aston:

Penso que isso é muito útil. Gostaria de aprofundar a questão do responsável pelo risco que não age ou não se envolve. Muitas vezes, pode existir relutância em assumir essa responsabilidade, porque, se o seu nome aparecer associado ao risco, passa a ter a obrigação de fazer algo: evitar o risco, mitigá-lo ou transferi-lo. É o seu risco. Contudo, observo uma tendência para as pessoas não assumirem os riscos ou, por defeito, para o gestor de projetos ser o responsável por todos eles. Como envolve as partes interessadas nos riscos e evita que o gestor de projetos seja o responsável por todos?

Kiron Bondale:

Pode responsabilizar o gestor de projetos por todos os riscos do projeto. Tudo bem. Pode até despedi-lo se esses riscos se concretizarem. Mas o gestor de projetos não é quem mais beneficiará ou sofrerá com o fracasso do projeto. É a organização. Por isso, a questão começa por saber se o projeto é valioso. Se for um projeto valioso, devemos pensar no risco como pensamos num seguro. Para conseguir que as pessoas assumam verdadeiramente os riscos, não as sobrecarregue com pormenores. Certifique-se de que os riscos apresentados são importantes e de que precisa realmente da sua ajuda. Quer que a organização preste atenção.

Ben Aston:

Certo.

Kiron Bondale:

Em segundo lugar, certifique-se de que foi feita uma análise suficiente e que as descrições dos riscos são claras. Torne-as tão específicas quanto possível e explique o que poderá causar a concretização do risco. Como saberemos que está prestes a concretizar-se? Forneça o máximo de informação possível. Faça a análise e prepare-se devidamente.

Se, além disso, os responsáveis pelas respostas aos riscos tiverem objetivos de desempenho anuais associados ao sucesso do projeto, terão algo em jogo. Se tiverem algo em jogo, vão querer garantir que o projeto é bem-sucedido. Muitas vezes, o problema da resposta aos riscos não é a informação ter sido apresentada de forma inadequada; é o facto de a pessoa a quem se pede que faça algo não ter qualquer interesse direto no resultado. Não lhe importa se o projeto é bem-sucedido ou falha. Está a pedir-lhe que utilize capital político, social ou financeiro para fazer a diferença no seu projeto. Isto remete para a capacidade do gestor de projetos para influenciar e persuadir esse tipo de partes interessadas.

Ben Aston:

Sim, isso é útil. Penso que todas estas sugestões foram muito valiosas, mas aquela que mais me marcou está relacionada com a construção da narrativa e com a necessidade de a tornar contextual e real para a parte interessada, para a pessoa que pode ser afetada pelo risco e cuja reputação também pode estar em causa. É importante tornar os riscos significativos. Uma das coisas que mencionou foi que a gestão de riscos pode falhar porque nos limitamos a cumprir formalidades. Copiamos e colamos todos os riscos do projeto anterior e não analisamos verdadeiramente as lições aprendidas ou os problemas anteriores. O que me marcou foi perceber que o envolvimento das partes interessadas é importante e que não devemos limitar-nos a cumprir formalidades. Devemos assumir o compromisso de gerir os riscos não apenas no início do projeto, mas como parte integrante de todo o ciclo de vida, o que nos ajudará muito mais a evitar que aconteçam coisas assustadoras.

Kiron, para alguém que pensa: “Mal consigo gerir riscos, nem sei realmente o que é um registo RAID”, ou para alguém novo na gestão de projetos que está a pensar em gerir riscos pela primeira vez, qual é a principal coisa que deve fazer corretamente para que a gestão de riscos funcione?

Kiron Bondale:

Torne-a relevante. É isso que importa. Pode registar mil riscos e mil dados sobre esses riscos, mas, se isso não for relevante, não importa. Prefiro que um gestor de projetos registe um ou dois riscos, mas consiga fazer com que as partes interessadas prestem atenção e ajam sobre eles. Isso mostra-me que existe um processo eficaz de gestão de riscos.

Para alguém novo na profissão ou a assumir o primeiro projeto, que queira acompanhar atentamente os riscos, é uma boa prática fazer uma retrospetiva em intervalos regulares e perguntar: o esforço que estamos a investir na gestão de riscos está a gerar o retorno esperado? As pessoas estão realmente a prestar atenção? As respostas aos riscos estão a ser implementadas? Estamos a observar uma redução do perfil de risco do projeto como resultado das ações que estamos a tomar? Se não, o que deveríamos estar a fazer de forma diferente? São estas as perguntas que gostaria de ver essa pessoa a fazer a si própria.

Ben Aston:

Excelente. Kiron, muito obrigado por se juntar a nós. Foi ótimo tê-lo connosco hoje.

Kiron Bondale:

Obrigado, Ben.

Ben Aston:

E você, o que pensa? Quais são as suas sugestões e estratégias para gerir riscos? Diga-nos nos comentários abaixo e conte-nos o que funciona e o que falhou consigo. Diga-nos como está a gerir os riscos. Se quiser aprender mais e progredir no seu trabalho, junte-se à nossa comunidade através da adesão ao DPM em thedigitalprojectmanager.com/membership para ter acesso à nossa equipa no Slack, modelos, workshops — incluindo workshops sobre riscos —, sessões de esclarecimento, livros eletrónicos e muito mais. Se gostou do que ouviu hoje, subscreva o podcast e dedique alguns minutos a deixar uma avaliação honesta do podcast DPM no Apple Podcasts. Adoramos os nossos fãs. Temos apenas algumas avaliações, embora saibamos que existem milhares de ouvintes, por isso passe por lá, atribua-nos uma classificação e diga-nos o que pensa. Até à próxima, obrigado por ouvir.