Menu
Esqueceu a senha? Fazer cadastro

Valor Agregado usando MS-Project

Nos posts anteriores (GVA 1 e GVA 2), apresentamos o método de Gerenciamento do Valor Agregado, seus conceitos e aplicações. Trata-se de uma técnica poderosa de planejamento e controle de projetos, que está presente na maioria dos softwares de gerenciamento de projetos.

Agora vamos ver como funciona o valor agregado no MS-Project 2010. Primeiro, precisamos saber como é calculado o valor agregado. Na aba Arquivo > Opções, nas opções Avançadas, temos as opções de cálculo do valor acumulado (Fonte: Manual do MS-Project 2010 e Melhores Práticas do PMI).

ms1
Figura 1 – Opções de Valor Acumulado deste projeto

O valor acumulado pode ser calculado com base na %Concluída ou na %Física Concluída. Quando tivermos salvo mais de uma linha de base para o projeto, devemos escolher qual será a linha de base utilizada para o valor acumulado. De modo geral, vamos utilizar a última linha de base salva, que reflete o plano de projeto atualizado com eventuais mudanças aprovadas. Observe a tabela do Gantt de Controle abaixo, onde temos o progresso de algumas tarefas.


msp2

Figura 2 – Gantt de controle do projeto

Para verificar o andamento do projeto utilizando gerenciamento do valor agregado, basta mostrar a tabela Valor Acumulado! Essa você não conhecia… Vá em Exibição > Tabelas > Mais tabelas

msp3
Figura 3 – Mais tabelas

msp4Figura 4 – Mostrar tabela Valor Acumulado

Teremos então a nossa tabela do Valor Acumulado, contendo todos os campos necessários para o gerenciamento do valor agregado.

msp5Figura 5 – Tabela Valor Acumulado

Além dessa tabela do valor agregado, podemos imprimir um gráfico, relatório visual, do valor agregado. Vá em Projeto > Relatórios Visuais.

msp6
Figura 6 – Relatórios Visuais

msp7
Figura 7 – Gráfico do Valor Acumulado

Para mais referências sobre Gerenciamento do Valor Agregado (Earned Value Management), existem várias referências sobre o assunto disponíveis neste link do PMI, além do Practice Standard for Earned Value Management – Second Edition.

Na próxima semana, vamos apresentar um passo-a-passo para gerenciamento de projetos na prática. Não percam!

Gestão do Valor Agregado – Parte 2

No post anterior, vimos uma introdução do método de Gerenciamento do Valor Agregado (Earned Value Management – EVM) e agora vamos prosseguir com mais algumas informações e dicas importantes.

As variáveis VA (valor agregado), VP (valor planejado) e CR (custo real) proporcionam ao gerente e sua equipe uma visão integrada do desempenho do projeto, considerando não apenas os custos, mas também as linhas de base de escopo e de cronograma. Vamos relembrar o que são VA, VP e CR:

  • Valor Planejado: orçamento autorizado designado para o trabalho a ser executado para uma atividade ou componente da EAP. Deve incluir o trabalho autorizado em detalhes e seu respectivo orçamento, distribuídos ao longo das fases do projeto. A curva do Valor Planejado é chamado de linha de base de medição do desempenho (PMB) e o valor total planejado ao final do projeto é chamado de Orçamento no Término (ONT)
  • Valor Agregado: é o valor do trabalho terminado expresso em termos do orçamento aprovado atribuído a esse trabalho para uma atividade ou componente da EAP. É, portanto, o trabalho autorizado que foi efetivamente realizado / terminado e seu correspondente valor de orçamento. O VA é freqüentemente utilizado para medir o progresso do trabalho (andamento) do projeto e deve ser comparado com o VP. As medições do VA podem ser incrementais ou cumulativas para analisar o progresso e / ou tendências
  • Custo Real: é o custo total incorrido e registrado na execução do trabalho para uma atividade ou componente da EAP. É o custo total real (CR) incorrido para o trabalho realizado, que é medido em VA.

Alguns autores como Lewis (1995), Fleming & Koppelman (2000) e Kerzner (2001) descrevem o GVA como uma das mais eficazes ferramentas de planejamento, monitoramento e controle na gestão de projetos. Todavia, como chamamos a atenção no primeiro post, a utilização do GVA exige alguns cuidados:

1) Criar o Plano de Gerenciamento do Projeto;

2) Definir o Escopo do Projeto detalhadamente;

3) Definir o Controle Integrado de Mudanças formalmente;

4) Definir Cronograma realista e detalhado; e,

5) Definir Orçamento realista e detalhado.

Se o escopo for mal definido, a utilização do GVA fica prejudicada. Desta forma, não se recomenda utilizar GVA em projetos sujeitos a grande indefinição e incertezas, como projetos de PD&I em suas fases iniciais. Também não é recomendada a utilização de GVA em conjunto com abordagens ágeis, por motivos óbvios.

