PMI anda se confundindo com as versões do PMBOK no exame PMP?

Para quem estava preocupado com a mudança da versão do PMBOK e conseqüente mudança no exame PMP, o texto abaixo, enviado em um e-mail para o PMHub (um dos mais importantes fóruns de discussão sobre o exame no mundo) joga ainda mais lenha na fogueira. Vejam:

“One thing I found extremely frustrating was that the exam used 3rd edition and 4th edition PMBOK terminologies interchangeably. I’m not sure if this was a mistake, since they had just recently converted to 4th edition, or if it was intentional (since the changes are listed in the appendix and are therefore fair game). Either way, this inconsistency made me livid during the exam, and if you’ve studied ONLY 4th edition, you’re certainly going to get things mixed up. For example, one of the questions mentioned a ‘Select Sellers’ process, which does not exist in 4th edition; it’s now part of Conduct Procurements.”

Processos que só existem na terceira edição aparecendo no exame novo? Será?

O poder da confiança

“Há algo que é comum a qualquer indivíduo, relacionamento, equipe, família, organização, nação, economia e civilização no mundo todo – algo que, se faltar, destruirá o governo mais poderoso, o negócio mais bem-sucedido, a economia mais próspera, a liderança mais influente, a maior amizade, o caráter mais forte, o amor mais profundo. Por outro lado, se desenvolvido e estimulado, tem o potencial de criar sucesso e prosperidades sem precedentes em todas as dimensões da vida. No entanto, é a coisa menos entendida, mais negligenciada e mais subestimada em nossos tempos. É a confiança.

De forma simples, confiança significa ter certeza de que a pessoa não esconde nada e é sincera. O oposto da confiança – a desconfiança – é a suspeita sobre sua sinceridade. Quando você confia nas pessoas, você confia em sua integridade e em suas competências. Quando desconfia das pessoas você desconfia de suas intenções e atitudes e de sua integridade, sua agenda, suas competências ou seus antecedentes.

A confiança sempre produz dois resultados – a velocidade e o custo.  Quando a confiança decresce, a velocidade também decresce e os custos aumentam.”

Acima temos um pequeno trecho do resumo do livro “O poder da confiança”, de Stephen Covey.  Alguns poderiam imaginar porque iniciei este post com um texto desta natureza. Mas é fácil explicar. Confiança é a base do relacionamento entre seres humanos, e como tal, tem tudo a ver com gerenciamento de projetos.  Vejam a última frase do texto.  “Quando a confiança decresce, a velocidade também decresce e os custos aumentam.” Vemos isto a todo momento. Situações em que cliente e fornecedor estão trabalhando pela primeira vez juntos  são marcadas por um formalismo excessivo das decisões do projeto, já que não se sabe a priori se o outro lado honrará acordos realizados apenas verbalmente. O mesmo ocorre quando cliente e fornecedor já trabalharam juntos, mas tiveram vários impasses gerados por um certo “disse me disse” em que um lado imaginava ter acordado uma coisa e o outro lado outra coisa diferente. A formalização nesses casos acaba sendo fundamental, mas como disse Covey, torna os processos mais lentos e caros.

Por outro lado, tem havido nos últimos anos um grande movimento na industria de software no sentido de se ter processos mais leves, mais rápidos e menos caros. Com o rótulo de “métodos ágeis”, essa nova abordagem prega a minimização de documentos e formalismos e uma maior interação entre indivíduos. Esta interação tem como objetivo fundamental aumentar o compromisso das diversas partes com as decisões tomadas nos projetos, aumentando por conseqüência a confiança entre elas.  Diminuição de custos e aumento na velocidade? Parece ótimo, não? Claro! O problema é que nem sempre é possível. Qualquer tipo de burocracia é sempre indesejável, mas acaba sendo necessária em ambientes em que o nível de confiança é baixo. Um mal necessário, infelizmente.  Que poder é esse, hein!?

Certificação PMP: faço o exame na versão nova ou velha do PMBOK?

