Como encontrar os lags das relações em Primavera P6

Não é fácil encontrar os lags das relações em planos do Primavera P6. Na verdade não há nenhuma funcionalidade para sublinhar os lags. Entretanto, compreender o que é que os lags fazem ao seu plano é uma parte importante para conhecer efetivamente o seu plano.
 

Está alguma coisa errada em usar Lags no plano?

A utilização de lags nas relações é muito discutido em todos os fóruns e o consenso tem vindo a situar-se em que a boa prática é que o uso de lags nas relações deve ser mínimo se é mesmo usado. Estivemos envolvidos em projetos em que o cliente exigia autorizar cada lag. Porquê?

De acordo com as normas, designadamente o Project Management Institute no seu Practice Standard Scheduling, a utilização de leads e lags nas relações adiciona um risco significativo ao projeto. A razão principal é a falta de visibilidade dos atrasos de lags num plano de um projeto. O tempo de lag é difícil de identificar e documentar – não é óbvio quando se olha para o Gantt Chart ou quando se analisam as datas do plano.

Quando se utiliza um lag num plano, raramente é documentado num tópico de Notebook porque é que o atraso foi adicionado o que faz com que os gestores cocem as cabeças. Porque tempo é afinal, dinheiro. Como boa prática os lags devem ser documentados, ou são usadas atividades para reprrsentar o atraso dos lead / lag. Esta abordagem faz com que eles sejam transparentes e muito visíveis.

É comum que os planeadores menos experientes apresentem planos com lags. Então precisamos de poder saber se estão a ser usados lags. Isso é muito difícil porque não há maneira de fazer um filtro em que as atividades com relações com lag sejam salientados.
 

Fazer um Relatório reutilizável para ver as relações com lags

Construir relatórios com o Primavera P6 é bastante fácil e as funcionalidades de reporting permitem discriminar as relações do plano. Com o uso de filtros conseguimos criar um bom relatório que mostra as atividades que tem relações com leads e lags. Aqui está como:

~

1º passo – Criar um novo relatório

Navegue na janela de Relatórios do P& e adicione (Add) na barra de comandos para adicionar um novo relatório à base de dados.

2º Passo – Escolha o tema do relatório

Quando o Report Wizard surge, clique Next para criar um New Report. No ecrã seguinte escolha a área de assunto “Activity Relationships” e clique Next.

3º Passo escolha as Colunas

Selecione as colunas conforme vê na figura. Clique OK

NOTA: Descobri que as colunas “Predecessor ID” e “Successor ID” irão sempre ser renomeadas pelo Primavera para “Activity ID”.  Se clicar OK depois de selecionar as colunas e voltar atrás para a escolha de colunas estas duas colunas estão renomeadas para “ID”.

4º Passo – desligue o Group and Sort

Clique em Group By no Group and Sort e defina-o para <none> ou deixe em branco.

5º Passo – Defina um filtro para o Lag

Clique no botão “Filter…”. Na lista de seleção, encontre e escolha “Lag”. Defina a condicional para “is not equal to” e escreva “0” na coluna de valor. Esta combinação irá filtrar ambos leads (lags negativos) e lags. Clique OK para guardar o filtro.

6º Passo – Guardar o relatório

Clique Next. No ecrã seguinte, dê o nome ao seu relatório. Antes de sair veja como ficou formatado relatório fazendo “Run”, depois clique Next e guarde e feche.
 

Finalmente

Com este relatório preparado a todo o tempo pode analisar o seu plano.

Lembre-se de evitar a utilização de lags e se tem de usá-los incluo uma atividade que os represente e justifique o atraso no seu plano do projeto.

Como sabemos que campos podem ser importados através do Excel?

O Excel é um óptimo interface para a edição de dados do P6. Podemos utilizar uma folha de cálculo para enviar para um cliente para eles nos remeterem o seu input de dados, tais como durações e orçamentos. Para clientes que não possuem ou não compreendem como utilizar o P6, o Excel torna-se um meio de comunicar com facilidade com eles. Pode ser utilizado para a comunicação de dados de progresso, facilitando a introdução manual de dados no P6 que pode ainda criar a possibilidade de erros.
É muito importante perceber que campos de dados podem ser importados através do Excel para evitar perdermos tempo a introduzir alterações na folha. O P6 assinala esses campos se soubermos para onde olhar.
A forma mais rápida de exportar dados do P6 para Excel é clicar com o botão direito do rato dentro da Tabela de Atividades, o que irá mostrar este menu:
Há, contudo, algumas limitações para este métodop de exportação. Algumas dessas limitações são:
· Todas as atividades que estão correntemente apresentadas na Tabela de Atividades são exportadas; deve filtrar-se as atividades para limitar o núm erro a serem exportadas.
· Todas as colunas correntemente apresentadas na Tabela de Atividades são exportadas; deve alterar o layout para ver outras colunas ou para limitar o número de colunas a serem exportadas.
Tenha em atenção que os campos Activity ID, Activitry Status e WBS Code são sempre exportados estejam ou não apresentados no layout. Porque o P6 necessita deles como referência para quaisquer mudanças que queira importa de volta para o P6.
A imagem abaixo mostra os campos de dados típicos apresentados quando se exporta diretamente da Tabela de Atividades para o Excel:

Eis como saber que campos de dados podem ser importados através do Excel: campos de dados que têm um asterisco (*) na segunda fila do título não podem ser importados. Embora os dados possam ser exportados diretamente da Tabela de Atividades, quaisquer mudanças feitas não serão importadas. Também, por exemplo, alterações feitas às datas de início e de fim, não podem ser feitas, porque estes são campos calculados. Mas os campos Activity Name e Original Duration, por outro lado, podem ser modificados no Excel e as mudanças serão importadas.
Por exemplo vou exportar dados dfo P6 usando este método de folha de cálculo. Vou usar o método de exportação, que toma mais tempo, mas permite exportar mais dados do que os da tabela corrente, tais como:

• Relações das Atividades
• Despesas
• Recursos
• Atribuições dos Recursos

Etas são aquilo que é denominado Subject Areas e cada uma delas irá aparece r com um separador de folha no Excel. Ainda mais importante é que os utilizadores podem editar dados nesses separadores e importar as alterações de volta para o P6. (Há algumas limitações do tipo de dados que pode ser modificado e em que separador).
Para criar este modelo de importação selecione File > Export > Spreadsheet – (XLS):

Porque queremos editar os custos orçamentados para as minhas atividades escolho a Subject Area de Atribuição de Recursos durante o processo de exportação:

As Unidades Orçamentadas e Custos ( Budgeted units and costs) só podem ser modificadas no separador de Atribuição de Recursos. As atribuições de recursos podem ser mostradas no separador de Atividades mas quaisquer modificações feitas aos orçamentos neste separador não irão importar.
Nesta imagem seleciono Budgeted Cost como um campo de dados. Repare que o campo de dados não menciona o tipo de recurso (labor, nonlabor ou material) porque cada recurso atribuído à mesma atividade irá ser apresentado numa linha diferente da folha. O P6 por isso não necessita de saber que tipo de recurso mostrar.

