A implementação do BIM e o Controlo do Projeto

As diferentes legislações nacionais, mais cedo do que mais tarde, irão gradualmente exigir a aplicação de BIM nas obras de construção e infraestruturas do setor público. Isso significa que os projetistas, empreiteiros e as cadeias de fornecimento na indústria irão necessitar de alterar as formas de trabalho e adaptar-se à nova legislação que sairá. O objetivo é de adotar uma progressiva melhoria e com isso melhorar em paralelo de forma significativa a eficiência da indústria desde as fases de desenho, procurement, construção e gestão do projeto até à gestão operacional subsequente do ativo ao longo da sua vida.

O Que é o BIM?

A utilização de desenho a 3D tem ajudado a indústria a coordenar as características arquitetónicas, a estrutura e os serviços de mecânica, elétricos para as obras públicas. O nosso mundo é tridimensional e, como tal, ser capaz de visualizar um espaço pelo designer, o construtor e o cliente dá uma reforçada interação em volta do ativo a ser construído quando se compara com as plantas, cortes e elevações tradicionais em 2D.

O poder da modelagem em 3D permite identificar pontos críticos e detalhes de planos e secções. Além disso, o modelo 3D pode ser ligado com um plano de trabalhos para mostrar uma simulação de como se pretende construir o edifício ou infraestrutura (a modelação 4D). Se dermos um passo mais à frente e introduzirmos os custos no modelo adicionamos uma nova dimensão – agora é 5D, desta forma a informação de controlo do projeto fornece índices de custo e performance conforme se atualiza o modelo.

Um dos principais desafios de incorporar toda esta informação é a capacidade de integrá-la a partir de sistemas diferentes: o modelo 3D do ativo, a informação de higiene e segurança, o plano de trabalhos de construção, a lista de quantidades, o sistema financeiro, o sistema de gestão de ativos. O facto de ainda existirem questões de compatibilidade simplesmente na importação / exportação entre ferramentas como o Primavera P6 e o Excel – para além do complexo processo de integração de cliente / utilizador para colocar o Primavera P6 a trabalhar com a gestão de custo do Deltek Cobra – sugere que estamos num mundo muito longe da total compatibilidade que o modelo BIM exige para alcançar o BIM 5D.

Gestão da Informação – sempre na raiz do problema

Podemos pensar que o problema reside na falta de integração entre sistemas de TI para os diferentes processo requeridos para realizar o projeto. A questão reside muito mais longe daqui. É a falta de uma estratégia de gestão da informação entre diferentes disciplinas que interagem no projeto. Esta visão apoia-se ainda nas sumulas das diversas conferência de gestão da construção que acompanhei.

Demasiados processos exigem a duplicação de esforços no decurso do ciclo de vida do projeto que deveriam poder ser evitados se fosse adotada tal estratégia de gestão integrada da informação do projeto logo a um nível comparável a um PMO. Esta lacuna gera ineficiências que corroem as já reduzidas margens da indústria.
 
Como exemplo, deixem-me descrever a realidade nas nossas empresas no que se refere a esta omissão. Os empreiteiros são obrigados contratualmente a reportar as quantidades instaladas relativamente às planeadas para suportar a percentagem física de conclusão dos trabalhos que irão informar os índices dos controlos de performance do projeto. Isto significa que a Lista de quantidades necessárias trem de ser mapeada no plano do Primavera P6 ou outra ferramenta de CPM. Contudo, o estimador e o planeador durante o período de definição do plano da obra não falam um com o outro e a informação que produzem (Mapa de Quantidades e Plano) está de forma consistente desalinhada. Não são atribuídos códigos de custo às atividades do projeto. As folhas de abertura de trabalhos, na maior parte das vezes, não têm qualquer referência a um número de desenho. Em resumo, uma enorme confusão para qualquer pessoa que queira fazer algum sentido do quando e onde as quantidades de construção serão instaladas.
 
Na investigação do sentido do trabalho desta obra, quando se procuram o estimador e planeador do plano comercial para obter a informação, a mais das vezes estão já em novos contratos, quando não saíram da companhia. Vai então recorrer-se a novos recursos para por em ordem toda esta informação sem sentido e estes percorrem toda a informação para compreenderem o desenho do projeto, a sequência de construção e as suas relações com as atividades do plano do projeto, mapa de quantidades e até as folhas de abertura de trabalhos. Em todo este retrabalho perde-se tempo valioso para realinhar o Mapa de Quantidades com o plano, por forma a poder reportar de forma adequada e em conformidade com o contrato.
 
Esta situação ocorre com os empreiteiros com processos e ferramentas apropriadas, mas a realidade, na maioria dos casos, estes utilizam ferramentas de planeamento que não mapeiam nada disso e que com muita dificuldade conseguem fornecer informação confiável ao cliente – o projeto vive assim numa mentira com folhas de cálculo a serem trocadas e com percentagens definidas de forma quase aleatória. Portanto, os projetos não são geridos numa forma conforme ao contrato e os resultados enfermam de toda esta ficção. 

Ineficiências e falta de produtividade

Há muitas ineficiências observadas na indústria, tal como as questões descritas acima na forma de realização dos contratos, até à dupla aquisição de materiais e o desperdício, sequenciação inadequada da construção, retrabalhos, só para enunciar algumas. BIM visto unicamente como uma ferramenta não é a solução destas questões.