Um aspecto de grande importância é a necessidade do controle integrado de mudanças como um processo formal. O GVA integra as linhas de base de escopo, tempo e custo, sendo necessário a mensuração dos valores de VA, VP e CR, bem como o cálculo dos indicadores e suas análises. Para que o monitoramento e controle seja efetivo, as mudanças, variações e suas causas precisam ser analisadas de maneira integrada e holística com relação ao projeto.

Compromissos entre escopo-tempo-custo precisam ser balanceados. Por exemplo, suponha que o projeto está atrasado (VA menor que VP) ao mesmo tempo em que estamos economizando (CR menor que VA), o que fazer? Trata-se de uma situação ruim? Seria possível trazer o projeto de volta para a linha de base de cronograma com um aumento nos gastos (CR)? Vale a pena?

Observa-se que os indicadores (IDP, IDP e outros) precisam ser analisados em conjunto, não isoladamente. Além disso, o controle integrado de mudanças visa garantir que as mudanças de escopo do projeto sejam corretamente avaliadas, assim como seu impacto nas outras áreas. Isto é, a inclusão (ou exclusão) de pacotes de trabalho altera a linha de base do escopo, alterando, consequentemente, as relações entre VA, VP e CR.

Outro ponto a se destacar é o método de medição adotado. Podemos adotar um dos métodos a seguir.

  • Para tarefas não recorrentes (marcos / milestones são estabelecidos em função do esforço ou valor);
    • Utilizar fórmulas fixas para medição (0% – 100%, 50 / 50%); e,
    • Utilizar estimativas do percentual de conclusão das entregas.
  • Para tarefas recorrentes
    • Nível de esforço (função linear, por exemplo)

É possível utilizar outros métodos e também combinar métodos. Para uma explicação mais aprofundada, consulte o artigo de Pierre Bonnal e Christian Braesch no primeiro volume do Journal of Modern Project Management. O meu objetivo é apenas chamar a atenção para o fato de que a maneira como você mede os valores de VA, VP e CR influencia os seus cálculos e, consequentemente, afeta a utilização do GVA. Portanto, é essencial analisar as causas de variação sempre. Podemos estar bastante acima do orçamento no momento atual porque adiantamos a aquisição de um determinado equipamento (CR maior que VA), porém isso vai refletir em economias no futuro do projeto, retornando à linha de base de custos (VA igual ou maior que CR)…

Agora vamos tratar novamente das fórmulas para estimar o orçamento e o cronograma no término do projeto, utilizando os indicadores do GVA.

  • Variações que serão monitoradas:
    • Variação de Prazos: VPR = VA – VP (associar ao método do caminho crítico)
    • Variação de Custos: VC =VA – CR
  • Índices de Desempenho:
    • Índice de Desempenho de PRAZO:

IDP = SPI = VA/VP

  • Índice de Desempenho de CUSTO:

IDC = CPI = VA/CR

A figura abaixo representa um gráfico de valor agregado.

evm1
Figura 1 – Valor Agregado (Trentim, 2011)

Temos a curva de orçamento dada pelo Valor Planejado (VP). A curva do Valor Agregado (VA) representa o trabalho efetivamente realizado, indicando que o progresso do projeto está sendo melhor que o planejado (VA > VP). A curva de Custos Reais (CR) representa os custos reais incorridos até o momento e indica que estamos gastando menos do que o planejado (CR < VP).

O ponto final da curva do Valor Planejado é o Orçamento no Término (ONT), que deve ser revisado e atualizado ao longo do projeto conforme as técnicas e ferramentas de medição que veremos a seguir.

Conforme o projeto progride, a equipe pode elaborar previsões para a estimativa no término (ENT), tipicamente baseadas nos custos reais incorridos para o trabalho executado mais uma estimativa para terminar (EPT).

  • ENT bottom-up: o pessoal que está executando o trabalho é responsável por fornecer a EPT do trabalho restante
    • ENT = CR + EPT
  • ENT em ritmo de trabalho orçado (planejado)
    • ENT = CR + ONT – VA
  • ENT para trabalho executado ao ritmo IDC
    • ENT = ONT / IDC
  • ENT considerando ritmos de IDP e IDC
    • ENT = CR + (ONT – VA)/(IDC*IDP)

Também é possível calcular o Índice de Desempenho para o Término (IDPT). Trata-se da projeção calculada do desempenho de custos que deve ser atingido no trabalho restante para alcançar os objetivos estabelecidos nas linhas de base de escopo, tempo e custo. Isto é, IDPT é a performance que o projeto deve desempenhar no restante do trabalho para que possamos terminar no prazo e orçamento previstos inicialmente.

  • IDPT = (ONT – VA)/(ONT – CR)

