quarta-feira, dezembro 21, 2011

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 projecto. Pode funcionar como um embrião para a criação de um Registo de Riscos para utilizar em projectos. Então aqui vai:
Riscos relativos ao Âmbito – Deslizar potencial do âmbito porque os requisitos do projecto 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 projecto? Foram definidos os procedimentos de gestão da mudança do âmbito? 
IMG00012-20101031-1140
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 factor significativo. A falta de experiência anterior. Conhecimento experimentado da área de actividade, falta de adequadas revisões e verificações são as causas para estimativas inexactas. Ser pessimista faz-nos ganhar pontos e devemos quase ser paranóicos quando se trata da estimação do projecto. O optimismo mata, muitas vezes!

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

Riscos relacionados com Dependências
– O projecto 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 projecto. 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 projectos 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 seleccionada 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 electró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 projecto está na definição no contrato de critérios de aceitação vagos ou pouco claros. Este também é um aspecto muito difícil de definir nos estágios iniciais do projecto 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 arquitectura de alto nível esteja realizada. Em alguns projectos esta importante questão só é tratada já tarde no projecto e esto deixa este exposto a um risco inaceitável.


Riscos da Regulação
– A equipa de projecto tem de avaliar cuidadosamente os requisitos regulatórios e de certificação pra o produto e avaliar o seu impacto nos colaboradores do projecto, no desenho do produto, e no orçamento e tempo de realização do projecto. 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 projecto e reflectem-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 actividade pode ser um requisito importante em muitos projectos. Este conhecimento especializado pode ter a ver com a indústria ou com os domínios de tecnologia. O projecto 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 projecto.


Riscos Políticos
– Não podemos negligenciar este importante aspecto em qualquer projecto. Será que o projecto tem o compromisso adequado dos mais importantes apoios? E o sponsor do projecto será que ele tem o suporte e o financiamento da gestão? Quem é que sofrerá o impacto do projecto? 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 projecto e a orgânica da organização cliente?


Riscos relacionados com a Garantia
– Diferentes contractos têm diferentes cláusulas. O plano do projecto deve ter em consideração e planear para a os termos da garantia definidos para este projecto. 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 projecto. 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 projecto porque lhes parecem estar para além da sua esfera de influência. Mas estes riscos devem ser registados no planeamento de grandes contractos 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 actualizada, para garantir um mecanismo de comunicação efectiva que possa em tempo sincronizar todos no mesmo propósito.

terça-feira, dezembro 13, 2011

Categorias de Riscos a ter em atenção

Os riscos são inevitáveis nos projectos. Não podemos evitar os riscos e conseguir uma suave execução do projecto. Temos somente de aceitar este facto e afastarmo-nos dos riscos iminentes. Estes eventos de risco estão muito bem escondidos em lugares dos mais improváveis, mas confiamos sempre em que o bom tempo e a bonomia dos nossos concidadãos nos permitam alcançar algum sucesso sem sermos confrontados com um destes eventos prováveis.image

Os gestores de projecto pesquisam os riscos em locais conhecidos ou dependem por completo da experiência quando identificam riscos potenciais no seu projecto. O seu registo de riscos vai melhorando conforme eles adquirem experiência. Mas este tipo de educação é muito dispendiosa para o projecto e para o sponsor do projecto. Uma exploração sistemática de riscos em áreas problemáticas conhecidas deve ser uma obrigação em todos os projectos. Esta exploração deve ser sistemática e deve, para facilitar, ser realizada com a utilização de uma lista de verificação. Não se pode deixar um aspecto tão crítico do projecto para a memória do gestor de projecto. Esta lista deve ser um documento vivo e deve ser actualizada sempre que factos novos ou conhecimentos estejam disponíveis durante a execução dos múltiplos projectos.

Em sumário, o gestor de projecto deve ter atenção às seguintes áreas de risco:

  • Âmbito
  • Plano e Esforço
  • Asumpções, Dependências e constrangimentos
  • Tecnologia
  • Critérios de Aceitação e Qualidade
  • Pessoas, experiências e competências
  • Regulação e Política

Todas estas áreas correspondem a uma lista de perguntas que os gestores de projecto devem colocar quando, de forma obrigatória e regular, abordarem a revisão de riscos para o projecto.

quarta-feira, dezembro 07, 2011

O jogo do projecto – uma fábula

Agora uma fábula, já que de jogo se trata. Imagine um rei que é solteiro e quer ter um herdeiro. Ele pede a 3 membros do seu conselho para gerirem um projecto e recebe as respostas seguintes:

  • O primeiro conselheiro diz que ele consegue organizar a produção de um herdeiro em 4 meses.
  • O segundo conselheiro declara de 3 a 5 anos, tendo em consideração a necessidade de encontrar um cônjuge adequado, seguir protocolos complexos de noivado real, casamento e deixar a natureza realizar o seu curso.
  • O terceiro afirma 9 meses.

imageConsiderando que o rei funciona como a maioria das companhias, quem é que ele vai seguir?