A solução é a implementação de uma estratégia de integração da informação dentro das organizações que possa fornecer informação consistente e compatível alinhada com os requisitos das diferentes etapas do ciclo de vida do ativo. A definição desta estratégia ao nível do PMO que estabelece a solução apropriada de gestão da informação é a chave deste desafio, tal como é a disponibilidade de recursos competentes para a implementar e gerir. Muito mais fácil de dizer do que fazer, claro!

Assumam que desde a etapa inicial de um projeto a solução de gestão de informação é considerada em linha com os requisitos BIM do cliente. Se a solução é implementada desde a etapa de proposta comercial irá reduzir o tempo despendido e os esforços sujeitos a erro de ligar as peças diferentes depois de o contrato ter sido atribuído ao empreiteiro. O projeto poderá então progredir através das suas fases de vida do desenho, à construção e à operação, tendo cada interface os próprios desafios de integração.

Ao nível do PMO, estes desafios devem ser enfrentados o mais cedo possível na vida do projeto e resolvidos através da inclusão das ferramentas apropriadas nos diferentes processos de gestão. Ora, na maioria a totalidade das empresas de construção nacionais nem sequer ainda pensou numa estrutura de PMO ou tão só tentou integrar com efetividade todos os processos de gestão.
 
Muitos empreiteiros orgulham-se da sua utilização ocasional da modelação 3D na realização de um ativo para um cliente. Devem lembrar-se que este é só o primeiro passo na redução das ineficiências da indústria, e só uma parte pequena do âmbito que o BIM pode realizar. Os exemplos desta utilização – embora muito poucos – surgem em áreas como a saúde, a segurança, gestão de risco e da qualidade e mostram o valor do BIM como uma inestimável ferramenta multidimensional.

Em conclusão

A junção da estratégia de gestão integrada da informação com os controlos do projeto irá melhorar a exatidão dos KPI e, se realizada de forma correta, poderá ser o primeiro passo para a criação de uma base de dados de imenso valor comercial (com informação estatística sobre a performance de todos os tipos de trabalho).

A integração BIM estará sempre condicionada à junção de desenhos, planos, custos e sistemas financeiros. Esta estratégia BIM deverá poder integrar todos os requisitos globais da indústria.

LQ

Mostrar as Variâncias

Este procedimento permite mostrar uma barra que mostra as diferenças entre as datas da baseline e as datas correntes.O P6 não tem incluída uma barra de variância mas há um modo de a criar. Vamos usar um exemplo em que as datas da baseline são as correspondentes à baseline primária e queremos mostra a barra de Variância para o fim.

Os passos são os seguintes

Vá para Enterprise User Define Fields e adicione 2 novos user define fields. Para o primeiro, garanta que o Data Type é definido para Start Date. Para o segundo defina o Data Type para Finish Date.
Vá para Tools Global Change e crie uma nova global change. Vamos denominá-la “Store Variance Date”.
Na declaração Then estabeleceremos o primeiro parâmetro como user defined field da Start Date que criámos atrás, e tornamo-lo igual à data de baseline que pretendemos usar. Neste exemplo utilizaremos o BL1 Finish, por queremos a variância de fim.
Adicione uma nova linha à declaração de Then. Defina este parâmetro como a data de Fim do user defined field que foi criado no passo 1 e ponha-o igual à data corrente que quer usar. Neste exemplo será Finish porque pretendemos usar uma variância de fim. Clique OK.

Clique Apply Change para aplicar a Global Change. De seguida na janela de relatório clique em Commit Changes. Irá perguntar se quer guardar o ficheiro do relatório e isso é consigo fazer ou não.
Quando terminar a aplicação da global change, vá para View Bars para adicionar uma nova barra no botão Add.

Dê à barra o nome que quiser, por exemplo “Variance Bar”. Na coluna Timescale escolha User Dates. Na coluna de User Start Date coloque a Start date do user defined field criado atrás. Na coluna de User Finish date ponha a Finish date do user defined field criado. Qualquer formatação a fazer a isto será opcional. Clique OK. Está feito!

Barra de Variância para Milestones

Se pretender mostrar a Variância nas Milestones o processo é o mesmo excepto que a Global Change deve ser a seguinte (porque as Start Milestone só têm data de início).

Para ver somente as variâncias das Milestones deve alterar o filtro de All Activities para Milestones no menu de Bars.

REPORTING COM 4 SEMANAS À FRENTE

Uma vez que o plano do projeto foi criado, foi criada a baseline e começou a execução vai iniciar-se o processo de acompanhamento do progresso. Em apoio a este esforço, não é raro pretender mostrar todas as atividades que ocorrem em digamos, as próximos 4 semanas.

Uma boa prática reconhecida incentiva a que se concentre em elencar os próximos passos necessários para manter o avanço do progresso do seu projeto. A beleza da Primavera P6 é que ele pode exibir tudo o que começa ou está em progresso ao longo dos próximos 4 semanas. Estes são os próximos itens do trabalho no seu cronograma do projeto.

