Boa gestão da equipa de projecto

Como Gestor de Projecto, o sucesso depende de como a sua equipa realize bem o seu trabalho. Assim, se pretendemos melhorar a performance da equipa use algumas destas dicas:

Há muitas maneiras diferentes de aumentar a performance das equipas. Eis 10 destas formas para o ajudar…

Dica 1: Mostre-lhes a visão

As pessoas só desempenham bem uma função quando compreendem q que é que é necessário realizar e porquê. Por esta razão, sugiro que reúna a sua equipa para reforçar a visão do projecto, os objectives, escalas de tempo e deadlines. Faça com que a sua equipa se sinta desejada mostrando-lhes que o projecto é critico para o sucesso do negócio. Ganhará a sua adesão e o compromisso para continuar em frente.

Dica 2: Reúna com eles individualmente

Depois da sua reunião, encontre-se à parte com cada membro da equipa e diga-lhes o que necessita deles para ajudar a realizar o projecto. Certifique-se que todos eles possuem uma clara descrição de funções e que eles sabem como irá ser medida a sua performance. Pergunte-lhes como gostariam de ser geridos, o que +e que os motiva e como poderá apoiar a função deles.

Dica 3: Dê-lhes espaço

Neste ponto, precisa recuar um pouco e dar~lhes espaço para trabalharem. Se a pressão aumentar no seu projecto, necessita de lhes dar ainda mais espaço e não menos. Isto é difícil de fazer, mas não os deve pressionar demais senão a sua performance reduzir-se-á em vez de melhorar.

Dica 4: Conte as metas

Ao mesmo tempo que recua, deve pôr em posição verificações para medir regularmente a performance da equipa. Reúna individualmente com os membros da equipa todos os meses para discutir as suas realizações, o que se destacou e como podem ainda melhorar. Garanta que arruma as suas preocupações. Em vez disso fale com les abertamente, mantendo-se construtivo a todo o tempo.

Dica 5: Seja positivo

Se está stressado e desconfortável, não descarregue na equipa. Falar alto ou tomar posições negativas só os tornará mais pressionados.É incrivelmente difícil mas precisa de ser positivo, apoiando e dando-lhes suporte a todo o tempo, mesmo quando o projecto está atrasado.

Dica 6: Aperte mãos e dê palmadas nas costas

É fácil esquecer de louvar os sucessos da equipa. Assim, sempre que realize um produto de boa qualidade, termine uma actividade difícil em tempo ou receba um feedback bom do seu cliente – dê os parabens os responsáveis por isso na sua equipa.

Dica 7: Actividades de reforço do moral

Reúna regularmente com a equipa para construir um forte espírito de equipa. Leve-os a socializar em conjunto, para que sejam formadas novas amizades. Quanto mais forte for a ligação que os membros da sua equipa tenham uns com os outros, mais provável é que trabalhem em conjunto como uma unidade singular e coesa e alcancem os objectivos que estabeleceu.

Dica 8: Dê tempo livre

Não tenha receio de dar aos membros da equipa tempo livre por terem trabalhado arduamente. Ao terem tempo livre, irá reduzir os tempos de doença, melhorar a motivação e aumentar a eficiência.

Dica 9: Dê-lhes o que eles precisam

Todas as pessoas são motivadas por diferentes coisas. Precisa saber o que motiva cada membro da sua equipa. precisa de os conhecer bem, Se consegue recompensar cada pessoa diferentemente com base nas suas motivações, então conseguirá ao longo do tempo melhorar a sua performance. Este é o truque mais difícil do livro, mas aquele que paga maiores dividendos.

Dica10: Celebre as vossas vitórias!

A equipa demasiadas vezes termina um projecto e muda-se directamente para o próximo sem sequer celebrar o sucesso. Quando isto é feito, o que acontece é que o stress e a pressão vão ser carregados para o novo projecto onde irão trabalhar. Assim, ajude a sua equipa a começar «de fresco» celebrando o sucesso no fim do projecto.

Se tomarmos em conta e de forma séria estas dicas, aumentaremos as possibilidades de melhorar a performance da equipa e também a chance de sucesso.

Solucionar Problemas de Qualidade

 

Os problemas de qualidade podem não ser incrementados até ao nível de uma questão mas não deixam de ser problemas e devem ser solucionados utilizando as mesmas técnicas de solução de problemas do projecto. Adivinhar a causa do problema é um método que raras vezes funciona. Uma abordagem estruturada é muito mais efectiva. Queremos não só resolver este problema particular, mas também queremos compreender o problema de forma suficiente a que possamos identificar a causa que se encontra na sua raiz e garantir que este problema de qualidade particular não ocorra outra vez.

Utilize o seguinte processo geral para identificar e solucionar problemas de qualidade.