A Imagem final mostra a folha criada por este modelo. Desta vez não há asterisco no título Budgeted Cost, o que significa que estes dados podem ser modificados e importados de novo para o P6.

Mas deve reparar que não pode editar o campo Activity Name – pois este só pode ser alterado no separador de Atividades 8que não foi incluído neste modelo). Cada separador tem algumas limitações em termos dos campos de dados que podem ser importados. A Subject Area é a chave.
De qualquer forma aquele asterisco é uma grande ajuda desde que percebamos o que ele significa!
Seguindo post de Bill Pepoon

Problemas de Importação com Excel

Na semana passada esclarecemos o processo de importação para P6 com a utilização de Excel, mas algumas questões devem ser clarificadas para que o processo possa ser usado com alguma transparência.

Em primeiro lugar, apesar da funcionalidade existir deve procurar usá-la com cuidado e garantia de que o processo a usar não vai contribuir para destruir o seu plano. Portanto, cópias de segurança e testes são coisas que devem ser executadas antes de proceder a importações.

Em segundo lugar, a criação de um modelo através da exportação para Excel dos dados a importar é o processo mais aconselhável de reimportação de dados, pois fornece muito mais controlo ao utilizador, com seleção dos campos e filtro dos dados.
 

Porque é que não consigo importar dados de custo do Excel?

Com todos estes cuidados continuam a subsistir problemas com a importação de custos ou outros dados numéricos escritos manualmente em Excel.

Primavera só importa dados que estejam formatados como “Text” em Excel. Se introduziu manualmente 32000€ numa célula de Excel, a aplicação automaticamente formata como “Currency”. Então ao reimportar não irá aceitar os dados, porque tem de estar como “Text”.

Definir o formato “Text” de Excel não resulta!

Se tentar definir uma célula de custo ou de número para o tipo de formato “Text” do Excel, continuará a não conseguir importá-lo. Porquê?

Precisa de introduzir uma Apóstrofe (‘).

O P6 não importa o campo a não ser que tenha uma apóstrofe no seu início. A apóstrofe é um indicador antigo de que o campo é textual e o P6 procura-o. Se as células de dados não uma apóstrofe no início, o P6 não importa os dados da célula.
 

OK! Agora já introduzi a Apóstrofe e não consigo ainda importar os custos para o P6?

Para importar custos para o P6 do Excel, tem de se assegurar que o P6 não está a calcular os custos por si. Na coluna dos recursos para incluir no separador inclua uma coluna “Calculate Costs from Units”; esta é uma caixa de verificação que só pode estar ou On ou Off. Se a atribuição do recurso tem o campo Calculate Costs from Units em ON, então não conseguiremos especificar um custo e dessa forma importá-lo do Excel. Assegure-se que o campo está OFF antes de tentar importar.

Para estabelecer este campo como OFF em todas as atribuições de recursos, crie uma Global Change que faça isso. Veja imagem abaixo.

A Apóstrofe é sempre importante!

Os bugs da Pré-impressão em P6

Pensa que uma ferramenta que está em desenvolvimento constante desde 1998 deveria estar praticamente livre de bugs. Mas, infelizmente a natureza de todos os softwares é que em algum lugar do código, há sempre estes pequenos pedaços de sintaxe que não fazem o trabalho conforme projetado ou causam inesperados resultados. O Primavera P6 Professional não é uma exceção a esta regra, e há uma abundância de questões que você precisa saber sobre estes pequenos problemas.
Neste artigo, vamos olhar para um par de erros na previsualização de impressão e área de Cabeçalho e Rodapé que se mantém há um longo tempo, mas de alguma forma se consegue tornear.
A colaboração dos utilizadores poderá permitir resolver outros problemas ou ajudar a todos sermos mais produtivos com esta poderosa ferramenta.

Bugs da Previsão de Impressão e cabeçalho e rodapé

1º Bug

A letra S é impossível de ser escrita nas regiões de Add Text do cabeçalho e rodapé. Verdade! É impossível.

Este é um bug relatado e à espera de resolução. A forma de o resolver é escrever em qualquer outra ferramenta de texto, o Notepad por exemplo, e depois copiar e colar. Incrível! Este bug tem mais de 5 anos.

2º Bug

Quando se consegue escrever um texto na área de Add Text, ou colar algum seja o caso de conter um S e termos de recorrer ao Notepad, quando aplicamos, o texto não aparece na previsualização, quer no cabeçalho como no rodapé.

Se usar os botões de justificação à direita e à esquerda para alterar o texto de um lado para o outro, o texto irá finalmente aparecer quando clicarmos em Apply.

Em tempo
Na versão 8.3.2 foi finalmente solucionado este bug. A solução encontrada é simples e fácil de aprender, mantendo as funcionalidades anteriores e facilitando a personalização dos cabeçalhos e rodapés.

O que é um Plano de Projeto?

Adaptado de Ten Six

As grandes empresas com dezenas ou centenas de projetos de investimento de capital, devem considerar importante criar normas e métodos a que todos os projetos devam aderir. Isso proporcionará à organização a capacidade de sumarizar e avaliar o desempenho global dos projetos de toda a organização, bem como olhar para a capacidade dos recursos e outros indicadores-chave de desempenho.

Recentemente, trabalhei com uma organização que implementou o Primavera P6 e foi necessário definir esses padrões. Começaram por responder a uma pergunta básica acerca do que era um plano de projeto. Uma pergunta fácil e tantas ideias e percepções diferentes.

A base de um plano de projeto

Algumas ideias fundamentais em que assentou o conceito de método de plano de projeto. Todos os projetos são descritos num documento que define os objetivos e o âmbito do projeto. O plano do projeto é obrigatório e é preparado em Primavera P6. O plano prevê uma declaração estruturada de como e quando os objetivos do projeto serão alcançados, mostrando os produtos a serem entregues, as atividades a serem realizadas e os recursos necessários. Ele é utilizado para definir o custo do projeto ao longo do tempo. Isto fornece a base para o orçamento do projeto, através da integração do plano de Primavera P6 com, por exemplo, o ERP (a ferramenta de contabilidade do projeto).

Um plano de projeto é:

¶ Estrutura

• · Estrutura de Planeamento da Empresa (EPS)
• · Work breakdown structure (WBS)
• · Os pacotes de trabalho

¶ Sequência de eventos necessários para atingir os objetivos do projeto

• · Atividades e Milestones
• · Agendamento de Tempo e Lógica
• · Incluir tratamento de riscos

¶ Veículo para o planeamento dos recursos necessários e o custo da entrega

• · Todos os recursos exigíveis e outros recursos escassos / críticos
• · Custos de contrato
• · Perfil de custo faseado no tempo – curva de custo

¶ Baseline contra a qual é medido o desempenho

¶ Mecanismo para determinar os progressos, os custos e as previsões

• · Custo Interno e do empreiteiro do trabalho realizado
• · Programação e desempenho de custos (Valor Acrescentado)
• · Custo final antecipado

¶ Meios pelos quais a empresa pode avaliar e analisar a sua visão coletiva em todos os projetos