O Primavera P6 Professional tem características de filtro que permitem escrever uma rotina de filtro para exibir os itens da próxima etapa. Então, se está apenas a reportar o que está próximo, no futuro próximo ou quer acompanhar o progresso do cronograma, este recurso a um filtro apoia o esforço. Neste post vamos mostrar como criar um filtro para quatro semanas à frente para facilitar o acompanhamento do progresso.
A Figura 1 abaixo mostra um projeto de demonstração.

Figura 1

Este é um plano que progrediu um mês, Janeiro. As barras azuis no gráfico de Gantt indicam o trabalho concluído, enquanto o vermelho e verde indicam trabalho crítico e não crítico futuro, respetivamente. Para criar um filtro selecione o ícone de filtro, a Figura 2.

Figura 2

O que faz mostrar o diálogo de Filtros, Figura 3.

Figura 3

Este diálogo tem três secções: filtros padrão que vêm de fábrica com o P6, filtros globais criados pelo administrador do sistema e filtros definidos pelo utilizador. Queremos criar um filtro definido pelo utilizador, de modo a destacar na seção definida pelo utilizador e selecione + Novo. Agora queremos capturar todas as atividades que começam nas próximas quatro semanas, de modo que a primeira linha de nosso filtro seja como na Figura 4.

Figura 4

O parâmetro que estamos a usar é 'Start'. A equivalência é "Within range of". O valor baixo é Data Date (DD). O DD é a última data até onde foi registado o progresso. A razão pela qual nós selecionamos DD e não a data atual (CD), que é a data de hoje, é porque queremos que as atualizações meçam o progresso desde a último dia em que foi gravado o progresso no nosso projeto.

Se essa é a nossa intenção, então queremos que as quatro semanas de foco devam começar na DD e não na CD, que pode ser diferente do DD. O valor alto é DD mais 4W (quatro semanas). Vamos testar o nosso filtro, Figura 5.

Figura 5

Na Figura 5 vemos que todas as atividades que começam nas próximas quatro semanas de fevereiro, são exibidas. O único problema é que as atividades que começaram em janeiro, mas continuam em fevereiro não são exibidos. Portanto, precisa adicionar uma outra linha de código para a rotina de filtro.

Na linha dois do nosso filtro capturamos todas as atividades que começaram em janeiro, mas estão em progresso durante as próximas quatro semanas de fevereiro. Como apresentado na Figura 6, o parâmetro é 'Activity Status, a equivalência é "igual", e o valor é "In Progress".

Figura 6

Com esta nova linha adicionada ao filtro, testamos a sua eficácia, ver Figura 7.

Figura 7

O que aconteceu? Agora o filtro não mostra nenhuma atividade.. O problema é que o primeiro parâmetro, que é o padrão, é ‘All of Foillowing?, Figura 8.

Figura 8

Isto coloca uma condição de And depois de cada linha de código. Este ‘And’ significa que ambas as linhas de código, quer a primeira como a segunda, sejam verdadeiras para que essa atividade seja mostrada. Mas, não há atividades que respondam ao critério porque não pode haver atividades que estejam em progresso e se iniciem nas próximas quatro semanas. Na Figura 9 temos o código com o parâmetro correto que é ‘Any of the following’.

Figura 9

Como mostra a Figura 9, esta opção coloca o código ‘Or’ entre a primeira e a segunda linha. Agora o código do filtro captura todas as atividades que começam nas próximas quatro semanas ou estão em progresso. Na Figura 10 vemos o relatório resultante do agendamento.

Figura 10

Em Suma

A funcionalidade de Filtro do Primavera P6 é robusta e flexível e permite criar o código que suporte o reporting de progresso do agendamento.

O ponto-chave para se lembrar é observar se o seu parâmetro de origem está definido para "All of the following" ou "Any oif the following". Isso determina se todas as linhas de código devem ser verdadeiras para cumprir os critérios de filtro ou uma qualquer linha de código deve ser verdadeira. Este fato deve ser a primeira configuração a olhar para verificar como começa a solucionar o código de filtro. 

Razões para as falhas nos Planos de Projeto e como as evitar

Os planos de projeto em caminho crítico, quando a equipa não está a puxar para o mesmo lado, apresentam-se erróneos, apesar das melhores práticas usadas. A integridade do cronograma pode não ter nada a ver com a razão por que se tornou inútil ou sem sentido, ou como eu gosto de dizer, um gravador mais do que um preditor do caminho crítico e do progresso. Se o projeto é grande e tem múltiplos empreiteiros principais, o cronograma é bem mais suscetível de degradação.

"Um cronograma de CPM deixa de atingir o propósito pretendido, logo que se torna um gravador, em vez de um preditor.”

Muitas vezes, a falha de programação é previsível. Mesmo assim, pode parecer inevitável. No entanto, para cada obstáculo ao sucesso, há um caminho ou solução alternativa. Às vezes este é um remédio amargo e difícil de tragar. Cabe ao planeador fazer tudo o que puder para manter a integridade da programação do projeto. O que descrevemos abaixo destina-se a destacar os obstáculos mais desafiadores para planear o sucesso e oferecer soluções para estes.

Porque é que os cronogramas de caminho crítico na engenharia e construção são negligenciados, ignorados, incompreendidos e considerados inúteis?

Voto de desconfiança

