Principais Categorias de Riscos

Abaixo descrevemos algumas das áreas que devem ser averiguadas (ou pelo menos visitadas) para verificar se existem alguns riscos escondidos ao longo de todo o projeto. Pode funcionar como um embrião para a criação de um Registo de Riscos para utilizar em projetos ou uma lista de questões para colocar  em reunião de gestão de risco.
Então aqui vai:

Riscos relativos ao Âmbito – Deslizar potencial do âmbito porque os requisitos do projeto não estão definidos com clareza. Foi bem definido o critério de performance? Estão definidas todas as condições limite? Onde começa e acaba o trabalho? Foram definidas as responsabilidades de todas as partes nas diferentes fases do projeto? Foram definidos os procedimentos de gestão da mudança do âmbito? 

Riscos relacionados com o Plano e o Esforço – O deslizar do âmbito é um risco de grande dimensão para o plano e o custo, mas estimativas de qualidade pobres são também um facto significativo. A falta de experiência anterior. Conhecimento experimentado da área de atividade, falta de adequadas revisões e verificações são as causas para estimativas inexatas. Ser pessimista faz-nos ganhar pontos e devemos quase ser paranoicos quando se trata da estimação do projeto. O otimismo mata, muitas vezes!

Riscos relacionados com Assunções – Será que definimos com clareza todas as assunções do projeto na especificação de trabalhos? E elas cobrem todos os aspetos importantes e as fases do projeto? Já foram documentadas as atividades a realizar se uma assunção se comprovar como errada e evolui para ser um risco para o projeto? Já fez a revisão com o cliente / sponsor as assunções e as contingências para cada uma? Todas as assunções, num projeto ideal, devem ser registadas e visitadas em cada relatório de status e revisão de projeto

Riscos relacionados com Dependências – O projeto está dependente de stakeholders múltiplos como, por exemplo, cliente / sponsor, fornecedores, empreiteiros, agências externas, etc. e para cada dependência irão existir riscos associados. Teremos de garantir que todas as dependências são documentadas e que: estão registadas as entregas que devem ser realizadas por cada parte? Garanta que as linhas de tempo para as entregas de cada parte estão claras para todos e comprometidas? E mencionou neste compromisso qual é a contingência se se materializar o risco e o compromisso não é alcançado pelo stakeholder? Todas as dependências devem ser registadas e visitadas nos relatórios de status e nas revisões do projeto. Alguns exemplos destes riscos são – atraso do fornecedor, problemas de entregas, questões com empreiteiros, atrasos do cliente, atrasos de envio, etc.

Riscos relacionados com Constrangimentos – Quase todos os projetos têm algum tipo de constrangimento. O exemplo deste constrangimento pode ser limitados recursos para a execução, elevado custo dos produtos envolvidos, tempo de execução muito apertado, condições apertadas de extensas de garantia, etc.

 

Riscos relacionados com a Tecnologia – A tecnologia selecionada pode colocar riscos em dependência das suas limitações. Isto é especialmente verdade se a tecnologia é recente e pouco comprovada ou não é conhecida se for necessário suporte técnico. A limitação da tecnologia pode ainda inibir a interoperabilidade futura entre sistemas. A mesma tecnologia pode colocar problemas se estamos ainda a funcionar com versões antigas e o fornecedor passou a novas versões. A obsolescência eletrónica de equipamentos é um risco de grande dimensão quando tratamos de os embeber no desenvolvimento do produto muito especialmente se necessitamos de garantir o suporte destes produtos por longos anos.

