Tipos de risco em projetos de construção

Tudo o que deu errado num projeto de construção é um risco potencial no próximo projeto. Muitos gestores de projeto desenvolvem instintivamente uma lista de riscos históricos e lições aprendidas e tomam medidas para minimizar a exposição a esses riscos no futuro. A importância de pensar na contingência como forma de enfrentar o risco conduz-me a desenvolver estas linhas sobre riscos em projetos de construção.

Os riscos variam de acordo com a indústria e até pelo tipo de projeto de construção, bem como pelo pessoal envolvido com o projeto. Um projeto de autoestrada ou ponte tem um grupo diferente de riscos do de uma instalação ou prédio, e os contratados selecionados podem ter diferentes graus de influência sobre o nível de riscos para o desempenho. Este é o primeiro tópico em que se deve basear a análise.

Riscos diretos

Se um dono de obra tentar economizar dinheiro em serviços de pré-construção, limitando a extensão da investigação de campo ou o desenvolvimento de dados executados, haverá um risco maior de descoberta tardia de problemas desconhecidos. A experiência e competência dos arquitetos e engenheiros que lidam com o desenho do projeto, bem como o seu controlo de qualidade no desenvolvimento de desenhos de trabalho, afetam diretamente o esforço de construção e, consequentemente, o risco associado aos planos e especificações.

Mesmo que o dono de obra tenha sido proativo na investigação pré-construção, há sempre o risco de condições imprevistas. Isso pode ser uma função do tipo de solo encontrado, do município do local e da sua cultura e histórico de manter bons registos de equipamentos obsoletos. Se a cidade na qual o projeto será construído tem um histórico de exigir que os empreiteiros removam todas as linhas subterrâneas abandonadas, há um risco muito menor de conflitos subterrâneos.

Riscos internos

A seleção da equipa do projeto pode impactar positiva ou negativamente na probabilidade de conclusão do projeto com sucesso. Os projetos que criam propostas que usam filosofias de aquisição permitindo que todos os contratados com capacidade financeira participem, provavelmente experimentarão um nível muito mais alto de risco para desempenho pontual do que uma filosofia de aquisição que requeira qualificação dos contratados propostos para garantir que eles tenham a experiência apropriada e recursos para construir o projeto. Um único subcontratado fraco num projeto aumentará o risco de desempenho e exigirá mais gestão do que o previsto. Se isso não for considerado, todos ficarão surpresos quando o subcontratado falhar e precisar aumentar ou corrigir o trabalho. Problemas relacionados com a gestão e possível rescisão de um subcontratante em falha causam geralmente sérios impactos negativos no projeto.

A reputação do gestor de construção (CM), bem como a cultura corporativa afetará o desempenho do projeto. Se o CM definir o sucesso com extensões de tempo mínimas como o único benchmark, provavelmente haverá mais conflitos e maior necessidade dos esforços de resolução de reclamações. Além disso, as capacidades de gestão do CM afetam diretamente muitas atividades do projeto, como a revisão de desenhos de trabalho e a resposta a solicitações de informações por forma a resolver questões sobre a construção.

O trabalho de fora ou de terceiros pode acarretar riscos significativos de influência no sucesso do projeto. Por exemplo, uma estação ferroviária ligeira a ser construída no topo de um parque de estacionamento em construção por um contratante diferente correrá um risco acrescido de conclusão em tempo. O projeto não tem controle sobre - e pouca capacidade de influenciar - a conclusão do estacionamento, que rapidamente se torna vital para a conclusão do projeto do metro ligeiro.

Riscos externos

A maioria dos projetos é afetada pelas condições meteorológicas locais, que, quando adversas, podem impedir significativamente o progresso. A maioria das especificações exige que o empreiteiro leve em consideração as condições climáticas locais normais no planeamento, o que inclui condições climáticas adversas normais, mas também permite extensões de tempo quando ocorre um clima adverso incomum. As melhores práticas exigiriam que o contratado pesquisasse os registros meteorológicos históricos locais para planear as condições climáticas médias de três a cinco anos. Diferentes partes do país e do mundo têm uma grande variação nas condições climáticas, portanto, planear ou não planear o risco do clima local pode afetar significativamente o sucesso do projeto.

Situações políticas locais, especialmente em climas políticos voláteis, podem dificultar todos os esforços para construir um projeto de forma eficiente. Países com sistemas políticos ou económicos instáveis ​​terão maiores riscos na conclusão de projetos bem-sucedidos do que aqueles com sistemas mais estáveis. Países ou regiões sujeitas a guerras, terrorismo, turbulência ou outros tipos de violência também correm maiores riscos para o sucesso do projeto do que outros. Se a administração local tiver uma política de exigir uma investigação profunda sobre questões ambientais ou burocracia rigorosa ou complicada, os projetos construídos nessa localidade terão um risco maior de licenças atrasadas e conflitos durante a construção.

Riscos de reputação

Outro grande risco em qualquer projeto é a experiência e a reputação da equipa do projeto para práticas seguras de construção. Violações de segurança e acidentes podem encerrar completamente uma obra. Mesmo pequenas falhas de segurança podem distrair a equipa do projeto e impedir o desempenho oportuno. Se um contratado tiver um histórico de segurança insatisfatório, o risco de atrasos por causa de violações de segurança é aumentado e deve ser levado em consideração durante o desenvolvimento do cronograma.

Em suma

Sem um cronograma de linha de base de caminho crítico bem projetado e desenvolvido, um processo de gestão de riscos não será efetivo. A análise de risco depende de cálculos precisos e consistentes da lógica da rede, da adequação do sequenciamento e das fases e de uma abordagem razoável para estimar as durações das atividades. O cronograma tenta prever quanto tempo levará para concluir uma atividade em algum momento desconhecido no futuro, com uma composição de equipa mais ou menos conhecida, com experiência variável e a trabalhar em condições desconhecidas.