Muitos profissionais da construção não ligam aos cronogramas de CPM (gestão de caminho crítico), talvez como resposta a experiências passadas, ou mais frequentemente, o voto de desconfiança é apenas destinado a mascarar a sua inexperiência que compromete a imagem profissional que pretendem passar.

Reconheça que planear em CPM é uma ciência que geralmente não é bem compreendida por não planeadores. Ignore a crítica desconstrutiva, ou tome-a como uma oportunidade para um momento de educação.

Faltas de reporting

Muitos empreiteiros pensam que podem passar com uma baseline e, subsequentemente, com um mínimo de atualizações de status possíveis. Talvez não sejam simplesmente obrigados pelo CM ou pelo proprietário.

Mantenha a procura de dados todos os meses e submeta uma atualização adequada, mesmo que não seja exigido. Impressionar sobre o empreiteiro a importância de manter atualizações mensais, especialmente no que se refere a reclamações. As reclamações  que têm lacunas de relatórios são mais prováveis de serem recusadas pelos revisores.

Erros de reporting e omissões

Muitos empreiteiros não mantêm registos precisos do progresso e são forçados a adivinhar nas datas atualizadas. Essa adivinhação pode voltar a assombrá-los se o proprietário tiver datas e dados diferentes. Outros simplesmente não seguem as instruções básicas do contrato. Finalmente, acreditam que apenas é necessária uma baseline de CPM.

Todos as questões acima referidas podem ser evitadas com a devida diligência. Impressione o cliente com a importância de manter o cronograma adequadamente, se por nenhum outro motivo, que seja para estar preparado em caso de reclamação.

Falta de liderança da gestão nível superior

Apesar dos poderosos MBAs, graus de engenharia e certificações exaltadas, muitos dirigentes de topo nunca vêem um gráfico GANTT adequado nos projetos sob sua administração. Eles podem considerar-se pessoas de "linha de fundo" - como se esta designação os dotasse com conhecimentos de CPM. Não.

O planeador será sempre mantido (pelo GC ou CM) o mais longe possível dos executivos do projeto, porque o seu conhecimento não dominado é um passivo. Na verdade, os resumos executivos de CPM não parecem atingir o público-alvo antes de estarem obsoletos. Estas circunstâncias estão fora do controle do planeador.

À medida que um projeto começa a perder tração, deve oferecer-se soluções e exigir o acesso a membros da equipe de nível superior para que possam ajudar a agilizar o processo ou facilitar os planos de recuperação ou mitigação ou mesmo para compreenderem uma reclamação.

Políticas

Muitas vezes, os GCs e CMs alteram indevidamente os relatórios de progresso para obterem vantagem ou ocultarem alguma outra realidade. Também manipularão e tentarão influenciar os relatórios ao seu gosto, ou adaptados ao gosto do destinatário. E no fim, eles simplesmente podem até não enviar os relatórios às partes interessadas.

Na primeira parte, é a integridade do planeador que está em questão quando se toma consciência de uma discrepância. Em suma,terá que fazer o que achou certo e deixar o responsável pelo relatório saber. Na medida em que não há nada que o planeador possa fazer para forçar o problema com as partes interessadas, ou mesmo induzir o responsável a publicar o cronograma, como deveria.

Incompreensão

Os membros da equipe da gestão da construção que ignoram o plano em CPM podem prejudicar o processo quando provam ser como estudantes sem vontade – demasiado orgulhosos para aprender. Eles também não possuem informações técnicas e analíticas. Por exemplo, à medida que um projeto vai por mau caminho, o cronograma pode ser referido como "inútil, obsoleto" ou pior, como se a integridade do cronograma dependesse do que ocorre hoje, na atualidade.

Novamente, deve educar o público quanto à diferença entre o progresso projetado e o progresso real e como a informação é disseminada numa atualização de plano.

Falta de um propósito comprometido

Muitos contratantes pensam que o cronograma é um requisito de projeto desnecessário. Como tal, eles planeiam apenas passar pelos movimentos, realizando o esforço mínimo e fazendo o planeador trabalhar mais.

Lembre o empreiteiro que manter o cronograma é como manter qualquer recurso que melhore em valor, na proporção de sua integridade, e que, no caso de uma reclamação de interrupção ser considerada, nada será melhor que um cronograma devidamente mantido.

Cedência do controlo do projeto

Os planeadores e estimadores de CPM são controladores de projetos. Ninguém mais, independentemente do seu título, o poderá ser. Apesar desse fato, os gestores de projetos tentam muitas vezes erroneamente micro-gerir o desenvolvimento do plano, em vez de o facilitar e aprofundar. Em outras palavras, eles tomam o "controlo" do "projeto": o que deve ser o trabalho do planeador. Os resultados são muitas vezes desastrosos.

Lembretes frequentes, mas gentis, geralmente induzem os gestores de projeto a serem mais amigáveis com o planeador e o plano. Deixe-os saber quando pisam a linha, ou quando pensam fora da caixa, e esforcem-se por os educar sobre as melhores práticas.

Rejeição

Muitos revisores de planos por parte do cliente deliciam-se em rejeitar ou não aprovar o agendamento enviado. Às vezes, como uma questão de posição legal: ou seja, eles acreditam que, ao rejeitar qualquer determinado cronograma, eles ganham alguma alavancagem contratual ao considerar o contratante não conforme.

