Opções de configuração de nivelamento de recursos

Quais são as opções que devemos estabelecer antes de começar a usar a função de nivelamento no P6. Para ver essas configurações temos de abrir Tools à Level Resources.

1) ‘Automatically level resources when scheduling’: Esta opção nivela os recurso todas as vezes que se recalcula o projecto (Schedule).

2) ‘Consider assignments in other projects with priority equal/higher than’: Seleccione se quiser incluir alocações noutros projectos dentro da prioridade de nivelamento especificada quando se determina se um recurso está ou não sobre alocado. São consideradas as alocações em projectos fechados. Por exemplo, marca esta opção e especifica a prioridade de nivelamento 5 e a opção definida irá nivelar todos os projectos com prioridade de nivelamento de1,2,3,4 e 5.

A prioridade de nivelamento vai de 1 (mais alta) a 100 (mais baixa). A prioridade de nivelamento é definida no separador General da janela de Projectos.

3) ‘Preserve scheduled early and late dates’: seleccione esta opção para preservar as datas mais cedo e mais tarde que foram calculadas durante o processo de ‘scheduling’.

4) ‘Recalculate assignment costs after leveling’: selecione isto para recalcular os recursos e as funções (roles) nos projectos. Use esta opção para calcular recursos / funções que têm atribuídas taxas múltiplas.

5) ‘Level all resources”: seleccione para nivelar todos os recursos.

6) ‘Level resources only within activity Total Float’: Seleccione esta para atrasar actividades com conflitos de recursos só até à sua data de fim.

7) ‘Preserve minimum float when leveling’: A quantidade folga que se pretende manter quando as actividades são atrasadas devido a conflitos de recursos.

O valor introduzido neste campo é convertido automaticamente em horas. O valor é convertido em horas com base nas horas por período de tempo definidas nas definições de Tools à AdminPreferences ou no calendário do projecto, dependendo da preferência definida (AdminPreferences à separador Time Periods). Assim se introduzir o valor de 5d ele automaticamente converte esse número no nº de horas configurado.

8) ‘Max percent to over-allocate resources’: pode especificar a percentagem máxima em que a disponibilidade do recurso pode ser acrescida durante o nivelamento. Esta opção pode ser usada no caso em que sabemos que podemos sobre alocar um recurso até determinada percentagem. Este recurso então será sobre alocado por este valor no caso de que os valores de folga para estas actividades não possam ser ajustados.

9) ‘Leveling Priorities’:

a) ‘Field Name’: indica os campos pelos quais podem ser priorizados os recursos quando se nivela. As prioridades são utilizadas só nos casos em que mais do que uma actividade «luta» pelo mesmo recurso ao mesmo tempo.

b) ‘Sort Order’: a ordem pela qual são nivelados os recursos de acordo com o campo definido. Faça um duplo clique para escolher Ascending, Descending, ou Hierarchy (opõa que surge só nos campos que são hierárquicos).

c) ‘Add’: adiciona outra prioridade de nivelamento.

d) Remove: Remove uma prioridade de nivelamento.

Começar os projectos com o pé direito

A preparação é uma parte chave na gestão de projecto. Se o projecto não começar de forma correcta irá ter problemas como refazer o trabalho, O âmbito indeterminado, atrasos no plano, má estimação, etc. Embora alguns pensem que o importante é saltar para o trabalho com as duas mãos, o gestor de projecto precisa de ajudar a oferecer um ponto sólido de partida para o projecto. Este ponto de partida é que muitas vezes determina se o projecto vai ou não ter sucesso, representa o ponto de partida do projecto e da equipa, e merece todo o tempo e esforço que se faça para garantir que se apoia em sólidos alicerces. Não se pode saltar às cegas para qualquer coisa que não está perfeitamente compreendida pela equipa.
 

O âmbito

A gestão do âmbito é uma parte importante da gestão de projecto. Muitos projectos iniciam-se com a visão de uma pequena cascata e os stakeholders acabam a dizer que querem as Cataratas Vitória. A gestão de âmbito irá ser uma parte da gestão de projecto ao longo de toda a sua vida, mas há alguns passos que o gestor de projecto deve tomar no início para minimizar as questões com o deslizar do âmbito.

O primeiro passo é definir o âmbito para o projecto; esta definição não tem de ser muito detalhada, mas tem de ser compreendida por todos os envolvidos. O segundo passo (e muito mais difícil) é obter aprovação formal para o âmbito. Esta assinatura pode ser de um documento legal ou pode ser um acordo entre o sponsor e o gestor do projecto. Em qualquer dos casos, é necessário sublinhar para todos que se o âmbito for alterado terão de haver alterações do projecto. A definição de âmbito deve ser claramente compreendida antes de começar o trabalho ou existirão problemas no futuro.
 

Baseline

Depois de o âmbito ter sido definido e acordado pode então ser desenvolvido um rascunho dum plano base. Este não terá de incluir todas as pequenas actividades que serão realizadas pela equipa do projecto, mas deverá incluir as milestones chave e o desenho de como o trabalho do projecto será executado. Esta baseline inicial será o primeiro passo para o plano completo do projecto que será desenvolvido e actualizado durante o projecto. Tal como o âmbito, esta baseline preliminar deve ser compreendida e formalmente acordada pelos stakeholders e o sponsor do projecto antes que o trabalho do projecto se inicie. Conforme esta baseline inicial vai sendo desenvolvida, o gestor do projecto deve apresentar e definir como serão os status do projecto apresentados ao sponsor do projecto durante a sua execução.

 

Organização da equipa

Um último ponto que deve ser compreendido cobre a equipa que irá trabalhar no projecto e que é a necessidade de estabelecer a forma de funcionamento da equipa. Dê a conhecer a todos os recursos quem é que está na equipa e quais são as suas funções nesta. É muito importante comunicar quem será responsável por quê e como prestará contas desta responsabilidade ao gestor de projecto.

Ser aberta e honesto acerca do trabalho do projecto e como o projecto será gerido é o melhor caminho para pôr, de imediato, a equipa do projecto a colaborar. Fazer com que a equipa de projecto esteja motivada de início para o trabalho do projecto passa assim por todos conhecerem as funções e as responsabilidades mútuas.

Kenneth Darter e LQ

O que é o nivelamento de recursos?

O nivelamento de recursos é uma importante funcionalidade no processo de gestão de projecto durante a fase de planeamento mas é uma das opções mais raramente utilizada em Primavera. O nivelamento de recursos ajuda a garantir que a procura de recursos não excede a respectiva oferta.

Quando se nivela os recursos o Primavera P6 segue os processos seguintes:

1. Os requisitos dos recursos de todas as actividades programadas são comparados com a quantidade máxima disponível na ocasião do nivelamento.

2. Uma actividade é atrasada se está disponível só um número de recursos insuficiente em qualquer altura da duração da actividade.

A quantidade máxima para um recurso é determinada através da opção de Max units/time para um recurso particular no Separador de Recursos.