Na virada do ano o PMI publicou a nova versão dos seus principais padrões, incluindo o mais conhecido deles: o PMBOK (Project Management Body of Knowledge). A versão em Português teve apenas os 3 primeiros capítulos traduzidos, com previsão de 31/03/2009 para os demais. A reboque desta atualização já está prevista uma mudança no exame de certificação PMP. A partir do 30 junho de 2009, o exame passará a ser baseado na nova versão do PMBOK.

Esses momentos de modificação sempre confundem um pouco aqueles que estão no meio do processo de preparação para o exame. Devo continuar estudando na versão anterior do PMBOK? Devo passar a estudar pela versão mais nova e adiar a data da realização da prova? Não há uma resposta única, mas se você já está com seus estudos iniciados e disposição para encarar o desafio, meu conselho é que aumente o ritmo da preparação e faça a prova antes da mudança mesmo. É bom destacar também que as questões do exame têm se tornado cada vez mais situacionais, o que diminui bastante a dependência da versão do PMBOK utilizada. E que as mudanças ocorridas não são drásticas. Trata-se de uma evolução e não de uma revolução. Ou seja, os princípios gerais e lógica existente no gerenciamento de projetos não mudaram completamente em quatro anos. Para que você possa ter uma idéia do que estou dizendo, veja abaixo as principais diferenças entre a terceira e quarta (mais recente) edições do PMBOK:

1. Todos os nomes de processos estão na forma verbal.
2. Foram feitos esforços para que houvesse maior diferenciação entre “Fatores ambientais da empresa” e “Ativos de Processos Organizacionais”. Para quem não sabe estas são duas entradas comuns a vários processos do guia, em especial os de planejamento.
3. Foi adotada uma abordagem padrão para discutir mudanças solicitadas, ações preventivas, ações corretivas e reparos de defeito.
4. Há um total de 44 processos, ante 42 na versão anterior. Dois foram removidos, dois foram adicionados e 6 processos foram transformados em 4, na área de Aquisições.
5. Para maior clareza, foi feita uma distinção entre o Plano de Gerenciamento do Projeto e documentos de projeto usados para gerenciá-lo.
6. A distinção entre as informações presentes no Project Charter e na Declaração de Escopo ficou mais clara.
7. Os diagramas de fluxo de processo no início dos capítulos 4 a 12 foram suprimidos e substituídos por diagramas de fluxo de dados.
8. Um diagrama de fluxo de dados foi criado para cada processo a fim de mostrar de onde a informação vem como entrada e para onde vai como saída.
9. Um novo apêndice tratando de habilidades interpessoais que um gerente de projetos utiliza no decorrer de um projeto foi adicionado.

Fonte:http://www.rmcproject.com/about/pmp-examination-changes.aspx

Veja que a maioria absoluta das mudanças não tem o objetivo de modificar nada, mas apenas de melhorar o que já existe. Isto pode diminuir a ansiedade daqueles que pretendem iniciar os estudos agora para realizar a prova somente após 30 de junho. Normalmente esta ansiedade existe porque, apesar de já haver a disponibilidade da nova versão do PMBOK, outros livros de apoio ainda não foram atualizados (como os das famosas autoras Rita Mulcahy e Kim Heldman) e os que farão a prova após a mudança terão que, pelo menos por enquanto, estudar em uma versão “desatualizada”.

Para finalizar o post, um convite pessoal: se você está em Belo Horizonte e tem interesse em participar de um curso preparatório para o exame PMP (com base ainda na terceira edição do PMBOK) entre em contato comigo pelo e-mail andriele@brainss.com.br. Iniciarei o curso com um grupo fechado em fevereiro e há ainda algumas poucas vagas. 

 

Quão único é um projeto?

Um projeto, por definição, cria um produto, serviço ou resultado único, exclusivo. Mas quão único é este resultado? Já parou pra pensar a respeito?

Se nunca fez isso, aproveitemos o momento pra refletir um pouco.