Se a integridade do plano estiver intacta, e todos os requisitos das especificações cumpridos, simplesmente não é apropriado para um revisor rejeitar definitivamente um cronograma com base em aspetos técnicos mais comuns ou exigir um plano de recuperação, quando houver atrasos indemnizáveis.

Se este é o padrão, deve perceber que o revisor está a atrasar para evitar reclamação de interrupção. Pode até ser em seu detrimento para emitir um plano de recuperação ou plano de reclamação prévia – impedindo a realização. Na verdade, pode ser melhor interromper a publicação de atualizações - protegendo o cliente. Isso é certo: eu disse "parar de publicar atualizações": ou melhor, você emite-as, mas elas são retidas do revisor polémico até que um elemento imparcial possa ser escolhido para as rever.

Negligência voluntária

Um empreiteiro pode, desde o início, não ter intenção de manter o plano. Esta condição é aquela em que o planeador pouco pode fazer para mudar, além de ser persuasivo da melhor maneira que ele pensa que pode, sem ostracizar o cliente. Além disso, até talvez ninguém no nível executivo se oponha à ausência de atualizações e relatórios de cronograma, já que eles não os parecem entender ou rever em tempo útil.

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

 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).

ERROS COMUNS NO CONTROLO DE PROJETO

TEMPO EFETIVO DE TRABALHO (Média de horas /turno que um trabalhador gasta diretamente a trabalhar em atividades na construção, manutenção).

Está estimado que um trabalhador gasta em média somente 3,5 horas a trabalhar efetivamente durante um turno de dez horas; este é um número assombroso. Quando faltam na indústria já tantos trabalhadores qualificados, não seria sensato tentar aumentar a performance dos trabalhadores? As poupanças que se conseguiriam em custos indiretos (deslocações, ferramentas, segurança, condições de vida, etc.) por si próprios poderiam poupar milhões em ultrapassagens de custos, sem mencionar um fator mais baixo de risco que se alcança por se empregarem menos pessoas, mas pessoas com as competências efetivas para desempenharem com segurança o trabalho.

Se pensa que este é só um problema sindical ou de atitude, volte a refletir. Esse tipo de consideração não nos levou a nenhum lugar no passado. Então onde se localiza o problema? Bem. Em muitos casos é uma falta de efetivo suporte da gestão. Se não acredita nisto, tente então: é uma falta de compreensão da gestão.

Temos de começar a olhar para as formas como a gestão pode usar ferramentas, formação, supervisão e planeamento para apoiar os trabalhadores a aumentarem o tempo de trabalho efetivo. Isto significa criar para os trabalhadores um ambiente de trabalho seguro tão eficiente como possível e fornecer as ferramentas, direções, materiais, equipamento e apoio tão efetivo quanto possível para permitir aos trabalhadores realizarem as atividades atribuídas.

Demasiadas vezes a um trabalhador não são fornecidos em tempo, autorizações de trabalho, reuniões de definição de trabalho seguro, ferramentas, materiais e equipamento ou instruções suficientes para executar o trabalho. Perdem tempo à espera, à procura de ferramentas, de materiais, à espera de recursos de suporte e ficando frustrados com a gestão do projeto. Adicione as pausas de café, almoços, reuniões de segurança, limpezas e acabámos de reduzir a quantidade de trabalho que um trabalhador gasta nas ferramentas em mais de 60 por cento.

Mas então qual é a solução?

Passei centenas de horas com equipas de gestão, e outros recursos treinando, educando e apoiando para o desenvolvimento de estratégias para a definição do trabalho, planeamento do trabalho, agendamento e supervisão da execução. Descobri que na maioria dos casos a vontade para realizar trabalho de qualidade é prevalente em todas as categorias. Eles estão geralmente frustrados por não conseguirem alcançar as metas de performance para os seus clientes. O que falta é uma relação construída sobre claras expectativas e confiança. Os contratos são muitas vezes deficientes na definição do âmbito e dos indicadores de performance.

Uma companhia de topo terá de fazer isto através do estabelecimento de um processo formal para gestão de projeto e controlo suportado em melhores práticas na forma de políticas, procedimentos e orientações e ferramentas de gestão. Toda a gente desde os recursos a contrato até ao pessoal de gestão interno é educado no seu propósito e utilização.

A liderança e prestação de contas decorre de uma Equipa de Gestão que é estabelecida nas etapas mais precoces do projeto que assiste à definição do âmbito, à determinação dos riscos e ao estabelecimento das metas chave de performance, para a segurança, qualidade, performance do trabalho, custo e duração do plano. Através dum planeamento efetivo, contratação, procurement e agendamento a Equipa poderá determinar os números corretos de recursos diretos e indiretos exigidos para executar o trabalho.

Ao estabelecer um grupo de controlo de projeto (em oposição a um grupo de monitorização – o que é muitas vezes o caso), uma companhia pode dirigir o plano do projeto dia a dia, medir a performance, dados de tendência e realizar os ajustamentos necessários para controlar o resultado. Istro é denominado uma gestão de agendamento dinâmico.

Demasiadas vezes os projetos saem dos carris devido à falta de controlos efetivos de projeto. Vou listar alguns dos principais erros que conduzem sempre à perda de tempo efetivo de trabalho.