O plano cobre todo o âmbito do projeto e pode estender-se por vários anos. Uma baseline do plano e seu perfil associado de custo é autorizada no ERP, por etapas, de acordo com o ciclo de vida de projeto da organização e as exigências relevantes da autoridade de financiamento. A baseline fornece uma referência acordada para a programação e o custo contra o qual o desempenho pode ser medido. Previsões do cronograma do projeto e do custo oferecem a visibilidade do resultado esperado.

Resumo

Embora a maior parte disto parece bastante rudimentar, é surpreendente como muitas organizações de grande dimensão e responsabilidade, têm lacunas significativas nos seus processos de gestão de projetos, especialmente no nível mais detalhado. Ao definir o que um projeto deve conter e como ele é planeado pode ser o lugar óbvio para começar, mas as organizações muitas vezes perdem de vista outros processos no ciclo de vida do projeto. Essas lacunas podem permitir que utilizadores bem intencionados voltem a divergir dos padrões e processos definidos na empresa. Isto pode causar muitos problemas, incluindo dificultar os esforços para fornecer visualizações precisas consolidadas em todo o portfólio de projetos da organização.

4 formas fáceis de mostrar o caminho crítico no P6

1. Verifique o Gantt Chart

O Gantt Chart irá mostrar a vermelho, por omissão, as atividades no Caminho Crítico no seu projeto. Esta opção torna mais fácil ver de imediato o caminho crítico ressaltado.

Mas não está a trabalhar! Não consigo ver a vermelho o Caminho Crítico! O que é que está a acontecer?

Ainda bem que perguntou! Se calhar está a ver-se assim:

O Primavera P6, utiliza por regra o Total Float para decidir se uma atividade é crítica ou não. As atividades com um valor de Total Float de 0 (ou menos) aparecem normalmente a vermelho no Gantt. Se não tiver atividades a vermelho, pode ter uma data de Must Finish By definida no seu projeto. Se o seu projeto termina mais cedo do que a data de deadline do Must Finish By, então pode não ter atividades com Total Float com valores de 0 ou menos, o que significa que não há atividades críticas.

Neste caso, diga ao P6 para mostrar O Caminho crítico pelo Longest Path em vez do Total Float.

• × Prima F9 e de seguida clique em Options.
• × Encontre a configuração “Define Activities as” e escolha Longest Path.
• × Recalcule o projeto.
• × Verifique o Gantt Chart e já deve ver o Caminho Crítico.

2. Use as colunas de Caminho Crítico e Longest Path

Abra a opção Columns e procure por ‘Critical’ e outra denominada ‘Longest Path’. Adicione ambas ao seu layout de Atividades para ver com clareza quais as atividades que são críticas.

3. Selecione um filtro

A utilização de um filtro pode também mostrar de forma rápida e efetiva o Caminho Crítico. Clique em Filters para ligar o filtro de Caminho Crítico. Isto irá mostrar o Caminho Crítico e há ainda um filtro para Longest Path.

4. Verifique a programação das atividades

Por fim, pode ainda verificar o P6 Schedule Log. Este log é actualizado cada vez que usando a função Schedule (F9) calculamos a programação. Deve estar selecionada a opção ‘Log to File’. De seguida selecione ‘View Log’ para abrir esse registo.

Na secção ‘Exceptions’ pode ver uma lista das atividades Críticas do seu projecto.

Traduzido de Plannertuts.

Os desafios das Boas Práticas de programação

Vamos referir de forma breve algumas dicas de planeadores profissionais que o apoiam a manter o seu projeto na linha.

Há uma série de erros comuns que são praticados quando se criam os planos do projeto, particularmente por pessoas que chegam de novo a estas artes. Apontamos alguns dos mais frequentes enganos que encontramos e falamos acerca das boas práticas comuns de orientação e dos dilemas que estas fazem que os planeadores tenham de enfrentar no mundo real.

Vamos tratar de 3 questões:

1. Evitar a lógica com fins em aberto

2. Utilize o número mínimo possível de constrangimentos

3. Mantenha a duração das atividades abaixo de 45 dias a não ser que sejam do tipo Level of Effort

Estamos sempre a lutar contra a aparência de as boas práticas serem contraditórias, porque quando seguimos uma somos forçados a não usar a outra ou a ignorá-la. A orientação relativa a fins em aberto (open ends) é uma daquelas que nos coloca perante um dilema-

Lógica de fins em aberto

Várias orientações dizem que deve ser evitada a lógica de atividades com o fim em aberto que, portanto, não têm sucessores. Esta parece a questão que se vê de forma mais comum nos planos, em que uma atividade não tem sucessor e fica flutuando no fim de uma cadeia de predecessores. Quando se pergunta ao planeador a razão para isto a resposta é quase sempre a mesma: “Não há outras atividades dependentes desta atividade, assim não há sucessor”. Em termos do mundo real, isto até tem muito sentido, se não há nada dependente da sua conclusão então não há dependência para ilustrar.

Contudo, a boa prática é não ter estas atividades flutuantes na rede. Ao fazermos isto retiramos a atividade do caminho crítico e criamos um muito grande e desabitual Total Float. Pode retorquir que se cabe dentro do âmbito do projeto, em algum ponto irá causar impacto na conclusão do projeto, assim se não puder ser mais nada pode-se fazer da milestone final do projeto o seu sucessor.

Entretanto, em projetos mais longos, isto pode incrementar os limites do Total Float, em especial se esta atividade ocorre cedo no ciclo de vida do projeto. E então surgem os dilemas das linhas de orientação, pois a solução óbvia é adicionar um constrangimento ao fim da atividade flutuante, o que pode parecer um conflito com a orientação geral.

Limite a utilização de Constrangimentos da Atividade

O termo ‘constrangimento’ não se refere necessariamente aos atributos especiais de data de Início e Fim que podem ser adicionados às atividades na maioria das ferramentas de software. O termo ‘constrangimento’ pode significar uma relação entre duas atividades, sendo o constrangimento físico: isto é o telhado não pode ser construído até as paredes estarem concluídas. Pode ainda referir-se a uma condição num contrato onde foi especificada uma data de entrega crucial. Isto refere-se a um constrangimento externo. Contudo para o propósito em questão, referimo-nos a constrangimentos que podem ser adicionados como atributos especiais de data a atividades numa ferramenta de software. Estas datas irão influenciar o cálculo do caminho crítico.

Muitas das orientações publicadas recomendam um uso muito limitado destes constrangimentos num plano de projeto o que significa que as datas rígidas que são adicionadas às atividades irão prender as datas mais cedo ou mais tarde.