Situação A: Suponha que você trabalhe em uma instituição de alta tecnologia e receba a incumbência de gerenciar um projeto de criação de um sistema imunológico artificial, que será posteriormente utilizado em chips tolerantes a falhas (antes de me chamar de louco saiba que tem gente por aí tentando produzir algo nesta linha). Inovação da pesada hein? Provavelmente ninguém nunca fez isso antes e quem teve a idéia de levar a iniciativa adiante provavelmente não sabe exatamente como chegar lá. O processo de criação de um produto desta natureza está longe de ser prescritivo. Ao contrário é provavelmente altamente empírico, o que quer dizer que algumas tentativas e erros podem e devem acontecer pelo caminho.

Situação B: Você agora é um gerente de projetos de uma empresa de infra-estrutura de TI convencional. Já implementou dezenas de redes de computadores em escritórios deste “Brasilzão” afora e acaba de ser nomeado GP para um nova inciativa do gênero. O passo a passo pra resolver a demanda do cliente é bem conhecido. Você tem documentado um processo de implementação de redes que, tirando algumas coisas que sempre variam caso a caso, funciona bastante bem de modo geral.

Situação A e Situação B podem ser tratadas como projetos, certo? No caso da Situação A creio não haver muita dúvida. Em B, é bom lembrar àqueles que ainda não estão muito seguros que “algumas coisas sempre variam caso a caso” e que “Deus está nos detalhes” – esta última frase não sei exatamente de quem é mas sempre gostei dela e acho que se encaixa bem aqui.

Dado que consegui convencê-los que ambas as demandas podem ser consideradas projetos (se alguém ainda não se convenceu comente o post logo abaixo dizendo porque ), podemos afirmar também que as duas devem ser planejadas, monitoradas e controladas. Mas será que devemos planejá-las, monitorá-las e controlá-las da mesma forma? Veja a figura abaixo. Ela nos ajuda a clarear um pouco a situação:

Veja que a demanda B pode ser classificada como projeto, mas situa-se próximo ao que costumamos chamar de “Operações Continuadas”, para classificar aquilo que é repetitivo. Já a demanda A está muito próxima do outro extremo do desenho. Denominei esta outra extremidade de “Mundo Completamente Desconhecido”, mostrando que, quando mais para direita, mais nebuloso e indefinido é o resultado que se espera do projeto. O ponto “Marco zero de projetos” é conceitual e serve apenas para mostrar que a partir de algum momento, algo deixa de ser repetível e contínuo para se tornar temporário e exclusivo.

Algumas conclusões interessantes podem ser tiradas deste desenho:

• A primeira é que a distinção entre operações continuadas e projetos não é discreta, mas contínua. Existem operações continuadas muito padronizadas (ex: produção de tijolos), operações continuada menos padronizadas (ex: manutenções de software não projetizadas), projetos com produtos finais pouco exclusivos (situação B) e projetos com produtos finais muito exclusivos (situação A);
• E a segunda, retornando à nossa dúvida que ficou em aberto é: apesar de A e B serem considerados projetos, tratam-se de duas demandas com perfis bastante diferentes. Assim a abordagem gerencial para conduzir as duas iniciativas será, naturalmente diferente.

Em B as entregas, tanto finais como intermediárias, podem ser delineadas com boa precisão. Afinal de contas isso já foi feito dezenas de outras vezes. É possível definir, seqüenciar e estimar recursos e durações com boa taxa de acerto para uma quantidade razoável de atividades, até mesmo para algumas próximas do final do ciclo de vida do projeto. Ou seja, enxergamos com clareza todo o fluxo de atividades a ser desenvolvido, do início ao fim do projeto.

Em A as coisas já são mais complicadas. Tem-se uma idéia do que se quer ao fim do projeto, mas é impossível definir-se logo no primeiro ciclo de planejamento, de forma prescritiva, a seqüência de todas atividades a serem executadas para chegar-se ao produto final. Produtos intermediários são gerados e seus resultados são analisados para se definir etapas posteriores e em alguns casos para se decidir se o projeto segue ou não adiante. É possível planejar, monitorar e controlar mas a filosofia é outra. O produto final é mais ou menos conhecido. Há objetivos traçados. Mas o caminho que é percorrido é definido ao longo do projeto. Planejado sim, mas com antecedência menor.