A gestão de riscos reconhece a incerteza na estimativa de duração e fornece um sistema para debater estes e outros riscos que podem ocorrer durante o projeto. As distribuições de probabilidade são a melhor maneira de modelar as durações das atividades planeadas e um dos primeiros métodos usados de gestão da incerteza.

Identificar o que pode atingir o projeto

Uma séria abordagem do Risco continua a ser a maior lacuna nos projetos no nosso país.A razão para isso entronca no deficiente conhecimento mas também na dificuldade de enfrentar a incerteza de forma prática.

O primeiro passo no processo de gestão de risco é descobrir o que enfrentamos. Que tipos de coisas ameaçam a capacidade de fornecer o que se prometeu? Tudo começa com a incerteza de não saber exatamente como as coisas vão acabar. Esta é apenas outra maneira de dizer que muitos aspetos dos projetos são imprevisíveis, apesar dos esforços para realizá-los. Eis algumas das áreas mais comuns de incerteza.

Área	Descrição
Âmbito	Extensão estimada do trabalho, capacidade de definir com clareza o trabalho, erros de desenho e omissões, mudança de âmbito dirigida pelo cliente
Tempo	Duração estimada do projeto, duração estimada de atividades, tempo para o mercado, data de lançamento, escala de revisões de gestão e aprovações
Custo	Custos estimados do projeto, custos de produção do procurement, custos de manutenção, Inflação, variações cambiais, limitações de orçamento
Tecnologia	Expetativas do cliente, probabilidade de sucesso, capacidade de escalação, sucesso do design, capacidade de produção
Recursos	Quantidade, qualidade, disponibilidade, competências adequadas, definição de funções e responsabilidades
Organizacional	Prioridades e conhecimentos do cliente, coordenação entre departamentos
Adaptação	Expetativas dos utilizadores, volume de vendas, demografia, qualidade, geografia, economia
Fatores externos	Ações e reações externas, regulação

Tabela 1 - Áreas típicas de alta incerteza

A partir destas fontes de incerteza, surgem questões. Estas são o que precisa descobrir, problemas potenciais específicos, quantos você puder imaginar. Mas como vai identificar problemas? Não há uma fórmula mágica para identificar possíveis ameaças ao seu projeto. Isso exigirá conhecimento específico do projeto, capacidade intelectual significativa e capacidade de especular. Hummm ... isso soa como uma excelente oportunidade para um evento de team-building.

Os melhores eventos de teambuilding são aqueles em que os membros da equipa expandem os conhecimentos uns dos outros e do projeto ao mesmo tempo. Identificar possíveis problemas como equipa é uma maneira ideal de conseguir isso. Caracterizo o efeito de eventos como este como construção da inteligência coletiva da equipa. Especificamente, a abordagem começa pela reunião de toda a equipe. Recomendo reservar de duas a quatro horas, dependendo do tamanho e da complexidade do projeto. Reúna cada peça Reúna toda a documentação que você puder e peça aos outros que façam o mesmo.

Documentos em background típicos podem incluir o Documento de Requisitos, o Documento de Definição do Projeto e o business case. De valor mais imediato, serão os documentos de planeamento do projeto, como a WBS, o cronograma de controle do projeto e a Matriz de Atribuição de Responsabilidades. Finalmente, estruture qualquer documentação de suporte relevante, como base de planos de estimativas, suposições de planeamento e o diagrama de rede usado para o desenvolvimento do cronograma.

O ponto central de tudo isso é que pretendemos que o maior número possível de documentos ajude e estimule o pensamento sobre possíveis problemas. Uma lista de verificação também pode ser bastante útil para estimular a especulação. Considere usar uma lista de verificação similar a esta quando realizar a reunião com a equipa.

Âmbito do Projeto _ Cliente adiciona âmbito ou funcionalidades _ Trabalho não pode ser definido com rigor _ Âmbito está subestimado _ Objetivos do projeto mudam	Instalações e equipamento _Indisponibilidade _Fraca confiança _Incompatibilidade com existente _Limitações proprietárias _Fraca flexibilidade _Má localização e espaço	Pessoal _Férias/Doenças _Família e outros _Interesses em conflito _Distrações externas _Questões éticas _Questões morais
Cronograma do Projeto _ duração subestimada do projeto _ Data de fim altera-se durante o projeto _ Data de fim irrealista _ Atraso nas aprovações _ Revisões da gestão atrasam projeto	Recursos _Mudança nos elementos da equipa _Financiamento _Custos/despesas incertos _Indisponibilidades _Prioridades desalinhadas	Interpessoais _Performance/ produtividade _Conflitos interpessoais _ Desenvolvimento _Má motivação e atitudes _Competências desajustadas
Materiais _ Fonte e disponibilidade _ Integração pobre com o existente _Deficiente confiança do fornecedor _ Confiabilidade do material _Qualidade fora do standard _Alto preço	Organizacional _Difusas funções e responsabilidades _Pobre delegação _Relações más entre unidades _Falta de coordenação _Conflitos entre unidades _Pobres comunicações _Limitações de política	Influências Externas _Meteorologia e desastres _Regulação e governo _Higiene e Segurança _Barreiras culturais _Tensões políticas _Mudanças económicas _Posição política desfavorável

Tabela 2 - Lista de verificação de questões

Relacione o máximo de problemas possíveis, com o uso técnicas de brainstorming. Embora não queira sufocar a criatividade, tente manter a lista com um tamanho razoável (talvez de 30 a 50, dependendo do tamanho e da complexidade do projeto).

Ao listar possíveis problemas que ameaçam o projeto, não perca de vista o conceito de incerteza. Lembre-se de que a falta de informação, conhecimento e compreensão é realmente o inimigo. Em outras palavras, pense nas maiores “ameaças” como aquelas que têm o maior potencial para o desviar o mais longe possível - numa direção desfavorável.