IDPT mostra o índice de quanto de trabalho vem sendo executado divido pelo quanto de recursos ainda resta. Se ONT não for mais viável, pode-se utilizar ENT, calculado de acordo com alguma das fórmulas sugeridas anteriormente.

  • IDPT = (ONT – VA)/(ENT – CR)

evm2Figura 2 – Determinação do IDPT (Trentim, 2011)

Deixe seu feedback, dúvidas, críticas e sugestões nos comentário ou envie um e-mail para trentim@mundopm.com.br

Na próxima semana, veremos como utilizar a Gestão do Valor Agregado, GVA, no MS-Project 2010. Não percam!

Gestão do Valor Agregado – Parte 1

Para aqueles que já leram o Guia PMBOK (Os 47 Processos do Guia PMBOK 5a Edição), Gestão do Valor Agregado (EVM – Earned Value Management) aparece entre as ferramentas e técnicas do grupo de processos Monitoramento e Controle, área do conhecimento de Gerenciamento de Custos, processo Controlar Custos. A maioria dos livros de gerenciamento de projetos também trata de GVA. Embora o conceito seja simples, como veremos a seguir, trata-se de um método bastante mal utilizado.

O método de Gestão do Valor Agregado foi desenvolvido na década de 1960 pelo Departamento de Defesa dos Estados Unidos a partir de um modelo de controle de projetos chamado Cost / Schedule Control System Criteria – C/SCSC (Fleming e Koppelman, 2000 – download do paper aqui).

A idéia do GVA é simples:

  1. Antes de iniciar o projeto, estabeleça as linhas de base de escopo, tempo e custo;
  2. Determine qual será o ritmo de execução em termos de entregas, tarefas e gastos;
  3. Integre as linhas de base; e,
  4. Acompanhe a execução do projeto usando indicadores do GVA.

Portanto, GVA nada mais é do que uma abordagem estruturada para o controle dos projetos com base na integração entre escopo, cronograma e orçamento para a medição do desempenho. Porém, nunca é demais ressaltar que o estabelecimento de uma boa referência de medição de desempenho (Performance Measurement Baseline – PMB) é essencial para o sucesso na utilização do GVA. No post seguinte, discutiremos algumas limitações do GVA.  Enquanto isso, vale a pena ler (novamente) o post Relatórios de Progresso para Melhorar o Desempenho.

Agora vamos ao funcionamento do GVA. A primeira coisa é definir as linhas de base de escopo (Declaração do Escopo, Estrutura Analítica do Projeto e EAP), tempo (Cronograma) e custo (Orçamento). Estando completo o plano de gerenciamento do projeto, temos os seguintes parâmetros definidos:

  • Valor planejado – VP (PV – Planned Value) – Custo planejado do projeto, linha de base de custo do projeto;
  • Valor Agregado – VA (EV – Earned Value) – Custo planejado para o trabalho executado até a data de medição; e
  • Custo Real – CR (AC – Actual Cost) – Custo total do trabalho até o momento.

Por exemplo, suponha que o trabalho do projeto consiste em construir quatro muros idênticos para cercar um terreno. Cada muro tem 100m de comprimento e 2m de altura, devendo ser construído em 1 semana ao custo de R$1.000,00 (por muro). Temos então um orçamento total de R$4.000,00 (custo), duração de 4 semanas (tempo) e 4 entregas de muros iguais (escopo).

Ao final da segunda semana, observamos que foram construídos 2,5 muros e o custo real dos materiais foi de R$3.000,00 devido a um aumento no custo da mão-de-obra. Quais os valores de VP, VA e CR?

  • VP = R$2.000,00 (ao final da 2a semana, conforme planejado, deveríamos ter 2 muros construídos);
  • VA = R$2.5000,00 (foram construídos 2,5 muros, sendo R$1.000,00 o valor agregado por muro, conforme a linha de base); e,
  • CR = R$3.000,00 (efetivamente tivemos custos de R$3.000,00).

Qual a situação do projeto acima? Está indo bem? Atrasado ou adiantado? Gastando mais ou menos? Vai dar para terminar?

Para responder às perguntas acima, vamos aos indicadores e variações para Gestão do Valor Agregado:

  • Variação de Prazo – VPR – Diferença entre o valor agregado (VA) e o valor planejado (VP);

VPR = VA – VP

  • Variação de Custo – VC – Diferença entre o valor agregado (VA) e o custo real (CR).

VC = VA – CR

  • IDP (Índice de Desempenho de Prazo) – Trata-se do valor agregado (VA) dividido pelo valor planejado (VP)

IDP = VA/ VP

  • IDC (Índice de Desempenho de Custo) – Trata-se do valor agregado do projeto (VA) divido pelo custo real (CR)

IDC = VA/ CR