De forma bem pragmática, executar um projeto como o descrito em B é parecido com viajarmos para o Nordeste comprando um pacote turístico. Sabemos que vamos conhecer 5 cidades, os hotéis em que vamos nos hospedar, os passeios que vamos fazer (inclusive com os horários). Sempre tem algum imprevisto, mas de modo geral a coisa não muda muito. Executar A é mais ou menos como viajar para o Nordeste por conta própria com o hotel para o primeiro destino reservado e um objetivo de conhecer outras 4 cidades. Que outras 4? Ainda não sabemos, mas quando estivermos prestes a sair da primeira já teremos reservado o hotel para a segunda, tendo inclusive uma boa idéia de quando iremos para a terceira. Alguém poderia me dizer: o bom mesmo é pegar o carro e ir viajando sem destino certo… Parando quando der vontade, conhecendo praias nunca antes visitadas, decidindo tudo na última hora, sem plano algum. Eu diria que um comportamento assim pode até funcionar… pra sua próxima viagem para o Nordeste. Mas nunca para a criação de um sistema imunológico artificial. Entendeu a diferença?

Participe da Pesquisa de Maturidade 2008!

Este é um post diferente que vocês estão acostumados a ver por aqui. Não se trata de um artigo, como os demais, mas de um convite.

Gostaria de incentivá-los a responder a Pesquisa Archibald & Prado sobre Maturidade em Gerenciamento de Projetos. A pesquisa está baseada no modelo de categorização de Russel Archibald e no modelo de maturidade de Darci Prado – MMGP, duas grandes referências em Gerenciamento de Projetos no exterior e no Brasil.

O MMGP, lançado em 2002, permite avaliar a maturidade de um setor (ou departamento) de uma organização em uma escala de 1 a 5.

A pesquisa pode ser respondida por gerentes de departamento, coordenadores de PMO, ou profissionais que tenham, sob sua responsabilidade, uma carteira de projetos.

Além de contribuir para um melhor conhecimento da maturidade das empresas brasileiras como um todo, aqueles que responderem à pesquisa terão os seguintes benefícios:

• Conhecimento imediato do nível de maturidade do seu setor de trabalho ou departamento
• Possibilidade de comparação (benchmarking) com o resultado global brasileiro e com a categoria ou tipo de organização, após o resultado da pesquisa
• Possibilidade de montagem de um Plano de Crescimento de Maturidade para o seu setor ou departamento

Para resonder à pesquisa visite: www.maturityresearch.com. Manterei também um link direto no canto superior direito do “Falando em Projetos” até o fim da pesquiisa.

Os perigos de saber “um pouquinho”

Certa vez, há uns 5, 6 anos atrás ouvi uma frase de um sócio-diretor de uma empresa de TI que nunca mais esqueci. O sujeito, muito experiente no mundo da tecnologia e bastante seguro do que dizia, soltou num tom nervoso: “O pior tipo de gente é o que sabe um pouquinho de cada coisa”. Acho que a frase ficou gravada em minha cabeça, menos por concordar com ela (pra falar a verdade nunca parei pra refletir seriamente a respeito e tenho um certo receio em relação a generalizações deste tipo) e mais por eu ter achado muito engraçado o jeito que o cara falou.

Mas por que eu, sumido há mais de um mês aqui do “Falando em Projetos” (vou aproveitar os parênteses para me justificar rapidinho – férias e depois muito trabalho logo em seqüência), estou contando esta pequena passagem de minha vida? Simplesmente porque, em função do apelo que o assunto vem ganhando ultimamente, muita gente no mundo corporativo parece ter aprendido algo relativo a gerenciamento de projetos. O problema é que alguns, apesar de precisarem de maior solidez no assunto em função da posição que ocupam, aprenderam só “um pouquinho”. “Um pouquinho”, suficiente para saber mais ou menos o que é uma WBS, pra falar algumas frases vazias sobre PMI, PMP, PMBOK, pra mostrar alguns caminhos supostamente críticos no cronograma, pra defender a importância do gerenciamento de riscos, pra impressionar outros que também só sabem “um pouquinho”… Mas INSUFICIENTE pra gerenciar um projeto de verdade!