Vamos considerar que temos um recurso denominado Consultor com o Max units /time de 6h/dia e este recurso foi alocado a duas actividades que ocorrem no mesmo dia. O requisito para este recurso seria 12 h/dia mas ele só pode trabalhar 6 h/dia. Assim o recurso é considerado sobrealocado.

Pode verificar se os recursos estão sobrealocados no seu projecto se for ao Resource Usage Profile e activar a Limite Line.

A linha vermelha no gráfico irá mostra o número de unidades sobrealocadas para o seu recurso.

Quando souber quais os recursos no seu projecto que estão sobre alocados, pode então utilizar a opção de ‘Level Fessources’ no menu Tools para nivelar os seus recursos.

Global Change em Primavera P6

O processo de ‘Global Change’ ajuda-nos a realizar mudanças às actividades e aos seus atributos (atribuição de recursos, despesas de projectos, etc.) com base em filtros seleccionados no procedimento respectivo. Pode utilizar a ‘Global Change’ para editar os valores existentes ou atribuir novos valores. Por exemplo, pode criar uma global change para atribuir recursos a um grupo de actividades.

Para utilizar ‘Global Change’ tem de ir a Tools à Global Change.

Nesta janela pode ver algumas das ‘global changes’ predefinidas e criadas quando se instala a base de dados com os projectos de exemplo.

Vamos escolher um exemplo em que pretendemos mudar a Duration % Complete de actividades começadas em 1 de Setembro de 2012 dentro da WBS “Zona 1” até 50%.

1) Para adicionar uma nova ‘Global Change’ clicamos em New.

2) Abre a janela ‘Modify Global Change’ e será necessário introduzir os parâmetros necessários.

3) A’ Subject Area’ é a primeira opção que deve ser escolhida antes de adicionar dados. Há três escolhas:

a. Actividade – Escolha este assunto se necessita mudar atributos da Actividade tais como Duração, Tipo de Actividade, etc.

b. Alocação de Recursos à Actividade – escolha esta área se quer alterar os atributos da alocação dos recursos tal como unidade orçamentadas, unidades Reais, etc.

c. Despesas de Projecto – Escolha esta opção se quiser realizar mudanças às despesas de Projecto.

4) Depois de escolhida a área de assunto pode definir o nome da ‘Global Change’ para mais tarde a poder identificar.

5) A escolha dos parâmetros de IF, Then e Else é a parte mais importante da ‘Global Change’.

a. Parâmetro de IF – define a condição de filtro em que as actividades ou recursos podem ser escolhidas para mudança global.

 

 

 

 

Parâmetro IF

if	Parameter	Is	Value	High Value
	(All of the following)
where	WBS	Equals	Zone 1	-
And	Actual Start	Equals	01/09/12	-

Neste exemplo o P6 irá filtrar as actividades da WBS Zone 1 em que o Actual Star é igual a 01/09/12.

Nota – quando se escolhe ‘all of the following’ a mudança abrange todos os dados que o parâmetro de IF satisfaz.

b. Parâmetro THEN – define as mudanças para especificar aos dados do projecto depois de satisfeitas as condições do parâmetro de IF.

Neste caso:

Then	Parameter	Is	Parameter/ Value	Operator	Parameter/Value
	Duration % Complete	=	50%	-	-

c. Parâmetro ELSE – define a mudança a fazer aos dados do projecto quando as condições de IF não são encontradas. Neste caso, pode fazer outras alterações às actividades que em que a “WBS não é Equal a Zone 1”

Depois de proceder às alterações acima a ‘Global Change’ terá esta informação.

Finalizada a criação dos parâmetros da ‘Global Change’, deverá clicar em ‘Change’ para aplicar as mudanças ao projecto aberto.

O exemplo vem de cima

Até em Projecto.

Global Change para substituir recursos

O Global Change é uma das ferramentas que agilizam a utilização do P6 e permitem realizar actividades complexas de forma eficiente e simples.

Vamos criar um script de Global Change para substituir Recursos num projecto aberto. Assim:

1. Criar um novo script de Global Change indo a Tools, Global Change.

2. Seleccione "Activity Resource Assignments" como ‘Subject Area’.

3. Introduza o seguinte na secção If:

Where Resource ID Name     equals     Resource A.

Se não pretender alterar os recursos em todas as actividades, pode adicionar declarações de If adicionais para filtrar as actividades apropriadas.

4. Introduza o seguinte na secção Then:
Resource ID Name     =     Resource B

Quando se substitui uma alocação do recurso A pelo Recurso B a atribuição não irá manter as definições de units/time, price/unit por omissão. Estes valores serão obtidos do dicionário de recursos para a nova atribuição de recurso.

Se pretende que a atribuição de recursos mantenha as mesmas ‘Remaining Units/Time’ deve alterar as preferências do utilizador em Edit, User Preferences no separador ‘Calculations’. Aí, assegure-se que está seleccionado ‘Always use current assignment's Units per Time and Overtime’. De outra forma, serão susbstituídos os ‘Remaining…’ pelos ‘Default Units/Time’.

Razões para falhar a mudança

As iniciativas de mudança nas organizações, como a implementação de processos novos ou alterados ou a utilização de novas aplicações para processos de negócio, falham muito mais vezes do que os responsáveis gostariam, mas isso é uma característica destas actividades que não deixa de acontecer só por que queremos. Há algumas razões principais que fazem com que estas iniciativas falhem e se as conhecermos talvez consigamos gerir e utilizar a nosso favor.

 

Uma visão pouco clara

A mudança atinge todos. Temos de fazer com que a visão para a nossa mudança seja mesmo muito fácil de entender para que toda a gente compreenda. A criação de uma visão clara significa trazer para cima da mesa aquilo que se pretende mesmo atingir. Se é implementar um processo para a gestão de projecto ou se é melhorar as taxas de sucesso dos projectos? Será que é a generalização de ferramentas de gestão de projecto como o Primavera P6 ou a recolha de melhores dados para gerir os custos dos projectos?

Uma das formas de garantir que a visão é clara é estabelecer como é que sabemos que alcançamos o propósito. Pense nas métricas que pode utilizar e que o ajudem a avaliar qual a proximidade para o seu objectivo. Conhecer como é que o sucesso se apresenta ajuda toda a equipa a trabalhar com efectividade na sua direcção.

 

Comunicação deficiente

Se perguntar qual é o maior factor de risco de uma iniciativa de mudança a resposta é: as comunicações. Algumas companhias até são muito boas a comunicar de cima para baixo e assim os projectos de mudança são lançadas com banda de música e foguetes. À superfície, pelo menos, todos sabem o conteúdo da última newsletter do projecto e como o trabalho deles irá contribuir para os objectivos gerais.

Mas a comunicação funciona nos dois sentidos. Para cima a comunicação é também importante. A comunicação das pessoas afectadas pela mudança para aqueles que a estão a implementar. Como estão as coisas a correr na linha da frente? Somente com métodos de comunicação efectiva para reunir o feedback é que quem dirige o projecto sabe como é que a mudança está a ser entendida – e, assim, se irá mesmo ser possível alcançá-la.

 