Mas o que esses indicadores e variações querem dizer? Vamos voltar ao nosso exemplo inicial, onde teríamos:

  • VPR = 2.500,00 – 2.000,00 = R$500,00
  • VC = 3.000,00 – 2.000,00 = -R$1.000,00
  • IDP = 2.500,00 / 2.000,00 = 1,25
  • IDC = 2.500,00 / 3.000,00 = 0,833

Observamos que o projeto está adiantado em termos de entregas e cronograma. Na verdade, o IDP nos diz que estamos 25% adiantados. Por outro lado, os custos reais estão maiores do que o planejado, como podemos verificar pelo IDC. Esses indicadores devem ser analisados da seguinte forma:

  • IDC > 1 : valor agregado é maior do que o custo real gasto, indicando economia; isto é, estamos abaixo do orçamento planejado.
  • IDC = 1 : valor agregado é exatamente igual ao custo real; isto é, estamos exatamente em cima do orçamento planejado.
  • IDC < 1: valor agregado é menor do que o custo real gasto, indicando gastos acima do orçamento planejado.
  • IDP > 1 : valor agregado é maior do que o valor planejado; isto é, executamos mais do que o previsto e estamos adiantados em relação ao cronograma.
  • IDP = 1 : valor agregado é exatamente igual ao valor planejado; isto é, estamos exatamente em cima do cronograma planejado.
  • IDP < 1: valor agregado é menor do que o valor planejado; isto é, executamos menos do que o previsto e estamos atrasados em relação ao cronograma.

grafico

Figura 1 – Exemplo de GVA

Na Figura 1, temos o exemplo de um gráfico do valor agregado de um projeto. A curva preta (VP) representa o ritmo planejado do projeto, consolidando a linha de base de performance (escopo – tempo – custo). A linha vermelha representa os custos reais, isto é, quanto estamos gastando ao longo do tempo no dia-a-dia do projeto. Finalmente, a curva azul representa o valor agregado, isto é, o valor planejado para o trabalho que executamos ou as entregas que executamos no projeto até a data de medição. VC e VPR estão representados também na figura.

Nesta Figura 1, em particular, não fizemos extrapolação e previsões para o término do projeto. Mas existem várias formas de estimar o orçamento no término a data final ou prazo. De uma maneira simplificada, acreditando que o ritmo de execução atual irá se manter, podemos aplicar os índices IDP e IDC. Vamos retomar nosso exemplo inicial:

  • ONT (orçamento no término) = R$4.000,00 (4 muros)
  • DUR (duração total) = 4 semanas
  • IDC = 0,833
  • IDP = 1,25

A estimativa no término (ENT) do projeto seria igual ONT / IDC = 4.000,00 / 0,833. Portanto, a previsão é que o projeto termine cusstando R$4.802,00. E a nova duração total será igual a DUR / IDC = 4 semanas / 1,25. Portanto, a estimativa é que o projeto termine em 3,2 semanas. Obviamente, estamos simplificando bastante as coisas. Outras análises precisariam considerar se o projeto realmente vai continuar no ritmo atual (IDC, IDP). É preciso buscar as causas de variação.

 

Na próxima semana, vamos voltar às previsões e estimativas no término, além de falar um pouco do GVA em softwares de gerenciamento de projetos. Até lá!

Project Management Global Survey MIT & USP

Carta Convite

Project Management Global Survey

 

Caro Profissional,

Convidamos você a participar do PM Agility Global Survey. Trata-se de um estudo em nível global que integra pesquisadores do MIT (Massachusetts Institute of Technology, U.S.A.) e da USP (Universidade de São Paulo), da Escola de Engenharia de São Carlos, Brasil, sob à coordenação de Edivandro Conforto, PhD, pesquisador afiliado do Sociotechnical Systems Research Center (SSRC) no Engineering Systems Division, do MIT.

O estudo tem por objetivo identificar um conjunto de práticas gerenciais, fatores organizacionais e variáveis relacionadas com o conceito de “agilidade”, visando o melhor entendimento a respeito dos efeitos desses conceitos nos resultados e desempenho do projeto e do produto. Os resultados serão utilizados para o desenvolvimento da “teoria da Agilidade” bem como o desenvolvimento de modelos de gestão e ferramentas, que serão úteis no processo de diagnóstico, avaliação e implementação de práticas gerenciais adequadas para diferentes contextos organizacionais.

São elegíveis para participar do estudo, Gerentes de Projeto, profissionais certificados (PMPÒ) Scrum Masters, Gerentes de Programas, Gerentes de Portfólio e Membros e Times de projeto que tenham experiência e vivência nas práticas adotadas durante a execução de um projeto. A unidade de análise é um projeto já concluído ou em fase final de execução. Cada profissional pode responder por um projeto. É possível preencher mais de um questionário por organização. Para isso, basta compartilhar o link que dá acesso ao questionário online. Não há limite máximo para cada organização. Cada organização pode preencher quantos questionários desejar para os projetos já concluídos nos últimos 2 ou 3 anos.