Alguém poderia dizer: “Mas é melhor saber um pouquinho do que nada, certo?”. Nem sempre. O arsenal de frases e expressões de efeito dá àquele que o possui uma falsa sensação de segurança, pelo fato de teoricamente estar usando as “best practices do mercado” – expressão também muito utilizada ultimamente . E o uso superficial de uma série de ferramentas faz com que a pessoa acredite plenamente que está protegida do insucesso, pelo fato de estar metodologicamente acobertada. Aí é que mora o perigo! Metodologias são ótimos instrumentos, quando seus usuários sabem como utilizá-las na prática. O PMBOK continua sendo uma referência importantíssima e bastante útil pra quem se preocupa em entendê-lo verdadeiramente. Mas projetos são impiedosos com quem os tratam com desdém e pouco caso. Assim, se você está a frente de um ou mais projetos, não se contente em saber só “um pouquinho” sobre o assunto. Corra atrás de auxílio e informações. A diferença no desempenho é certa.

Você conhece a força das restrições do seu projeto?

Uma restrição é algo que limita a liberdade de ação de um gerente na condução de um projeto. Limitações normalmente não são coisas muito agradáveis e podem afetar o desempenho de uma iniciativa. Seria interessante, portanto, que sempre conhecêssemos a fundo as restrições que nos são impostas, certo?

Imagine por exemplo o projeto que tem como entrega a realização da cerimônia de abertura dos Jogos Olímpicos. Será que alguém cogitaria a possibilidade da ocorrência de um atraso neste caso? Certamente não. Isto significa que há para este projeto uma restrição de tempo fortíssima.

Agora pense na seguinte situação: uma empresa do setor automobilístico contrata uma empresa de tecnologia para desenvolver um software para controle de alguma operação industrial. Além de esperar um software que atenda às suas necessidades, a contratante exige que a contratada siga um processo de desenvolvimento de software específico definido por ela. Em princípio esta é uma restrição do projeto. Mas seria esta uma restrição forte? Tudo depende do contexto e do motivo pelo qual ela foi imposta. Pode ser que a contratante tenha tido boas experiências com esse processo proposto e queira por algum motivo padronizar a forma como seus fornecedores produzem seus softwares. Mas pode ser também que alguém na empresa automobilística tenha ouvido falar que tal processo é bom e sem nenhum conhecimento de causa tenha estabelecido a restrição. Pra piorar, vamos assumir que a contratada dispõe de um processo de desenvolvimento muito melhor do que o imposto pela restrição. Será que é certo simplesmente aceitar a situação? Ou seria melhor tentar mostrar ao cliente que o caminho a priori escolhido por ele não é o melhor. Na segunda possíbilidade, (situação em que a escolha pelo processo imposto foi baseada em opiniões vagas) a restrição não tem bases “fortes” e poderia com um pouco de empenho ser eliminada para o bem do projeto.

Já vi também algumas restrições de tempo criadas de forma equivocada. Em um determinado projeto o sponsor, que era um cliente externo à organização, havia definido que o projeto deveria ser finalizado em 4 meses. A equipe fez o planejamento e chegou à conclusão de que o tempo mais adequado para o atendimento de todas as necessidades seria em torno de 6 meses. O sponsor não aceitou e o cronograma foi comprimido para se adequar à restrição de 4 meses. O problema é que a compressão pode gerar riscos para o projeto, que se materializados podem ter o efeito inverso: uma data fim ainda mais distante que a original. E foi o que acabou ocorrendo neste caso específico. Tempo final de execução: 9 meses. Mais tarde descobriu-se que a finalização do projeto em 4 meses não era uma restrição de fato. O sponsor queria apenas dar uma pressionada no fornecedor, porque achava que de outra forma o produto esperado demoraria demais para ser finalizado.