1. Identificar o problema ou sintoma. Não deve assumir que todos conhecem já o problema. Encontrar tempo para documentar o problema em termos claros que todos possam compreender. Garanta, também, que explica o impacto no projecto do problema de qualidade.
2. Identificar a raiz causal. Este é o passo mais importante, já que não queremos perder o nosso tempo resolvendo um sintoma de qualidade. Pelo contrário, devemos ser muito claros na raiz causal e explicar como esta causa causa em úlima instância o problema. Se não conseguimos determinar a raiz causal do problema apercebido isso significa que não investigámos tão profundamente quanto necessário.
3. Determinar alternativas e impactos. O gestor do projecto pode atribuir uma ou mais pessoas para determinar as alternativas. Para cada alternativa, devem também destacar o impacto no projecto.
4. Seleccionar a melhor alternativa. A equipa do projecto, o sponsor e o cliente podem ainda ser envolvidos na determinação da melhor alternativa. Contudo, a equipa de projecto pode ser capaz de resolver por si própria o problema se este não constituir uma questão formal. De facto, pode ser um problema relacionado com os produtos de trabalho intermédios que se encontram integralmente sob o controlo da equipa de projecto.
5. Executar. Um mini-plano deve ser activado para enfrentar o problema de qualidade e implementar a alternative escolhida. Estas actividades devem ser movidas para o plano de trabalho do projecto de forma a garantir que são realizadas.
6. Validar. Este processo deve ser revalidado para garantir que a qualidade foi melhorada conforme o esperado. Se a qualidade melhorou ou está a caminha nesse sentido, pode monitorar a partir daì. Contudo, se a qualidade não está a melhorar conforme esperado devem ser adoptadas acções correctivas se necessário.

"Causas Especiais” e "Causas Comuns" de Erros

Quando se procuram as causas de defeitos de produtos (erros) verificamos que elas caem em duas categorias gerais. O Dr Edward Deming chama a estes erros "causa especial" e "causa comum".

As "causas especiais" são aquelas que os utilizadores locais do produto podem encontrar e, por vezes, solucionar. Isto inclui deficiências, falta de formação, uso deficiente de equipamento, vandalismo, etc.

A segunda categoria é denominada "causas comuns". Estas causas podem provocar variações grandes na qualidade e incluem problemas sistemáticos que os utilizadores não podem determinar. Por exemplo, erros de causa comum podem incluir imperfeições menores no equipamento, desenho deficiente do produto, má performance do equipamento, processos que trabalham mas não estão optimizados, etc. Estes problemas são "comuns”, mas são muito difíceis de detectar pelos utilizadores locais.  

As desvantagens do Percent Complete

 

ou O Acompanhamento e Controlo do Projecto em MS Project

Quando um gestor de projecto chega à ocasião em que se torna necessário recolher o real progresso há uma tendência para actualizar a informação colocando um valor no campo Percent Complete (% complete) para as actividades. Isto acontece por duas razões:

– As empresas podem considerar difícil obter dados referentes ao trabalho real dos membros da equipa.

– Também a barra standard de tracking do programa baseia-se neste método e assim esta parece ser a escolha mais lógica.

Apesar deste procedimento parecer o mais fácil, quer do ponto de vista da obtenção de informação dos vários membros da equipa e a quantidade de tempo que é necessária para actualizar o plano, há desvantagens na perspectiva de se obter um exacto calendário de execução do projecto. Quando se acompanha o progresso com a introdução de Percent Complete o Project pode mudar os valores nos campos de Work. E certamente não é isso que é pretendido se o projecto foi aprovado com base numa determinada quantidade esforço de trabalho.

Como Percent Complete afecta o calendário restante

Quando se actualiza o Percent Complete da actividade, o Project multiplica o campo de Duração da Actividade (Task Duration) pela percentagem introduzida e introduz esse valor como a duração real (Actual Duration). De seguida marca tantos períodos de tempo desde o início da actividade como estando concluídos, utilizando as atribuições das alocações planeadas durantes aqueles períodos de tempo. O trabalho planeado nesses períodos de tempo fica agora marcado como trabalho real concluído (actual work completed).

O Project assume que o trabalho se desenrolou conforme planeado e isto pode muitas vezes ser irrealista.

Assim, se pretende introduzir o tracking com o Percent Complete e pretendemos que o Project reflicta com precisão o progresso planeado, deve então mudar o Work e as Units da alocação do recurso conforme a execução real antes de introduzir a percentagem

E se houver recursos múltiplos numa actividade?

Outra desvantagem de introduzir os dados como Percent Complete é que este campo existe ao nível da actividade e não ao nível da alocação do recurso (resource assignment level).