Falta de apoio na cultura da organização

A implementação de uma estrutura de processos numa companhia com uma cultura aberta e em rede irá funcionar com muita dificuldade. De igual forma, uma função de gestão de projecto altamente colaborativa sem apoio em metodologias estruturadas irá lutar para ter sucesso nas indústrias reguladas dos nossos dias. As grandes ideias de mudança são só início da viagem!

Teremos de conseguir que a forma como iremos implementar forneça um novo modelo de cultura para o negócio. Se não o conseguir, então mude, em primeiro lugar, a cultura.

 

Falta de direcção de topo

Infelizmente isto acontece todo o tempo e em todo o lugar. O responsável executivo da liderança da iniciativa muda de posição na companhia ou perde o foco e, no final, a mudança falha. Tem de haver sempre alguém no topo como proprietário da mudança e decidindo acerca da direcção das actividades que esta exige para ser alcançada. Esta pessoa é aquela que explicará aos colaboradores nas reuniões por que é que a mudança é tão importante. Será responsável, claro, pelo orçamento e prestará contas pelo resultado alcançado. Se perdermos o líder da mudança, considere parar o processo de mudança – pelo menos até conseguir encontrar outro executivo que funcione como campeão da mudança.

 

Declarar o sucesso demasiado cedo

Contratar um director não é um sucesso. Instalar o novo software não é um sucesso. Muitas iniciativas de mudança enfraquecem e morrem porque se instala um estado de «deixar andar». Há muito mais para fazer o sucesso de uma mudança do que o ligar de um interruptor. Nos dias iniciais a novidade pode ser suficiente para obter alguns benefícios, mas com o tempo, a não ser que haja apoio, as pessoas voltam às velhas formas de fazer as coisas.

Não desmobilize a equipa da mudança demasiado cedo. Assegure-se que a mudança transitou de facto para o negócio como a forma usual de fazer as coisas e resolva todas as questões que sejam colocadas. O melhor é descontinuar totalmente as formas antigas de os colaboradores fazerem as coisas. Os campeões da mudança de cada equipa podem ajudar porque podem descobrir lacunas e apoiar os colegas.

Mas o conselho mais importante é pensar naquilo que, no final, queremos alcançar. Se conhecemos o objectivo final, aquilo por que estamos a trabalhar, articulando e comunicando com outras pessoas torna-se muito mais fácil. Planeie para o estado final, garanta que sabe o que é que você quer e torne possível a todos realizarem a viagem até lá consigo.

Melhor Gestão de Projecto na recuperação económica

Não há nada de bonito nesta recessão económica. A economia está a mudar, muitas companhias estabelecidas no mercado estão a desaparecer ou sofrem processos de compra e de fusão, as indústrias estão a operar em modo de sobrevivência preocupadas por evitar riscos que as possam colocar em vulnerabilidade. Para sobreviver, as grandes empresas têm de se manter na vanguarda da inovação e das tendências de mercado.

Mas nem tudo tem sido negativo!

Aparentemente com a queda de empresas lentas e ineficientes afectadas pela recessão, foram criadas oportunidades para outros negócios florescerem. Para as companhias que conseguiram ultrapassar estas grandes dificuldades e estão a navegar no actual horizonte de negócios, jogar pelo seguro não é a forma de ter sucesso, mas também não o é avançar sem cuidados.

Um factor chave que faz a diferença nas empresas é a execução inteligente dos projectos. Actuar sobre os projectos que são mais lucrativos e agindo com margens de erro muito pequenas, permitirá que os negócios sejam capazes de maximizar o valor das suas actividades e assegurar que irão operar com lucro nos anos seguintes.
 

Manter o projecto dentro do prazo

Quando se trata do sucesso dos projectos este é o aspecto mais importante. É essencial aplicar métricas às realizações, mas quando queremos recolher a informação adequada para esse efeito podemos levar imenso tempo. Se estabelecermos inícios e fins claros para as actividades poderemos aplicar métricas valiosas de tempo que façam sentido para os stakeholders do projecto e, sobretudo, para o cliente, que verá o resultado comparado com a métrica de baseline.

O estabelecimento de uma baseline é obrigatório na realização de um projecto com métodos sérios e métricas com valor.
 

Do custo do projecto

A maioria das empresas não conhece o verdadeiro custo por projecto e isso pode conduzir a um mundo de trabalhos. Se sabe quais são os projectos que estão ser lucrativos poderá alocar os recursos a projectos com um perfil similar e estar mais confiante na sua performance e no sucesso. Mantenha curtos os elos de comunicação nestes projectos e monitorize constantemente a medida em que eles estão alinhados com o custo e o orçamento.

Estes dados ajudarão a determinar quais os clientes que permitem manter as margens e aqueles que pela sua actuação impedem ou dificultam o progresso e reduzem ou destroem as margens.
 

Utilize eficientemente as ferramentas

Qualquer ferramenta é tão efectiva como a pessoa que a está a usar. Mesmo o melhor software irá falhar se não tivermos um plano para o utilizar. Isto não significa que o software possa ser optimizado. Quando temos de gerir projectos múltiplos e os dados complexos que estão associados com a sua realização, uma ferramenta que agregue e prepare os dados automaticamente pode poupar muito tempo e confusão enquanto fornece uma visão clara e transparente sobre o estado dos projectos.
 

Desenvolva sem receio os projectos

Executar consistentemente os projectos e realizar valor é muito importante. Para isso tem de assumir projectos inovadores que requerem algum risco. O segredo está em saber quando e como assumir esses riscos. Pode ajudar muito poder avaliar os recursos disponíveis e determinar, a partir dos dados da experiência, quais os tipos de projectos mais lucrativos. Armados com essa informação, mesmo quando um projecto atrasa, não deve ser muito difícil recuperar. Mas mais do que isto, por tentarmos novos projectos continuamos a melhorar e a refinar as métricas de sucesso.

Agora chegámos ao tempo de começar a quebrar a estagnação associada à recessão. Os novos projectos levam a novos clientes, o que conduz à melhoria das margens e dos lucros e a vantagens competitivas. Estará aí um mundo de oportunidades se alterarmos as nossas perspectivas, nos equiparmos com metodologias e ferramentas. Mas muitas companhias persistem escondidas nos seus abrigos de crise.

Temos de tomar a iniciativa para nos colocarmos na cabeça da corrida.

LQ

A WBS (Work Breakdown Structure) em P6

Cada projecto tem a sua hierarquia própria de WBS com o elemento de nível superior WBS a ser igual ao de cada nó da EPS ou projecto. Cada elemento da WBS pode conter níveis mais detalhados ou actividades ou ambos.