O grande problema é que normalmente informações sobre a verdadeira força das restrições não estão disponíveis facilmente. Não caem em nosso colo de graça. Para conseguí-las, é preciso que o gerente de projetos se dedique a entender a fundo o contexto que cerca o projeto. E que seja corajoso o suficiente para questionar e negociar aquilo que parece não fazer muito sentido, independentemente de quem tenha imposto.

Conhecer a força das restrições é bastante útil também para que decisões importantes possam ser tomadas no decorrer do projeto. Em uma situação extrema, em que custo, qualidade ou prazo terão que ser sacrificados, qual deles escolher? O ideal seria nenhum, mas em alguns casos sabemos que as coisas não são tão perfeitas assim.

Portanto, ao assumir um projeto, antes de aceitar tudo aquilo que lhe é imposto, analise, questione, argumente. Pode estar aí a diferença entre seu sucesso ou fracasso.

Planejamento na medida certa, na hora certa

Planejamento é bom, todos nós sabemos. Mas a forma de planejar um projeto pode variar muito, de acordo com suas características. Sponsors mais conservadores sempre desejam um plano extremamente detalhado, com a especificação precisa de tudo que será feito, ainda antes do início da execução do projeto. O problema é que em muitas circunstâncias as informações disponíveis neste momento são insuficientes para um detalhamento desta natureza.

Há projetos em que se sabe perfeitamente o que se quer e o que tem que ser feito para a obtenção dos resultados desejados. Um bom exemplo deste caso é a construção de um prédio de apartamentos voltado para um público de renda mais baixa. As construções costumam ser extremamente padronizadas, com requisitos e processos produtivos bem conhecidos. Nesse caso creio ser possível a existência de um plano de projeto detalhado antes do início da execução. Ele poderá sofre mudanças e refinamentos, mas de modo geral se manterá relativamente estável.

Agora imagine um projeto que tenha como resultado permitir que um varejista passe a executar suas vendas também pela Internet. O número de possíveis caminhos a serem tomados no projeto de montagem de uma operação deste tipo é muito grande. E para cada conjunto de possibilidades, o trabalho a ser executado, o custo e o tempo de execução podem variar bastante. Para ilustrar vejamos algumas possibilidades de variação:

Em relação à parte de tecnologia a empresa poderia:

- Optar por criar uma estrutura própria de hardware e software para hospedar sua loja virtual
- Construir um software próprio e rodá-lo em um datacenter terceirizado
- Utilizar uma loja virtual já montada, com toda a infra-estrutura já pronta

Em relação às entregas para os clientes ela poderia:

- Utilizar os Correios
- Utilizar grande empresas de entrega, tais como DHL, Fedex, etc
- Utilizar pequenas empresas locais de entrega
- Utilizar um mix destas diversas opções

Em relação à estruturação de centros de distribuição (CDs):

- Poderia haver um único CD a partir do qual as entregas para todos os estados do Brasil ocorreria
- Poderia-se optar por CDs descentralizados em cada um dos estados da federação

Como já foi possível perceber existem muitas possibilidades. Claro que a documentação de algumas premissas poderia melhorar um pouco a situação, tornando o cenário mais definido. O problema é que as análises a serem feitas para que cada uma das decisões sejam tomadas não raro são complexas e podem ser melhor gerenciadas se fizerem parte do ciclo de vida do próprio projeto. Nesse caso não tem jeito: devemos recorrer ao velho e bom planejamento em ondas sucessivas. Na minha opinião um dos mais importantes conceitos a serem conhecidos e utilizados na prática pelos gerentes de projeto. Mas que no dia a dia costuma ser desconsiderado, mesmo quando sua utilização é a única opção viável para o sucesso.

Para quem não conhece o conceito, segue sua definição, presente no PMBOK:

Planejamento em ondas sucessivas / Rolling Wave Planning [Técnica]. Uma forma de planejamento de elaboração progressiva em que o trabalho que será realizado a curto prazo é planejado em detalhes em um nível baixo da estrutura analítica do projeto, enquanto o trabalho distante no futuro é planejado em um nível relativamente alto da estrutura analítica do projeto. Porém, o planejamento detalhado do trabalho a ser realizado dentro de mais um ou dois períodos no futuro próximo é feito conforme o trabalho está sendo terminado durante o período atual.