Se a atividade flutuantes (ou cadeia de atividades flutuantes realizam uma milestone importante do contrato, então, o uso de uma data de constrangimento é adequado. Isto irá reduzir o float global nas atividades flutuantes. Para uma maior clareza do agendamento, deve ser adicionada uma Milestone como sucessor da atividade flutuante e o constrangimento deve ser aplicado a esta. Dependendo da proximidade da data de constrangimento das datas agendadas correntes, esta opção irá remover o Total Float à cadeia de atividades flutuantes. E se a data agendada é já mais tarde do que a data constrangida, será calculado float negativo indicando que já não se consegue alcançar a data contratual e são exigidas mudanças ao plano.

No exemplo seguinte, adicionámos uma milestone de realização do contrato ao final da atividade G e depois aplicámos um constrangimento de Finish On. A data de constrangimento é de três dias após a data de fim agendada para a atividade, assim temos 3 dias de Total Float, em vez dos 21 dias que tínhamos antes de termos introduzido o constrangimento. Podemos sempre ligar a data da Milestone Contract Complete à Milestone de Fim, mas se deslizar de tal forma que empurre para a frente a data de fim do projeto ficamos em problemas de qualquer forma. Podemos adicionar um lag longo entre a nova milestone e a Milestone de Fim, mas algumas orientações desencorajam a utilização de lags longos ou leads. O que irá finalmente fazer será um acompanhamento próximo, com base nas particularidades do trabalho real modelado.

As orientações que desencorajam a utilização de constrangimentos são sólidas porque demasiados constrangimentos irão mascarar o caminho crítico. Torna-se mais difícil diferenciar entre atividades no caminho crítico e atividades constrangidas. Já vimos agendamentos literalmente juncados de constrangimentos e era quase impossível discriminar o caminho crítico. Também pode criar enormes quantidades de float negativo o que não é nunca uma coisa boa. Se o cliente sabe alguma coisa pensa que as datas não podem ser alcançadas e os constrangimentos foram utilizados artificialmente para parecer tudo bem.

Em breve, use unicamente constrangimentos quando tem uma boa razão para isso. E mesmo assim utilize constrangimentos do tipo Start on or After or Before (constrangimentos soft), o que continuará a permitir que o agendamento siga na direcção em que deve ir.

Mantenha a duração das atividades abaixo de n dias

Vemos esta linha de orientação em algumas publicações ou mesmo estabelecidas em regras de contratos, e têm diferentes limites de duração dependendo dos tipos de projeto alvo. Claro que atividades continuadas como gestão, segurança, saúde etc. podem correr durante todo o projeto, mas estas são criadas como Level of Effort. Ou seja, uma atividade cuja duração está dependente de atividades às quais está ligada.

Uma atividade que não cria um resultado pode ter virtualmente qualquer dimensão, contudo os work packages concretos que descrevem um particular trabalho devem ser mantidos com uma dimensão razoável. Um máximo de dimensão costuma ser manter a dimensão das atividades abaixo de 3 meses. Quando a atividade é mais longa que isto, sugere que está a atuar mais como uma atividade sumária e isso significa que representa muitas operações que deviam ser decompostas.

Há contratos em que a dimensão da duração das atividades tem um máximo de duração definido para obrigar o planeador a decompor o trabalho. Este limite está muitas vezes ligado ao ciclo de controlo do projeto, isto é, num ciclo mensal podem exigir que não tenha mais 20 a 30 dias, num ciclo semanal, não podem exceder os 10 dias, etc.

Determinar o nível certo de decomposição do trabalho e estimar as durações das atividades pode ser por si um novo dilema. Existem várias linhas de orientação que discutem os métodos formais de fazer isto, tais como Opinião de Peritos, Estimação Análoga e Paramétrica. De qualquer modo, porque o trabalho pode ser sempre realizado de mais do que uma forma, estabelecer as atividades ao nível certo é sempre um desafio.

Quando cria a sua lista de atividades tenha presente que é desta forma que o trabalho vai ser registado. Se a descrição da atividade cobre mais do que um tipo concreto de trabalho, será difícil acompanhar e aplicar o status. Pense sempre na necessidade de oferecer atualização exata do status quando considera o nível de detalhe a que cria a atividade porque isso também ajuda na sua estimação.

Sumário

Quando chegamos ao fim, lembre-se que todas as orientações são desenhadas para oferecer o modo ótimo para alcançar um plano viável. São linhas de orientação e não leis rígidas precisamente por que cada plano tem um desafio único a ultrapassar. Os planeadores, que enfrentam o dia-a-dia cheio de desafios para manter válido o agendamento, receber orientações pode ser um assunto difícil, particularmente quando sabemos que temos de ignorar algumas delas para que o plano reflita a realidade que tentamos modelar.

Tradução de Ten Six

Primavera P6: Críticas ou não tão Críticas?

Por TenSix

Muitos guias e orientações incluindo o PMBOK do PMI utilizam o termo ‘quase crítica’ para descrever actividades num plano de projecto que estão a alguns dias de se juntarem ao caminho crítico; isto significa que elas só têm mais uns dias de Total Float.

Se utilizarmos os métodos flexíveis como o P6 tem para apresentar as barras de actividade que aparecem no Gráfico de Gantt, podem ser criadas barras adicionais cuja aparência pode ser controlada pela quantidade de Total Float que têm. Isto irá permitir que facilmente se vejam as actividades quase críticas no Gantt Chart.

Vamos mostrar como poderemos criar estas barras de actividade que aparecem diferentes das barras standard vermelha, azul e verde quando a actividade é quase crítica.

O processo para as criar utiliza um Filtro. Este filtro é depois utilizado por uma barra adicional que se define na caixa de diálogo de Bars do Primavera P6 Professional,

Criar um filtro quase crítico

Abra a caixa de diálogo Filters e clique no botão New.

Crie o seguinte filtro.

Este irá apresentar qualquer actividade cujo Total Float esteja entre 0,1 dias até 10,0 dias. Deverá testar o filtro no plano antes de passar ao passo seguinte.

Criar uma barra de actividade quase crítica

O próximo passo é criar um estilo de barra de actividade novo usando a caixa de diálogo Bars.

Faça um clique da direita na área de Gantt Chart da vista das Actividades para abrir o diálogo Bars.

No diálogo Bars, desça e selecione a barra Critical Reamaining na tabela. Isto irá causar o surgimento de uma nova barra abaixo logo que clicamos em Add.

Depois deve clicar no botão New para aparecer uma nova barra pode deve dar-lhe um nome e sugerimos ‘Near Critical’.

Na coluna Timescale, coloqueo valor Remain Bar e depois na coluna Filter selecione os filtros Normal e Nera Critical.

Finalmente, defina as cores da barra e padrões que pretende para uma actividade quase Crítica. Utilizámos o laranja.

Após aplicar a nova barra ao layout, poide ver as actividades quase críticvas a laranja no Gantt Chart.

Pode ainda levar isto muito mais longe do que ‘quase críticas’. Com a utilização das mesmas técnicas, pode criar filtros para ‘Críticos Potenciais’ em que a actividade tem entre 10 e 30 dias de Total Float, ou ainda ‘Super Críticas’ em que há float negativo fazendo aparecer uma barra a preto. Claro que as diferentes barras só são limitadas pela nossa imaginação. Um dos nossos clientes usa diferentes cores das barras para indicar que uma particular actividade tem um certo código atribuído, por exemplo. Talvez já tenha feito uso desta capacidade?

REPORTAR VARIÂNCIAS no Oracle Primavera P6

Introdução às Variâncias

Realizar relatórios de variâncias em Primavera P6 exige que o projecto tenha uma baseline e que esta esteja atribuída quer como Project Baseline ou como Primary Baseline.

Antes de tentar realizar um relatório de variâncias, deve verificar a baseline que está a utilizar no projecto. Pode fazer isso, de forma rápida, verificando a informação na barra de status da Janela do Primavera P6.

As Baselines são atribuídas com a utilização da opção do menu Project à Assign Baselines . O diálogo permite que as baselines pré-existentes sejam atribuídas como uma Project Baseline ou Primary, Secondary ou Tertiary baseline.

Com uma baseline atribuída é possível reportar qualquer actividade que se tenha movido para uma posição diferente da sua data na baseline no projecto corrente.

Os Relatórios de Variância são criados com o uso de Filtros que procuram por valores diferentes de zero nos campos de variância disponíveis em P6.

Pode ver os campos de variância disponíveis através do diálogo Columns no P6, como abaixo vemos.

Explicação dos Prefixos dos campos de variância

Campos com o prefixo Variance – BL Project contém os valores de variância baseados na baseline do projecto atribuído como Project Baseline.

Campos com o prefixo Variance – BL1 contém valores de variância baseados na baseline atribuída como projecto Primary.

Campos com Variance – BL2  e Variance – BL3 contém os valores baseados nas baseline secondary e tertiary atribuídas ao projecto respectivamente.

Assim, se pretendemos saber qual é a performance do projecto corrente comparado com a Project Baseline, deve-se procurar os valores diferentes de zero nos campos de Variance – BL Project.

Opções de Filtros comuns de Variância

Para sabermos quais as actividades que já não estão projectadas para começar ou acabar nas datas da baseline original de acordo com a baseline atribuída como Project Baseline, devemos criar o filtro seguinte usando o diálogo de Filtros:

Se uma actividade deslizou da data de início da baseline ou de fim da baseline, os campos de Variance – BL Project Start Date  e Variance – BL Project Finish Date conterão um valor diferente de zero e a actividade será mostrada no Gantt Chart.

Se o diálogo de Bars estiver configurado para mostrar as barras do Project Baseline, verá o desvio visualmente no cronograma projecto. Pode ainda mostraros campos de  Variance – BL Project que está a filtrar na tabela de actividades para ver qual a quantidade que as actividades varima da baseline.

Mais exemplos de filtros de Variância

Excluir actividades completas

O filtro seguinte irá mostrar todas as actividades que t~em uma variância e que não têm o Activity Status de Completed.

Só mostra as actividades que iniciaram tarde

Neste exemplo o filtro mudou para mostrar somente valores de menos de zero de variância. Por outras palavras, a variância é negativa que irá unicamente mostrar actividades que irão começar tarde. Se a actividade começar mais cedo que a baseline, não irá aparecer no Gantt chart com este filtro.

Quando o Gantt chart mostra os campos requeridos dos dados de actividade, o comando File | Print Preview pode ser usado para correr o relatório de variância.

Nota: os filtros podem ser guardados num layout com nome e serão activados sempre que o layout é aberto.

Retirado e traduzido de Ten Six

Variance Reporting in Primavera P6 Professional

Variance Overview

Variance reporting in Primavera P6 requires that the project has a baseline and it is assigned as either a Project Baseline or a Primary Baseline.

Before attempting variance reporting, you should check the baseline being used for the project. To do this take a look at the information bar at the bottom of the Primavera P6 window.

Baselines are assigned using the Project | Assign Baselines… menu option. The resulting dialog allows existing baselines to be assigned as a Project Baseline or Primary, Secondary or Tertiary baseline.

With a baseline in place it is possible to report any activity that has moved away from its baseline date in the current project schedule.

Variance Reports are typically created using filters that look for values other than zero in the Variance fields available in P6.

You can see the available variance fields using the Columns dialog in P6 as shown in the following figure:

Variance Fields Prefix Explanation

Fields prefixed with Variance – BL Project contain variance values based upon the baseline project assigned as a Project Baseline.

Fields prefixed with Variance – BL1 contain variance values based upon the baseline assigned as the Primary Project.

Fields prefixed with Variance – BL2 and Variance – BL3 contain values based upon the secondary and tertiary baseline assignments for the project respectively.

Therefore, if you want to find out how the current project is performing compared to the Project Baseline, you would look for non-zero values in the Variance – BL Project fields.

Common Variance Filter Options

To find out which activities are no longer scheduled to start or finish on their original baseline dates according to the baseline assigned as Project Baseline, you would create the following filter using the Filter dialog:

If an activity has slipped from its baseline start or baseline finish date, the Variance – BL Project Start Date and Variance – BL Project Finish Datefields will contain a value other than zero and the activity will be displayed in the Gantt chart.

If the Bars dialog is configured to show the Project Baseline bars, you will see the slippage visually on the schedule. You can also display the Variance – BL Project fields you’re filtering on in the activity table to see by what amount the activities vary from the baseline.

More Variance Filter Examples

Exclude Completed Activities

The following filter will show all activities that have a variance and do not have an Activity Status of Completed.

Only Show Activities Starting Late

In this example the filter has been changed to only show values of less than zero variance. In other words, the variance is negative which will only show activities that will start late. If the activity is starting earlier than the baseline, it will not appear in the Gantt chart using this filter.

Once the Gantt chart is displaying the required fields and activity data, the File | Print Preview menu option can be used to run a variance report.

Note: Filters can be saved with the named layout and will be activated whenever the layout is opened.

From Ten Six

Relatórios Distribuídos no Tempo em Excel

Como prática normal os relatórios com Distribuição no Tempo do Primavera P6 Professional serem utilizados para criar tabelas de dados faseadas no tempo que são então exportadas para MS Excel. Contudo, se já fez isto deve ter notado que em muitos casos a linha dos Subtotais pode estar numa coluna demasiado à esquerda.

Este desalinhamento requer que se reveja toda a folha de cálculo apagando células para voltar a colocar as colunas no alinhamento.

Entretanto, há uma melhor maneira de resolver permanentemente esta questão e é isso que iremos mostrar.

Na Janela de Relatórios, faça um clique da direita no seu Relatório de dados Distribuídos no Tempo e escolha o Botão Modify.

Quando vir a pergunta seguinte, clique no Botão Yes.

Ao clicar em Yes abrirá o editor de Relatórios seguinte. Este é a tela que é criada pelo wizard quando criamos o relatório. Embora seja possível criar com esta funcionalidade um relatório, não o recomendo pois é complexo e consome demasiado tempo, assim deve sempre criar os seus relatórios utilizando o Report Wizard.

O Report Editor permite a adição ou remoção de campos utilizados para povoar o relatório final no P6. Neste caso vamos adicionar um campo na linha dos subtotais para podermos resolver a questão referida acima com os dados desalinhados na folha de cálculo.

O campo de subtotal está a utilizar o espaço entre os campos Activity ID e Activity Name da linha acima. Dessa forma os subtotais são escritos numa linha que tem menos uma coluna.

Adicionar um novo campo ao relatório

Primeiro temos de arranjar espaço para um novo campo, assim clicamos com o botão da direita no campo Subtotals e arrastamo-lo para metade da sua dimensão original.

Agora clicamos com o botão da direita na fila atrás do campo subtotal e do menu escolhemos Add Text Cell.

Esta acção coloca uma célula de texto na mesma fila e abre o diálogo de Properties.

No campo de Cell type, seleccione Custom Text e depois feche o diálogo de properties utilizando o botão pequeno X no topo direito.

O próximo passo é arrastar a nova célula por cima para a esquerda da fila. Isso vai adicionar uma coluna ao ficheiro CSV que é aberto em Excel na etapa final do processo.

Sem mais nenhuma modificação, esta colocação de célula não parece bem na previsão do relatório, contudo, como a criámos para a importação para a folha de cálculo isso não tem grande importância.

Finalmente clique no botão OK para fechar o report editor e correr o relatório, guardando o ficheiro de texto ASCII utilizando a configuração abaixo.

Na folha de cálculo final, pode ver que a adição de um novo campo de texto provocou que os dados ficassem na linha correcta com os cabeçalhos.

Traduzido a partir de TenSix blog.

Earned Value (Valor Ganho) – Fazer ou não fazer?

Por Ten Six

Porque é que devemos fazer EVM (Gestão do Valor Ganho)? Para aqueles que já implementaram sistemas de Gestão do Valor G anho (EVMS), de forma regular em diferentes organizações, ouvimos sempre as razões mais diversas por quer uma organização não deveria fazer EVM. No final a maioria das organizações implementam um EVMS porque necessitam de estar em conformidade com um contrato.

Porque não devemos?

Apresentamos algumas das razões mais comuns porque as organizações não querem implementar um EVMS:

· Demasiado burocrático

· Implementação demasiado dispendiosa

· Exige-se muitas pessoas para administrar um EVMS

· Exige-se um conjunto de ferramentas especiais de TI

· A Baseline não pode ser estabelecida mais cedo … o desenvolvimento dos programas tem demasiada incerteza, vamos esperar para ver.

· «Este programa é demasiado pequeno para necessitar de um ferramenta tão intrusiva».

· A nossa é uma companhia demais para custear isto

· O programa é demasiado grande e o EVM não tem sentido para nós,

Estas são algumas das razões mais referidas, mas há outras questões escondidas que nãosão tão facilmente partilhadas. Estas incluem:

· A objectividade de um EVMS não deixa nada escondido.

· Teremos de detalhar o plano antes de ser necessário e não estamos disponíveis para esse esforço.

· O EVM irá revelar mais detalhes acerca dos custos reais do que queremos que seja conhecido internamente ou pelo Cliente.

· Não queremos proceder a uma Revisão Integrada da Baseline com o Cliente para provar que o nosso plano base é válido.

Porque devemos?

Não será certamente uma surpresa para ninguém que a razão número um para implementar um robusto EVMS seja porque é um requisito contratual. De facto, nos Estados Unidos o governo e as agências têm limiares diferentes contratuais quando o EVM é um requisito do contrato.

Eis algumas das razões pelas quais deve não só implementar um EVMS mas também aplicá-lo a todos os outros programas:

· Para os projectos nos EUA, O governo exige EVM para ver as variâncias do custo e agendamento por forma a mitigar as questões antes que se tornem demasiado grandes.

· A não conformidade com estas regras governamentais pode ser dispendiosa.

· As 32 Orientações reflectidas no ANSI/EIA-748 representam princípios sólidos de gestão de projecto. Qual destes grupos de orientações é que se enquadra qualquer coisa que se possa descartar e não ser reflectido nos processos da companhia para gerir com efectividade programas?

• Organizar – definir o trabalho e atribuir a responsabilidade / prestação de contas pela sua performance?
• Planear e Orçamentar – desenvolver um plano definitivo para monitorizar como é que vamos alcançar o objectivo e quais os custos requeridos?
• Contabilização – estabelecer os números de custos incorridos para acrescer custos directos e indirectos por cada elemento maior. Isto ajudará a comparar os custos reais com os planeados?
• Análise – revisão de rotina da performance do custo e do agendamento até à data para ver onde é que não alcançamos a meta, compreender como é que será resolvido e quais os custos finais?
• Revisões – manter um registo do acompanhamento das mudanças ao contrato com o impacto nas baselines de custo e no agendamento para utilizar no próximo programa similar?

Na verdade a implementação e execução de um projecto EVM em conformidade com a ANSI-748 requer esforço por parte quer da equipa de projecto como da gestão senior. A alternativa de não estabelecer um plano sólido para gerir o âmbito do contrato, o agendamento, orçamento e riscos pode resultar no fracasso do projecto e numa pressão financeira sobre a sua organização. Será que vale arriscar de não fazer EVM?

Que tal Preço Fixo Firme

Os contractos com preço fixo firme muitas vezes não requerem EVM já que todo o risco pesa sobre o empreiteiro. Mas tal levanta uma questão. Porque é que uma companhia que aceita um contrato de preço fixo firme que enfrenta todos os riscos custo e agendamento não quer fazer EVM? Eles estão efectivamente numa posição para não conhecerem os riscos de exposição potencial de custo e agendamento. Quer apostar que vai correr tudo bem?

Em Suma

EVM é essencialmente uma melhor prática de gestão de projecto. Obter s más notícias da performance do projecto suficientemente cedo é muito menos doloroso do que as consequências do fracasso do projecto e da não conformidade contratual.

Link interessante que complementa este post.

Porque é que o Início e Fim das Actividades não apresentam o dia correcto?

Em primaverablog.in

Por vezes as actividades não iniciam ou terminam nas datas correctas apesar de a matemática afirmar o contrário. Há diversas razões que causam isto e vamos ver algumas delas.

1) Actividades fora da sequência – Estas são actividades que deveriam começar antes de estar concluído o predecessor. Estas actividades são criadas quando se utiliza a opção de schedulling “Retained Logic”. Esta cria períodos de não trabalho e estes podem levar a que a actividades seja empurrada para fora das datas normais calculadas. Pode verificar quais as actividades é que estão a ser empurradas para fora da sequência (Out of Sequence) marcando a opção de “Schedule Log”. Pode escolher “Progress Override” para calcular e corrigir estas datas ou mudar as relações para estas actividades.