Uma WBS é uma hierarquia do trabalho que deve ser feito para concluir um projecto e define um produto ou serviço a ser produzido. A WBS é estruturada em níveis de detalhe de trabalho, começando com o produto final em si, e então é decomposta em elementos de trabalho identificáveis.
Ao criar um projecto, o gestor de projecto desenvolve primeiro a WBS, atribui documentos para cada elemento da WBS, e, em seguida, define as actividades para realizar o trabalho do elemento. Para além das tarefas de documentação e atribuição da actividade, cada elemento da WBS tem também um calendário atribuído, configurações específicas de cálculo valor ganho e um elemento da OBS definido como responsável por todo o trabalho incluído no elemento da WBS.
 

Usar a WBS para planeamento de alto nível

O uso da WBS nas etapas de planeamento de um projecto é benéfico para a sumarização de dados ainda não associados com os projectos.
A hierarquia da WBS pode conter datas previstas, os orçamentos previstos e valores de resumo. As informações financeiras são usadas ​​de forma intermutável entre os projectos e seus elementos de WBS, assim pode usar os valores de orçamento pré-estabelecidos e informações de financiamento definidas para elementos WBS imediatamente para o seu projecto e actividade respectivas. O orçamento e o plano de despesa podem ser os únicos a representar os dados financeiros para o nível WBS, ou podem reflectir os dados do orçamento de distribuição estabelecidos para o projecto. A informação de sumário pode ser agrupada para qualquer nível WBS que especificar.
 

Usar milestones ponderadas na WBS

O P6 oferece vários métodos de calcular o desempenho da percentagem de conclusão. Um dos métodos é atribuir milestones ponderadas ao nível da WBS. Para cada elemento da WBS seleccione a opção de WBS Milestones Percent Complete no separador de Earned Value, e de seguida defina tantas milestones quantas necessitar e atribua a cada uma um nível de importância ou peso.
Conforme o progresso se realiza vai marcando a conclusão das milestones respectivas e o P6 Professional calcula a performance da percentagem de conclusão do elemento da WBS com base no seu peso, independentemente das actividades de mais baixo nível.
Há assim mais do que um meio de acompanhar de forma física a realização de um projecto.

Calcular o EVM do Current Project

Durante o curso do projecto o plano muda de acordo com a situação corrente mas podemos analisar a medida do Earned Value contra a Baseline, isto é, relativamente ao que foi planeado anteriormente. Para saber qual é o Earned Value relativamente ao Current Project deve fazer o seguinte:
1. Vá a Project à Assign Baselines e seleccione o Current Project como Project Baseline.

2. Ao nível da Enterprise é necessário ir a Projects à seleccione o Projecto e no separador Settings escolha a Baseline para os cálculos de earned value como Baseline do projecto.

Depois de escolher estas configurações o cálculo do Earned Value será feito relativamente ao projecto corrente. Mas é necessário, ainda, ter em conta uma configuração importante que irá afectar os cálculos.
3. Em Admin à Admin Preferences à Earned Value é necessário seleccionar o cálculo de Earned Value. No próximo post explicaremos detalhadamente as razões desta configuração.

Budgeted Values vs. At Completion Values especifica aw iremos usar ou o Budgeted Cost ou At Complete Cost como base para os calculus de Earned Value.
Planned Dates vs. Current Dates especifica se usamos o Planned Start/Planned Finish ou o Start/Finish para a actividade como as datas pelas quais se irá calcular o Earned Value.

O cálculo do ROI para as ferramentas de empresariais de gestão de projecto

Quando é desenvolvido o business case para implementar as ferramentas de gestão empresarial de projecto, tal como o Primavera P6, existem muitas reduções de custo as quais, muitas vezes, não são tomadas em consideração. Esta lista que não é exaustiva, pode ser adicionada às reduções de custo que podem ter sido já apontadas para criar a justificação da selecção da ferramenta EPPM P6. 

Um forte business case com um ROI melhorado que, não só cria poupanças adicionais, mas também pode conduzir a oportunidades de financiamento numa implementação empresarial constituirá mais uma razão para o sucesso e revisão dos benefícios obtidos.

Podemos no business case extrapolar todos os custos estimados abaixo a partir do custo anual do uso do sistema.

1. Custo da Oportunidade – Realização atrasada de Projectos estratégicos

• Os projectos críticos para a missão da companhia custam perda de rendimento de oportunidade e de quota de mercado

Custos: Rendimento potencial estimado por mês e perda de quota de mercado

2. Tempo reduzido da gestão para apagar fogos

• Melhor controlo e informação atempada significa menos tempo perdido a tratar de problemas.

Poupanças: horas estimadas de gestão gastas

3. Custo do Trabalho extra

• Planeamento e controlo melhorado irá significar menos uso de trabalho extra para cumprir os prazos.

Poupanças: Média de Horas extra por semana.

4. Custo do aumento do custo de recursos dos empreiteiros

• Devido á não optimização dos recursos internos
• Evitar o último recurso de usar recursos de empreiteiros para a solução do problema

Poupanças: Média de custo de incremento dos recursos de empreiteiros

5. Custo da falha do projecto

• Planear os projectos melhor
• Expor os problemas mais depressa
• Realizar acções correctivas cedo

Poupanças: melhoria da taxa de custo estimado de falha de projecto

6. Custo de sobre alocar recursos

• Desgaste dos recursos devido ao cansaço
• Custos do recrutamento

Poupanças: Aproveitamento do tempo e redução de custos de recrutamento.

7. Custo da inexactidão da informação – ultrapassagem de custo

• As decisões baseadas em dados incorrectos conduzem ao acréscimo dos custos dos projectos

Poupanças: Melhoria por projecto da percentagem estimada de acréscimo de custos

8. Redução do trabalho redundante

• Redução do esforço duplicado e melhoria do foco na prioridade dos projectos

Poupanças: Redução das horas estimadas do pessoal e redução do número de recursos.

9. Redução do trabalho refeito

• Qualidade melhorada do trabalho através de processo standard e acesso a documentos de referência no Plano do Projecto.

Poupanças: Redução estimada das horas de trabalho em percentagem

10. Custo da produtividade devido a inadequação das competências do pessoal em relação com os requisitos

• As funções e competências requeridas são inerentes ao plano e são evitadas as inadequações

Poupanças: percentagem do pessoal afectado

11. Redução das reuniões de status com o pessoal

• As reuniões são mais focadas com informação concisa na info0rmação de status dos recursos de projecto e portfólio

Poupanças: Número estimado de horas de pessoal por rteunião

12. Tempo de recolha de informação para reuniões de status e relatórios

• A preparação das reuniões é muito mais fácil, rápida e os relatórios focam-se nas áreas de preocupação.

Poupanças: Horas de tempo estimado despendido na recolha de informação e preparação.

13. Produtividade incrementada com base em práticas consistentes

Poupanças: 1% das horas por ano vezes o nº de pessoas vezes a taxa horária.

Análise de Risco do Projecto: O que é e porquê fazer?

Os planos de projecto são, evidentemente, acerca do futuro tudo o que trata do future tem certa incerteza associada. Quando se estima a duração da actividade em 5 dias está intrinsecamente assente que isto pode provavelmente não ser assim mesmo. Pode haver uma pequena quantidade de incerteza ou uma grande, mas alguma haverá com certeza.