Análise de Impacto As-Planned: com Primavera P6 combinado

O método de análise de impacto de atraso As-Planned é uma técnica que prevê ou prediz um efeito de atraso na data de conclusão de um projeto. Esse método de análise de atraso envolve a inserção ou adição de atividades que representam atrasos ou mudanças no cronograma de baseline para determinar o impacto dessas atividades de atraso. O uso do método de análise de cronograma As-Planned é geralmente limitado à quantificação de atrasos para pedidos contemporâneos de extensões de tempo.

A implementação da análise impacto de atraso As-Planned envolve a identificação de atrasos ou mudanças do projeto e, em seguida, inserir ou adicionar atividades, que representam esses atrasos ou mudanças, no cronograma de construção da baseline. A programação resultante demonstra o efeito dos atrasos ou mudanças na data de conclusão do projeto.

A realização da análise de atraso pode ocorrer numa situação combinada de múltiplos atrasos.

Se precisarmos ver um efeito combinado do evento de atraso 1 e do evento de atraso 2, teremos de criar um novo projeto e inserir esses eventos de atraso. Então, se precisarmos ver um efeito combinado do evento de atraso 1 e do evento de atraso 3, devemos criar um novo projeto e inserir esse evento de atraso. Este processo continua e podemos acabar com mais de 20 projetos.

Então, descobrimos que a Baseline precisa fazer um pequeno ajuste (por exemplo: adicionar mais 1 relacionamento), temos que editar os 20 projetos.

Isso vai ficar uma loucura.

Vamos ver como produzir um relatório de efeito combinado sem ter de criar todos estes projetos através do modelo de multi-projeto em Primaver4a P6.

O nosso projeto de Baseline é o da Figura 1:

Figura 1

Para 5 eventos de atraso vamos criar esses eventos em 5 projetos:

Figura 2

Pretendemos agora ver somente o efeito do Evento de Atraso 1, abrimos 2 projetos: a Baseline e o Delay Event 1.

Calculamos o projeto (F9) para vero efeito do Evento de Atraso 1. Contudo vamos de clicar na opção de Schedule “Ignore relationships to and from other projects”:

Figura 3

Faça F9 e pode ver o efeito do Evento de atraso 1 na Baseline:

Figura 4

A Extensão de Tempo (EOT) no exemplo é de 15 dias.

Agora queremos ver somente o efeito do Evento de Atraso 2, abrimos 2 projetos Baseline e Delay Event 2. Fazemos F9 para ver o efeito do Evento de Atraso 2.

Figura 5

A EOT é de 10 dias.

Agora se pretendermos ver os efeitos de ambos os Eventos de Atraso 1 e 2, abrimos os 3 projetos: Baseline, Delay Event 1 e Delay Event 2. Corremos F9 para ver o efeito de ambos os eventos.

Figura 6

A EOT seria de 25 dias.

Podemos fazer um processo semelhante como acima para ver o efeito combinado de qualquer evento de atraso ou todos os eventos de atraso:

Figura 7

Desvantagens da metodologia de análise de impacto de atraso As- Planned

Há uma série de metodologias de análise que serão usadas numa análise de atraso forense. O método de Impacto As-Planned foi amplamente utilizado nos primeiros dias do agendamento CPM, mas à medida que nos tornamos mais sofisticados no nosso agendamento, o As-Planned não é usado hoje como era, por estas razões:

O Impacto As-Planned não leva em consideração informações As-Built

O Impacto As-Planned ignora o fato de que o (s) caminho (s) crítico (s) podem mudar conforme uma programação é progredida

No entanto, na minha opinião, o método de Impacto As-Planned é simples de entender e fornece um bom ponto de partida para os planeadores que estão interessados em desenvolver seus conhecimentos de análise de atraso forense. Ele também fornece uma boa base para aprender outros métodos mais sofisticados, como Análise de Impacto de Tempo (TIA).

Gestão de Risco

A gestão de risco é um dos grupos de processos essenciais na gestão de projeto e um daqueles que é realizado elementarmente e sem consistência, quando algo é feito. Na maioria dos projetos em que me vi envolvido a gestão de risco não era um processo do projeto e a sua análise só era realizada quando algum evento gravoso se apresentava. Mesmo nessas ocasiões a abordagem era a de principiantes.

Juntei aqui alguns dos posts que escrevi ao longo do tempo sobre a gestão de risco e tentei organizá-los para que a sua leitura os conduzisse por um processo de aprendizagem.

1. Iniciação do Projeto
2. Um princípio fundamental na gestão de Incerteza
3. Análise de Risco do Projecto: O que é e porquê fazer?
4. Tipos de Risco no Planeamento
5. Categorias de Riscos a ter em atenção
6. Principais Categorias de Riscos
7. Reporting de Risco em Projetos
8. O Risco, uma técnica simples

O último post apresenta uma técnica sumária para realizar uma simples análise de risco do seu projeto elencando os principais elementos que são origem de risco.

Tipos de Risco no Planeamento

Os riscos de agendamento são ameaças e oportunidades que afetam de qualquer forma o sucesso do projeto. As ameaças comprometem a realização de metas em projetos, entretanto, as oportunidades aumentam a probabilidade de atingir esses mesmos objetivos.

Assim, os riscos podem ter bons ou maus impactos no nosso projeto, mas que tipo de risco podemos encontrar nos cronogramas de projetos?

Há principalmente dois, e eu digo "principalmente", porque alguns especialistas mencionam mais, embora estes pudessem ser considerados parte disto. Estes são INCERTEZA DE DURAÇÃO e EVENTOS DE RISCO.

Quando realizo workshops de identificação de riscos, apresento o exemplo a seguir para observar e compreender a diferença entre a incerteza e os eventos. Que depois se esclarece por si.

