domingo, fevereiro 12, 2012

Análise de Risco do Projecto: O que é e porquê fazer?

Os planos de projecto são, evidentemente, acerca do futuro tudo o que trata do future tem certa incerteza associada. Quando se estima a duração da actividade em 5 dias está intrinsecamente assente que isto pode provavelmente não ser assim mesmo. Pode haver uma pequena quantidade de incerteza ou uma grande, mas alguma haverá com certeza.clip_image002

Como resultado da incerteza acerca das durações das actividades, qualquer estimativa da data de conclusão do projecto é só isso, uma estimativa. Esta será válida tão só as estimativas das durações das actividades se verifiquem como verdadeiras. Como há sempre muitas actividades, é quase certo que muitas delas tomem menos tempo que o estimado enquanto outras levarão mais tempo que o estimado.

Assim, na realidade o fim do projecto é provável que não possa ser projectado de forma tão determinística como o CPM e o PERT, mas esteja, talvez, dentro de um limite de datas que se pode espalhar simetricamente à volta da estimativa. (Na realidade é pior do que isso. O uso de estimativas determinísticas também introduz um preconceito de tal forma que as estimativas tendem sistematicamente para serem optimistas.)

A Análise de Risco do Plano (Schedule Risk Analysis) é uma técnica que reconhece esta incerteza ao substituir a duração determinística para cada actividade pela distribuição representando os limites das durações prováveis. Existem métodos analíticos para processar as distribuições de probabilidade em casos simples, mas as redes de projecto são normalmente muito complicadas para que estes possam ser aplicados.

A solução é utilizar uma simulação Monte Carlo. Isto é como simular um evento da vida real através do lançamento de dados, só que isto é feito num computador. Os computadores podem gerar aquilo que é denominado como números pseudo-random. Não são verdadeiramente ao acaso, porque eles podem ser reproduzidos se alguém conhecer o mecanismo de geração: utilizando estes números pseudo-random, podemos gerar séries de distribuições desejadas e estas são usadas numa simulação Monte Carlo para simularem sistemas físicos sobre um grande número de cenários gerados ao acaso.

A simulação Monte carlo tem aplicações em muitas áreas. No contexto de uma rede de projecto, a simulação Monte Carlo:

Usa uma amostra da distribuição definida pelo utilizador para cada duração da actividade.

Faz uma análise de caminho crítico (CPM) com base nas durações da amostra.

Armazena os resultados desta análise de tempo (geralmente de uma forma sumária como um histograma).

Repete os passo de 1 a 3 várias centenas ou milhares de vezes.

No fim deste processo pode produzir histogramas representado a probabilidade das distribuições de qualquer resultado de interesse, que geralmente incluem datas mais cedo e mais tarde de início e datas de fim, folga livre e total e custo para cada actividade.

Como resultado, a data de fim estimado do projecto e outras milestones importantes são representadas por distribuições de probabilidade em vez de estimativas com um único ponto. Assim em vez de prever que o projecto será completado em determinada data – uma previsão que o mais certo é ser errada – podemos fazer previsões mais realistas tais como «há 90% de hipótese que o projecto termine até 31 de Maio.»

Mas, talvez a razão mais importante para fazer uma análise de risco é o equilíbrio anteriormente mencionado, que significa que uma estimativa de um só ponto da conclusão do projecto realizada através de um determinístico CPM ou PERT não está muitas vezes nem dentro dos limites representados pela distribuição probabilística produzida pela análise de risco. A razão para isto é um fenómeno denominado merge bias.

UM equilíbrio fundido (merge bias) ocorre sempre que dois ou mais caminhos convergem numa rede e a incerteza acerca das suas durações é tal que qualquer dele pode tornar-se crítico. Para ilustrar este equilíbrio fundido, considere uma actividade que só tem dois predecessores que correm em paralelo. Suponha que cada uma possa levar qualquer coisa como de 1 a 6 dias com probabilidade igual. E suponha, ainda, que elas não ocupam fracções de um dia. (Isto pode parecer um pouco artificial e até é. No entanto, isto permite que o ponto a ser feito por analogia com o lançamento de dados e sem nos envolver numa montanha de cálculo.)