O tempo necessário para responder de forma adequada o questionário é de aproximadamente 30 minutos. Por se tratar de uma pesquisa em nível global, é necessário que o respondente tenha conhecimento do idioma inglês para ser capaz de responder apropriadamente todas as questões da pesquisa.

Ao preencher corretamente o questionário você terá a opção de receber um relatório executivo contendo os resultados consolidados e implicações gerenciais para a melhoria do processo de gerenciamento de projetos na sua organização. O relatório será enviado em um período de 30 dias após a conclusão da coleta de dados, que está prevista para 31 de Dezembro de 2013. Todas as respostas serão codificadas e analisadas de forma agrupada, garantindo o sigilo dos dados, e confidencialidade das informações fornecidas.

Clique no link abaixo para acessar o site da pesquisa, que contém informações adicionais e o passo a passo para participar deste estudo.

http://conforto.scripts.mit.edu/pmagilitysurvey/

 

Desde já, agradecemos sua contribuição e colaboração neste estudo.

 

Cordialmente,

Edivandro Carlos Conforto, PhD

Executive Coordinator

conforto@mit.edu

8º Congresso de Gerenciamento de Projetos | PMI-MG

 

Vem aí: 8º Congresso de Gerenciamento de Projetos | PMI-MG

Este ano, o PMI-MG promove a 8ª Edição do Congresso que terá como tema a “Regência de Projetos”, fazendo a analogia entre o maestro e o gerente de projeto.

O evento será realizado nos dias 16 e 17 de setembro de 2013, em Belo Horizonte, no Hotel Ouro Minas.

 image001PMIMG

Foto PMI-MG: Congresso de Projetos realizado em 2012.

No Congresso, serão apresentados técnicas e conceitos para o desenvolvimento das habilidades de gerir equipes com conhecimentos diversificados, buscando sinergia e conformidade em suas ações e visando atingir os objetivos dos projetos.

Os dois dias do evento serão formados por uma série de atividades, com apresentação de palestrantes de alto nível. O evento também promoverá a troca de experiências e a ampliação de network.

Para o ano de 2013, dentre os grandes nomes nacionais e internacionais já confirmados, destacamos Angela Hirata (consultora da Alpargatas, que transformou as sandálias Havaianas num produto mundial), John Croft (co-criador do método “Dragon Dreaming”, para implementação de projetos criativos) e Diomar Silveira (presidente do Instituto Cultural Filarmônica de Minas Gerais).

Então corra! As inscrições para o congresso já estão abertas. Para se inscrever, visite o hotsite: http://8cgp.pmimg.org.br

A equipe de voluntários que está envolvida neste projeto, conta com o trabalho de 40 profissionais divididos em equipes como programação, comunicação, logística, inscrições, aquisições e patrocinadores. A liderança da equipe ficou a cargo do José Roberto Bolognani, que vem atuando junto a Diretoria de Eventos Técnicos desde 2011.

image002PMIMG

 

 

 

Patrocínio

image003

Conversa Fiada – Qual o ROI de um pedaço de pizza?

Preparei um post sobre Gestão do Valor Agregado para esta semana, como prometido. Entretanto, vou publicá-lo na próxima. Pedindo licença aos amigos leitores, eu queria tratar de um assunto extremamente importante em gerenciamento de projetos: pessoas.

Em vários posts já conversamos sobre soft skills versus hard skills. Eu, particularmente, sou um defensor das hard skills. Sem conhecimento técnico e competência, não tem habilidade pessoal, de liderança ou de comunicação que possa salvar um projeto. Todavia, as soft skills tem enorme impacto nos resultados dos projetos porque são as pessoas que executam tarefas e geram resultados.

Por mais que possamos investir em ferramentas, softwares e processos, a cultura e a estrutura organizacionais, e da equipe em particular, são fatores críticos para o sucesso dos projetos. As ferramentas não aprendem, não pensam e não tem vontade. As pessoas sim.

O que me motivou a escrever este post foram duas postagens no Blog do Dr Harld Kerzner. No primeiro post (My Most Important Project Management Best Practice), Kerzner compartilha uma “melhor prática” que ele tem utilizado na sua vida para evitar convites de jantar ou almoço. A melhor prática, segundo ele é:

Quando as pessoas me convidam para jantar, eu lhes pergunto: Por que você quer me levar para jantar? Isso os pega de surpresa e muitas pessoas se recusam a responder, tentando mudar o rumo da conversa.

  • Se eles têm uma razão válida, eu vou jantar com eles.
  • Se eles me dizem que é uma razão pessoal, então (…) digo a eles que podem se juntar a mim no café da manhã em meu hotel, entre as 06h30 – 07h00 para discutir o que quiserem. Eu faço com que eles entendam que às 7:00 eu estou indo para a minha palestra.

 