A proposta do primeiro conselheiro é fisicamente impossível, quaisquer que sejam os recursos que se atribuírem à actividade. O segundo conselheiro parece ao rei demasiado cuidadoso. O terceiro conselheiro recebe o projecto, porque ele está a propor um plano agressivo mas que não é impossível. O conselheiro reconhece que o prazo não vai ser alcançado, mas pode enfrentar isso mais tarde. O rei sabe também isso, mas aposta em que o conselheiro redobrará os seus esforços para evitar o fracasso e conseguir entregar em tempo. Quatro meses e onze meses depois, nasce um príncipe.

Neste tipo de situação, a duração das actividades usada no planeamento do projecto são as mais curtas que não violam as leis da física. Os gestores do projecto fazem a venda nesta base, falham os prazos e trabalham desesperada e vigorosamente para o concluir. Como resultado de sobreviver neste jogo, são promovidos e continuam as mesmas práticas na geração seguinte.

O jogo não tem de ser jogado desta forma, mas a iniciativa deve vir de cima. Soichiro Honda estabeleceu um tom diferente no desenvolvimento da sua companhia, ao envolve-la nas corridas de motos. Quando participava numa corrida nada mais interessava a não ser que o veículo, o piloto, a equipa e os fornecimentos estavam colocados e prontos no início da corrida. Este tipo de prazos rígidos também encontramos em coisas como concertos de música, a organização de exposições em museus ou o lançamento de uma sonda espacial para voar para os planetas do sistema solar. Esta abordagem foca as equipas de projecto em realismo, avaliação das actividades e criatividade para enfrentar o inesperado.

terça-feira, dezembro 06, 2011

O Jogo do Projecto

Iniciei o trabalho com uma equipa de projecto de uma grande companhia que está a preparar a realização de uma obra de grande dimensão – que é mesmo o propósito da mesma companhia e veio-me à cabeça um turbilhão de ideias com os problemas enfrentados no início de um projecto e com as concepções diversas que se tem sobre a gestão de projecto.

O desenvolvimento dos grandes projectos de engenharia como a ilha Jumeirah no Dubai ou o desenvolvimento do Airbus A380, são concluídos com atraso de perto de dois anos relativamente ao plano. Estes são só dois exemplos, mas essa é uma constante porque esta performance dos projectos não é uma excepção. Desde a remodelação da cozinha até ao desenvolvimento de um produto, os projectos tendem para estar atrasados no tempo relativamente ao plano ou acima do orçamento, ou ambos. image

É tecnicamente possível fazer melhor mesmo em projecto de grande escala, com envolvimento de nova tecnologia como o exemplo do programa Apollo, que alcançou o seu propósito 5 meses antes do prazo, ou, para falarmos de um exemplo mais perto, a Ponte Vasco da Gama (2 meses antes do prazo). Mas estes não são fenómenos que se repitam com facilidade.

Assim, é legítimo perguntar se não somos capazes de fazer melhor, considerando as ferramentas que agora possuímos. A chave é, parece-me, que a gestão de programas e de projectos são tratadas como campos técnicos quando deviam ser olhadas como jogos, visto que os resultados são consequência de decisões tomadas por diversos agentes independentes.

Na gestão de projecto decompõe-se um projecto em actividades mais pequenas, às quais se atribuem durações, recursos e constrangimentos de tempo e de precedência. De seguida são realizados cálculos que produzem gráficos de Gantt, são identificados os perfis para os recursos, o caminho crítico, etc. A ferramenta mais comum é aquela que permite realizar o Método do Caminho Crítico (todas as ferramentas no mercado). Recentemente, chegou Eli Goldrath com a sua Cadeia Crítica da Gestão de Projecto (Critical Chain) que se foca nos recursos ou a Matriz de Desenho da Estrutura (Design Strucuture Matrix) que visa gerir as interacções entre as actividades.

Estes são todos modelos consistente e muito bons para as apresentações de soluções, mas estão muito longe do dia-a-dia da gestão de projecto dirigindo-se muito mais ao primitivo processo de listas de itens de acção. O problema mais óbvio com o uso destas ferramentas é que a duração para as actividades elementares é desconhecida e nunca vi uma organização que realizasse um esforço sério para recolher estes dados.

Uma actividade de projecto não é como uma actividade de montagem fabril que possa ser cronometrada ou registada em vídeo. O trabalho de projecto nunca é completamente repetitivo, se repetimos sempre a mesma acção, então é chamado produção ou transacção, mas não um projecto. Como nunca fizemos esta actividade de projecto antes, não pode dizer quanto tempo levará, mas pode obter outra informação dos seus componentes e pode estimar as similaridades ou as diferenças, com as actividades que já realizou antes, se mantém um registo disso. O trabalho de engenharia é organizado por projecto e o tempo dos engenheiros é controlado por timesheets, mas estas folhas são preenchidas após os factos pelos próprios engenheiros sem rigor efectivos e não são exactas.

Há formas de estimar melhor o trabalho das actividades, mas esse não é a preocupação principal dos gestores de projecto, ao contrário, o seu pensamento está focado em frases que começam com «Nada mais interessa, se…». Inicialmente, um gestor encarregado de liderar o projecto criou um plano que deve ser aprovado e nada mais interessa. O propósito do plano não é assim estimação mas sim persuasão. Como é que isto será realizado? Não há uma forma directa de o dizer, porque obviamente depende de quem deve ser persuadido. O que é constante é que o gestor de projecto está a vender, e irá fazer tudo o que for necessário para fechar o negócio.