As companhias NÃO…

• Usam um processo formal de gestão da execução do projeto que permita à gestão de topo verificar a conclusão de milestones em etapas pré-determinadas antes das entregas. Isto é muitas vezes denominado um agendamento de Milestones ou um Processo de etapas.
• Estabelecem uma Equipa de Gestão que integre a Gestão Sénior (Liderança), um Gestor de Projeto quie reporte à Gestão Sénior e uma Equipa Central de Gestores que represente cada um dos Departamentos participantes, i.e., Manutenção, Operações, Contratação / Comercial, Administração, QA/QC, Materiais, Procurement, Ambiente, Engenharia, Logística, etc.
• Utilizam uma ferramenta formal de análise de benefício de risco / custo.
• Desenvolvem um orçamento preliminar baseado no âmbito do trabalho determinado pela ferramenta formal de análise de benefício de risco / custo. O orçamento preliminar deve ser desenvolvido com estimativas das horas diretas de Tempo Efetivo de Trabalho, suportado pelas estimativas de recursos indiretos com uso de dados standard da indústria. Usualmente o suporte indireto é 115% das horas de tempo efetivo direto.
• Estabelecem um processo formalizado de Gestão da Mudança para limitar o crescimento do âmbito e gerir quaisquer mudanças que afetem o orçamento.
• Estabelecem metas chave de performance realistas para segurança, qualidade, performance do trabalho, custo e duração do plano. Com foco na segurança e na performance do trabalho irá permitir em última análise ter sucesso no alcançar das metas de performance de qualidade, custo e agendamento.
• Criam um processo formal de gestão que permita a identificação precoce do trabalho seguido através de contratação e procurement.
• Envolvem, como muito importante, a produção e a supervisão do trabalho em obra no processo de planeamento e agendamento cedo durante a fase de planeamento. É também recomendado o uso de supervisão independente da execução em obra. Relembre que planeamento, agendamento e coordenação não são posições, são funções. Cada função necessita de ser atribuída aos recursos adequados, ou equipas, para gerir.
• Estabelecem controlos de projeto efetivos e agendam dinamicamente as atividades planeadas com base me intervalos de status regulares, i.e. dia a dia ou semanalmente nos projetos de construção.

Confiança no Cronograma e Contingências

Os cronogramas de projetos tendem para o atraso, mas o que pode ser feito para tornar os cronogramas mais confiáveis no tempo? O buffer de agendamento semelhante a uma contingência de custo ajuda os projetos a tornarem-se mais confiáveis.

Os planos de projeto geralmente são mais otimistas do que a realidade. Os motivos dessa disfunção são que os planos do projeto não consideram: ineficiências na transferência de tarefas entre recursos, o congestionamento no local de trabalho, a coordenação entre vários contribuidores e a multitarefa de recursos críticos. Pode-se pensar que não contabilizar esses efeitos de atraso seria contrabalançado pelos contribuidores que cumprissem as suas estimativas. Mas este não é o caso. Uma vez que a duração é inserida no plano do projeto (seja conservadora ou otimista) torna-se sujeita a todos os efeitos de arrasto da Lei de Parkinson e a procrastinação.

Assim, mesmo as estimativas conservadoras de duração podem tender para o atraso na execução. O que pode ser então feito para tornar as durações da atividade competitivas e confiáveis? Inclui na programação um buffer de agendamento semelhante a um item de linha de contingência de custs. Os itens de linha orçamentais não são preenchidos e o projeto geral está protegido contra gastos excessivos com uma contingência de custos. Esta mesma abordagem funciona bem para proteger o cronograma e manter as durações da atividade competitivas.

Este post discute como incluir um buffer de agendamento para que a duração da programação permaneça competitiva e confiável no objetivo.

Temos um cronograma de projeto na Figura 1.

Figura 1

Este agendamento tem dois caminhos que são igualmente críticos.  As estimativas de duração nos dois caminhos incluem alguma folga. A data de fim do projeto é 22 de Junho de 2018.

Na figura 2 ajustámos as durações das atividades para remover a folga e ron´las mais realistas e competitivas.

Figura 2

Note a linha de base original e as durações correntes de atividade. As economias de tempo cortando as estimativas de duração são combinadas numa atividade de buffer. O projeto ainda está programado para finalizar em 22 de junho de 2018.

Temos um cronograma muito mais confiável do que a Lei de Parkinson ou o arrastão devido à procrastinação. (A Lei de Parkinson diz que o trabalho tende a preencher todo tempo alocado). Os membros da equipa trabalham cada vez mais rápido, de acordo com as durações mais agressivas de atividade. E o atraso em qualquer caminho crítico pode ser absorvido pelo buffer. Isso proporciona ao gestor do projeto uma ferramenta para prolongar as durações de atividade relevantes quando necessário.

Felizmente, todas as atividades estão de acordo com as estimativas do plano e o projeto acaba cedo. Caso contrário, o cronograma, incluindo o buffer, ainda é um cronograma muito mais confiável. O trabalho é realizado com mais senso de urgência e o gestor de projeto pode distribuir buffer, de acordo, para atividades que realmente precisam de extensão.

Em suma