Quando entramos uma percentagem, o Project assume que todos os recursos estão a progredir com o mesmo ritmo. Isto pode não ser verdade, especialmente nas instâncias em que os recursos possuem diferentes responsabilidades. Se um recurso concluiu 75% da sua atribuição e outro somente 25%, seria mais acertado introduzir Percent Work Complete (Campo:  %Work Complete) , para cada um dos recursos alocados. Desta forma o Project vai calcular o Percent Complete ao nível da actividade no seu todo mas não se evitaram os outros problemas acima referidos. O trabalho completado continua a ser registado como tendo sido desenvolvidos nos dias para os quais se encontrava originalmente planeado.

 

E o trabalho em falta?

Há ainda outro problema decorrente da utilização da tabela de Tracking. Quando se acompanha por Percent Complete, o Project faz muitas assumpções de outros campos relacionados com o progresso real. Estamos e facto a recolher a percentagem da duração que está concluída, e desta forma o Project actualiza a Actual Duration e Remaining Duration com base no valor de Percent Complete. Os campos Actual Work e Remaining Work também são valorizados se manteve a opção pré-definida de option 'Updating task status updates resource status', no separador de Calculation das Options do programa.

Na tabela de Tracking podemos ver o Actual Work, mas não está lá o Remaining Work ( na versão pré-definida da tabela. A única forma de o Project re-planear a actividade (ou seja reavaliar a data de Fim) é estimar uma nova quantidade de trabalho que é necessário realizar para completar a actividade.

Quando se decide re-planear a data de fim da Actividade (Finish Date) actualizando o campo da duração restante (Remaining Duration) , o que parece ser o método preferido do Project com base no design da tabela de Tracking, corre-se o risco de modificar o total de trabalho da actividade. Tal ocorre se o tipo de Actividade (Task Type) está estabelecido para Fixed Units (pré-definido no Project) ou Fixed Duration. Ainda é pior se estamos a fazer a monitorização sem utilizarmos a tabela e sem incluirmos nela os campos que necessitamos.

O que deve fazer um P. M.

A verdadeira solução para tudo isto é monitorizar o trabalho realizado e o trabalho em falta (Actual  and Remaining Work) e não o Percent Complete e para fazer isto deve utilizar-se a grelha de tempo e não a tabela de Tracking.

Lembre-se que se não se introduzir valores a 0 para todos os dias em que o trabalho não ocorreu ainda é possível de planear o trabalho em falta. Se está preocupado com a quantidade de trabalho e de tempo que levará para actualizar o plano que contenha muitos recursos e actividades e realizar estas tarefas de forma regular.

Enfim

A linha de orientação é que para que o Project calcule com eficência e exactidão o plano:

Crie uma vista que mostre a informação crítica e que reflicta o progresso real e o trabalho que falta realizar.

• Recolha o trabalho realizado de acordo com o tempo.
• Recolha o trabalho em falta.
• Re-planeie o trabalho em falta

Como criar o Plano Financeiro do Projecto

Passo 1: Listar as Despesas Financeiras do Projecto

O primeiro passoi tomado quando se define o Plano Financeiro e se estabelece o orçamento do projecto é identificar todos os tipos de despesas que que podem ser incorridas durante o Ciclo de Vida do Projecto.

Muitos projectos, tipicamente, gastam a maioria do seu orçamento na compra, aluguer e arrendamento ou contratação de recursos para o projecto (como trabalho, equipamento e materiais). Contudo podfem ser realizadas outros tipos de despesas que se relacionam com:

• Compra de recursos de fornecedores
• Estabelecimento de um Project Office
• Administração do projecto

Passo 2: Quantificar as Despesas Financeiras

Logo que tenha identificada uma lista detalhada de despesas que serão realizadas durante o projecto, o proóximo passo será prever a unidade de custo de cada despesas listada na relação acima efectuada. A unidade de custo é simplesmente o custo de uma unidade singular de um item particular de despesa. Por exempo, a unidade de custo para:

• Trabalho pode ser calculado como custo de hora fornecida
• Equipamento pode ser calculado como o custo de arrendamento por dia
• materiais pode ser calculado como custo de compra por quantidade 

Depois de listar os custos unitários pode então calcular a quantidade total de cada item de despesa nécessária para realizar o projecto. Por exemplo:

• Identificar o número de funções exigidas
• Quantificar os itens de equipamento necessários
• Determinar a quantidade de materiais requerridos
• Quantificar os itens de compras que devem ser recebidos de fornecedores 
• Calcular Os custos de administração do projecto

Passo 3: Construir o agendamento da despesa

Recolhemos então toda a informação necessária para construir um agendamento detalhado da despesa. Este agendamento permitirá ao Gestor de Projecto calcular o custo total para realizar o projecto numa base diária, semanal ou mensal.

Para criar o Agendamento da Despesa, construa uma tabela que liste todos os tipos de despesas do lado esquerdo da página e todas as semanas do ano na coluna da frente. Identifique depois para cada semana e cada tipo de despesa a quantidade de despesa financeira a orçamentar. Quando terminar, pode somar todas as despesas de uma semana particular para obter um orçamento semanal de todo o projecto.

Claro que pode querer calcular uma visão diária, mensal ou anual com base nas necessidades próprias do seu projecto. E não esqueça ainda de listar as assumpções feitas durante a criação deste Plano Financeiro. Por exemplo, pode ter assumido que:

• "As data de entrega dos resultados não sofrerão alteraçõesdurante o projecto."
• "As previsões de unidades de custo estão exacatas dentro de uma variação de 5%."
• "Os fundos financeiros listados no plano estarão disponíveis quando necessário."

Finalmente, liste quaisquer constrangimentos identificados durante o processo de planeamento financeiro. Como por exemplo:

• "A informaçõo disponível era l,imitada durante a identificação dos custos"
• "Uma retração do mercado provocou um acréscimo nos custos do trabalho"

Passo 4: Definir o Processo Financeiro

Depois da criação do Agendamento das Despesas pode necessitar de definir o processo de monitorização e controlo das despesas  (i.e. custos) durante o Ciclo de Vida do Projecto. Definir o Processo de Gestão do Custo do seu projecto através da documentação de:

• Propósito do processo
• Passos envolvidos na realização do processo
• Funções e responsabilidades envolvidas na realização do processo
• Modelos utilizados para suportar o processo

Chegámos ao fim. Concluondo estes passos pode construir um Plano Financeiro adequado que o auxilie a disponibilizar os resultados do projecto em tempo e no orçamento.

Como definir o âmbito do projecto

 

O âmbito do projecto (project scope) é composto por todas as coisas que devem ser produzidas para completar o projecto. Estas «coisas» são denominadas resultados (deliverables) e precisamos de as descrever em profundidade tão cedo quanto possíveol na vida do projecto, para que todos saibam o que é necessário ser produzido. Estes são cinco passos para definir o âmbito dos seus projectos:

Passo 1: Definir a Direcção

Comece por estabelecer a direcção do projecto. Já possui uma visão do projecto acordada pelos stakeholders, sabe os Objectivos e a Escala de Tempo? Foram definidos com profundidade e o cliente concordou com eles? Será que já toda a gente no projecto os compreende verdadeiramente e a razão da sua importância? Só estabelecendo a direcção para o projecto pode definir o âmbito do projecto.

Passo 2: Workshops de âmbito

O caminho para alcançar bons resultados com a definição do âmbito do projecto é obter a ajuda de todos os stakeholders importantes na sua concretização. Para isso, reuna na mesma sala o sponsor do seu projecto, o cliente e outros stakeholders e realize um work shop de identificação do âmbito.

O que pretende deles é que concordem num conjunto de garndes resultados (deliverables) que devem ser produzidos pelo projecto. Também quer saber «o que está fora do âmbito».

Comece o workshop colocando  a cada stakeholder qual a lista de resultados que cada um expera ´que a equipa obtenha com o projecto.

Com esta lista completa obtida da discussão procure obter o assentimento colectivo relativamente ao que é «mandatório» e ao que é «opcional». No final procure priorizar a lista, para poder saber a ordem de produção dos resultados.

Passo 3: Esclareça tudo

Possui agora uma lista acordada de resultados do projecto. Necessita definir em profundidade cada uma destas.

Trabalhe com as pessoas adequadas na sua para descrever como cada resultado deverá ser apresentado e o que deverá incluir, como irá operar e como será suportado, etc. Mas isto ainda não é suficiente!

O seu objectivo é tornar tudo tão específico que o seu cliente não possa declarar maios tarde no projecto que «quando diziam isto, afinal pretendiam significar aquilo».

Passo 4: Avaliar a Viabilidade 

Tem agora uma lista detalhada e a descrição de todos os resultados a serem produzidos no seu projecto ordenados por prioridade e separados por mandatórios / opcionais.

Muito bom! Mas será isto viável de alcançar dentro da dta de fim prevista para o projecto? Antes de confirmar o âmbito, é necessário rever cada resultado da lista e obter uma indicação geral da equipa relativamente a se todas podem ser completadas antes da data de fim. Se não puderem, então quais os resultados que podem ser removidos da lista para permitir que a data de fim possas ser cumprida?

Passo 5: Preparar o arranque

Apresente o conjunto priorizado de resultados ao Sponsor do Projecto e peça-lhe para aprovar a lista como o âmbito do projecto. Peça-lhe ainda que ele concorde com as priroridades, com as descrições de rsultados e com os itens considerados fora do âmbito.

A obtenção de uma aprovação formal coloca-nos numa posição muito boa para gerir o âmbito do projecto de acorod com o camin ho definido. Assim , quando o Sponsor nos diz após algumas semanas ”Pode adicionar mais estes resultados à sua lista?”, pode responder dizendo “Sim, mas ou removemos alguns itens da lista para isso ou alargamos a data de fim do projecto. Qual é que vai ser?”

Pode facilmente gerir as expectativas do Sponsor com um documento detalhado de âmbito na sua mesa.

O documento de âmbito é a armadura do Gestor de Projecto. Protege-o das alterações e fá-lo sentir-se invencível.

O Custo da Qualidade

A construção dos passos da qualidade no agendamento do projecto adiciona uma certa quantidade de esforço e custo ao projecto. Contudo, estes custos incrementais serão recompensados com linhas de tempo mais curtas e custos reduzidos durante todo o ciclo de vida da solução. Exemplos do custo da qualidade incluem:

· Revisão de resultados. Há um custo associado com o tempo das pessoas que realizam revisões. Este inclui qualquer preparação, o tempo da própria revisão para todos os participantes e o trabalho de follow-up a partir da revisão.

· Criação do Plano de Gestão da Qualidade. O tempo exigido para planear a qualidade no projecto e a solução, incluindo a identificação dos critérios de correcção e totalidade.

· Aprovação pelo Cliente. O tempo e esforço requerido pelo cliente para rever os resultados intermédios e finais e aprová-los formalmente como correctos e completos.

· Teste. O teste faz parte do ciclo de vida do projecto e é realizado para garantir que a solução responde aos requisitos e standards da qualidade.

· Standards de controlo da Qualidade. O tempo e custo associado com a definição dos standards relevantes utilizados durante todo o projecto e/ou a organização.

· Auditorias. Auditorias são oportunidades para realizar uma revisão por uma terceira parte dos processos utilizados para criar os resultados. Os auditores da terceira parte oferecem uma perspectiva fresca e sem preconceitos sobre se estão definidos bons processos e estes estão a ser seguidos. Contudo, não há dúvida que a auditoria implica trabalho adicional e esforço por parte do gestor do projecto e da pessoa que realiza a auditoria.

· Listas de Verificação. Estas são usualmente utilizadas para validar se todos os passos de um processo foram concluídos ou se todos os componentes de um resultado estão no seu lugar. Há um custo para as criar e um custo para as preencher.

· Grupos de Controlo da Qualidade e da Garantia da Qualidade. Se a sua companhia tem grupos distintos especializados no controlo de qualidade ou garantia da qualidade, o seu custo são uma parte dos custos globais da qualidade para a organização.

· Recolha de métricas. As métricas são normalmente recolhidas para mostrar o estado de um processo e para corrigir existe associada a este um custo.

Os Benefícios da Qualidade

Os custos da qualidade devem ser medidos contra os benefícios de oferecer uma solução de qualidade. Assim muitos dos custos da qualidade são visíveis no projecto, ao mesmo tempo que os benefícios da qualidade se mostram em todo o ciclo de vida da solução. Os benefícios da qualidade incluem:

· Satisfação acrescida do cliente. Menos defeitos, significa que o cliente estará mais satisfeito. Qualidade de serviço elevada tornará a experiência do cliente mais satisfatória. Se está num negócio tendo por objective o lucro, esta satisfação traduz-se numa acrescida boa vontade e pode converter-se em vendas adicionais ou mais altas margens em produtos futuros.

· Produtividade mais elevada. Solucionar erros e refazer resultados previamente completados são consumo da produtividade. De facto, contribuem para a produtividade negativa. Se os resultados são produzidos com qualidade mais elevada e menos trabalho repetido, crescerá a produtividade global do projecto.

· Custos mais baixos / duração mais curta. Embora existam custos iniciais mais elevados num processo de qualidade estas condições são compensadas por menos trabalho repetido até ao fim do projecto. Esta opção irá poupar tempo e custo do projecto.

· Moral mais elevada da equipa. O moral da equipa é afectado se existem muitos erros por descobrir durante o projecto. As pessoas sentem-se mal quando os erros não são encobertos e pode ser frustrante ter de corrigir erros de forma repetitiva. A moral da equipa crescerá (ou pelo menos manter-se á estável) se os resultados são criados com menos erro à primeira.

· Menos erros / defeitos. A qualidade mais alta demonstra-se ao longo da vida da solução com menos erros e defeitos. Se está a produzir um produto para venda no Mercado, a qualidade mais alta significa menos queixas, menos trabalho em garantia, menos reparações, etc. Se está a criar uma solução de longo prazo isto significa menor suporte e menos problemas de manutenção ao longo do ciclo de vida.

O Custo da Baixa qualidade

Custa tempo e dinheiro construir uma solução de qualidade. Pode parecer que é mais barato deixar os passos da qualidade de for a, mas este não é o caso. É importante reconhecer que há também um custo por ter uma qualidade pobre. Estes custos podem não ser aparentes quando o projecto está em progresso, mas devem ser tomados em conta definitivamente como parte do ciclo de vida total do custo da solução que está ser desenvolvida. Exemplos de custo de pobre qualidade incluem:

· Trabalho em garantia. Este inclui o trabalho que é realizado num produto ou aplicação sem facturação (ou a preço reduzido) dentro da garantia.

· Reparações / manutenção. Este é o trabalho que é feito para resolver problemas depois que a solução é posta em produção.

· Insatisfação do Cliente. Se a solução tem qualidade pobre o cliente não ficará satisfeito e pode não voltar a querer trabalho nosso. Se o projecto é interno o cliente pode não querer utilizar o gestor de projecto e os membros da equipa em projectos subsequentes.

· Help desk. Muito do esforço e custo (mas não todo) de manter um serviço de help desk pode ser requerido porque o cliente tem problemas com as soluções produzidas ou tem questões de compreensão da forma de utilizar as suas soluções.

· Pessoal de suporte.  Muito do esforço associado com o pessoal de suporte é necessário para manter e suportar uma solução devido a problemas, erros e questões, etc.

· Baixa moral. Ninguém gosta de trabalhar para uma organização ou um projecto com pobres processos ou que produza soluções de baixa qualidade. Os custos da baixa moral incluem absentismo, despesas maiores e baixa produtividade do pessoal.

Os conceitos básicos do valor ganho

Valor ganho uma forma de medir o progresso.

Em qualquer projecto, o valor obtido é baseado na conclusão do trabalho. Na perspectiva do cliente, o valor de negócio é alcançado quando o projecto é completado. Se um projecto é cancelado a 90% da sua conclusão, valor de negócio pode ser de zero. Contudo o valor ganho vê estas coisas de forma diferente. Com o valor ganho, vamos ganhando o valor do projecto numa escala incremental conforme o projecto é executado. Quando 50% do trabalho está executado, pode dizer-se que 50% do valor do projecto também foi realizado.

Da mesma forma, face aos condicionalismos de hoje, os cálculos de valor ganho, permitem determinar o custo total do trabalho realizado até ao momento, bem como o custo total de todo o trabalho que esperava ter completado até ao momento. Comparando estes dois números temos um sentido sobre se estamos acima do orçamento, abaixo do orçamento ou no orçamento.

Utilizando ambas as métricas de agendamento e de custo obtemos ainda mais informação. Pode estar a gastar o seu orçamento mais rápido do que esperava, mas e se a razão para isso é porque está avançado também no agendamento? Ou seja, pode estar a gastar mais porque a sua equipa pode estar a fazer mais trabalho que o planeado. Isto até pode ser bom. Da mesma forma, se o seu projecto está atrasado no agendamento, mas também está atrasado nos gastos, pode também ser bom. Talvez não tenha sido capaz de alocar ops membros da equipa tão rápido como o planeado. Assim, o seu projecto está atrasado no agendamento, assim como na taxa e gastos. Se tem uma data crítica de fim isto pode ser um problema. Se a sua data de fim é flexível, estará bem enquanto não ultrapassar o seu orçamento.

O valor ganho oferece-nos a informação necessária para tomar as decisões apropriadas.

Há três métricas que formam a construção do valor ganho – Valor Ganho, Custo Real e Valor planeado.

Valor Ganho (EV)

O valor ganho é calculado adicionando o custo orçamentado de cada actividade que foi concluída. (Lembre-se, este não é o custo real das actividades de trabalho; este é o custo orçamentado.) Veja o seguinte exemplo: 

Data de Hoje: 31 de Março

Actividades completadas	A	B	C	D
Data de alvo	10 de Março	15 de Março	31 de Março	5 de Abril
Custo Orçamentado	20	10	15	5
Custo Real	20	5	20	10

Vamos considerar que completámos as actividades A, B, C e D. Pode adivinhar a fórmula simples para determinar o valor ganho? Encontrou! É 20 + 10 + 15 + 5), o que dá o nº redondo conveniente de 50.