Como resultado da incerteza acerca das durações das actividades, qualquer estimativa da data de conclusão do projecto é só isso, uma estimativa. Esta será válida tão só as estimativas das durações das actividades se verifiquem como verdadeiras. Como há sempre muitas actividades, é quase certo que muitas delas tomem menos tempo que o estimado enquanto outras levarão mais tempo que o estimado.

Assim, na realidade o fim do projecto é provável que não possa ser projectado de forma tão determinística como o CPM e o PERT, mas esteja, talvez, dentro de um limite de datas que se pode espalhar simetricamente à volta da estimativa. (Na realidade é pior do que isso. O uso de estimativas determinísticas também introduz um preconceito de tal forma que as estimativas tendem sistematicamente para serem optimistas.)

A Análise de Risco do Plano (Schedule Risk Analysis) é uma técnica que reconhece esta incerteza ao substituir a duração determinística para cada actividade pela distribuição representando os limites das durações prováveis. Existem métodos analíticos para processar as distribuições de probabilidade em casos simples, mas as redes de projecto são normalmente muito complicadas para que estes possam ser aplicados.

A solução é utilizar uma simulação Monte Carlo. Isto é como simular um evento da vida real através do lançamento de dados, só que isto é feito num computador. Os computadores podem gerar aquilo que é denominado como números pseudo-random. Não são verdadeiramente ao acaso, porque eles podem ser reproduzidos se alguém conhecer o mecanismo de geração: utilizando estes números pseudo-random, podemos gerar séries de distribuições desejadas e estas são usadas numa simulação Monte Carlo para simularem sistemas físicos sobre um grande número de cenários gerados ao acaso.

A simulação Monte carlo tem aplicações em muitas áreas. No contexto de uma rede de projecto, a simulação Monte Carlo:

Usa uma amostra da distribuição definida pelo utilizador para cada duração da actividade.

Faz uma análise de caminho crítico (CPM) com base nas durações da amostra.

Armazena os resultados desta análise de tempo (geralmente de uma forma sumária como um histograma).

Repete os passo de 1 a 3 várias centenas ou milhares de vezes.

No fim deste processo pode produzir histogramas representado a probabilidade das distribuições de qualquer resultado de interesse, que geralmente incluem datas mais cedo e mais tarde de início e datas de fim, folga livre e total e custo para cada actividade.

Como resultado, a data de fim estimado do projecto e outras milestones importantes são representadas por distribuições de probabilidade em vez de estimativas com um único ponto. Assim em vez de prever que o projecto será completado em determinada data – uma previsão que o mais certo é ser errada – podemos fazer previsões mais realistas tais como «há 90% de hipótese que o projecto termine até 31 de Maio.»

Mas, talvez a razão mais importante para fazer uma análise de risco é o equilíbrio anteriormente mencionado, que significa que uma estimativa de um só ponto da conclusão do projecto realizada através de um determinístico CPM ou PERT não está muitas vezes nem dentro dos limites representados pela distribuição probabilística produzida pela análise de risco. A razão para isto é um fenómeno denominado merge bias.

UM equilíbrio fundido (merge bias) ocorre sempre que dois ou mais caminhos convergem numa rede e a incerteza acerca das suas durações é tal que qualquer dele pode tornar-se crítico. Para ilustrar este equilíbrio fundido, considere uma actividade que só tem dois predecessores que correm em paralelo. Suponha que cada uma possa levar qualquer coisa como de 1 a 6 dias com probabilidade igual. E suponha, ainda, que elas não ocupam fracções de um dia. (Isto pode parecer um pouco artificial e até é. No entanto, isto permite que o ponto a ser feito por analogia com o lançamento de dados e sem nos envolver numa montanha de cálculo.)

A duração esperada para cada actividade individual é, claro, de 3,5 (já que 1+2+3+4+5+6 todos divididos por 6): mas qual é o tempo esperado para ambos para se concluírem? A tabela seguinte mostra todos os 36 resultados possíveis para o par de actividades, que pode ser simulado pelo lançamento de dois dados. (Assim , por exemplo, se a primeira levar 5 dias e a segunda só 3 dias. O tempo tomado por ambas para serem completadas é 5 dias e pode ser visto na tabela.

	1	2	3	4	5	6
1	1	2	3	4	5	6
2	2	2	3	4	5	6
3	3	3	3	4	5	6
4	4	4	4	4	5	6
5	5	5	5	5	5	6
6	6	6	6	6	6	6

Das 36 possibilidades, só uma tem 1 como máximo enquanto 11 têm 6 como máximo. Assim tendo só dois caminhos paralelos podemos ver que o tempo que leva a realizar ambas as actividades é provável que seja maior do que a estimativa determinística de 3,5 dias. Se fizermos as contas vemos que o valor esperado é na realidade quase 4,5 dias. Com 3 actividades paralelas, o valor esperado é quase de 5 dias e com 5 actividades é cerca de 5,4 dias. E com 10 é de 5,8 dias. A convergiram claramente para 6 conforme o nº de caminhos paralelos aumenta).

Outra forma de olhar para isto é declarar a Lei de Murphy de uma forma menos pessimista do que Murphy.

“Se houver muitas coisas que possam correr mal então pelo menos uma irá correr mal.”
Numa rede de projecto com caminhos paralelos, basta um caminho correr mal para atrasar a conclusão do projecto. (correr mal significa tão só durar mais do que o esperado. Isto não implica que foi feito algum erro, mas pode ser só o resultado da inevitável incerteza envolvida na estimativa original). É isto o merge bias.

“Nestes assuntos a única certeza é que nada é certo.”  (Plínio o Velho)

Opções de Scheduling por omissão

As opções de origem de Scheduling são as constantes do separador General. Por omissão nada está seleccionado no separador Adavanced.

• Use Expected Finish Dates.
• Quando schedulling as actividades progredidas use. Retained Logic.
• Calcule o lage de star para start: Early Start.
• Defina as actividades críticas como: Total Float menos ou igual a zero.
• Calcule o Float com base na Finish Date de: cada projecto.
• Calcule o Total Float como: Finish Float = Late Finish - Early Finish.
• O Calendário para fazer o schedulling do lag da Relação: Calendário da Actividade Predecessora.

Como criar um filtro de look-ahead com base na corrente Data Date

Na vista de Activities, vá para View, Filters. Clique em New, crie o seguinte filtro ajustando-o para as suas necessidades específicas.

Exemplo: O filtro seguinte selecciona todas as actividades planeadas entre a Data date e duas semanas depois da Data Date.

1. No campo de Parameters, seleccione Early Date.
2. No campo Is, seleccione o is within range of.
3. No campo Value, selecione DD - Earliest Data Date
4. No campo High Value, selecione DD - Earliest Data Date e adicione um incremento de tempo que é requerido.