2) O calendário da actividades contém não-trabalho que está a empurrar a data de fim.

3) Nivelamento de Recursos – a opção de “Level resources during scheduling” deve ser desmarcada nas “Schedule Options” para calcular o projecto.

4) Calendários múltiplos – se está a utilizar calendários múltiplos e o número de horas de trabalho não são iguais nas configurações de Time Period das Preferências de Admin então as actividades podem terminar numa hora diferente do dia.

5) Constrangimentos – Se uma actividade tem um constrangimento de “As late as possible”, este permite que a actividade se inicie e termine tão tarde quanto possível sem afectar as actividades sucessoras. Mesmo se uma actividade é iniciada, a data de fim pode ser empurrada para mais tarde no tempo se existir uma folga positiva quando é aplicado o constrangimento “As late as possible”. Isto fará com que a data de fim pareça ser mais tarde do que na base da sua duração remanescente.

6) O Projecto tem actividades com Datas Reais maiores que a Data Date – para verificar se alguma das actividades tem este problema deve ir a Tools à Schedule e abrir o Log de Schedule. Verifique então se veja tem alguma actividade listada na secção Activities with Actual Dates > Data Date. Se a resposta for afirmativa, pode então ou remover as datas reais ou mover a data date para as datas reais.

Percentagem de conclusão – Já lá estamos a chegar?