Um exemplo

Se eu perguntar, quanto tempo leva para ir de sua casa ao escritório, o que iria responder? Vamos dizer que a sua resposta é 45 minutos. Leva esse tempo quase todas as vezes, todos os dias. Mas isto não é sempre. Às vezes leva 40 minutos, talvez porque conduziu um pouco mais rápido, outros dias você faz 50 minutos apenas porque você fez uma pequena paragem para dizer olá a um amigo e, é claro, há dias que você leva apenas 45 minutos. Há, assim, incerteza na resposta de "45 minutos". Você deu a melhor estimativa. Alguns chamam-lhe de "média", embora não seja.

Agora vamos introduzir algo mais. Suponha que um dia há um acidente de trânsito sobre a sua rota e a estrada é fechada. Fica preso na estrada. Tem que conseguir outra maneira de chegar ao escritório, e esta estrada é mais longa. Naquele dia leva duas horas para chegar. Desta vez, aconteceu evento, e chegou tarde 1 hora e 15 minutos. Fora de qualquer previsão.

O mesmo acontece com as nossas atividades agendadas, oferecemos nossas melhores estimativas de duração, mas elas estão sujeitas a incerteza e a eventos que podem afetar a duração do cronograma de forma positiva ou negativa.

Modelar o cronograma com este tipo de análise de risco produz cronogramas mais realistas

O tratamento para cada um destes tipos de risco é diferente.

A incerteza é tratada com simulação de Monte Carlo, o que é realizado pelas aplicações que fazem gestão de risco. Neste processo executa-se um grande número de iterações com base na propagação e os limites das estimativas de duração, de modo que muitas combinações de durações são usadas.

Os eventos de risco podem ocorrer ou não durante o Projeto, a melhor maneira de modelar eventos é colocá-los num registo, que aborda as atividades com impacto, a probabilidade de existência e a magnitude do impacto nas atividades. Depois disso, pode executar cenários de hipóteses com os eventos de risco que têm maior exposição ao risco (probabilidade x impacto) adicionando fragmentos ao seu Cronograma e analisar os resultados. Se o evento realmente pode ter impacto no seu projeto, será necessário atenuá-lo de qualquer forma para reduzir o risco. Claro, que isso vai custar dinheiro.

Iniciação do Projeto

Muitas decisões são tomadas durante a vida de um projeto, mas a decisão que como maior impacto de todas é a primeira; esta é a decisão de executar o projeto. Vamos analisar a fase de iniciação do projeto que decorre antes dessa primeira decisão.

Para a primeira decisão devemos realizar a análise cuidadosa dos benefícios do projeto potencial, as necessidades de recursos, os custos e o peso do portfólio organizacional e congruência estratégica e tudo ponderado então proceder à decisão de iniciar o projeto. Como os esforços de iniciação do projeto normalmente começam informalmente, muitas vezes a decisão e esta ponderação não é executada de forma tão rigorosa como necessário.

A análise de potencial de projeto, normalmente é embalada numa proposta formal de iniciação do projeto. A proposta, de facto, é a saída ou resultado do processo de iniciação do projeto. Importa ser claro. O sucesso da decisão de "go/no-go ' deve basear-se numa análise disciplinada e completa que culmina na proposta de iniciação do projeto. E, sim, como mencionado, o projeto potencial deve ser considerado à luz de outros projetos da organização e da mais abrangente estratégia. Embora os projetos possam variar em tamanho ou complexidade existem princípios comuns que devem ser empregues antes de decidir sobre cada implementação do projeto.

Neste artigo descrevo alguns princípios fundamentais para apoiar a decisão de aprovação de lançamento de iniciação do projeto.

Input dos Stakeholders

É essencial manter a comunicação das partes interessadas durante todo o ciclo de vida do projeto, mas o envolvimento das partes interessadas é especialmente importante na fase de iniciação do projeto. A fim de incluir e envolver as partes interessadas certas deve considerar o seguinte na sua pesquisa:

• Todas as pessoas que podem interagir com o produto ou serviço. Isto inclui não só o utilizador final, mas também os fornecedores e providers da manutenção. Entenda o problema ou oportunidade a partir da perspetiva em que cada um é afetado diretamente.
• Mude os defensores e opositores. Alguns defensores incentivam a mudança, enquanto outros procuram manter o status quo. Quais são os motivos por trás de ambos os lados do argumento de mudança?
• O cliente é definitivamente impactado pelo projeto e a importância de ouvir o input do cliente tem de ser sempre enfatizada.
• Estado e administração local. Sim, as leis e regulamentos dos órgãos do governo tornam-nos numa das partes interessadas.
• ·         Cultura e valores. O apoio ou desaprovação podem estar profundamente enraizados em crenças fundamentais, que podem ultrapassar os benefícios propostos. 

O propósito de mencionar este processo de estudo das partes interessadas não é encorajá-lo a aprofundar o mundo das partes interessadas, mas antes reconhecer a importância, desde o início, de uma análise exaustiva das partes interessadas para o conhecimento do projeto. O valor do conhecimento das partes interessadas é o de proporcionar a deteção precoce de requisitos e restrições. Quanto mais cedo os conhecermos, mais baratos são de gerir.

Clarificação dos Problemas

Não compreender verdadeiramente qual o problema que é preciso resolver é um erro muito comum. Então, gastar tempo a definir o problema, e empregar a "análise de intervalos", o que explica o problema como a diferença entre o estado atual e o ideal.

Compreender que o estado ideal estabelece um quadro para a avaliação de alternativas. Disciplinando-nos para definir adequadamente o problema proporciona soluções mais plausíveis e, possivelmente, melhores. Se realmente entender o problema então será capaz de desenvolver uma melhor gama de soluções viáveis.

Analise diversas alternativas