No segundo post (The Secret to Grabbing That Desired ROI: Dinner Team Meetings), Dr Kerzner defende que existem duas coisas que motivam a equipe do projeto: comida e dinheiro (veja também What’s The Return on Investment of a Slice of Pizza to a Project Manager?).

2200

Fonte (www.grantland.net)
Dr Kerzner defende a importância de conhecer os membros da equipe do projeto e se socializar com eles, levantando as seguintes questões:

  • Você encontra com os membros de sua equipe fora do trabalho?
  • Você conhece os interesses pessoais deles?
  • Você já conheceu os familiares (cônjuges, filhos) dos membros de sua equipe?

Nós preferimos reuniões demoradas e formais, seguindo procedimentos e mantendo uma distância fria entre as pessoas…

661.strip

Fonte: Dilbert.com

Na verdade, o que Dr Kerzner está sugerindo é que devemos todos colcoar em prática a Teoria Z (Theory Z – R Daft, 2004), que defende que a lealdade e o comprometimento das pessoas aumenta quando a organização, por meio de seus gerentes, demonstra interesse e apoio em suas vidas pessoais e profissionais, aumentando a satisfação e a produtividade. Parece algo mais ou menos óbvio, certo? Então por que não fazemos?

Não fazemos exatamente por causa daquilo que o Dr Kerzner escreveu no primeiro post, sobre aceitar ou recusar convites de jantar. O nosso tempo é considerado tão valioso que não temos tempo para os outros, algo que fica patente hoje em dia com a profusão de gadgets (More connected and yet more alone). Não temos mais tempo para “conversa fiada” porque queremos ser efetivos e eficientes, objetivos. Porém, estamos ficando cada vez mais em desvantagem por perder e não valorizar essas conexões pessoais.

Reuniões da equipe de projeto envolvendo suas famílias podem ter valor inestimável, por várias razões (segundo Kerzner):

  • Se você é como a maioria das pessoas, você discute o seu trabalho em casa com sua família, mas sua família nunca conheceu as pessoas que lhes dizem respeito.
  • Seu cônjuge pode não ter qualquer entendimento sobre gestão de projetos e ter uma discussão com outros cônjuges pode ser útil.
  • Os cônjuges terão um melhor entendimento sobre a pressão eo stress que os membros da equipe devem suportar.
  • Sua família vai ser mais capaz de ajudá-lo a gerenciar o estresse e pode obter dicas de outros cônjuges em como ajudar seu esposo a gerir o stress e pressão.

 

Espero ter chamado a atenção para esse distanciamento que temos observado. Não é fácil combatê-lo. Exige disciplina. Talvez seja hora de colocar “conversa fiada” em nossas To-Do lists (eu já coloquei). É um tempo para relaxar, ouvir e se conectar com outras pessoas sem preocupações e sem outros interesses (segundas intenções).

Na próxima semana, voltaremos com Gestão do Valor Agregado. Até lá!

A integração entre o Gerenciamento do Programa e a Engenharia

 

Neste post, apresento um resumo dos resultados de uma pesquisa em nível global conduzida com mais de 600 profissionais cujo objetivo primário foi investigar a integração entre duas áreas, representadas pelo Gerente de Programas e o Engenheiro de Sistemas, ou Engenheiro Chefe, conhecido como “Systems Engineer” ou “Chief Systems Engineer – CSE”.

O estudo é um esforço em conjunto, uma aliança de pesquisa formada pelo Project Management Institute (PMI) e o International Council on Systems Engineering (INCOSE) e conta com o apoio estratégico e científico do MIT (Massachusetts Institute of Technology) do grupo CEPE (Consortium for Engineering Program Excellence). O trabalho busca identificar oportunidades para o desenvolvimento de soluções com foco na redução de conflitos entre as disciplinas (ou áreas) na execução de um programa.

Em Outubro de 2012, o PMI juntamente com o INCOSE conduziu um levantamento (survey) entre os membros de suas comunidades. Este levantamento teve como resultado mais de 600 respondentes. O grupo de pesquisa CEPE/MIT conduziu as análises e exploração dos dados para identificar evidências relevantes para o tópico. O relatório na íntegra pode ser acessado gratuitamente por meio deste link “Survey Report: Improving Integration of Program Management and Systems Engineering”.

Antes de apresentar os resultados, quero definir alguns termos utilizados neste trabalho. O termo “integração” citado neste texto trata da união, trabalho conjunto entre duas partes, voltado para um objetivo comum. A definição encontrada no dicionário de Cambridge para o termo “integrate” é “to combine two or more things into one”. Outro termo utilizado é “unproductive tension” que pode ser traduzido como “conflito”, um evento de qualquer natureza que pode significar um problema e que pode ter impacto negativo no desempenho e resultados de um programa.