Por Ian Webster e traduzido por Luís Quintino

Tenho um relógio velho em casa: Está avariado – completa e totalmente sem uso como relógio, mas eu não sou capaz de o deitar fora e pelo menos ele diz-me as horas certas duas vezes por dia. No entanto, não o utilizaria para gerir um projecto.

Percentagem de conclusão

Confiar unicamente na percentagem de conclusão como um verdadeiro indicador do progresso de um projecto é tão seguro como utilizar um relógio avariado para saber as horas. A percentagem de conclusão tem as mesmas limitações. Pod estar certa, mas usualmente só duas vezes – nos 0% e nos 100%. Todas as informações no intervalo não podem ser confiadas como verdade. Na melhor das hipóteses a percentagem de conclusão é o produto de adivinhação. Na pior, é uma mentira … um relógio avariado.

O gestor de projecto imprudente pode com facilidade enganar-se. Eis como acontece. Uma actividade começa e a pessoa que faz o trabalho reporta o progresso regularmente ao gestor do projecto. Em face disto, as coisas avançam depressa no início. O progresso move-se de 0%, para 10%, 20%, 30% etc. O projecto vai progredindo. É encorajante. O Gantt de acompanhamento é actualizado. O progresso é reportado para cima. Toda a gente está contente.

Então o progresso alcança os 80% e as coisas parecem arrastar-se. As pessoas que trabalham em projectos de alta visibilidade não querem parecer que estão arrastar os pés, mas têm de demonstrar progresso, assim continua a haver incrementos de percentagem de conclusão, mas são mais pequenos – 75%, 78%, 79% e então normalmente param. Os últimos 20% levam 80% do tempo a terminar – é o princípio de Pareto (também conhecido como a regra 80/20).