Traduzindo de forma bem pragmática, significa planejar o que se conhece de forma detalhada e o que não se conhece de forma mais superificial. Como à medida em que o projeto avança o conhecimento a seu respeito aumenta, significa também que o planejamento deve ser refinado várias vezes ao longo do projeto.

Assim, se você trabalha com projetos em que há muitas indefinições em relação ao que se quer ou em relação a como atingir os objetivos (grande maioria), não se orgulhe de, ainda antes de a execução começar, apresentar um plano super-detalhado mesmo para as últimas fases do projeto. Se este for o desejo do seu chefe, você o agradará num primeiro momento, mas certamente terá problemas em um futuro bem próximo. Quer apostar?

Qual o valor do Gerenciamento de Projetos?

Você acredita nos benefícios do gerenciamento de projetos, mas tem dificuldades em vender a idéia para outras pessoas? O PMI está tentando lhe dar uma mãozinha… A instituição financiou um trabalho de pesquisa de proporções bastante expressivas denominado Researching the Value of Project Management, que está bem perto de ser finalizado. Foram 4 anos de investigações, envolvendo 65 organizações ao redor do mundo. As organizações analisadas pertencem a diversos setores distintos (serviços, pesquisa, industria, alta tecnologia) e executam projetos de diferentes tipos (internos, criação de produtos, para clientes, etc). Cerca de US$1.2 milhões foram investidos apenas pelo PMI. A previsão é que o lançamento do documento final contendo os resultados do trabalho ocorra em outubro deste ano. Entretanto, uma prévia do que foi feito pôde ser vista em apresentação ocorrida no dia 14 deste mês durante a última PMI’s Research Conference, realizada na Polônia. O vídeo está disponível aqui.

Eu assisti ao vídeo e na minha opinião os resultados parecem animadores, apesar de ser difícil analisá-los de forma mais aprofundada com base apenas no que vi e ouvi na apresentação. Abaixo um resumo do que foi mostrado:

- Em metade dos estudos de caso analisados foi possível identificar a presença de um valor tangível na aplicação do gerenciamento de projetos. Com tangível, quer-se dizer, mensurável. Metade parece uma quantidade pouco expressiva. “Copo meio cheio ou meio vazio”, conforme o ponto de vista. Mas é bom lembrar que em muitas organizações simplesmente não há a cultura de se medir investimentos em gestão, seja ela de projetos ou de qualquer outro tipo. Ou seja, o resultado não quer dizer que na metade em que não se identificou resultados tangíveis o investimento em GP foi dinheiro jogado fora.

- Na maioria das organizações estudadas (o número exato não foi revelado) foi possível perceber a presença de um valor intangível como resultado dos investimentos em GP. Como exemplos de fatores que estão relacionados a um valor intangível estão: comunicação mais efetiva, maior alinhamento da equipe como um todo em relação à abordagem de gestão utilizada, terminologia e valores e maior efetividade da organização.

Outras conclusões interessantes dizem respeito a algumas características da implementação de GP que estão associadas à criação ou destruição de valor.

Segundo os pesquisadores, organizações que percebem esse valor:

- Possuem uma equipe que se sente “dona” da implementação de gerenciamento de projetos realizada. Apesar de em muitos casos esta implementação ser extremamente parecida com o que se vê na maioria das empresas, a participação efetiva da equipe conferiu a ela um senso de buy-in significativo, que certamente contribuiu para o sucesso;

- Têm foco, comprometimento e investimento continuos na área;

- Têm uma percepção coletiva de “fit” (adequação), da abordagem de gestão adotada.

Por outro lado, são causas de destruição ou neutralidade em relação ao valor:

- Mudanças constantes no pessoal responsável por liderar a implementação do gerenciamento de projetos;

- Falta de foco;