De forma bem simplificada podemos assumir que o gestor do programa é o responsável pelo custo, cronograma, e entrega dos resultados no prazo. O Engenheiro Chefe seria o responsável por todos os aspectos técnicos do produto, requisitos, especificações, etc. Um conflito bem comum é quando o prazo de uma entrega se aproxima e o responsável pela parte técnica indica que haverá um atraso, ou necessidade de reprogramação da entrega devido à falta de informações para completar um requisito e finalizar a entrega, ou algum desafio tecnológico não previsto no cronograma, que poderá impactar nas especificações técnicas ou qualidade do resultado final do programa.

Neste cenário há a necessidade de um “acordo”. Será necessário um ajuste no cronograma e talvez no custo para atender as especificações técnicas exigidas na entrega de um sistema ou subsistema. A forma como será tratado este evento poderá gerar ou não um conflito e ter um impacto negativo para o programa como um todo, ao invés de encontrar rapidamente uma solução para o problema. Tais eventos podem ocorrer nos diferentes níveis de execução de um programa, desde o nível operacional até o nível estratégico, e a extensão do impacto nos resultados do programa podem ser imensuráveis.

Dito isso, o objetivo do levantamento realizado em conjunto pelo PMI, INCOSE e MIT é identificar como reduzir tais conflitos que geram resultados negativos para o programa. Além disso, os resultados deste levantamento também servirão como fonte para a definição de políticas de trabalho conjunto e oportunidades para a definição de mecanismos e formas de colaboração entre as duas entidades, PMI e INCOSE, e assim prover soluções e conhecimento para ambas as comunidades de profissionais.

Do total de respondentes, 30% disseram que possuem alguma forma moderada ou significante de conflito entre as áreas. Outros 20% indicaram não possuir nenhuma forma de conflito que gere resultados negativos para o programa. Ainda de acordo com os entrevistados, algumas das possíveis fontes de conflito podem ser:

  • Ausência de planejamento integrado considerando as duas disciplinas.
  • Autoridade, papéis mal definidos.
  • Práticas conflitantes entre o gestor do programa e o chefe da engenharia.
  • Responsabilidades e atribuições não definidas claramente.
  • Expectativas pouco objetivas/definidas por parte do patrocinador do projeto.

O gráfico a seguir (Fig.1) ilustra as porcentagens das potenciais fontes de conflito, segundo os respondentes da survey. O “n” neste caso é diferente do total de respondentes da amostra pois os dados foram agrupados considerando apenas os respondentes que disseram ter alguma forma de conflito.

Fig. 1. Potenciais fontes de conflito entre as áreas

Fig. 1. Potenciais fontes de conflito entre as áreas. Fonte: Conforto et al. (2013).

Após ilustrar algumas possíveis fontes de conflito, salvo que esta lista não é definitiva, uma vez que as fontes podem variar bastante de um contexto de negócio para outro ou de acordo com o tipo do programa, a pergunta que emerge é a seguinte: o que fazer para evitar ou tentar reduzir os conflitos entre essas duas áreas, profissionais?

A figura a seguir (Fig.2) ilustra um conjunto de ações que de acordo com a análise dos dados da survey podem contribuir para a redução dos problemas que dificultam a integração entre as partes  durante a execução de um programa.

Fig. 2. Elementos críticos para a integração entre as áreas e redução de conflitos. Fonte: Conforto et al. (2013).

Fig. 2. Elementos críticos para a integração entre as áreas e redução de conflitos. Fonte: Conforto et al. (2013).

Uso de padrões (Standards) de ambas disciplinas

Os resultados indicam a existência de organizações que desenvolvem seus próprios Standards, baseados em padrões comerciais; outras adotam os padrões sem realizar alterações ou adaptações. Existem também empresas que não adotam nenhum tipo específico de Standard, seja para a gestão do programa ou voltado para sistemas de engenharia (conforme Fig.3). Em resumo, os Standards amplamente conhecidos, do PMI e INCOSE, demonstraram ser utilizados em diferentes contextos da indústria, independente do porte ou setor.

Fig. 3. Tipos de standards utilizados por área. Fonte: Conforto et al. (2013).

Fig. 3. Tipos de standards utilizados por área. Fonte: Conforto et al. (2013).

As evidências coletadas no estudo indicam que as empresas que não possuem conflitos adotam um ou mais Standards por área de conhecimento. Por exemplo, utilizar Standards sobre gerenciamento de programas ou gerenciamento de projetos combinados com Standards específicos da área de engenharia. Outra evidência é que o uso de ao menos um tipo de Standard está positivamente relacionado com a efetividade da integração entre as duas disciplinas/áreas, conforme ilustrado na Fig. 4.

Fig. 4. Uso de standards e a relação com a integração entre as áreas. Fonte: Conforto et al. (2013).

Fig. 4. Uso de standards e a relação com a integração entre as áreas. Fonte: Conforto et al. (2013).

Definição formal e clara de “integração”, dos papéis e responsabilidades