Os valores válidos devem estar no formato + 4W. Em que o ‘+’ pode ser quer ‘+’ como ‘-‘, indicando o futuro ou o passado. O número será o número de horas/dias/semanas/meses e em que a letra indica (H)oras, (D)ias, (W) semanas, (M)esses ou (Y) Anos.

Note: Este filtro pode ser modificado para seleccionar qualquer limite com a introdução de datas adaptadas através dos campos ‘Value’ e ‘High Value’.

Outro Exemplo: seleccionar as actividades que tem trabalho planeado entre a Data Date e duas semanas depois da Data Date.

Remaining early start e Remaining early finish cobrem todas as actividades, incluindo milestones, que não foram ainda iniciadas ou estão em progresso durante o espaço de tempo especificado.

Para incluir actividades que não estão planeadas iniciar, mas estão agendadas para trabalharem durante o intervalo de tempo do filtro de Lookahead, adione a linha:

OR Activity Status equals In Progress

A capacidade para criar um filtro de lok ahead com a utilização do ‘within range of’ em P6 é um pedido de funcionalidade adicional.

Como limitar os dados a exportar com projecto em XER ou MSP

Esta capacidade ainda é um desenvolvimento solicitado à Oracle, mas há formas de limitar os dados exportados utilizando caminhos alternativos.

Os caminhos são os seguintes:

Atalho 1 – é uma solução genérica que pode ser usada para remover um conjunto de dados do ficheiro de exportação

Vá para Enterprise, Projects.

Seleccione o projecto que quer exportar e copie-o com Edit, Copy e, de seguida, vá para Edit, Paste.

Vai ver as Copy Project Options. Na caixa de diálogo desactive os itens que não quer exportar.

Em seguida, aparecerá o Copy WBS Options. Desactive quaisquer itens que não quiser exportar.

O último ecrã é o de Copy Activity Options. Desactive quaisquer itens que não quiser exportar.

Depois de o projecto completar o processo de cola (Paste), exporte o projecto copiado.

Apague o projecto copiado.

Atalho 2 – Como incluir as unidades de recursos, mas remover os custos dos recursos do ficheiro exportado.

Os dados exportados só contém informação para a qual o utilizador que cria o ficheiro de exportação tem acesso. Considerado isto, pode criar um ficheiro de exportação só com a informação que se quer exportar retirando outra que o «utilizador» não deverá ter acesso. Se não pretender dar a conhecer a informação financeira e de custos dos recursos o processo é criar um utilizador que não tenha esse tipo de acesso e fazer a exportação com esse utilizador. Como ele não tem acesso a esta informação a exportação por este realizada não incluirá esta informação.

Atalho 3 – Específico para os Códigos de Actividade

Se quiser unicamente restringir o acesso aos códigos de actividade, pode torná-los secure codes que nunca são exportados.

Vá para Enterprise, Activity Codes e clique em Modify. Escolha para tornar ou códigos de actividade Global ou EPS alterando o check na coluna Secure Code.

Os Códigos de Actividade de Projecto não podem tornar-se em Secure Codes. Entretanto, para realizar esta operação o utilizador deve possuir suficientes permissões e privilégios para editar secure codes.

Atalho 4 – através de folha de cálculo

Exporte para folha de cálculo e durante o processo terá a opção de seleccionar que colunas serão incluídas na folha exportada. Desta forma, pode de forma simples não incluir os dados que não quer exportar.

Dados que podem ser importados / exportados num ficheiro .XER

Ao exportar um projecto para formato XER, apenas um pequeno subconjunto de dados não está incluído no que exporta, no entanto, alguns destes dados podem ser exportados de outras formas.
 

Layouts

Os Layouts, por omissão, não exportam com o XER. No entanto, eles podem ser exportados manualmente fazendo o seguinte:

• Seleccione View > Layout > Open > Seleccione o layout em seguida, seleccione 'Export'.
• Isto irá criar um arquivo. Plf (Primavera Ficheiro de Layout) que pode ser enviado junto com o ficheiro XER

Para exportar o projecto e juntos Layouts veja abaixo:

• Guarde o layout como um Project Level Layout depois exportar usando o formato de exportação Primavera PM XML em vez do formato de ficheiro XER.
• Marque a caixa que diz " Export all project level layouts”'.
• O projecto terá uma extensão. Zip e irá conter o XML do projecto e os layouts.

A capacidade de XER exportação para incluir layouts e filtros é um acessório. Por favor, veja no Suporte Bug 9951816 para mais informações.

Filtros

Os Filtros, por omissão, não exportam com o XER. No entanto, eles podem ser exportados manualmente fazendo o seguinte:

• Criar o filtro e o layout.
• Vá para as Options do filtro e escolha " Copy as layout” - isso irá criar um filtro de layout específico.
• Exportação usando o formato de exportação Primavera PM XML em vez do formato de arquivo XER.
• Marque a caixa que diz " Export all project level layouts”.
• O projecto terá uma extensão. Zip e irá conter o XML do projecto e os layouts.

A capacidade de XER exportação para incluir layouts e filtros é um acessório.

Se o filtro ou Layout usar um Código de Projecto ou WBS, então, estes campos não serão transferidas, porque esses campos são exclusivos para o Projecto onde são usados ​​para. Assim, o Grouping, ou coluna ficará em branco ou o filtro ficará em branco. Eles precisarão ser actualizados para o projecto actual. Ver, no Suporte, o documento de ID 895.356,1
 

Códigos

Códigos de Actividade - Projecto, EPS e Global

• Todos os códigos Global & EPS atribuídos e valores estão incluídos no XER. UNASSIGNED Global & EPS não serão incluídos.
• Todos os códigos de Projecto e Actividade e valores, independentemente se atribuído ou não, serão incluídos no XER.
• Os códigos EPS são exportados com um ficheiro de formato XER. No entanto, para importar esses códigos do XER, eles devem ser criados antes da importação do XER. Para obter instruções sobre como criar códigos de EPS, veja no Suporte Documento ID 901318,1.
   

Códigos de Recursos

Os códigos de recursos e valores são importados com o XER, porém os valores não serão atribuídos ao recurso.
 

Códigos projecto

Todos códigos Projecto e valores estão incluídos no XER. UNASSIGNED Códigos Projecto e valores não estão incluídos.
 

Baselines

As baselines do projecto não são incluídas com a exportação no formato XER. No entanto, elas podem ser exportadas como um projecto separado e reatribuídas após a importação.

A capacidade de exportar baselines com o projecto em formato XER é uma Funcionalidade futura. Por favor, veja no Suporte Bug 9073723 para mais informações.
 

Dados de Progress Reporter

Os dados de Progress Reporter de propagação não-linear não podem ser exportados. É uma base de dados específica e não podem ser migradas para outra base de dados, no entanto, o total de horas efectivas de actividades estarão presentes.

Por exemplo - Horas reais são armazenadas para uma actividade de três dias através de Progress Reporter com uma decomposição assim: Seg - 5 horas, ter - 3hrs, Qua - 7hrs de modo que o número total de horas reais para essa actividade será 15hrs.