Valor ganho (EV) é a básica medida de quanto valor o projecto atingiu até agora. Por si só não nos diz muito. Assim, utilizamo-lo em combinação com outros cálculos para determinar o status do projecto.

Custo Real (AC)

Para calcular este valor adiciona-se o custo real de todo o trabalho completado até à data no projecto. Se o seu projecto consiste sobretudo de trabalho, então o custo do esforço acompanhará as mesmas linhas. Se tem muitos custos de não trabalho no seu orçamento, então os custos do projecto não estão directamente ligados aos custos do trabalho amos ver de novo o exemplo:

Data de Hoje: 31 de Março

Actividades completadas	A	B	C	D
Data de alvo	10 de Março	15 de Março	31 de Março	5 de Abril
Custo Orçamentado	20	10	15	5
Custo Real	20	5	20	10

O custo real para as actividades de A a D é (20 + 5 + 20 + 10) ou 55. Pode ver que os custos reais para o trabalho realizado são maiores que os custos orçamentados para o trabalho realizado. Isto pode representar um problema.

Valor Planeado (PV)

Esta é a soma das estimações orçamentadas para todo o trabalho que foi agendado para estar completado hoje ( ou outra data específica).

Data de Hoje: 31 de Março

Actividades completadas	A	B	C	D
Data de alvo	10 de Março	15 de Março	31 de Março	5 de Abril
Custo Orçamentado	20	10	15	5
Custo Real	20	5	20	10