Se identificou completamente o problema, então terá várias soluções para explorar. E considerar ainda outras abordagens alternativas inspira outras novas ideias para resolver o problema. O objetivo depois é classificar estas soluções de acordo com seus custos e benefícios.

O desafio na análise de alternativas é que normalmente comparamos maçãs e laranjas: opções com vantagens diferentes e desvantagens. Quantificar os custos e benefícios permite ver as diferenças entre as alternativas. Os benefícios são tangíveis ou intangíveis. Os benefícios tangíveis são mensuráveis. Descrever e quantificar cada benefício tangível, e listar os seus pressupostos. Embora os benefícios intangíveis sejam difíceis de medir mesmo assim são importantes. Mais uma vez, deve descrever o benefício, os pressupostos e a probabilidade de sucesso. Além disso, deve considerar e comparar os recursos necessários para cada abordagem.

Encontrar formas de quantificar e comparar custos e benefícios permite perceber porque perseguir um menor custo e uma opção de menor alcance é melhor do que uma opção mais cara que tem todo o âmbito de aplicação, ou seja, "todas as funcionalidades”. Será que o ótimo é mesmo inimigo do bom?

Considere o portfólio e a estratégia

Chegado ao ponto em que não só definiu o seu problema, mas tem também uma solução proposta – o seu projeto. Antes da empresa mergulhar na execução do projeto devemos querer considerar se o projeto corresponde aos critérios de seleção. A maioria das empresas categorizam os projetos dentro de uma carteira de projetos. Os fatores principais ou benefícios dos projetos estão geralmente nas seguintes categorias:

• Conformidade/regulação. Os requisitos do projeto são orientados para a necessidade de certa lei ou regulação.
• Eficiência/redução de custo. O propósito é diminuir os custos operacionais.
• Aumento do rendimento. Estes projetos tendem a ser de risco elevado, mas tem resultados muito desejáveis e favoráveis.

As empresas alocarão recursos e o risco entre estas categorias tal como um investidor do mercado de ações distribui dinheiro entre os investimentos de renda e de capital fixo. O objetivo do investidor é diversificar os investimentos para reduzir riscos e aumentar os ganhos potenciais. As empresas diversificam projetos entre as categorias de projeto para minimizar o risco e obter alavancagem para o ganho máximo. Além de classificar o projeto, indicar como o projeto se alinha com outros projetos da empresa e a estratégia global da empresa.

Sumário

Os pré-requisitos da decisão de início do projeto incluem, com a consulta a uma ampla variedade de partes interessadas, esclarecer o problema, analisar alternativas, e considerar portfólio da empresa e estratégia. O resultado desses esforços de iniciação do projeto será uma proposta de iniciação do projeto que é adequada para o processo de seleção da empresa.

A decisão de "go no-go 'decisão pode ser parte de um processo de gestão de portfólio de projeto ou uma decisão pessoal de um executivo. É importante a execução de trabalho base de apoio a uma decisão de iniciação bem sucedida. Mais uma vez, a decisão de executar o projeto tem o maior impacto. Pode não ter a autoridade para tomar essa decisão, mas pode estabelecer a base para uma decisão de compromisso bem sucedida. E às vezes a melhor decisão é a de não prosseguir o projeto.

Chegar a acordo com a Data de Conclusão

Por definição todos os projetos tem de ter uma data de fim. A forma como o planeador e o gestor do projeto chegam a essa data e como a equipa de projeto enfrenta a data de fim varia muito de projeto para projeto. Nada tem mais efeito na equipa do projeto que a data de conclusão do mesmo, e não há nada que crie mais stress nas pessoas que estão envolvidas efetivamente no trabalho do que a forma como é compreendida a data de conclusão por todos. Chegar a acordo com a data de fim, significa conseguir ganhar para a data de conclusão todos os envolvidos no projeto. Todos tem de acreditar que o projeto pode ser feito até essa data.

Em termos gerais, temos três diferentes maneiras de encontrar a data de fim de um projeto e se as entendermos isso ajudará a equipa a chegar a acordo com isto.
 

A data indicada

Quando a data de conclusão é indicada pelo cliente ou pela gestão, o gestor do projeto tem de aceitar isso e planear o agendamento do projeto à volta desta data de fim. Embora isto não seja a forma ideal de planear um projeto é a mais comum no mundo de hoje. Se o gestor de projeto tenta puxar a data para mais tarde, o cliente pode decidir encontrar uma nova equipa para realizar o trabalho.

Esta é a data mais difícil para chegar a acordo internamente porque muitas vezes não faz qualquer sentido para a equipa. O gestor de projeto vai ter de equilibrar entre a realidade do agendamento para encontrar a data; terá compreender que âmbito pode ser realizado para cumprir a data indicada. Terá de ser compreendida também a necessidade que está por detrás da indicação da data de fim, pois apesar das aparências muitas vezes esta data não é arbitrária e, se a compreendermos, será mais fácil aceitá-la. Aceitar a data significa ainda enfrentar os riscos envolvidos na realização deste deadline forçado e gerir cuidadosamente o âmbito do projeto dentro dos constrangimentos de datas.
 

A data agendada do projeto

O exato oposto da data indicada é a data agendada do projeto. Esta decorre da inclusão de todo o trabalho no software de agendamento, são anotados os constrangimentos e os recursos atribuídos e o software analisa e calcula a data em que o projeto irá terminar. Esta é possivelmente a forma mais fácil de chegar a acordo com esta se tivemos em conta, de forma verdadeira, todas as variáveis.

Por exemplo, se o agendamento foi calculado com calendários de 60 horas ou semanas de 80 horas de trabalho e se as atividades foram agendadas sem flexibilidade. Então esta data agendada será tão arbitrária como uma qualquer data definida por alguém sem nenhum conhecimento do projeto. Para que a data seja adequada necessita do envolvimento do gestor do projeto e do planeador na criação de um plano com datas realistas dentro dos constrangimentos de recursos e âmbito.
 