Ao importar este projecto a propagação de Horas Reais será linear a partir do Actual Start até ao Early/Actual Finish. A nova decomposição será assim: Seg - 5 horas, ter - 5 horas, quartas - 5 horas igualando o número total de horas reais em 15hrs.
A importação remove a propagação não-linear, mas mantém o total de horas reais em cada actividade >
 

Relatórios

Os relatórios podem ser exportados manualmente fazendo o seguinte:
Clique da direita do rato sobre o Relatório e seleccione 'Exportar'.

Isso irá gerar um ficheiro. Erp (Ficheiro de Relatório).

Qualquer tipo de dados não listados acima é exportada com o ficheiro XER.

KPIs de Performance de Projecto

Quais são as métricas de performance de projecto mais críticas? Vamos fazer uma lista das mais importantes:

• Planeamento – planeado versus real – preferencialmente através do Valor Ganho
• Funcional – % desenhado, implementado, testado, produzido
• Realização em tempo – milestones planeadas versus as milestones reais
• Custo
  • Custo planeado versus custo real
  • Total Planeado na Conclusão versus Revisto ou estimado na Conclusão
• Crítico e outros defeitos – Planeado versus Real + tendência
• Recursos (Pessoas, Equipamentos)
  • Recursos Planeados versus Recursos Reais
  • Recursos Totais Planeado na Conclusão versus Revistos ou estimados na Conclusão
• Riscos – Novos, Fechados, Abertos + Tendências
• Questões – Novas, Fechadas, Abertas + Tendências
• Resultados – Planeados versus reias até à data

Naturalmente que todas estas métricas são quantificáveis. A informação qualitativa pode ser útil quando preparado no seguimento das métricas acima. Os problemas só começam quando as pessoas começam a esgrimir as suas declarações qualitativas e esquecem-se de colocar no relatório algumas das métricas quantitativas. A standardização dos valores a reportar ajuda a mantermo-nos no caminho certo.

Luís Quintino

Selecção de Software de Gestão de Projecto

O software de gestão de projecto é desenvolvido por dezenas de fabricantes com as mais variadas funcionalidades e sofisticação e correspondentes variações de preços. O problema que se pôe às empresas é como encontrar a ferramenta adequada. Esta não é uma tarefa fácil porque não dispomos da possibilidade filtrar todo o «barulho» de marketing, que permita seleccionar a ferramenta certa para a situação ou para a nossa carreira.

Tipos de projectos que fazemos	Categoria de Software
Programas com sub-projectos múltiplos com uma grande equipa e dependências complexas entre as actividades	4
Projecto estratégico: afecta múltiplos depart6amentos ou organizações com um grande orçamento e uma grande equipa, fornecedores externos com muitos stakeholders	3 ou 4
Projecto cliente – fornecedor: equipa de 3 a 8 pessoas com um importante orçamento e um prazo fixo e complexidade na sequenciação de membros da equipa, fornecedores e materiais	2 ou 3
Pequeno projecto: realizado para outro departamento ou para um cliente externo. Equipa de 3 a 5 pessoas, sem orçamento e com uma data de entrega importante	1 ou 2
Projectos ad-hoc: realizados dentro do departamento com uma equipa de 2 ou 3 pessoas incluindo o gestor do projecto e demora menos de um mês sem orçamento e uma data de entrega flexível	1

Os profissionais usam software da categoria 3.

As Categorias de Software

O software disponível encaixa nestas categorias com grandes diferenças de preço conforme vamos subindo a escada.

1. Software web ou baseado na cloud que conserva a informação de projecto com planeamento limitado e permitindo a distribuição de informação, acompanhamento de problemas e colaboração entre os membros da equipa. Se não necessitar de acompanhar de perto o progresso ou fazer relatórios de status, este tipo de software é suficiente. Alguns exemplos Apolo e Dotproject.
2. Software de cloud ou instalado que oferece planeamento com datas de início e fim para cada actividade. Quando a situação muda, terá de introduzir novo início e fim. Se não está a gastar muito dinheiro no projecto e se este é de importância menor este software permite-lhe acompanhar o projecto, saber onde está e reportar o progresso. Exemplos são o iManageProject e Quickbase.
3. Software instalado ou de cloud que possui algoritmos para optimizar um plano e a construção de um orçamento para o projecto. Pode introduzir as actividades, o trabalho / duração das mesmas, precedências e disponibilidade de recursos. O software calcula o plano e o orçamento e fornece ferramentas avançadas para detecção de problemas e modelação de situações. O software de categoria 3 é aquele que é usado pelas pessoas que habitualmente gerem projectos. Exemplos deste são Microsoft Project e Oracle.
4. O software de servidor para gerir centenas de projectos, equipas com muitas pessoas e portfólios de projectos. O software empresarial de gestão de projectos custa muitos milhares de euros. Exemplos são Microsoft Project e Oracle, cada um com a sua versão de portfólio.

As duas primeiras categorias são adequadas para projectos mais pequenos. As capacidades são limitadas assim como a curva de aprendizagem. A sua ineficiência e falta de capacidade é um pequeno incómodo porque o projecto só tem umas poucas pessoas e uma duração curta. O custo deste software é baixo , mas estas não são ferramentas dirigidas a profissionais que regularmente gerem projectos.
O passo grande é o salto da categoria 2 para a 3. Neste ponto, o software muda de plano estático, em que as datas e durações são introduzidas manualmente, para dinâmico dirigido pelos recursos e as dependências. O plano actualiza-se automaticamente sempre que se adiciona ou remove recursos ou a sequência das actividades. Estas funcionalidades poupam muito tempo aos gestores de projecto na criação, optimização e actualização. A curva de aprendizagem é muito mais ingreme e o investimento só vale a pena se o projecto for crítico para a organização e a gestão pretender ter a possibilidade de identificação e correcção precoce. Estas soluções tornam-se indispensáveis quando se trata de projectos de complexidade ou de grande dimensão ou programas com múltiplos sub-projectos
Luís Quintino.

Até que ponto confia na avaliação do tempo e custo real versus o planeado?

Com a agenda das companhias dominada pelas questões de custo e eficiência foi criado um ambiente operacional constrangido em que a capacidade de comparar e contrastar o planeado relativamente ao real em tempo e custos oferece uma maior visibilidade e um controlo mais apertado da performance, determinante para a informada tomada de decisões.

A capacidade para planear com efectividade é crucial, mas poder alocar o tempo e o custo (dos recursos) com absoluta confiança em que serão alcançadas as metas financeiras e de projecto, será muito difícil se as ferramentas de planeamento e os sistemas de registo do trabalho forem usados de forma isolada como é típico nas companhias.

Os sistemas de Timesheets fornecem uma visão adequada e exacta do que deve ser facturado no final de cada semana ou mês, tornando relativamente directo calcular o custo real de atribuir recursos ao projecto e o rendimento que está a ser gerado como resultado. Contudo, se estes cálculos não forem comparados com regularidade relativamente ao tempo e recursos alocados originalmente ao projecto, não haverá forma de avaliar se estamos a trabalhar tão eficientemente como podíamos.