Uma linha de item como buffer de agendamento similar a um item de contingência de custo encoraja um bom ritmo de trabalho e melhora a confiabilidade. O fator-chave que faz com que o buffer de agendamento funcione é que ele é de propriedade e controlado pela gestão. Possível discussão sobre quem controla o buffer, pode levar alguns a ocultar este buffer nas suas atividades de agendamento de final do projeto, como o comissionamento.

Acredito que o buffer funciona melhor quando é claramente visível no cronograma. Este buffer ajuda a limitar os efeitos negativos da Lei de Parkinson e a procrastinação. Além disso, o buffer é uma ferramenta adicional de gestão de projetos para estender apenas essas atividades que têm necessidade real de ajuste. Assim, o buffer torna o cronograma mais confiável, pois o gestor do projeto começa com um cronograma comprimido e direciona a extensão das atividades, de acordo, e somente onde realmente é necessário.

Limiar de estimação

Quando se cria um plano de trabalhos não se sabe geralmente o suficiente para descrever com detalhe,pelo menos na primeira vez, as actividades . Ao invés, identificam-se grandes actividades em primeiro lugar e decompõem-se estes grandes bocados em actividades mais pequenas. Estas mais pequenas são por sua vez desdobradas em actividades mais pequenas e mais concretas. Esta técnica é denominada de criação da Work Breakdown Structure (WBS).

Uma pergunta adequada seria saber qual a dimensão que devem assumir as actividades pequenas até não ser necessário decompô-las. Isto é referido como o «threshold» ou limiar de estimação. O trabalho pode ser decomposto para além do limite de estimação, mas normalmente nenhum trabalho é deixado a um nível mais elevado. O limite pode ser diferente conforme a dimensão do projecto e conforme a sua compreensão pelos destinatários.

Pode, entretanto, utilizar-se como guia o seguinte critério. Para um projecto de grande dimensão (por exemplo 5000 horas de esforço ou mais) qualquer trabalho que seja maior do que 80 horas deverá ser decomposto em actividades mais pequenas. Projectos de média dimensão (ou seja, de 1000 de esforço ou mais) não deverão ter actividades superiores a 40 horas. Se o projecto é pequeno (200 horas), as actividades deverão ser decompostas até não mais de 20 horas. Estas indicações são os limites superiores podendo as actividades serem decompostas mais abaixo.

A alocação de trabalho menor do que o limite definido permite que este trabalho seja melhor gerível. Por exemplo, se o seu projecto tem 250 horas e tem actividades que possuem cada uma 80 horas, não tem possibilidade de recuperar de uma destas actividades se a mesma se atrasar. Contudo, se a actividade mais longa tiver 20 horas, terá possibilidade de determinar se o trabalho está a ser realizado em tempo.

Evidentemente que é possível que actividades que devem ser trabalhadas num futuro distante possam estar decompostas acima do limite definido, pois há tanto que ainda é desconhecido acerca do trabalho em si. Neste caso a abordagem deverá se de decompor o trabalho em dois projectos distintos. O segundo projecto poderá ser definido com mais exactidão com base nos resultados obtidos com o primeiro projecto.

No caso de não ter a possibilidade de utilizar projectos múltiplos, o trabalho futuro pode ser deixado a um nível mais elevado que o do limite de decomposição. Contudo, se deixa trabalho futuro a alto nível, continua a ser critica a sua decomposição em partes menores pelo menos 2 a 3 meses antes da necessidade de execução do trabalho. 

Além de permitir que faça uma gestão mais eficaz do trabalho, outro motivo para dividir as atividades em partes menores é garantir que se entenda o que o trabalho significa. Quando atribui um membro da equipe a uma atividade do plano de trabalho, ele pode não entender o que é o trabalho e pode pedir uma explicação. Se não sabe o que o trabalho quer dizer, terá problemas. Então, deve garantir que o trabalho seja dividido num nível pequeno o suficiente para que as atividades sejam compreensíveis. Por exemplo, se uma atividade que é estimada em 80 horas nunca foi feita antes, ainda pode precisar ser dividida em atividades menores para garantir que o membro da equipe que é atribuído ao trabalho sabe exatamente o que é esperado.

Esses dois fatores - a capacidade de gerir de forma eficaz o trabalho e compreender o trabalho necessário - devem orientar a decisão sobre o quão pequeno fazer as atividades.

O Caminho Crítico e o Caminho mais Longo

O Oracle Primavera P6 oferece duas formas de definir uma atividade crítica num projeto. Elas são:

• Total Float menor ou igual a [0.0h]
• Caminho mais Longo (Longest Path)

Aquele que se utiliza no projecto depende de três coisas. A primeira é a configuração que se escolhe na janela de Projects no separador Settings. A segunda, é a opção que se seleciona na caixa de diálogo de opções de Schedule. A terceira, que se compreenda a diferença entre as duas opções referidas. A configuração por omissão do P6 é o método do Total Float.

Vamos sobretudo falar da terceira questão, ou seja, qual é a diferença entre a criticalidade do Total Float e do Longest Path? Há alguma confusão acerca disto na indústria porque infelizmente os termos “Caminho Crítico” e “Caminho Mais Longo” são muitas vezes utilizados de forma indiferente e intermutável. Na realidade são dois distintos métodos de calcular o caminho crítico e o P6 pode usar ambos.
Primeiro vamos ver onde se encontram as configurações para estas duas opções no Primavera P6 Professional.
 