Riscos relacionados com os Critérios de Aceitação – Uma causa importante de preocupação para o gestor de projeto está na definição no contrato de critérios de aceitação vagos ou pouco claros. Este também é um especto muito difícil de definir nos estágios iniciais do projeto quando se define a especificação do trabalho. Deve preparar um plano de teste da aceitação logo que os requisitos estejam fixos e a arquitetura de alto nível esteja realizada. Em alguns projetos esta importante questão só é tratada já tarde no projeto e esto deixa este exposto a um risco inaceitável.

 Riscos da Regulação – A equipa de projeto tem de avaliar cuidadosamente os requisitos regulatórios e de certificação pra o produto e avaliar o seu impacto nos colaboradores do projeto, no desenho do produto, e no orçamento e tempo de realização do projeto. Se nada foi feito então estamos a enfrentar um risco maior, que deve ser regularmente acompanhado. Este tipo de riscos pode ter um alto impacto no projeto e refletem-se no custo e no tempo com impactos significativos na satisfação do cliente / sponsor.

 Riscos relacionados com Pessoas – Estes incluem conflitos, falta de competências, experiência, moral, motivação, relações da equipa, etc.

 Riscos relacionados com a Experiência e as Competências – A disponibilidade de conhecimentos sobre a atividade pode ser um requisito importante em muitos projetos. Este conhecimento especializado pode ter a ver com a indústria ou com os domínios de tecnologia. O projeto pode necessitar destes peritos para desenhar um sistema que seja de confiança, que passe nos testes de certificação e que satisfaça as necessidades do utilizador final. Se estes conhecimentos especializados são necessário então desenvolve-se uma dependência e um risco associado. Um conflito com este tipo de especialização pode debilitar o projeto.

 Riscos Políticos – Não podemos negligenciar este importante aspecto em qualquer projeto. Será que o projeto tem o compromisso adequado dos mais importantes apoios? E o sponsor do projeto será que ele tem o suporte e o financiamento da gestão? Quem é que sofrerá o impacto do projeto? E a sua colaboração é necessária durante a execução? Que precauções devem ser tomadas se algum stakeholder importante da organização cliente se recusar a cooperar? Quem é que deverá o cliente contactar se quiser levantar uma escalação? Foi criado um ponto de contacto entre a organização da equipa de projeto e a orgânica da organização cliente?

 Riscos relacionados com a Garantia – Diferentes contractos têm diferentes cláusulas. O plano do projeto deve ter em consideração e planear para a os termos da garantia definidos para este projeto. As cláusulas de garantia, numa visão ideal, deverão descrever o tipo de suporte que será fornecido ao cliente / sponsor durante a fase de garantia. Não é anormal vermos cláusulas de garantia por múltiplos anos e estas colocam grande risco. Como é que se retém o conhecimento da equipa por este período de forma a cumprir os compromissos? Como se mantém as licenças das ferramentas durante este período? Como se enfrenta a obsolescência das ferramentas vitais e do equipamento?

 Riscos relacionados com Penalidades – Muitos contractos incluem cláusulas de penalidades relacionadas com a performance da equipa de projeto. As estimativas iniciais devem ter em conta estas penalidades potenciais. Pode ser necessário entrar em linha de conta com a potencial perda de rendimento devido a penalidades de atraso criando uma margem adicional de contingência.

 Riscos relacionados com a Qualidade – O que é que pode ir mal no que respeita à qualidade do produto? Os exemplos para pobre qualidade são pobre performance, interface difícil de usar, produto mal desenhado, reduzida confiança, etc. ajuda definir os parâmetros críticos para a qualidade para o produto logo cedo, como parte do âmbito e, em seguida, medir a qualidade do produto contra estes critérios.

 Risco de Mercado – O produto foi construído mas o mercado coloca riscos significativos se o produto tem má ou errada funcionalidade, qualidade pobre, custos elevados, é difícil de usar, não passa nos testes de certificação, é difícil de produzir, é difícil de manter ou é atrasada a sua introdução no mercado.

 Desastres Naturais – Estes riscos são muitas vezes ignorados pelos gestores de projeto porque lhes parecem estar para além da sua esfera de influência. Mas estes riscos devem ser registados no planeamento de grandes contratos e programas. Os planos de resposta ao risco devem ser documentados e em posição para que a equipa possa responder na eventualidade de ocorrer algum desastre. O propósito é minimizar o dano tanto quanto possível e por essa forma não é possível realizar a eliminação total do risco. A mitigação deste tipo de riscos são a diversidade geográfica, uma gestão robusta do conhecimento e documentação atualizada, para garantir um mecanismo de comunicação efetiva que possa em tempo sincronizar todos no mesmo propósito.

 

Melhorar a PREVISIBILIDADE do projeto

A previsibilidade do projeto consiste em prever com precisão o resultado de um projeto com antecedência suficiente para que seja possível identificar pontos de problema, tomar ações corretivas e manter o projeto em andamento.

 Para um portfólio de projetos, a ideia de previsibilidade pode ser expandida para todo o conjunto de projetos. Nesse contexto, a previsibilidade do projeto é aumentar a consistência e minimizar as surpresas num grande número de projetos.

Tradicionalmente, quando os líderes do setor procuram determinar o sucesso do projeto em todo o portfólio de projetos, concentram-se na variação dos resultados. No entanto, a variação não é um preditor confiável, pois mostra apenas a diferença entre custos reais e planeados e o cronograma. (De fato, a variação é aceitável em percentagens menores.)

Em vez disso, a previsibilidade do projeto concentra-se na pontualidade das informações num ciclo do projeto - quando mudanças prováveis ​​no resultado são identificadas.

No setor de engenharia e construção, por exemplo, estima-se que 98% dos megaprojetos excedam o orçamento em mais de 30%. Quanto disso pode ser evitado prevendo as ultrapassagens anteriores e resolvendo-as rapidamente?