MS Project

Há uma funcionalidade no MS Project muito conveniente mas pouco conhecida que permite definir a percentagem de conclusão para ser precisamente o que deve ser se as coisas decorressem conforme o plano. Nem necessita pensar. Se o trabalho numa actividade deveria ser 57% de percentagem de conclusão, tal é o que se pode estabelecer como o estado da actividade – com uns poucos cliques do rato. Assim se cria a ilusão que as coisas estão a decorrer perfeitamente em linha com o plano.

Nos meus primeiros dias como gestor de projecto confesso ter utilizado o processo uma ou duas vezes. Alguns anos mais tarde, quando herdei aquilo que na ocasião era um programa falhado, descobri que toda a minha equipa de gestores de projecto usavam esta funcionalidade rotineiramente para reportar o progresso tal como devia ter sido (quando na realidade não era nada disso). Terminaram essa prática. Compreendemos onde se encontravam na verdade os projectos e conseguimos dar a volta à situação.

Uma ferramenta de comunicação

O problema é que a percentagem de conclusão é atractiva como ferramenta de comunicação. Permite desenhar curvas de progresso muito atraentes num Gráfico de Gantt. Trabalha bem até um ponto e por um tempo, a seguir começa a não ter significado. As pessoas confundem-se com a quantidade de tempo que já passou relativamente à quantidade de progresso feito na realidade. Assumem que são a mesma coisa e é quase possível utilizar 100% do tempo alocado para uma actividade e esta ainda estar a 0% da conclusão. Gastámos todo o dinheiro. Queimámos todo o tempo, mas não temos nada para mostrar.

Psicologia

Existem em jogo nesta situação vários factores psicológicos.

As pessoas são super optimistas quando definem as estimativas iniciais e, muitas vezes, não querem admitir isso quando o trabalho está em curso.

Os gestores de projecto não gostam de pedidos de mudança e assim persistem em cima do plano original.