A data negociada

A terceira forma de obter a data de conclusão é negociar a data com o cliente. Muitas vezes, esta negociação vai cair entre a data indicada e a data agendada e, embora possa não ser a ideal o gestor de projeto pode ter capacidade de a tornar aceitável desde que os riscos estejam sob controlo e sejam revistos durante a negociação. Espera-se que todos fiquem de acordo com a data depois da negociação e que isso envolva uma compreensão do que foi alcançado e quais os compromissos resultantes da negociação.

Este é o processo do bom senso e é aquele que resulta do esforço de obter a data mais adequada para todas as partes. No decurso do projeto é esta a data que decorre dos processos de atualização e revisão bem como das extensões de tempo necessárias a enfrentar as mudanças nos constrangimentos e nas necessidades afirmadas pelo cliente.

Reporting de Risco em Projetos

Os projetos devem ser reportados ao cliente com regularidade, semanal ou mensal. A maioria deles têm muitas vezes regras predefinidas com alguma profundidade para medida do trabalho realizado e seu controlo. Este é o reporting normal de progresso, mas se precisarmos de reportar os riscos e as questões em aberto, como devemos fazer?

 
As normas de gestão de projeto têm alguma orientação para reporting de informação de risco?

Não. A prática de risco do PMI não inclui nada e o PMBoK fala só acerca de relatórios de performance, mas não fornece nenhum detalhe sobre o que devem estes relatórios incluir. Assim, cada um e em cada caso deve ser definida o conteúdo dos relatórios.

 
O que deve ser incluído num interface gráfico de gestão de risco?

Para um relatório para a gestão sénior só deve relatar os riscos em aberto por projeto e / ou os riscos em aberto por categoria (âmbito, orçamento, plano, etc.). isto irá permitir ver se há uma área como o plano em que há maior impacto de risco nos projetos.

Não incluir:

• Número total de riscos gerais
• Riscos fechados
• Riscos com um status de impacto baixo ou médio

A razão para isto é que a gestão sénior não pode fazer muito, se alguma coisa, com esta informação. O número de riscos é por si só uma informação sem significado. Alguns podem ser muito pequenos, alguns projetos podem só ter uns poucos mas podem ser muito significativos. Uma forma melhor seria reportar sobre o impacto do risco – qual o custo de todos estes riscos se ocorrerem?

A abordagem mais adequada será confirmar junto da gestão qual a informação que lhes interessa ver. Não penso que o número de riscos ou os riscos fechados seja informação que eles necessitam para tomar decisões acerca do projeto. Os riscos por categoria, ou riscos com classificação de impacto «alto» são muito mais significativos.

 
Devo mostrar as tendência do risco ao longo dos meses?

Não. O que vai a gestão fazer com esta informação? No início do projeto são identificados muitos riscos e depois fechamos alguns e abrimos novos. Se num determinado mês se realiza uma revisão dos riscos e se identificam mais 50 as tendências vão ficar todas baralhadas. O melhor será em termos de tendências mostrar a situação para um período largo de tempo. Pode utilizar-se uma seta para indicar se o perfil de risco global do projeto está a subir ou a descer, ou usar uma métrica para mostrar se há mais ou menos riscos de «alto» impacto ou se as implicações de custo decorrentes da mitigação de risco subiram ou desceram.

 
E então como reportar as questões e problemas?

Para a gestão sénior só deve mostrar as questões de alta prioridade e em aberto. Em termos de progresso, importa mostrar as questões de «alta» prioridade fechadas durante este mês. Isto mostra o progresso que se está a realizar na resolução de questões, mesmo quando surgem novas questões. Se não fizer dessa forma, o relatório mostrará que existem 20 questões abertas com um status de «alta» prioridade este mês e novas 20 questões abertas. Contudo estas podem ser 20 questões completamente diferentes. Sem muito mais detalhe, como nomes das questões e descrição (o que certamente os sponsors não tem interesse em percorrer), não será fácil ver que estamos a resolver as questões e podem assumir que não estamos a enfrentar os problemas no projeto.

Incluam também as 10 mais importantes questões, com descrições a planos de ação. No caso em que o input dos sponsors é importante para a resolução das questões, não nos podemos esquecer de as incluir no relatório e são salientadas as que necessitam da sua decisão.

Aqui a melhor abordagem é conhecer o que a gestão sénior tem necessidade e pretende saber. Para isso não há como perguntar. Se os sponsors não sabem, apresente-lhes os gráficos e relatórios durante alguns meses e depois peça pelo feedback sobre o que pensam e que mais informação acham que necessitam para desempenharem as suas funções no projeto – tomada de decisão, governação e supervisão.

Um princípio fundamental na gestão de Incerteza

Existe um mito popular nos projectos e, muito em especial, nos projectos de software que impede que resultados accionáveis ​​ocorram. É comum acreditar - erroneamente por sinal - que não podemos prever o futuro.

Não é o projecto que é inerentemente incerto no futuro. São os participantes do projecto que ainda têm de identificar plenamente o trabalho real que está lá fora para ser feito e está lá o tempo todo. Mesmo que o âmbito do trabalho não tenha sido totalmente percebida antes - o progresso identifica as incertezas e quantifica as acções correctivas para lidar com essas incertezas.

Isto é bastante importante para ser dito novamente. Não é o projecto que é incerto. É a nossa capacidade de ver essas incertezas se não olharmos para elas. Esta é uma diferença fundamental entre as incertezas em finanças, sociais, políticos, ou outro sistema caótico e um projecto. Há várias razões que fazem com que não possamos ver para o futuro:

• Nós não nos podemos dar ao luxo de olhar para o futuro. Não temos tempo e dinheiro suficiente para fazer o trabalho necessário para revelar as possibilidades futuras. Significa geralmente que nós vamos descobrir isso quando chegarmos lá. Derrapagens de custos e atrasos não são incorporadas no plano. Ou vamos ter que rever o âmbito do projecto quando corremos contra o tempo e o dinheiro.
• Não sabemos onde olhar para ver as incertezas. Nós não temos as competências certas, experiência ou capacidade para saber para onde olhar. A solução mais simples é a de ir buscar alguém que o sabe fazer. Vê-los a trabalhar e aprender.
• Não queremos realmente saber as incertezas do futuro. Você não consegue lidar com a verdade (You can't handle the truth!).  É muito mais comum do que se imagina. Saber o custo e o cronograma do projecto até um nível de confiança de 80% pode fazer com que o projecto não se inicie ou seja cancelado.
• Não queremos simplesmente fazer o trabalho necessário para olhar para o futuro para ver onde o problema se apresenta, onde o custo irá ocorrer, onde podem ocorrer atrasos. Esta é uma abordagem daqueles que normalmente não são responsáveis pelo custo e do cronograma do projecto. Eles não conseguem ligar os pontos entre o trabalho e o dinheiro de outras pessoas. Isso geralmente é uma visão bottom-up do mundo.

Os problemas acontecem em projectos, essa é a natureza de todos os projectos. Gerir as questões que vão acontecer no futuro é uma factor crítico do . Não gerir isto significa que estas questões vão dominar os resultados do seu trabalho.

Reblogued from Herding Cats by Glen B. Alleman

O livro na Amazon

Planear projectos de grande dimensão com  Oracle Primavera P6

A primeira edição do Gestão com Oracle Primavera P6 para projectos de grande dimensão já está publicada na Amazon em formato Kindle.

Pode comprar aqui Gestão com Oracle Primavera P6.

Estamos a realizar actualizações mensais que depois podem ser obtidas pelos leitores.

Não tem Kindle?

Não importa? Pode ler descarregando o leitor do Kindle para o seu computador. Este está disponível em:

Free Reading Apps

Ou pode ler no seu browser em Read.Amazon.com

Estou a finalizar a versão inglesa.

Book Description

Publication Date: January 31, 2013

O presente volume tem por objectivo apresentar e documentar aos gestores de projecto que, por obrigação profissional, terão de usar o Oracle Primavera P6 como ferramenta de controlo de projecto, um processo geral mas ilustrado para enfrentarem as suas responsabilidades. Este processo decorre das boas práticas que fomos recolhendo nos projectos que acompanhámos e para o qual fornecemos as ferramentas de software e muitas vezes também serviços.

---

Product Details

• File Size: 1820 KB
• Print Length: 124 pages
• Publisher: Enfase, Lda; Primeira edition (January 31, 2013)
• Sold by: Amazon Digital Services, Inc.
• Language: Portuguese
• ASIN: B00B9BGOZO
• Lending: Not Enabled

Proteger e servir

Vem esta conversa a propósito de estar 3 dias a falar sobre a auditoria das TI e a dificuldade de manter o investimento quando a auditoria é utilizada para garanntir que é suficiente a proteção em posição.

Este lema é certamente bom para as TI, como para outras actividades mais ‘bélicas’. Ouvimos dizer muito este lema, por que parece ser o lema da polícia dos EUA e soa como uma coisa das «berças» que se usa nos filmes.

Quando olhamos para as TI parece-nos que estas só existem para criar novas respostas de TI para satisfazer as necessidades do negócio. De facto, isto não é verdade!

Servir sabemos que é o seu propósito mas também protegem.

O Departamento Financeiro não existe somente para encontrar dinheiro para quaisquer que sejam as necessidades do negócio. O departamento financeiro também existe para se preocupar com a saúde e a segurança da organização. Por vezes o departamento financeiro irá resistir a novas iniciativas simplesmente porque a organização não tem possibilidade para as custear. Esta então faz tudo para que a sua posição seja escalada para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não contra a opinião do responsável financeiro.

Da mesma forma, o departamento de TI existe para proteger os interesses das TI, dos responsáveis da organização, ao mesmo tempo que servem os seus clientes e os utilizadores. Os dois interesses algumas vezes não se alinham. A fixação corrente no Cliente – o culto do Cliente – pode ser errada e perigosa. O departamento de TI deve proteger os activos de TI da organização. Esta actividade inclui:

· A própria informação, a sua confidencialidade, integridade e disponibilidade;

· O investimento nos sistemas existentes para gerir, suportar e usar a informação;

· A capacidade para implementar sistemas novos e alterados: arquitectura, análise, desenho, desenvolvimento e implementação.

Algumas vezes, não é do melhor interesse da organização abandonar estes investimentos ou aumentar os riscos para a confidencialidade, integridade e disponibilidade da informação, de forma a responder a novas necessidades para novas TI para os clientes ou, por outro lado, por que o departamento financeiro considera que não há dinheiro para os custear.

Em qualquer dos casos, as TI devem resistir (aconselhar em desfavor) à mudança e escalar para o Executivo ou para o Conselho de Administração para este decidir se prossegue ou não.

As TI não podem ser encaradas só como um centro de custo, pelo contrário, se as suas principais actividades têm a ver a defesa da informação avultam sempre as destinadas ao prosseguimento do investimento e em apoio e resposta às necessidades dos seus clientes – o negócio. Sem este esforço de investimento, a resposta do negócio ao ambiente seria inadequada e impediria a obtenção dos resultados positivos que permitem a afirmação e desenvolvimento da organização.

Luis Quintino

Como planear um projecto Prince2

Um guia para gestores de projecto

"Um objectivo sem um plano é só um desejo." - Antoine de Saint-Exupery

O que é isto?

Planear é um processo muito natural. Todos os dias fazemos muitos pequenos planos (por exemplo, o que é que vamos ver na TV esta noite, onde é que vamos no fim-de-semana, onde é que vamos nas férias). O processo é tão natural que o mais provável é que nem sequer pensemos que se trata de planeamento, só mais uma forma da vida diária. O facto é directo, todos planeamos todos os dias e somos (como um todo) muito bons nisso.

 

De que se trata?

Tente sempre planear os projectos como naturalmente os planeia. Utilize o seguinte guia:

Comece por aquilo que pretende alcançar com o projecto (isto é, o seu objectivo) e decomponha-o em coisas que tem de fazer para o alcançar. Por exemplo, se quiser umas ‘boas férias’ no próximo ano (e pretender conseguir uma reserva barata) pode querer começar hoje o seu projecto da «próximas férias». Sabe que para ter umas boas férias tem de fazer uma reserva de férias, reserve também espaço num lar para o gato e assegure-se de que alguém toma conta dele. Numa data acordada terá de pagar a Reserva e fazer a mala e obter transporte para o aeroporto. São seis coisas (a que chamamos ‘produtos’) que temos de fazer para alcançar o nosso objectivo.

Comece pelo fim do projecto e venha de trás para afrente para ter uma ideia dos ‘produtos’ escolhidos, porque os produtos finais temos uma boa ideia do tempo que tem de estar definidos para os obter antes da obtenção do objectivo.

Faça a revisão dos tempos e assegure-se de que tem os ‘produtos’ pela ordem correcta. Muitas vezes é óbvio mas em outros casos não é assim tanto. Reserve algum tempo para garantir que alguma coisa que queremos fazer na próxima semana não esteja dependente de outra coisa que só pode ser iniciada no próximo mês.

A outra coisa que termos só de considerar nesta etapa é por alto quanto é que isto irá custar. Lembre-se que isto, neste momento, é só uma estimativa.

Possui agora um plano de alto nível (todas as coisas que (pensa) necessita fazer; nas datas que (pensa) necessitar delas). Agora decida o que tem de acontecer agora e/ou nas próximas semanas e chame-lhe a ‘primeira etapa’. Se apropriado divida o resto do projecto em etapas e registe-as no seu plano. Agora foque-se na sua primeira etapa e naquilo que tem de fazer. Para cada ‘produto’ na primeira etapa, deve responder a algumas perguntas específicas:

• O que tenho de fazer?
• Qual é o orçamento?
• Quem vai fazer o trabalho? E estará disponível para o fazer? (já falámos com eles e conhecem o projecto).
• Como é que vou saber quando está terminado na forma adequada?

Com a resposta a estas perguntas criamos um pequeno plano para a etapa e para que consigamos obter os ‘produtos’ completos.

A não ser que seja você a fazer o trabalho, não se preocupe com as tarefas passo a passo de como é que o trabalho será feito, antes acorde a sua realização com quem irá ser responsável por cada ‘produto’ e saiba como se irá manter em contacto. Isto é, Como e quando será informado do progresso e como irá ser comunicado se as coisas correrem de forma inadequada.

Finalmente, quando tiver concluído o seu plano, peça a toda a gente para olhar para ele e pense simular o que é que poderá correr mal. Isto pode parecer muito pessimista mas pode poupar tempo e esforço mais tarde. Para tudo aquilo que pode correr mal veja se pode fazer alguma coisa para reduzir as possibilidades de isso acontecer. Pense também o que poderá fazer se de facto correr mal. Mantenha todos estes riscos para o projecto num Registo do Projecto e reveja-os com regularidade.

 

Quem faz o quê?

Como gestor do projecto será o responsável pelos planos do projecto. Isto não significa, no entanto, que os deve escrever isolado, longe disso. Consulte as pessoas o mais possível, tente realizar workshops para incluir os outros no seu plano.

 

Quando é que acontece?

Planear é um esforço contínuo ao longo do projecto. Podem acontecer muitas coisas durante o projecto que o irão forçar a fazer mudanças controladas aos seus planos. Nenhum plano deverá sobreviver na sua forma original desde o início do projecto até ao seu fim.

 

Dicas e armadilhas

Se tem de usar uma ‘ferramenta’ como o MS Project, lembre-se que esta irá tentar e forçar o planeamento ‘não natural’, isto é, adicionar actividades individuais desde o início do projecto até ao fim, assim tente planear primeiro os ‘produtos’ e depois carregar os dados na ‘ferramenta’.

Planeia a próxima etapa antes do fim da etapa corrente. Quando chegar ao fim da etapa, apresente ao sponsor uma visão completa do que foi realizado até à data e o que é que pretende realizar na próxima etapa.

 

Documentos chave

 

O Documento de iniciação do projecto (PID)

O PID é o centro de toda a informação de definição relacionada com o seu projecto. Ou seja, os seus objectivos, o business case, as comunicações, o plano de qualidade, etc.

 

O plano do projecto

O plano do projecto compreende o seu plano de alto nível e o plano da etapa corrente. Pode ter muitas formas e isso exige que você garanta que usa alguma coisa apropriada para o projecto que está a gerir. Note que os planos de projecto são muitas vezes definidos dentro do Documento de iniciação do projecto (PID) em vez de num documento separado.

 

Descrições de produtos

A maneira mais fácil de chegar a acordo nos ‘produtos’ é utilizar descrições dos produtos – podem ser contidos numa folha de papel e deforma sucinta conter toda a informação que o gestor do projecto e a pessoa responsável pelo ‘produto’ necessitam para realizar com sucesso o produto.

 

Work Packages

Um work package destina-se a acordar uma relação de trabalho entre o gestor do projecto e o responsável pelo trabalho para a realização de uma parte ou de um ‘produto’ do projecto.

 

O registo do projecto

Detalha todos os riscos do projecto e toda a outra informação e é muitas vezes o documento mais útil a par com o PID e o plano.

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.

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)