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.

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.