Agora já possuímos um pouco mais de informação. Já que hoje estamos em 31 de Março, o valor planeado é A + B + C (20 + 10 + 15) ou 45. Não conta a actividade D, já que não estava previsto terminar até 31 de Março.

Agora vamos juntar estas métricas fundamentais em conjunto.

Variância de Agendamento (SV)

A Variância de Agendamento (SV) diz-nos se estamos avançados ou atrasados no agendamento e é calculada como EV - PV. No nosso exemplo acima, o EV é 50 (20 + 10 + 15 + 5) e o PV é 45 (20 + 10 + 15). Note que a diferença é a D. Mas como o trabalho foi concluído nesta actividade este está incluído no EV. Contudo, como não estava agendado para estar concluído até 31 de Março, não pode ser incluído no PV.

A Variância de Agendamento é 5 (50 – 45). Se o resultado é positive, significa que se realizou mais trabalho do que inicialmente agendado até este ponto. Estamos provavelmente avançados no agendamento. Da mesma forma, se o SV é negativo, o projecto está provavelmente atrasado no agendamento.

Variância de Custo (CV)

A Variância de Custo oferece-nos um sentido para como estamos a realizar face ao orçamento e é calculada como EV - AC. Se a Variância de Custo é positive, significa que o custo orçamentado para realizar o trabalho foi mais do que o que foi efectivamente gasto pela mesma quantidade de trabalho. Isto significa que estamos bem na perspective do orçamento. Se a CV é negativa, podemos estar acima do orçamento neste ponto. No nosso exemplo acima a EV é 50. O AC é 55. Assim, a Variância de Custo é -5 (50 – 55), o que significa que estamos acima do orçamentado.

