terça-feira, 20 de fevereiro de 2018

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.

quarta-feira, 31 de janeiro de 2018

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.

quinta-feira, 18 de janeiro de 2018

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.

sexta-feira, 12 de janeiro de 2018

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.

clip_image002
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).
clip_image003
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.
clip_image005
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.
clip_image007
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:
clip_image008
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.
clip_image011
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
























sexta-feira, 5 de janeiro de 2018

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.




quarta-feira, 3 de janeiro de 2018

Usar Resource Codes

Tal como oferece códigos de projecto e códigos de actividade para organizer e visualizar de forma estruturada os projectos e as actividades, o Primavera tem ainda resource codes que permitem organizar, agrupar, apresentar e filtrar o dicionário de recursos. Os códigos de recursos permitem ainda agrupar e alinhar nas vistas de Resource Assignments e Resource Profile. 

Criar um Resource Code

  1. Criar um resource code denominado Division
    realizando o seguinte:
  2. Seleccione Enterprise e escolha Resource Codes.
  3. Clique en Modify.
  4. Clique em Add.
  5. Escreva Division como o novo nome de resource code.
  6. Clique Close.
  7. No topo, verá Division na lista de drop down.
  8. Clique no botão Add, para adicionar nomes de recourse code departamentos.
  9. Depois de adicionar todos os nomes, clique Close na janela de resource code.
  10. Atribua aos recursos no dicionário de recursos os respectivos resource code. 
  11. Mantendo-se no dicionário de recursos, Clique na barra de Display Option e escolha Group and Sort. 
  12. Clique em Customize e coloque o resource code Division como a primeira opção para agrupar.
  13. O seu dicionário de Recursos está agrupado por este código.
  14. Para voltar atrás à forma como estava organizado o seu dicionário de recursos, clique na barra de Display Option outra vez e escolha Group and Sort, default.
Um profile de recursos pode ser também agrado por resource code.  Isto irá permitir que ao clicar o nome do departamento no profile ver todos os limites para o recurso dentro do nome do departamento respectivo. Esta  vista permite criar um grande relatório de planeamento de capacidade Para agrupar pelo resource code Department que criámos acima dentro do profile de rescursos, siga as instruções:
  1. Abra o projecto.
  2. Clique no botão Activities na barra de Directory.
  3. Escolha um profile de recursos no layout de baixo.
  4. Na lista de recurso no lado esquerdo do profile escolha a barra Directory.
  5. Clique em Escolher a Vista e depois Resource.
  6. Clique em Group and Sort By.
  7. Escolha o resource code Division como a sua primeira opção para agrupar.
  8. Clique em OK.
  9. Na lista de recursos, deve ver os recursos agrupados pelo Division.
  10. Clique no nome dos Division da lista e irá vendo a informação agrupada na vista do Profile no ecrã da direita.