Alternativa ao Asana para a gestão de riscos do projeto: um registo que não é uma lista
O Asana oferece um modelo de registo de riscos e um modelo de matriz de riscos. Ali pode registar uma ameaça, avaliá-la e atribuir-lhe um responsável. O problema está noutro lado. Esse registo é um projeto vulgar feito de tarefas com alguns campos acrescentados, não um módulo à parte do sistema. Com os primeiros riscos não faz diferença. Começa a importar quando tem vinte riscos, vários projetos, e alguém pergunta se outra equipa já está a tratar a mesma ameaça. Este artigo mostra o que uma lista dessas não consegue fazer e descreve os mecanismos que fecham a lacuna.
Principais conclusões:
- Um modelo de registo é uma lista de tarefas vulgar. Um risco registado como tarefa não pode ser ligado a outra tarefa nem comparado com riscos dos seus outros projetos.
- A matriz de riscos tem de usar a escala com que já trabalha. Uma empresa que usa uma escala três por três não passará para cinco por cinco. O módulo ficará vazio.
- Ligar um risco a uma tarefa muda a forma de trabalhar. Depois de o cronograma se mover, vê logo que ameaças se tornaram urgentes.
- O risco deve ser conhecimento de toda a organização. Modelos com riscos típicos e fichas de encerramento dão à equipa um ponto de partida em vez de uma lista vazia.
- A maior poupança é o fim da reescrita. O termo de abertura do projeto e o relatório mensal puxam os riscos do registo automaticamente.
Um registo de riscos que é uma lista de tarefas
O Asana tem um modelo pronto de registo de riscos e um modelo de matriz. A sua lógica é sólida: descreve a ameaça, avalia a probabilidade e o impacto, nomeia um responsável e acrescenta um plano de resposta. Com um projeto e uma dúzia de riscos basta. Também bate uma folha de cálculo, porque o registo está onde o trabalho acontece, e uma comparação funcionalidade a funcionalidade do FlexiProject e do Asana traça o quadro mais amplo.
A limitação está na construção. Um risco aqui não é um objeto à parte, apenas uma tarefa com campos extra. Tudo o que decorre de um risco não ser trabalho por fazer tem de ser organizado fora da ferramenta.
O que o modelo dá e o que não consegue
O modelo organiza a informação, e é esse o seu verdadeiro valor. Três coisas não dá.
Um risco não pode apontar para outra tarefa, porque ele próprio é uma tarefa. Por isso não pode registar que uma dada ameaça diz respeito a uma entrega específica do cronograma. Os riscos também não podem ser comparados entre projetos, porque os campos personalizados só funcionam dentro de um projeto. E não há um nível acima do projeto. Cada registo é completo em si e cego ao que está ao lado. Três equipas podem estar a gerir o mesmo risco de fornecedor e nenhuma delas o saberá.
Três sinais de que o registo deixou de funcionar
Um registo atualizado mesmo antes do comité de direção em vez de ao longo do trabalho. Se atualizar é uma atividade à parte, acontece quando alguém a pede. Normalmente demasiado tarde para mudar seja o que for.
Riscos reescritos à mão no termo de abertura do projeto e no relatório mensal. Esse trabalho não cria qualquer informação nova, e acabam por circular na empresa três versões da mesma lista.
A pergunta «já há alguém a tratar disto» sem ninguém a quem perguntar. Sem um nível onde os riscos de projetos diferentes se encontram, cada um é resolvido do zero. Também vemos o que procurar quando se consideram aplicações como o Asana.
O que exigir de um registo de riscos
A diferença entre uma lista e um módulo reduz-se a sete coisas. Cada uma é tratada pelo sistema ou feita à mão.
| Requisito | O que quebra sem ele |
| O risco como objeto à parte | Não o pode ligar a uma tarefa nem distingui-lo de trabalho por fazer |
| Uma matriz configurável | O sistema impõe uma escala que não usa, e o módulo é abandonado |
| Uma ligação ao cronograma | Depois de uma data se mover, não vê que riscos se tornaram urgentes |
| Categorias partilhadas na organização | Não consegue reunir riscos jurídicos ou tecnológicos de vários projetos |
| Um nível de portefólio | Várias pessoas trabalham em paralelo sobre a mesma ameaça |
| Uma base de conhecimento de riscos | Cada equipa identifica riscos do zero e a experiência da empresa perde-se |
| Preenchimento automático de documentos | O termo de abertura e o relatório têm de ser preenchidos à mão |
Juntos descrevem o que um software de gestão de riscos tem de fornecer. A seguir percorro os requisitos um a um e mostro como o FlexiProject os trata.
Identifique, controle, monitorize e faça a gestão dos riscos do projeto, experimente o FlexiProject grátis durante 30 dias.
Uma matriz nas dimensões que já usa
Configurar a matriz de riscos parece um detalhe. É uma das razões mais comuns para um módulo de riscos num sistema PPM ficar vazio. Uma empresa passou anos a desenvolver uma matriz três por três, e o sistema a implementar tem cinco por cinco fixo no código. Ninguém vai reformar trinta gestores de projeto numa nova escala porque um fornecedor assim decidiu. O resultado é previsível: o módulo fica por usar e o risco volta para um slide.
No FlexiProject as dimensões da matriz definem-se durante a implementação, sem programação. A empresa traz a escala que as suas pessoas conhecem, juntamente com o hábito de que uma dada avaliação exige uma dada resposta. O padrão que desenvolveu sobrevive assim à mudança de ferramenta.
Uma ficha de risco em vez de uma linha numa tabela
No sistema de gestão de projetos FlexiProject o registo de riscos é um módulo à parte do projeto. Cada risco tem nome, estado, responsável, uma ligação a uma tarefa do cronograma, uma categoria, impacto, probabilidade e data de identificação. O impacto no cronograma e o impacto no orçamento são avaliados separadamente. Isso importa na prática: um risco que atrasa a aceitação um mês e um risco que acrescenta cem mil ao custo pedem respostas diferentes. Uma avaliação comum de «impacto elevado» não os distinguirá.
Acima do registo está uma ficha de risco. Para além dos dados do registo, guarda anexos, o plano de gestão dessa ameaça e um mensageiro onde a equipa discute esse risco específico. Parece uma pequena coisa, mas resolve um problema real. Uma discussão num canal de equipa desaparece em dois dias. Uma conversa registada no risco fica com ele. Quando alguém pergunta seis meses depois porque foi escolhida essa resposta, a resposta está no mesmo sítio que a decisão.
Risco preso a uma tarefa do cronograma
Os registos de riscos costumam ser planos. Tratam um risco que diz respeito a todo o projeto, por exemplo uma escassez de recursos, do mesmo modo que um risco que diz respeito a uma só tarefa, como uma entrega de um subcontratado. São duas situações diferentes e gerem-se de forma diferente.
No FlexiProject cada risco pode ser ligado a uma tarefa específica do módulo de cronograma do projeto. Atribui um risco de fornecedor à tarefa que depende da entrega, e um risco regulatório à tarefa de aprovação. A partir daí o cronograma leva informação sobre ameaças. Na linha da tarefa surge um triângulo com um ponto de exclamação, com um círculo ao lado: vermelho quando o risco está ativo, cinzento quando não está. O gestor de projeto vê os pontos que exigem atenção sem abrir o registo.
Ajuda sobretudo quando o plano muda. Quando o cronograma se move, sabe logo que riscos se tornaram mais prementes. Dizem respeito a tarefas que se aproximaram de um prazo rígido ou passaram para o caminho crítico. Essa informação existe também num registo plano, mas tem de a deduzir sozinho comparando duas listas. Por isso normalmente ninguém o faz. Em separado explicamos como abordar o planeamento de projetos que o sistema mantém sozinho.
O risco como conhecimento da organização, não de um só projeto
Na maioria das empresas a forma como as equipas identificam e avaliam os riscos do projeto resume-se a uma reunião de arranque onde alguém imagina o que poderia correr mal. O método não é fiável. As pessoas subestimam ameaças que não encontraram antes. A empresa no seu conjunto costuma já as ter visto, só que noutro projeto.
Modelos com uma lista de riscos típicos
Uma lista de riscos potenciais para um dado tipo de projeto pode ser incorporada no modelo. Uma equipa que arranca uma implementação para cliente, um projeto de investigação ou um investimento começa com uma base pronta e ajusta-a ao seu caso. Isto muda a natureza da reunião. Em vez de inventar ameaças, a equipa revê as conhecidas e decide quais se aplicam. É mais rápido e mais eficaz, sobretudo em equipas menos experientes.
A ficha de encerramento e os relatórios de riscos
O outro lado deste mecanismo é registar o que realmente aconteceu. A ficha de encerramento do projeto pode listar os riscos que ocorreram e como foram resolvidos. As equipas que planeiam projetos posteriores têm acesso a fichas de encerramento históricas.
O terceiro elemento são os relatórios. No módulo de relatórios pode construir uma vista de riscos para os projetos de uma categoria ou de uma área da organização. Uma equipa nova obtém uma resposta concreta: estas são as ameaças que ocorreram em projetos semelhantes. Juntos, estes três mecanismos fazem com que a gestão de riscos deixe de depender da competência de um só responsável.
Faça a gestão dos riscos do projeto com eficácia com registo de riscos e planos de ação, comece grátis hoje com o FlexiProject.
Categorias de riscos e a vista para os departamentos
O risco raramente diz respeito só ao gestor de projeto. O jurídico quer saber que obrigações e litígios estão no portefólio. A produção pergunta pelos desafios tecnológicos, as compras pelas ameaças do lado dos fornecedores. Com um registo fechado dentro de um projeto, nenhum deles pode colocar a sua pergunta.
Nas definições do FlexiProject define a sua própria lista de categorias de risco, alinhada com a forma como a responsabilidade está repartida na empresa. É aqui que uma estrutura de decomposição de riscos (RBS) deixa de ser um diagrama e passa a ser algo por que o sistema pode filtrar. É sobre isso que se constroem os relatórios entre projetos. O jurídico vê os riscos jurídicos de todos os projetos, a produção os seus, as compras os seus. O risco deixa de ser assunto privado do gestor de projeto. À parte detalhamos o que é um verdadeiro controlo do orçamento do projeto.
Nível de portefólio, ou o fim de gerir o mesmo risco três vezes
Com várias dezenas de projetos, algumas ameaças repetem-se pela sua natureza. O mesmo fornecedor, a mesma alteração regulamentar, a mesma tecnologia imatura. Se os registos estão fechados dentro dos projetos, cada responsável mantém a sua própria versão desse risco e chega a conclusões ligeiramente diferentes.
O software de portefólio de projetos resolve isto de outra forma. Cada portefólio no FlexiProject tem um separador de riscos à parte. Reúne as ameaças de todos os projetos desse portefólio. O coordenador vê a repetição e pode resolver o risco de forma centralizada, usando todo o conhecimento disponível em vez de uma só perspetiva. O esforço triplo transforma-se num responsável e numa resposta. Elimina também a situação em que três projetos aplicam três estratégias diferentes ao mesmo fornecedor. À parte explicamos o que uma alternativa ao Asana para um PMO tem de oferecer.
Fim da reescrita: o termo de abertura e o relatório de estado
A poupança mais visível diz respeito à reescrita, não à análise. Em muitas empresas o procedimento exige que os riscos mais significativos cheguem ao termo de abertura do projeto e, uma vez por mês, ao relatório para a direção. Com um registo à parte, alguém move as mesmas entradas para dois sítios e verifica que as versões coincidem.
No FlexiProject o módulo de termo de abertura do projeto puxa os riscos do registo automaticamente. Ambos os documentos são coerentes por conceção, não pela diligência de alguém. O reporte de estado cíclico funciona da mesma forma. Se o relatório contém uma secção de riscos, preenche-se sozinho a partir do registo, e ao responsável resta um comentário sobre como essas ameaças estão a ser geridas. Uma atividade que não criava qualquer informação nova desaparece, e desapareceu da pior semana do mês.
Quando um modelo chega
Gere um projeto, é você que o gere, tem uma dúzia de riscos e ninguém exige reporte formal? Um modelo de registo numa ferramenta de tarefas chega. Um módulo à parte acrescentará formalidade, não controlo, porque os problemas descritos acima aparecem a maior escala. Se quer um olhar mais amplo sobre as opções, comparámos à parte o melhor software de gestão de riscos.
Os sinais de que essa escala chegou são concretos. Surgem um segundo e um terceiro projeto, e há que comparar os riscos entre eles. Alguém de fora do projeto pergunta pelas ameaças num dado corte. O procedimento exige riscos no termo de abertura e no relatório. A partir desse ponto, uma lista com campos personalizados custa mais trabalho do que poupa.
Como testá-lo no seu próprio registo em duas semanas
As comparações de funcionalidades decidem pouco, porque a página de cada fornecedor responde sim a tudo. Um teste com os seus próprios dados diz mais. Pegue no registo de um projeto em curso e transfira-o por inteiro, juntamente com a sua escala de avaliação. Esse primeiro passo mostra se a sua matriz entra na ferramenta sem mudar os hábitos da equipa.
Depois quatro testes. Ligue três riscos a tarefas do cronograma e verifique que os vê no diagrama de Gantt. Mova uma dessas tarefas duas semanas e veja se o quadro das ameaças muda. Construa um relatório de riscos para uma categoria, os fornecedores por exemplo, que abranja vários projetos. Abra o separador de riscos do portefólio e verifique se alguma ameaça se repete em vários sítios. Esse último teste costuma justificar a mudança por si só.
Perguntas frequentes
O Asana tem um registo de riscos?
O Asana oferece um modelo de registo de riscos e um modelo de matriz. Produzem uma lista com campos como probabilidade, impacto, responsável e plano de resposta. Não é um módulo à parte, apenas um projeto feito de tarefas. Por isso não pode ligar um risco a uma tarefa do cronograma, compará-lo entre projetos nem vê-lo ao nível do portefólio.
Qual é a diferença entre um registo de riscos e uma lista de tarefas com campos personalizados?
A mesma diferença que entre um risco e trabalho por fazer. Um registo trata o risco como um objeto à parte com o seu próprio ciclo de vida, avaliação, responsável, plano de resposta e ligações ao cronograma e ao orçamento. Uma lista de tarefas deixa-o registar essa informação mas não usá-la fora de um projeto.
O que se ganha ligando um risco a uma tarefa do cronograma?
Mostra onde no plano está a ameaça. No FlexiProject uma tarefa com um risco ligado leva um ícone de aviso no diagrama de Gantt, e a cor ao lado diz se o risco está ativo. Após cada mudança do cronograma vê que ameaças se tornaram mais prementes.
Podemos manter a nossa própria matriz de riscos?
Sim. As dimensões da matriz definem-se durante a implementação, por isso uma empresa que trabalha com uma escala três por três não tem de passar para cinco por cinco. É uma das condições mais importantes para que um módulo de riscos seja usado em vez de evitado.
Como começamos se o nosso registo de riscos está hoje em Excel?
Transferindo um projeto em curso, juntamente com a sua escala de avaliação e as suas categorias atuais. A folha de cálculo costuma conter toda a informação necessária. O que lhe falta são as ligações: às tarefas, a outros projetos e aos documentos que preenche à mão de qualquer forma. Essas ligações são a razão para mudar, não o mero facto de manter um registo.
Procura-se uma alternativa ao Asana para a gestão de riscos do projeto não porque não haja onde registar uma ameaça. A razão é outra: uma ameaça registada depois não faz nada. Um registo que é uma lista acaba na documentação. A informação existe, mas não se liga ao cronograma, não se soma entre projetos, não volta à empresa no projeto seguinte e tem de ser reescrita em cada documento separadamente. Um registo que é um módulo faz estas quatro coisas sozinho. Deixa ao responsável a única coisa que nenhum sistema fará por ele: decidir como responder. Se o seu registo hoje é atualizado sobretudo antes do comité de direção, a forma mais barata de o verificar é transferir um projeto e ligar três riscos a tarefas do cronograma.