- Overimplementation, ou seja, implementação de itens além do que a empresa realmente precisa, gerando burocracia desnecessária;

- Implementação de GP apenas porque está “na moda”.

O estudo pode não responder a todos os questionamentos dos mais céticos, mas certamente dará mais objetividade a argumentações favoráveis ao gerenciamento de projetos. Objetividade que é cada vez mais cobrada pelos executivos antes de optar por investir seus recursos. Mas que também não é novidade. Afinal, Willian Edward Deming, um dos papas da qualidade e teórico de gestão, há anos já dizia: “In God we trust, all others bring data”.

“O projeto andou pra trás?”

Já falei por aqui sobre possíveis contribuições que um software de gerenciamento de projetos pode trazer para o bom desempenho dos gerentes. Entretanto, alguns cuidados devem ser tomados em sua utilização, para que problemas e uma falsa sensação de controle sejam evitados. Software é apenas uma ferramenta e não é um atalho para capacitação de fato em gerenciamento de projetos. A história abaixo ilustra bem o que quero dizer.

Uma grande empresa de TI tinha em mãos um dos mais desafiadores projetos de sua existência. A substituição da tecnologia básica (hardware e software) que suportava a maioria das soluções oferecidas aos seus maiores clientes. Dada a criticidade da iniciativa, o presidente assumiu pessoalmente o papel de sponsor. Após alguns meses em que o projeto parecia não caminhar muito, deliberou que todas as reuniões gerenciais (que ocorriam mensalmente com todos os representantes funcionais da organização – gerentes, superintendentes e diretores), teriam em sua pauta uma apresentação breve e objetiva do projeto. Para garantir tal objetividade optou-se, entre outras coisas, pelo uso de um indicador de progresso – o % de conclusão.

Primeira reunião e o indicador foi apresentado: “Concluímos 13% do projeto!” – disse o gerente.

Segunda reunião e as coisas pareciam caminhar bem: “O percentual de conclusão atual do projeto é 25%” – anunciou novamente o gerente. Doze por cento em um mês é significativo, para algo que todos sabiam ser demasiado complexo.

Terceira reunião e o ritmo parecia ter diminuído: “Avançamos pouco desta vez presidente: estamos com 27% concluído”. A explicação que se seguiu, na tentativa de justificar as diferenças de desempenho entre os dois meses não parecia muito convincente . Mas a reunião terminou sem maiores percalços.

Na quarta reunião algo muito estranho aconteceu. Após uma explicação um pouco mais longa sobre o andamento do projeto veio a afirmação, no mínimo curiosa: “… e nosso percentual de conclusão é de 26%.”

O sponsor do projeto, incrédulo, disparou: “Deixe-me ver se entendi direito. O projeto andou pra trás?”

Evidentemente, as explicações dadas pelo gerente ao sponsor para o retrocesso do projeto não foram aceitas. Uma delas foi um possível aumento do escopo do projeto. Mas como o escopo foi aumentado sem que o sponsor tomasse conhecimento? Se este fosse o único motivo, já teríamos um problema na abordagem de gestão utilizada. Mas não era. O fato é que o % de conclusão do projeto era dado pelas contas realizadas pelo software Microsoft Project. Entretanto o software tem uma lógica para o cálculo desse percentual. E o padrão de atualização do cronograma (seja na atualização do progresso individual das atividades, seja no refinamento/desmembramento das atividades) deve ser feito segundo determinadas diretrizes, compatíveis com esta lógica, para que os resultados dos cálculos sejam confiáveis. Não basta simplesmente lançar um conjunto de números e copiar o % global apresentado para a apresentação do Powerpoint a ser mostrada na reunião de status. Parece que isso não foi muito bem observado.

Um cronograma, com suas datas de início e fim, recursos alocados e percentuais de conclusão individuais de cada tarefa é apenas um modelo da realidade. Os resultados apresentados serão tão bons quanto for a modelagem realizada. É muito importante saber o que se está fazendo. De outra forma o gerente de projeto pode passar por situações no mínimo constrangedoras, como a descrita acima.