A duração esperada para cada actividade individual é, claro, de 3,5 (já que 1+2+3+4+5+6 todos divididos por 6): mas qual é o tempo esperado para ambos para se concluírem? A tabela seguinte mostra todos os 36 resultados possíveis para o par de actividades, que pode ser simulado pelo lançamento de dois dados. (Assim , por exemplo, se a primeira levar 5 dias e a segunda só 3 dias. O tempo tomado por ambas para serem completadas é 5 dias e pode ser visto na tabela.

 


1


2


3


4


5


6

1

1

2

3

4

5

6

2

2

2

3

4

5

6

3

3

3

3

4

5

6

4

4

4

4

4

5

6

5

5

5

5

5

5

6

6

6

6

6

6

6

6

Das 36 possibilidades, só uma tem 1 como máximo enquanto 11 têm 6 como máximo. Assim tendo só dois caminhos paralelos podemos ver que o tempo que leva a realizar ambas as actividades é provável que seja maior do que a estimativa determinística de 3,5 dias. Se fizermos as contas vemos que o valor esperado é na realidade quase 4,5 dias. Com 3 actividades paralelas, o valor esperado é quase de 5 dias e com 5 actividades é cerca de 5,4 dias. E com 10 é de 5,8 dias. A convergiram claramente para 6 conforme o nº de caminhos paralelos aumenta).

Outra forma de olhar para isto é declarar a Lei de Murphy de uma forma menos pessimista do que Murphy.

“Se houver muitas coisas que possam correr mal então pelo menos uma irá correr mal.”
Numa rede de projecto com caminhos paralelos, basta um caminho correr mal para atrasar a conclusão do projecto. (correr mal significa tão só durar mais do que o esperado. Isto não implica que foi feito algum erro, mas pode ser só o resultado da inevitável incerteza envolvida na estimativa original). É isto o merge bias.

“Nestes assuntos a única certeza é que nada é certo.”  (Plínio o Velho)

quinta-feira, janeiro 26, 2012

A Consultoria de Gestão e o Fracasso dos PMO

Os PMO que foram implementados em grandes companhias fracassam porque perdem, na sua maioria, o seu tempo em intermináveis batalhas com outros departamentos ou em crises de identidade que impedem a afirmação da sua missão.

O problema é que o culpado habitual por esta ineficácia e falhanço do PMO, ou seja, a falta de compromisso da gestão, não é de facto a causa primária. Na realidade, o denominador comum do fracasso dos PMO pode ser atribuído antes ao papel desempenhado pelos consultores de gestão que estabeleceram o PMO. Estes consultores desempenharam um papel instrumental nas três áreas abaixo durante a criação do PMO, criando defeitos estruturais de grande dimensão, que embora com todas as tentativas de resolução se mantêm como uma nódoa que não se apaga.
 

Semear as sementes da confusão nos executivos

Mantém-se uma confusão perpétua mas cabeças dos executivos acerca das funções, responsabilidades e competências dos PMconsulting_mainO. Isto nasce porque os consultores contratados para o estabelecer focam-se, de forma exclusiva, em estabelecer um PMO que exiba características de uma função de reporting e pouco mais. Neste arranjo, os status de diferentes projectos e programas são agregados, racionalizados e então apresentados à equipa de gestão para a tomada de decisões.

O que acontece é que muitos dos executivos são incapazes de vestir a roupa do sponsor do projecto (antes desempenhado pelo CEO) e tomarem as decisões importantes para os projectos que estão debaixo do seu âmbito de decisão. Ainda mais, muito poucos executivos possuem ideias sólidas acerca de como um PMO centralizado deve funcionar. Assim, é lógico encontrar a falta de compromisso executivo quando o PMO entra em modo de cruzeiro.
 