As pessoas mentem (por muitas razões, tais como cobrir a sua pobre performance ou para que o projecto deixe de ser visto como defeituoso.

O trabalho geralmente irá expandir-se e irá de qualquer forma preencher todo o tempo disponível (por exemplo, a quantidade de tempo que os países têm para preparar os eventos desportivos de maior dimensão tais como os Jogos Olímpicos ou o Campeonato do Mundo de Futebol é medido em anos, mas estão sempre muito atarefados á volta dos últimos tempos tentando solucionar qualquer coisa – o relatório do projecto reportará provavelmente que estão a 99,99% durante as últimas semanas).

Qual é a Alternativa?

Acompanhar a quantidade de trabalho que falra fazer é normalmente uma abordagem mais honesta e efectiva. Os miúdos quando estão no banco de trás sabem isto por instinto.

“Já estamos quase a chegar lá?” Perguntam eles, seguido de uma questão qualificativa “Quanto é que ainda falta?” Eles não estão interessados em quantos quilómetros já viajaram. Eles querem saber quanto mais tempo falta para viajar e chegar.

Pessoalmente, eu prefiro milestones. O estado de umam milestone é binário – ou está completa ou não. É uma métrica limpa. Não se pode estar grávido por metade com uma milestone – não há erro (o que poderá significar, em último caso, muito menos irritação do banco traseiro durante viagens longas).

http://www.pmhut.com/percent-complete-are-we-nearly-there-yet

7 erros de planeamento a evitar

por Ten Six

O agendamento é uma das coisas mais importantes com que uma ferramenta de gestão de projectos pode ajudar. Mas, por boa que seja a ferramenta, é tão útil quanto os dados inseridos na mesma. Cronogramas de projectos complexos fatalmente mudam ao longo do caminho - como disse o Marechal alemão Helmuth von Moltke, nenhum plano sobrevive ao contacto com o inimigo.

No entanto, você pode dar a seu projecto uma oportunnidade de sucesso, evitando estes 7 erros de programação.

1. Deixar de assinalar as actividades concluídas

Todos os gestores de projecto que conheço gostam de assinalar como concluídas as tarefas duma lista. Tendo em conta isto não seria muito provável ter gestores de projecto a esquecer de marcar as tarefas concluídas como realmente completadas. Infelizmente, é um erro comum. Isso só mostra que o gestor de projecto não actualiza o status do projecto actual, e não está próximo das equipes que fazem o trabalho. Receba as actualizações regulares dos membros da equipe e certifique-se que você sabe exactamente o que foi concluído a qualquer momento.

2. Deixar de actualizar o progresso das actividades em curso

A falta de controlo do status não afecta apenas as tarefas concluídas. O progresso deve também ser monitorado para as actividades que estão em curso. Isso permitirá que veja o que está a ser trabalhado.

3. Não decompor os resultados de alto nível

Os planos só são úteis quando as actividades incluídas são de um nível de granularidade que faz sentido para acompanhar. Actividades como "Organizar conferência 'são difíceis de controlar, porque elas são compostas de uma série de resultados menores, como' contratar local ',' convidar conferencistas" e "Definir a reserva de website”. Decompor as grandes actividades em tarefas menores. A regra de ouro é parar quando as durações das actividades são de cerca de uma semana.

4. Dependências que estão em falta

O planeamento torna-se menos preciso quando as dependências estão em falta. Não será capaz de ver o que tem que acontecer primeiro, ou qual o esforço a jusante que depende de actividades que devem ser concluídas. Reúna-se com a equipe e analise onde estão as dependências e, em seguida, certifique-se de que sua programação reflecte com precisão todos elas. Não julgue que sozinho é capaz de fazer isso, recorra à ajuda de outros.

5. Falhar a ajustar o esforço de previsão

Quando as actividades na programação ficam atrasadas, a visão optimista é a esperar que a equipe consiga recuperar. Com toda a nossa experiência na Ten Six, sabemos que isso acontece, de facto, muito raramente. As actividades atrasadas normalmente ficam mais atrasadas. Se você sabe que algo está atrasado porque está levando mais tempo do que o planeado, ajuste o esforço restante para essa actividade em conformidade. Por exemplo, se a duração da tarefa é de quatro semanas, e concluiu o esforço de uma semana, mas isso tomou duas semanas de tempo decorrido, você sabe que está a trabalhar a cerca de metade da velocidade que você precisa planear mais quatro semanas para esta actividade.

6. Não planear para a disponibilidade dos recursos

Mesmo o melhor plano do mundo deixará de ser exacto no momento em que as pessoas estão indisponíveis para trabalhar nas suas actividades. Plano com previsão, especialmente com os recursos a tempo parcial. Você deve ter como objectivo dar às pessoas (e seus responsáveis) aviso sobre quando eles devem começar a trabalhar nas actividades, e lembre-se de os manter actualizados até à data pois se as coisas mudam, porque você está atrasado ou por ter ganho a algum tempo poderá ter de necessitar das suas competências mais tarde ou mais cedo.

7. Falhar no ajuste da programação às mudanças no âmbito

Tem de haver uma ligação entre o processo de gestão de mudança do projecto e o cronograma. A maioria das mudanças terão algum impacto no cronograma, seja através de adicionar ou remover algo do âmbito do projecto ou alterar por algum motivo datas de marcos importantes. Certifique-se de que seu projecto integra o processo de gestão da mudança e o processo de planeamento, de modo que você possa implementar imediatamente as mudanças na programação, como resultado de mudanças no âmbito. Esta é também uma boa forma de garantir que toda a gente sabe que a mudança foi implementada - às vezes os membros da equipe do projecto na obra não estão perto dos principais processos e podem não estar cientes de que algo mudou.

A boa programação leva tempo e compromisso e o esforço para se manter a par de tudo, o tempo todo. É um grande trabalho, especialmente em projectos complexos, mas se você mantiver o foco você pode evitar esses 7 erros de programação. Helmuth von Moltke ficaria orgulhoso de si.

O que é Planeamento?

Muitas vezes temos intervindo em público sobre o planeamento de projectos e a gestão de projecto e confrontamo-nos com a constante dificuldade que as pessoas têm de compreender o que é efectivamente planeamento. Fomos recolher um importante auxílio a um documento da American Association of Cost Engineers. Identificamos o que é planeamento e depois distinguimos entre o Plano do Projecto e o desenvolvimento do cronograma.

O Planeamento de projecto consiste em:

· Identificar os stakeholders do projecto e os seus papéis, responsabilidades bem como o seu efeito sobre o processo de planeamento e de programação.

· Identificar os requisitos de contrato, incluindo os métodos de entrega de projectos sob os termos do contrato. O método de entrega do contrato vai determinar a extensão do esforço de planeamento pela equipa do projecto.

· Identificar as restrições e variáveis ​​que permitirão que a equipa do projecto possa iniciar o processo de planeamento.

· Estabelecimento de um processo de planeamento para determinar o âmbito do trabalho, requisitos do cliente, hierarquia do cronograma, divisão de responsabilidades revisão do plano do projecto e requisitos de aprovação e distribuição.

· Identificar as principais actividades de trabalho (fases) e resultados (metas) e a sequência adequada em que devem ser realizadas.

· Estabelecer um plano agendado de tempo integrado e faseado para atingir a conclusão do projecto, conforme requerido.

· Identificação da coordenação de gestão do projecto necessária para estabelecer áreas de custo / programação para a melhor definição do âmbito do trabalho.

· Desenvolvimento metodologias de gestão de projecto não-relacionadas com a programação, tais como planeamento logístico, incluindo, mas não limitados a: plano de acesso ao site, planos de carga pesada, colocação de guindastes, com planos longos de aquisição de materiais / equipamentos, planeamento de material / equipamento fornecido pelo proprietário e outros planos específicos para diferentes usos.

 

Desenho do plano e Desenvolvimento do Cronograma

Planeamento e programação são processos distintamente diferentes, mas relacionados para projectos de construção de capital. Desenho do plano e desenvolvimento do cronograma geralmente exigem um conjunto diferente de habilidades e conhecimentos.

Planeamento consiste em planear o trabalho, os recursos, e o custo estimado ao longo do tempo para completar o âmbito do trabalho definido nas fases iniciais do projecto. Programação do projecto inclui a identificação de muitos elementos que estão associados com o âmbito de trabalho que é desenvolvido em pacotes de trabalho, sequenciados em fases e em seguida as actividades específicas. Os meios, métodos e recursos têm processos de planeamento iterativo como o plano de projecto é desenvolvido antes da fase de execução do projecto. Esta programação continua a evoluir durante a vida do projecto e coloca a ênfase na experiência e nos conhecimentos adquiridos com os sucessos e fracassos de projectos anteriores.

O propósito do planeamento por uma equipa de gestão de projecto é estabelecer um curso de acção aceitável ("Plano") para realizar o âmbito de trabalho de um projecto de uma maneira eficiente e coordenada com base numa revisão dos requisitos de projecto e responsabilidades. Incluído neste esforço de planeamento está a identificação das partes interessadas, os requisitos de contrato, e o método de entrega do projecto que são elementos-chave no esforço de planeamento inicial.

O objectivo da programação por uma equipe de gestão de projecto é desenvolver uma ferramenta de gestão de tempo em fases que vai ajudar a implementar o plano aprovado e orientar o projecto para os resultados desejados utilizando os resultados do processo de planeamento. O planeamento deve preceder o esforço de programação e, embora possa tornar-se menos formal em fases posteriores do projecto, o planeamento é um processo contínuo que nunca pára até que o projecto esteja concluído. O cronograma do projecto é detalhado durante a fase de desenvolvimento do cronograma do projecto. Há uma transição relativamente suave de planeamento do projecto de cronograma de desenvolvimento, enquanto o documento do plano do projecto é finalizado e revisto pelas partes interessadas apropriadas.

(Extraído de 39R-06: Project Planning – As Applied in Engineering and Construction for Capital Projects, da AACE® International)