PORQUE É IMPORTANTE A PREVISIBILIDADE DO PROJETO?

Criar processos e sistemas que melhoram a previsibilidade do projeto é crucial para o sucesso de uma organização de várias maneiras.

As previsões oportunas fornecem tempo suficiente para corrigir o curso, aumentando a probabilidade de atingir metas e reduzindo a variação dos resultados. A resposta a uma previsão preocupante pode ser descodificar alguns requisitos, modificar casos de negócios existentes ou até desfazer o projeto. No entanto, os líderes seniores anteriores têm a oportunidade de tomar difíceis estas decisões, melhor para a organização - isso pode levar a uma economia significativa de custos, além de um maior retorno sobre o capital empregado (ROCE) e economia de custos de oportunidade.

Outro motivo pelo qual a previsibilidade do projeto é importante é a credibilidade organizacional. Atrasos crónicos e excedentes de custos podem ter um impacto negativo na perceção da empresa. Para os empreiteiros em particular, quanto pior for prejudicada a reputação, mais difícil será obter projetos futuros. Se os problemas persistirem por algum tempo, pode até reduzir o valor da companhia e levar à queda de uma organização.

A previsibilidade garante que as organizações sejam conhecidas pela sua excelência na execução - não por apagar incêndios urgentes.

Os pilares da previsibilidade do projeto

Atingir a previsibilidade do projeto requer uma sólida base de boas práticas. É um processo contínuo que exige comprometimento de longo prazo, dos principais executivos a todos os funcionários da cadeia. Também requer incentivo e uma cultura de tomada de decisão baseada em dados.

Aqui estão os quatroelementos básicos da previsibilidade do projeto:

1. Gestão de Portfólio

O objetivo da gestão de portfólio de projetos (PPM) é identificar a combinação ideal de projetos que podem oferecer o máximo valor estratégico para a organização.

Para determinar o portfólio certo, os projetos são minuciosamente examinados, classificados para medir a potencial contribuição para a organização. Também ajuda a compará-los com indicadores anteriores para chegar a métricas iniciais do desempenho do projeto.

Analisar a disponibilidade de recursos é uma parte crucial deste pilar, pois é necessário entender a capacidade dos recursos e compará-la com a procura do portfólio. Dessa forma, torna-se possível estimar se há bloqueios iminentes durante a execução. Caso os recursos não estejam disponíveis conforme o esperado, as organizações podem planear adequadamente. Por exemplo, você pode contratar novas pessoas, mover recursos de outros projetos como solução alternativa, contabilizar mais orçamento para comprar novos equipamentos etc.

2. Gestão de Projetos e de Contratos

Se aprofundarmos ainda mais os portfólios, passamos à gestão de projetos e de contratos. No contexto da previsibilidade, o foco aqui é integrar as funções de mudança e risco com a restante plataforma do projeto. Este pilar é um reconhecimento da dinâmica da mudança nos projetos e uma mudança nas premissas que existiam no início ao decidir sobre o portfólio. Essas mudanças devem ser tratadas rapidamente, a fim de causar um impacto mínimo nos projetos em andamento.

Ao gerir as mudanças, riscos e problemas como parte de uma plataforma tecnológica holística, pode avaliar automaticamente o impacto no desempenho e nas previsões do projeto e, portanto, responder a estes o mais cedo possível. Também oferece uma oportunidade para ligar os dados do projeto ao vivo com métricas de previsibilidade.

3. Controlos de projeto e contrato

O objetivo desse pilar é impor controlos mais rígidos, com integração de funções de ponto a ponto do projeto, incluindo contabilidade, programação, gestão de recursos, compras e orçamento. Em vez de usar soluções em silos fragmentadas para cada uma dessas funções, ter uma solução consolidada (uma plataforma, um login, uma abordagem de banco de dados) garante que os dados sejam compartilhados entre diferentes departamentos do projeto e aumentando a visibilidade geral.

O uso da integração automatizada e nativa garante que os gestores de projeto recebem alertas quase em tempo real e análises de dados que podem conduzir ações corretivas em tempo útil. Além disso, fornece transparência e promove uma cultura que suporta a análise de cenários hipotéticos e a busca da raiz da causa das tendências.

4. Gestão de Performancce

Para derivar para um modelo de previsibilidade confiável, deve evitar métodos de previsão monolíticos e just-in-time em favor de métodos que constantemente ajustam as previsões e o fazem regularmente durante a execução do projeto.

Para conseguir isso, é importante recolher dados confiáveis de progresso ​​de fontes internas e externas em tempo real, agrupá-los e mapeá-los para o impacto real nos custos e excedentes de cronograma. Esse processo de medição de progresso com vários métodos permite que a fonte correta de progresso seja atribuída à entrega do projeto.