De forma similar, também sem mecanismos formais de reporting em posição que permitam que a gestão possa comparar regularmente o tempo planeado e o custo relativamente ao real, para determinar a exactidão do planeamento realizado não é possível ter dados rigorosos. Esta situação cria incerteza em temos de rendimentos previstos e impactos na capacidade de realocar os recursos e responder com rapidez aos picos de actividade em projecto, ou a impossibilidade de fornecer ao cliente estimativas baseadas na performance histórica quantificada.

Avaliar o níveis de variância

Planear os recursos significa avaliar os requisites destes relativamente às actividades planeadas. O que falta muitas vezes é a visibilidade necessária sobre a disponibilidade dos recursos, o que leva em muitas companhias, quer da construção como da energia, a utilizar recursos genéricos em vez de mapear o seu uso às pessoas, de acordo com as suas competências.

A capacidade de planear a alocação de recursos e prever com clareza o orçamento requerido e o tempo de execução, depende largamente do conhecimento anterior e da experiência da companhia. Muitas vezes os dados históricos não são mantidos e os factores externos parecem determinar que os projectos estejam sujeitos a mudança desde o início. Assim, só a recolha de dados de execução pode oferecer uma verificação da realidade com que o projecto foi orçamentado e do custo do projecto, o que determina o rendimento obtido pela realização de resultados para o cliente.

A variância significa que, a partir desta recolha regular de dados, é possível comparar o planeado relativamente ao executado. Uma variância negativa ocorre quando os custos reais do projecto excedem os custos orçamentados, enquanto uma variância positiva significa que o trabalho foi realizado abaixo do orçamentado.

A variância negativa resulta em ultrapassagens de custos, margem e rendimento reduzidos. Para não esquecer que as variâncias positivas não são necessariamente positivas. De facto, estas podem, por exemplo, ser um indicador de mau trabalho realizado, ou podem ainda significar, que poderia ser realizado o projecto com recursos menos dispendiosos e cumprindo as metas.

Melhorar a Performance

A análise dos níveis de variância entre o real e o planeado pode ser muito reveladora. As companhias gerem os projectos, com rigor cada vez mais aprofundado e com métodos crescentemente aperfeiçoados, e pretendem com esse esforço fazer mais com os mesmos recursos e de melhor maneira. Com isso irão obter uma margem maior e um maior rendimento.

A medida regular da performance dos projectos é a avaliação das diferenças entre os custos e o tempo planeados e os realmente incorridos e o que isso permite de detecção precoce dos problemas e questões. Só aqui se pode basear a tomada de decisões sólida e independente relativamente aos impulsos de intuição ou de avaliação com base numa qualquer «experiência».

Para isto são necessárias ferramentas que comparem os projectos, mas também nos indiquem a melhor forma de gerir a capacidade dos recursos e prever os obstáculos e problemas que são colocados pelas assumpções da realidade.

No topo das ferramentas existentes encontramos a Business Intelligence incluída nas aplicações de gestão de projecto «best of breed» da Oracle Primavera. Aqui podem ver uma demonstração do Primavera P6 Analytics.

Manter-se no caminho com exactidão

Através de um processo de melhoria contínua da efectividade geral do planeamento as companhias podem melhorar a sua performance mas também os seus níveis de serviço prestados aos seus clientes (ver post sobre as métricas das empresas) para quem os resultados estão a ser cumpridos. Quanto mais as previsões e as expectativas dos clientes são cumpridos, maior a experiência e a confiança é construída na companhia.

No clima actual em que a força de trabalho tem de encolher, tal como encolhem os orçamentos e os lucros, é essencial gerir a capacidade do uso dos recursos de forma eficiente e com utilização total. O reporting regular de tempo e custos usados e a sua comparação relativamente ao planeado é a informação essencial que permite fornecer a business intelligence para avaliar a performance entre o real e o planeado. Permite, ainda, construir uma base de dados históricos que assegura um planeamento baseado na evidência, com possibilidade de diminuição das variâncias e um maximizado aumento das margens.

Obtém-se, ainda a, visibilidade da realização dos projectos desde a estrutura organizativa até ao nível individual.

Vamos falar no próximo post na selecção das ferramentas de gestão de projecto.

Spending Plan

O “Spending Plan” é a opção menos usada no Primavera, mas é especialmente útil quando se pretende acompanhar o Custo Real relativamente ao Orçamento alocado ao projecto. Pode acompanhar os Custos Reais relativamente ao Orçamento através da WBS e acumulando-o para cima para o projecto e mesmo acima até à EPS. Entretanto, quando se utiliza o Spending Plan tem de pensar que este usa um método do tipo Top Down, ou seja, temos um orçamento total no nó de cima (Projecto) e distribui-se este valor pelas WBS / EPS abaixo.

Nota – As datas dos Spending Plans começam na na data de PS (Project Start) e terminam depois de 4 anos.

São utilizados os seguintes campos num Spending Plan:

1) Spending Plan – este é um campo usado pelo utilizador e aqui introduz-se o orçamento alocado para o WBS/Project/EPS.

2) Spending Plan Tally – é um sumário e acumula a partir dos nós dependentes. Se estamos a usar para um projecto, então acumula para um nível acima partir da WBS e o mesmo para os nós da EPS.

WBS	Spending Plan	Spending Plan Tally
WBS 1	200	200	Acumula das WBS 1.1 + 1.2
WBS 1.1	100	0	Não tem Spending Plan Tally porque não tem nó filho
WBS 1.2	50	0	Não tem Spending Plan Tally porque não tem nó filho
WBS 2	50	10	Acumula da WBS 2.1
WBS 2.1	10	0	Não tem Spending Plan Tally porque não tem nó filho

3) Variação Corrente não distribuída – (Spending Plan – Spending Plan Tally), segue uma lógica Top-Down, mostra se foi distribuído o seu orçamento pelos nós de WBS/EPS ou não.

3) Undistributed Current Variance – (Spending Plan – Spending Plan Tally) – Follows a Top Down logic, it shows whether you have distributed your budget to the child nodes (WBS/EPS) or not.

WBS	Spending Plan	Spending Plan Tally	Variação Corrente não Distribuída
WBS 1	200	200	0
WBS 1.1	100	0	100
WBS 1.2	50	0	50
WBS 2	50	10	40
WBS 2.1	10	0	10

4) Plano de Benefícios – O Plano de Benefícios segue a mesma lógica do spending plan mas indica os benefícioos que pretendemos alcançar em cada mês. Este é também um campo introduzido manualmente pelo utilizador.

5) Plano de Benefícios Tally – A mesma idea do Spending Plan Tally mas só para os Benefícios.

6) Variação de Benefícios - (Benefit Plan Tally value – Benefit Plan value) segue a mesma lógica da Undistributed Current Variance.