As organizações que conseguem definir formalmente a integração entre as disciplinas, as responsabilidades e funções de cada um dos envolvidos com a gestão do programa e as áreas técnicas (como engenharia), em geral, possuem melhor integração e tendem a ter menor quantidade de conflitos e problemas entre as duas áreas. Sem surpresa, empresas de maior porte conseguem maiores níveis de formalidade na definição de papéis e responsabilidades, muito devido à necessidade provocada pelo tamanho da organização e complexidade dos programas. Os resultados do estudo indicam que para a integração ser eficiente a formalização é considerada um fator crítico.

Definir claramente os papéis de cada profissional envolvido com a parte técnica e gerencial do programa é essencial para a integração. E assim, evita-se ou reduz-se os pontos de conflito. Uma dica é realizar um mapeamento dos possíveis pontos de conflito, definir as interfaces entre os profissionais, áreas e as responsabilidades que serão compartilhadas. Empresas que apresentam uma integração formalizada entre as áreas (parte técnica e parte gerencial) apresentam menores índices de problemas ou conflitos que geram resultados negativos para os programas.

Desenvolver avaliações e verificações específicas com foco na integração das áreas

Desenvolver avaliações de desempenho que sejam úteis para identificar problemas/melhorias na integração. As empresas que relataram possuir uma integração eficiente entre as áreas também demonstraram realizar avaliações e verificações regulares, com o objetivo de aprimorar a integração e reduzir as fontes de conflitos. Em alguns casos, as constantes avaliações contribuem para reduzir sistematicamente os conflitos e possíveis problemas decorrentes da integração das áreas.

Das empresas que alegaram utilizar algum tipo de avaliação, o gráfico a seguir ilustra os tipos mais comuns.

Fig. 5. Tipos de avaliação com foco na melhoria da integração entre as áreas. Fonte: Conforto et al. (2013).

Fig. 5. Tipos de avaliação com foco na melhoria da integração entre as áreas. Fonte: Conforto et al. (2013).

Compartilhar responsabilidades nos aspectos críticos para a integração

Para que a integração ocorra de forma efetiva e os conflitos ou problemas entre as áreas sejam reduzidos ou evitados é importante compartilhar responsabilidades sobre aspectos críticos do programa. Quando existem os dois papéis no programa, um Gerente de Programa e um Engenheiro Chefe, algumas das áreas que requerem colaboração na divisão das responsabilidades são: relacionamento com fornecedores externos; gerenciamento dos riscos (tecnológicos e gerenciais); gestão do ciclo de vida do produto e gestão da qualidade, dentre outras. As áreas que requerem compartilhamento de responsabilidades podem variar de acordo com a empresa, tipo do programa, mercado, etc.

Empresas que apresentam altos índices de integração entre as disciplinas apresentam melhor eficiência na colaboração entre a Engenharia e a Gestão do Programa. A melhor integração e eficiência na colaboração pode contribuir para a redução da quantidade de conflitos e outros problemas decorrentes do trabalho conjunto entre os profissionais de diferentes áreas de uma organização. A figura a seguir (Fig.6) ilustra a distribuição das responsabilidades de acordo com os respondentes da pesquisa.

Fig. 6. Responsabilidades compartilhadas entre as áreas. Fonte: Conforto et al. (2013).

Fig. 6. Responsabilidades compartilhadas entre as áreas. Fonte: Conforto et al. (2013).

Para concluir, as empresas com menores níveis de conflitos ou problemas entre as áreas apresentaram maiores níveis de integração. Ou seja, quanto menor a integração, formalização, clareza nas responsabilidades dos envolvidos, maior será a probabilidade de ocorrer conflitos. O uso de Standards, a definição dos papéis e o compartilhamento das responsabilidades, também contribuem para a redução dos conflitos.

Por fim, recomendo a leitura do relatório que está disponível neste link.

Informações adicionais: esta pesquisa está em sua segunda fase. Nesta fase estamos entrevistando profissionais de organizações que foram consideradas “best in class”, ou seja, que apresentaram poucos conflitos ou não reconhecem a existência de conflitos entre as duas áreas. O objetivo é refinar os resultados obtidos na survey e melhor compreender as práticas adotadas, o comportamento, e aspectos que contribuem para a melhor integração e redução de conflitos e problemas entre as áreas.

Os resultados consolidados desta segunda fase, juntamente com os resultados da survey, serão apresentados no PMI Global Congress 2013, North America, 27-29 October, New Orleans, U.S.A. Após esta apresentação farei um outro post para contar um pouco mais sobre os resultados finais deste projeto.

Forte Abraço, boa leitura! Edivandro Conforto.

Referência:

Conforto et al. (2013). Improving the Integration of Program Management and Systems Engineering. Whitepaper presented at the 23rd INCOSE Annual International Symposium, Philadelphia, USA, June 2013.