Nunca foi uma questão de metodologia de projecto

Na fase de lançamento, a companhia de consultoria que estabelece o PMO presta muito pouca atenção à metodologia de programa / projecto ou à standardização dos documentos de projecto e dos modelos bem, ainda, à formação das pessoas do PMO na realização das suas funções para além do reporting. O próprio reporting sofre da ausência de uma abordagem estruturada e muitas vezes existe uma exagerada dependência das «apresentações de Powerpoint».

Depois após a implementação, o PMO armado unicamente com slides coloridos está muito mal equipado para apoiar ou realizar projectos e programas. Segue-se um crescente fracasso dos projectos e todas as tentativas para rectificar esta situação fracassam irremediavelmente.

Tudo isto porque as soluções utilizadas para enfrentar a fraqueza estrutural derivam da experiência de lançamento do PMO. Como exemplo, muitos executivos assumem que, só porque o PMO realizou resultados durante a fase de lançamento, irá depois, com uma abordagem similar e sem trabalho adicional, fornecer os mesmos resultados positivos.
 

Demasiada confiança em funções e responsabilidades centralizadas

Outra descoberta desconcertante é que as funções e responsabilidades, estruturas de processos e governação executadas pelo PMO estão baseadas na sua vida no lançamento. Encontramos muitas vezes funções de 'Launch PMO', 'Launch Manager', 'Launch Director', 'Launch Gate', 'Launch Project Life Cycle', 'Launch Check Lists', etc. como parte do léxico. Em muitas vezes, só o prefixo ‘Launch’ é removido das descrições de funções e processos, mas a essência está inalterável. Subsequentemente, o PMO e a sua equipa são incapazes de se adaptarem ao ritmo da vida da companhia e descobrem-se na periferia da realização dos projectos.

Para remediar a situação, são aplicadas duas soluções típicas. Em primeiro lugar, são recrutados «gestores de projecto certificados» e espera-se que estes realizem os projectos dentro do plano. Contudo, na ausência de uma metodologia sólida de gestão de projecto, vemos que muitos ficam parados num limbo.

Em segundo lugar, são recrutados para a remediação consultores muito dispendiosos com experiência extensiva em trabalho com PMOs. Em alguns casos, os consultores são na realidade contratados da mesma companhia de consultoria que estabeleceu o lançamento do PMO e falham miseravelmente quando lhes é atribuída a responsabilidade de resolver os problemas e sanar o PMO. Tudo isto exacerba o problema e marginaliza o papel do PMO na vida da companhia.

Para ser justo com os gestores de gestão, estes são normalmente contratados em virtude da sua competência no domínio e não pelas suas competências em PMO. Este é um valor adicional que é introduzido como uma parte dos serviços de consultoria sem custo adicional. Esta prática está generalizada de tal forma que os executivos ficam a pensar porque é que há tanto fracasso de projectos apesar do lançamento com sucesso de novas linhas de negócio.

Para evitarem cometer o mesmo erro segunda vez, os executivos devem por bem escrutinar as capacidades de PMO dos seus consultores, para além do conhecimento do domínio. Em alternativa, podem contratar um especialista de PMO para a companhia, que trabalhe em colaboração com os consultores na fase de lançamento e assegure que é entregue um PMO adequado, equipado com a metodologia certa e os recursos estabelecidos.

Os executivos devem procurar optar por companhias que forneçam a capacidade de PMO, mas também transfiram as competências para os futuros responsáveis pelos mesmos na companhia.

quinta-feira, janeiro 19, 2012

Selecção de Software de Gestão de Projecto