Index de Performance do Agendamento (SPI)

Esta é uma relação calculada com a fórmula EV / PV. Mostra a relação entre o custo orçamentado do trabalho que foi efectivamente realizado e o custo do trabalho que estva agendado para ser concluído no mesmo tempo. Oferece-nos a taxa de velocidade do projecto. Se o cálculo é superior a 1.0, o projecto está avançado relativamente ao orçamentado. No exemplo acima o SPI é igual a (50 / 45) ou 1.11. Isto implica que a sua equipa completou aproximadamente mais 11% de trabalho do que aquilo que estava agendado. Se esta tendência continua, acabaremos por levar 11% menos de tempo para completer o projecto do que aquilo que estava agendado.

Index de Performance de Custo (CPI)

Esta é uma relação calculada com a fórmula EV / AC. Ela mostra a relação entre o Valor Ganho e o Custo Real do trabalho que foi re4alizado. This shows the relationship between the Earned Value and the actual cost of the work that was performed. Oferece-nos a taxa de consume do projecto. Se o cálculo é menor que 1.0, o projecto está sobre-orçamentado. No nosso exemplo o CPI é (50 / 55) ou .91. Um CPI de ,91 significa que por cada 91€ de despesas orçamentadas, o seu projecto está a gastar 100€ para obter o mesmo trabalho realizado. Se essa tendência continua acabará com o projecto sobre-orçamentado no final.