O outro aspeto da gestão da performance é fornecer métricas no momento certo: antes que seja tarde demais para reagir. A criação de ferramentas visuais, como painéis de controlo (dashboards), pode ajudar a partilhar continuamente informações com as partes interessadas relevantes.

Valor Ganho (EVM) explicado

Muitos sistemas avançados de gestão de projeto utilizam o modelo tradicional de planeado vs real para acompanhar até que ponto o projeto está a decorrer (bem ou não tão bem) de uma perspetiva financeira. Contudo este modelo deixa de fora um elemento importante – o valor do trabalho já realizado.

 Quando o planeado vs real são os únicos valores acompanhados, só consegue ver se está abaixo ou acima do orçamentado. Diz muito pouco ou nada sobre o progresso daquilo que estamos a realizar. Por exemplo, podemos estar a gastar demasiado porque estamos avançados relativamente ao plano e fizemos imensos progressos.

Assim, aquilo que parece um problema é antes uma vantagem porque iremos terminar mais cedo e provavelmente abaixo do orçamento. Mas, se não existir nenhum sistema para atribuir valor às realizações não teremos nenhuma forma fácil de saber quais as implicações de ultrapassar o orçamento. Pode, claro, rever o plano e obter um sumário da percentagem de conclusão do projeto, mas este valor de percentagem, por si só, não está ligado aos valores baseados em custo do orçamento e custo real que estamos a acompanhar.

Para simplificar muito o conceito de valor ganho, podemos dizer que este irá atribuir um valor ao progresso que se realizou, com base no orçamento baseado no tempo.
Para ilustrar vamos usar um exemplo em termos de planeado vs real e de seguida vamos adicionar valor ganho para ver o que revela esta outra dimensão.

Temos um projeto de 10 meses que está planeado para gastar 1 Milhão por mês para um orçamento total na conclusão (BAC) de 10 M. Já passaram 2 meses e de acordo com os números de custo do planeado vs real já gastou menos 50% do que devia. Podemos assim assumir que o projeto está a decorrer bem, porque aparentemente está a gastar menos do que o que estava planeado.

Ao introduzirmos os números de valor ganho com base no progresso real do projeto obtemos uma nova perspetiva. Depois de 2 meses de trabalho, só foi completado 5% do trabalho. O cálculo simples para este cenário é 5% sobre um total de 10 M do orçamento serão 500 k. Este é o número do valor ganho.

O que é que este número de valor ganho nos diz acerca da presente situação do projeto?A despesa inferior realizada não é uma boa notícia para o projeto porque o cronograma está 75% para trás; o projeto está na realidade a gastar mais com base no trabalho realizado. O que parece bem numa perspetiva de planeado vs. real está longe de estar bem quando o valor do progresso é introduzido como valor ganho.Isto significa ainda que podemos ver o impacto para o projeto utilizando os cálculos standard de valor ganho. 

Estes sublinham a dimensão dos problemas em que o projeto pode estar envolvido.

• Orçamento na conclusão (Budget at Completion - BAC): 10 M
• Valor planeado até à data (Planned Value – PV): 2 M
• Valor ganho até à data (Earned Value – EV): 0,5 M
• Custo real até à data (Actual Cost – AC): 1 M
• Variância de custo (earned value – actual cost) = -0,5 M (significa gastar mais 100%)
• Variância de agendamento (earned value – planned value) = 1,5 M (1,5 meses ou atrasado 75%)
• Cost Performance Index (CPI): (earned value / actual cost) = 0.5 (por cada euro gasto ganhou 50 cêntimos)
• Schedule Performance Index (SPI): (earned value / planned value) = 0.25
• Estimado na conclusão (Estimate at Completion – EAC): (budget at completion / cost performance index) = 20 M
• Estimado até à conclusão Estimate to Completion: (budget at completion – earned value)/cost performance index = 19 M
• Tempo para completar = (10-0.5) /0.25 = 38 meses

Com base na performance corrente este projeto irá necessitar de 20 M (19+1) e 48 meses (38+2) para concluir.

Embora este seja um exemplo exagerado, muitos projetos sofrem algum nível de sobre despesa e sub-performance nas etapas iniciais. Isto é característico porque leva sempre mais do que o estimado com seguir ter todas as pessoas no site, o equipamento entregue e todos a trabalhar a bom ritmo.

Sem gestão do valor ganho, contudo, é impossível ter consciência do impacto potencial destes atrasos iniciais, que podem passar sem notícia significativa. A gestão pode não reagir da forma apropriada ou suficientemente cedo a estas tendências de forma a prevenir a ameaça de longo prazo ao sucesso do projeto.

Adaptação de post da Ten Six Consulting LLC.