Definições de Atividade Crítica

Vá à janela de Projetos da aplicação e escolha o separador Settings do painel das definições.


Figura 1
Na zona abaixo encontra-se a definição por omissão da definição das atividades críticas. Este é o comportamento por omissão que é fornecido ao planeador quando faz o cálculo do plano.
Contudo, podemos ultrapassar esta definição a todo o tempo nas opções de Scheduling que são acessíveis na respetiva caixa de diálogo (clicar em F9 ou escolher Scheduling do menu Tools).

Figura 2
As opções são as seguintes:
Pode selecionar o Total Float inferior ou igual (valor em horas) ou escolher o Longest Path.

Figura 3

 Total Float e Longest Path

A diferença entre entre as opções de Total Float e Longest Path pode ser sumariamente assim descrita. Os cálculos de Total Float procuram a folga total para cada atividade na rede. Se o valor da folga é zero, então esta será marcada como crítica. Contudo esse fato não significa necessariamente que a atividade está no caminho mais longo; diz-nos somente que a atividade é crítica e isso pode acontecer devido a muitos fatores.

No exemplo seguinte, mostra-se que o caminho crítico aparece quando é usado o método de Total Float para o calcular. A Atividade 1050 tem um constrangimento ‘Finish On or Before’ que é igual à sua data planeada, e assim é mostrada como crítica. Se deslizar, provavelmente não irão ter impacto na data de fim do projeto, mas elas ultrapassarão a data do seu constrangimento; é por isso que elas são mostradas como críticas de uma perspectiva de Total Float = 0h.

Figura 4
Contudo se usarmos o método de cálculo de Longest Path nas mesmas atividades estas não irão aparecer porque há um constrangimento ao longo desse caminho. Elas neste caso não irão afetar a data de fim do projeto e não estão dentro do caminho mais longo. Como vemos abaixo:

Figura 5
As atividades que antes estavam críticas agora aparecem como não críticas. Mas continuam a ter valores de 0 no Total Float, mas o P6 está a ignorar porque não fazem parte da rede do caminho mais longo.
O Longest Path através da rede do plano apenas considera atividades que são críticas porque podem contagiar o caminho desde o princípio ou até ao fim do projeto. Normalmente este é um caminho singular em que cada atividade que deslisa irá impactar a data de fim do projeto.

Utilização

Os planeadores muitas vezes utilizam o método de Longest path quando estão a desenvolver o plano. Isto dá uma ideia clara das atividades que estão de fato a dirigir (driving) o fim do plano, sem estar preocupados com os fatores complicados como os constrangimentos, nivelamento de recursos, caminhos divergentes e convergentes e outros itens que surgem quando se trata de trabalhar num plano grande e complexo.
Primevera P6 até tem um campo boleano de Longest Path que permite filtrar todas as atividades para ver somente atividades no caminho mais longo.

As colunas críticas de Total Float e de Longest path terão valores diferentes quando o cálculo é efetuado com cada um dos métodos.

Figura 6
Com o Primavera P6 não estamos comprometidos com um ou com o outro método. Em qualquer momento do ciclo de vida do projeto pode mudar-se do Total Float para o Longest Path só dependendo do que precisamos ver. E a qualquer momento pode reportar com um ou com o outro método e mostrando os seus valores.
Adaptado de Tensix Consulting

Sumarização – Oracle Primavera P6 Professional

Porque é que a Sumarização é um passo importante na manutenção dos projectos?

Conceito de Sumarização

Quando sumarizamos um projecto, esta função actualiza um conjunto especial de dados denominados Summary Tables na base de dados do Primavera. Estas tabelas oferecem grandes benefícios de performance para o sistema porque permitem que o utilizador tenha presentes uma lista de projectos com um conjunto de detalhes de alto nível acerca destes, sem confundir a memória do cliente com actividade desnecessária e detalhes de recursos. Em vez disso, o P6 simplesmente mostra um conjunto de dados de alto nível sobre o projecto. Se fosse necessário apresentar para cada utilizador ligado ao sistema todos os dados o impacto na performance seria muito grande para a rede de suporte.
Sem as tabelas de sumário os sistemas seriam lentos e cada vez mais lentos com o tempo visto que o volume de dados necessário para carregar cada um dos projectos poderia sobrecarregar o sistema. Poderia ficar intoleravelmente lento e incapaz de ser usado. A solução para resolver a questão sem sumarização passa por arquivar projectos e retirada dos projectos completos da base de dados.

Quando sumarizar?

Pode parecer uma surpresa, mas deve realizar uma Sumarização sempre que altere o projecto. É um processo tão vulgar que é esquecido durante a formação em P6.
O processo garantirá que a tabela do projecto está a mostrar os valores correctos esteja ou não o projecto aberto. Terá também um benefício adicional que é os relatórios serão correctos.
Se não sumarizar depois de ter realizado qualquer tipo de alteração e alguém corre um relatório acerca de valores da área de Projecto, então o relatório não irá reflectir as mudanças. Entretanto, se o projecto estiver aberto esta condição não se concretiza e os dados ficam correctos.
Assim, quando muda deve sumarizar.