Serviços Especializados de Gestão de Projecto

Numa óptica empresarial orientada a custos, é normal que as empresas olhem para a gestão de projecto como um serviço complementar e que cai fora da cadeia de valor.
Como se pode então apresentar a gestão de projectos?
Que vantagens deve conter a gestão de projectos quando apresentada numa óptica de serviço básico no desenvolvimento de um projecto, entendida como um garante da qualidade das entregas e que, consequentemente, deve ser desempenhada por profissionais especializados para o efeito?
Podemos enunciar sete vantagens, que passaremos a desenvolver resumidamente a seguir:
1. Conhecimentos metodológicos;
2. Experiência acumulada;
3. Visão global do projecto;
4. Enfoque específico nas actividades de gestão;
5. Enfoque nos processos que acrescentam valor;
6. O gestor como garante da qualidade;
7. Imparcialidade das decisões.
1. Conhecimentos metodológicos
A gestão de projecto especializada assenta numa formação específica baseada em conhecimentos metodológicos estruturados em boas práticas de implementação de projectos, que incorporam o conhecimento de décadas de projectos em áreas empresariais diferenciadas, para além das SI/TI.
O Project Management Institut e a sua norma – PMBoK, é um bom exemplo no desenvolvimento de boas práticas de gestão de projectos. Este instituto, com sede nos Estados Unidos, junta actualmente cerca de 150 mil profissionais espalhados pelo mundo, que estão reunidos activamente com o intuito de realizar, divulgar e melhorar as práticas de gestão de projecto.
Estes conhecimentos metodológicos, baseados em áreas de conhecimentos, são aplicados na gestão de projecto especializada de acordo com o tipo de projecto em causa. Os gestores de projecto que são contratados exclusivamente para realizar actividades de gestão de projectos aplicam-nas de acordo com o timing e tipo de projecto em causa.
2. Experiência acumulada
Quando a gestão de um projecto é atribuída a alguém da organização puramente por se tratar de um profissional sénior, normalmente é porque esse indivíduo tem conhecimentos e experiência relativamente ao produto que vai ser desenvolvido, e não por conhecimentos de gestão.
A vantagem dos gestores que trabalham na área da consultoria especializada, designadamente da gestão de projecto, tem a ver com o facto de disporem de maiores conhecimentos do mercado, de uma visão mais alargada das boas práticas existentes, e de maior experiência no trabalho desenvolvido numa óptica de projectos, permitindo-lhes assumir uma posição de mentor e, por vezes, propondo melhorias aos próprios processos da empresa que os contrata.
3. Visão global do projecto
Quando os projectos atingem determinada dimensão, existe a necessidade natural de os dividir em sub-projectos e atribuir responsáveis a esses mesmos sub-projectos. Esses responsáveis são normalmente elementos com experiência específica na componente principal desse sub-projecto ou resultado, desconhecendo por vezes as necessidades dos outros sub-projectos.
A existência de um corpo de gestão de alto nível, permite criar um papel de gestor de projecto que detém conhecimentos dos vários sub-projectos, das formas de relacionamento entre eles e das respectivas dependências. Somente desta forma se consegue atingir e garantir que o projecto, no seu todo, atinge os objectivos inicialmente traçados.
4. Foco específico nas actividades de gestão
Actualmente o mercado já se encontra receptivo para contratar serviços especializados de gestão de projectos que detenham uma visão global do projecto, quer na sua vertente mais comercial, quer na sua vertente mais técnica.
A típica evolução de carreira assenta numa normal evolução, começando como técnico que realiza, para passar depois a responsável que coordena. Normalmente, quem tem gosto pela realização tende a refugiar-se naquilo que mais domina, no seu território de conforto. A actividade de gestão especializada tem a vantagem de dividir e orientar as tarefas para uma óptica de responsabilização, de forma a garantir o cumprimento de prazos e a qualidade de produto. O gestor deve gerir, enquanto o técnico deve construir.
5. Foco nos processos que acrescentam valor
A gestão de projectos é uma actividade que engloba uma grande quantidade de processos e as respectivas actividades. A gestão de projecto, quando contratada em regime de outsourcing, torna-se num serviço que, à priori, realiza um estudo prévio aos projectos, de forma a distinguir os processos que podem ser aplicados e que vão acrescentar valor.
Pegando, por exemplo, no conjunto de áreas de conhecimento da norma PMBoK, o gestor de projecto vai preocupar-se em distinguir quais delas se podem aplicar ao projecto em causa e verificar quais os processos que podem ser utilizados. Este estudo prévio serve como apresentação do trabalho a realizar pelo gestor e constitui o próprio âmbito do trabalho de gestão a desenvolver pelo mesmo.
6. O Gestor como garante da qualidade
Quando existe num projecto um gestor que provém de uma empresa terceira, o cliente final tem normalmente duas abordagens: ou considera estranho haver necessidade de contratação de um terceiro para gerir o projecto; ou então considera positivo existir uma terceira entidade externa ao contrato estabelecido que deu origem ao projecto, olhando para o gestor como alguém que abrange a totalidade do projecto e que, pelo facto de ser externo à empresa que detém o projecto, actua numa óptica de controlo e garantia da qualidade da entrega.
7. Imparcialidade das decisões
O gestor de projecto que não pertence aos quadros da organização que detém o projecto, tem normalmente uma capacidade de imparcialidade que qualquer outro elemento interno não possui. Esta imparcialidade possibilita o corte de determinados vícios existentes na empresa que o contrata e que são, por vezes, negativos para a dinâmica de uma realização orientada a projecto. Esta imparcialidade possibilita também que o gestor seja visto como um conselheiro pela direcção do projecto e da empresa.