O software de gestão de projecto é desenvolvido por dezenas de fabricantes co9m as mais variadas funcionalidades e sofisticação e correspondentes variações de preços. O problema que se pôe às empresas é como encontrar a ferramenta adequada. Esta não é uma tarefa fácil porque não dispomos da possibilidade filtrar todo o «barulho» de marketing, que permita seleccionar a ferramenta certa para a situação ou para a nossa carreira.

Tipos de projectos que fazemos

Categoria de Software

Programas com sub-projectos múltiplos com uma grande equipa e dependências complexas entre as actividades

4

Projecto estratégico: afecta múltiplos depart6amentos ou organizações com um grande orçamento e uma grande equipa, fornecedores externos com muitos stakeholders

3 ou 4

Projecto cliente – fornecedor: equipa de 3 a 8 pessoas com um importante orçamento e um prazo fixo e complexidade na sequenciação de membros da equipa, fornecedores e materiais

2 ou 3

Pequeno projecto: realizado para outro departamento ou para um cliente externo. Equipa de 3 a 5 pessoas, sem orçamento e com uma data de entrega importante

1 ou 2

Projectos ad-hoc: realizados dentro do departamento com uma equipa de 2 ou 3 pessoas incluindo o gestor do projecto e demora menos de um mês sem orçamento e uma data de entrega flexível

1

Os profissionais usam software da categoria 3.

As Categorias de Software

O software disponível encaixa nestas categorias com grandes diferenças de preço conforme vamos subindo a escada.

  1. Software web ou baseado na cloud que conserva a informação de projecto com planeamento limitado e permitindo a distribuição de informação, acompanhamento de problemas e colaboração entre os membros da equipa. Se não necessitar de acompanhar de perto o progresso ou fazer relatórios de status, este tipo de software é suficiente. Alguns exemplos Apolo e Dotproject.
  2. Software de cloud ou instalado que oferece planeamento com datas de início e fim para cada actividade. Quando a situação muda, terá de introduzir novo início e fim. Se não está a gastar muito dinheiro no projecto e se este é de importância menor este software permite-lhe acompanhar o projecto, saber onde está e reportar o progresso. Exemplos são o iManageProject e Quickbase.
  3. Software instalado ou de cloud que possui algoritmos para optimizar um plano e a construção de um orçamento para o projecto. Pode introduzir as actividades, o trabalho / duração das mesmas, precedências e disponibilidade de recursos. O software calcula o plano e o orçamento e fornece ferramentas avançadas para detecção de problemas e modelação de situações. O software de categoria 3 é aquele que é usado pelas pessoas que habitualmente gerem projectos. Exemplos deste são Microsoft Project e Oracle.
  4. O software de servidor para gerir centenas de projectos, equipas com muitas pessoas e portfólios de projectos. O software empresarial de gestão de projectos custa muitos milhares de euros. Exemplos são Microsoft Project e Oracle, cada um com a sua versão de portfólio.

As duas primeiras categorias são adequadas para projectos mais pequenos. As capacidades são limitadas assim como a curva de aprendizagem. A sua ineficiência e falta de capacidade é um pequeno incómodo porque o projecto só tem umas poucas pessoas e uma duração curta. O custo deste software é baixo , mas estas não são ferramentas dirigidas a profissionais que regularmente gerem projectos.

O passo grande é o salto da categoria 2 para a 3. Neste ponto, o software muda de plano estático, em que as datas e durações são introduzidas manualmente, para dinâmico dirigido pelos recursos e as dependências. O plano actualiza-se automaticamente sempre que se adiciona ou remove recursos ou a sequência das actividades. Estas funcionalidades poupam muito tempo aos gestores de projecto na criação, optimização e actualização. A curva de aprendizagem é muito mais ingreme e o investimento só vale a pena se o projecto for crítico para a organização e a gestão pretender ter a possibilidade de identificação e correcção precoce. Estas soluções tornam-se indispensáveis quando se trata de projectos de complexidade ou de grande dimensão ou programas com múltiplos sub-projectos

Luís Quintino.