Encontrei no LinkedIn o resultado de uma pesquisa sobre os obstáculos para o sucesso dos projetos, que criou um ranking dos 10 fatores que causam maiores problemas para o bom andamento de um projeto.

Apesar de que não tive acesso aos detalhes da pesquisa (número de respostas, perfil demográfico, etc.), concordo que esta lista nos mostra importantes barreiras para as quais o Gerente de Projeto deve estar pronto para planejar, mitigar, corrigir e monitorar.

A ordem do ranking não é o importante.  Diferentes projetos terão problemas diversos em ambientes diversos.  Alguns sequer fazem sentido em certos tipos de projeto.  O importante da lista é que ajuda o Gerente a avaliar melhor os riscos envolvidos no projeto.

Este é o ranking gerado na pesquisa:

1. Alongamento do escopo (Scope Creep)
2. Cronogramas desafiadores
3. Limitação em recursos
4. Fase de testes mínima ou não-existente
5. Entrega tardia das tarefas do projeto
6. Delegação de responsabilidade não relacionada à autoridade
7. Desafios financeiros
8. Requerimentos invisíveis
9. Equipe com habilidades limitadas
10. Desaparecimento do patrocinador

Vou iniciar uma série de posts sobre os problemas em projetos, entrando em mais detalhe sobre cada um (e agrupando problemas simliares) e sugerindo soluções de mitigação.

O linguajar popular, a palavra risco tem uma conotação negativa.  Normalmente, quando falamos de risco, estamos nos referindo a que algo ruim pode acontecer.

Na realidade, a palavra risco quer dizer apenas a potencialidade de um evento ocorrer.   Este evento pode ser positivo ou negativo - portanto temos riscos negativos e riscos positivos, também conhecidos como ameaças e oportunidades, respectivamente.

Os riscos positivos são um fator importantíssimo para os projetos, e podem trazer benefícios que acelerem ou incrementem seu sucesso, mas nem sempre avaliados como deveriam ser.   Assim como os riscos negativos, eles devem passar pelos processos de Gerenciamento de Risco, que incluem listar os riscos, realizar análises de probabilidade e efeito e traçar um plano de ação para cada um.

A diferença no caso dos riscos positivos é que as ações são voltadas a fazer com que eles aconteçam, influenciando stakeholders e criando as condições adequadas.

Ignorar o risco positivo é um grande erro.  O Gerente de Projeto deve perseguir as principais oportunidades com a mesma voracidade com que ele evita as ameaças.  Os benefícios que podem ser obtidos devem ficar claros para toda a equipe e os outros principais stakeholders, para estimular a realização das oportunidades.

Vale a pena ressaltar que riscos positivos não são condições necessárias para o sucesso.  Se seu projeto depende de um evento para avançar, estamos falando de um requerimento de projeto, e não uma oportunidade.  Lembre-se que riscos positivos são desejáveis e devem ser perseguidos, mas nunca em detrimento dos objetivos principais do projeto.

Após definidos os riscos positivos, as seguintes estratégias podem ser adotadas:

Exploração - envolver os melhores recursos da empresa (ou recursos externos, como consultores) para garantir que a oportunidade se torne realidade da melhor forma possível.

Compartilhamento - dividir os ganhos da oportunidade com terceiros (internos ou externos) que possuem mais capacidade para torná-la realidade.

Otimização - trata-se de aumentar a probabilidade de que uma oportunidade realmente ocorra.  Isto pode ser feito ajustando as condições do projeto com foco nas oportunidades.

Para finalizar, lembre-se que um risco pode ser negativo e positivo ao mesmo tempo.  Pense, por exemplo, no surgimento de uma nova tecnologia que é superior à que você está usando em seu projeto.  Esta tecnologia pode ser um risco negativo se adotada pela concorrência, mas também pode ser uma oportunidade para seu projeto caso você treine a equipe adequadamente.

Em qualquer caso, um dos maiores valores agregados que o Gerente de Projeto traz a uma organização é a maximização de oportunidades e a minimização de ameaças.

Projetos falham, e com frequência.  Recentemente vi em estudo que dizia que apenas 34% dos projetos nos Estados Unidos foram considerados um sucesso (perdi a fonte, mas lembro do número).  As causas para o fracasso são diversas, mas uma é frequente:  o projeto não atende a uma necessidade real da empresa.

Todo projeto deve ser gerado a partir de uma necessidade organizacional real.  Infelizmente nem sempre isto é feito.  Idéias megalômanas, desejos excêntricos, preguiça ou incompetência na pré-avaliação de projetos, sede de poder e outras bizarrices organizacionais geram projetos sem pé nem cabeça, que nascem destinados ao fracasso.

É aí que entra o Gerente de Projeto.   Qual gerente quer se envolver em projetos que darão de cara na parede?  Talvez muitos… e certamente porque se sentem tímidos para criticar projetos, não querem fugir do desafio ou desejam ficar bem com o patrocinador do projeto.

No entanto, o Gerente de Projeto deve avaliar bem sua participação em projetos não alinhados com as necessidades da empresa.  Projetos deste tipo podem manchar o currículo do Gerente, e deixá-lo em um beco sem saída, já que não é incomum ver projetos mantidos em estado moribundo…  não morre, mas também não recebe recursos para viver bem.

Cabe ao Gerente de Projetos fazer uma pré-avaliação do projeto para orientar adequadamente a seu patrocinador, mesmo que isto signifique dizer algumas verdades que ele não quer ouvir.  Esta é a sua responsabilidade perante a empresa, os stakeholders e sua própria carreira.  A oportunidade deve ser real, não imaginária, e os resultados devem ser concretos, não um sonho.

O ideal é quando a empresa é bem estruturada e possui métricas adequadas e uma boa organização financeira.  Nestas situações, fica mais fácil associar projetos a melhorias, e retorno a investimentos.  Uma métrica fora do planejado costuma ser uma boa oportunidade para bons projetos.

Ainda assim, nem sempre o Gerente conseguirá dados concretos para justificar um projeto.  Isto não quer dizer que o projeto não deva ser feito, mas gera um esforço adicional em tentar objetivar o subjetivo… ou seja, mostrar quais resultados concretos podem ser objetivos através do projeto.

Fazer a lição de casa antes de começar a queimar dinheiro beneficia a todos… mesmo que em um primeiro instante todos queiram ir na onda do sonho.

Comecei a ler um livro intitulado “Inteligência Emocional para Gerenciamento de Projetos”, do autor americano Anthony Mersino, PMP.  O livro fala da importância da inteligência emocional para a carreira do Gerente de Projetos e para o sucesso dos projetos em si.

Em breve farei uma resenha mais completa sobre o livro, mas logo no primeiro capítulo há uma lista muito importante de 7 pontos em que a inteligência emocional pode ajudar os gerentes de projeto:

1.  desenvolver relacionamentos com stakeholders que apóiem o sucesso do projeto;

2.  antecipar e evitar esgotamentos emocionais;

3.  lidar com membros difíceis da equipe e gerenciar conflitos;

4.  incrementar as informações emocionais para tomar decisões melhores;

5.  comunicar-se de modo mais eficaz;

6.  criar um ambiente de trabalho positivo e um alto moral na equipe;

7.  criar uma visualização de cenário para objetivos compartilhados no projeto, com o intuito de atrair, inspirar e motivar a equipe de projeto.

Como profissionais de projetos, não devemos ficar somente na parte “técnica” da disciplina.  Estabelecer processos, aplicar o PMBOK e fazer bons relatórios é só uma pequena parte do sucesso de um projeto.  Uma parcela muito grande está na influência e harmonia que o gerente consegue estabelecer com os stakeholders.

Neste blog, o mais próximo que cheguei ao tema foi no post sobre amizade entre gerentes de projeto e a equipe.  Certamente este livro irá me inspirar a escrever mais sobre a inteligência emocional nos projetos.

Muitos profissionais que tem interesse em gerenciamento de projetos, mas ainda não possuem um contato mais profundo com o tema, podem se perguntar por onde começar.

O material disponível sobre a disciplina de gerenciamento de projetos é muito farta, mas não é suficiente ficar apenas devorando conteúdo.  Para entender mesmo o que é gerenciar um projeto é necessário saber equilibrar a teoria básica com um pouco de vivência em projetos reais.

Seguem algumas dicas para quem quer começar a conhecer este tema:

1. Participe em um projeto

Se você não faz parte de uma equipe de projeto, se ofereça para participar em uma.  Caso sua empresa não tenha projetos “formais”, certamente está desenvolvendo novos produtos e serviços ou tomando iniciativas de melhoria - e isto é o que mais se aproximará de um projeto em sua organização.   Assim que estiver participando em um projeto, invista seu tempo em compreender como o projeto está sendo estruturado e organizado.

2. Leia um livro básico

Livros sobre gerenciamento de projetos têm proliferado no mercado.  Existem diversas opções que lhe darão uma visão sobre esta disciplina, e você poderá enxergar com mais clareza as diversas etapas de um projeto real.   Somente tenha o cuidado de não pegar um livro mais avançado que lhe trará mais confusão do que compreensão.

3. Não leia o PMBOK

O PMBOK é um livro muito técnico e pesado, direcionado a profissionais com conhecimento um pouco mais avançado e que estão desenvolvendo metodologias para seus projetos.  Na pior hipótese, leia apenas os primeiros capítulos que dão uma visão geral da disciplina.

4. Busque cases de projetos de seu setor

A associação entre projetos e uma área que você já conhece bem lhe ajudará a assimilar melhor os conceitos.  No futuro vale a pena vivenciar projetos em diferentes áreas, mas para começar a ganhar familiaridade com o tema, comece por uma área que está dentro de seu conhecimento.

5. Consiga um coach

Ter um profissional experiente que esteja disposto a lhe guiar em seus primeiros passos em gerenciamento de projetos é um benefício imensurável.  Aproveite esta oportunidade para ouvir muito e começar sua carreira nesta disciplina tão interessante e desafiadora.

Recebi através de um contato no Twitter uma dúvida interessante sobre conflitos em gerenciamento de projetos:  enquanto o departamento de vendas quer atender o cliente rapidamente, o departamento que executa o projeto quer mais tempo e planejamento (inclusive contratual) para que o resultado seja melhor.

Este problema é clássico em gerenciamento de projetos: prazos inadequados e falta de planejamento (tudo em nome de “atender ao cliente”).  Ao mesmo tempo, pode ser que o departamento comercial esteja com a agressividade necessária para atender ao mercado.

O que o gerente de projeto deve fazer neste caso é tentar determinar se nível de planejamento e controle está sendo adequado ou exagerado.  Acredito que 3 hipóteses devem ser consideradas:

1. O resultado para o cliente seria melhor com mais planejamento.

Cabe ao gerente de projeto usar seus recursos  para convencer o cliente e o departamento comercial de que uma estrutura de projeto bem montada trará mais resultados ao cliente.   Pode-se, por exemplo, fazer um projeto piloto no qual a forma de trabalho seja diferenciada e conduzida com mais planejamento e documentação.   Neste caso, é muito importante que os benefícios esperados para o cliente realmente fiquem muito evidentes, ou a equipe perderá credibilidade.

2. Planejar mais ou aumentar o tempo não mudará o resultado para o cliente ou para a empresa.

Neste caso, a equipe operacional deve engolir o choro se adaptar às necessidades do projeto e do cliente.  Se isto representa muita pressão e desgaste, infelizmente esta é muitas vezes a realidade do mercado.  Obviamente, a empresa deve dar as condições para que a equipe trabalhe nesta situação (ambiente de trabalho agradável, prêmios por resultados, etc.).

3. O resultado para o cliente não será melhor com mais planejamento, mas será melhor para a empresa.

Se o escopo e as condições do projeto (contrato) não estão bem definidos, corre-se sério risco de reduzir o resultado financeiro da empresa.  A pressão do departamento comercial pode levar a equipe operacional a entregar mais do que foi combinado, aumentando tempos e custos.   Definições pouco claras geram uma dificuldade de execução que depois precisa ser compensada com horas extras e mais estresse.

Avaliando as 3 hipóteses acima, o trabalho do Gerente de Projeto é definir as ações corretivas que devem ser tomadas na forma de execução dos projetos.  Não, isso não é nada fácil de fazer, mas se fosse fácil, talvez os projetos não precisariam de gerente.

Estes são alguns recursos que o Gerente de Projeto pode usar para atingir estes objetivos:

• Relacionamento interpessoal: quando os conflitos podem ser resolvidos pelo relacionamento do gerente com a equipe, o resultado final tende a ser melhor para todos os envolvidos.
• Negociação: projetos têm restrições, e muitas vezes o resultado deve ser negociado entre os envolvidos para chegar a um bom resultado, dentro das premissas da empresa.
• Patrocinador do projeto: o patrocinador deve ajudar a definir as prioridades do projeto e as exceções (ex. reduzir o lucro do projeto para atender melhor um cliente importante).
• Autoridade formal: dependendo da autoridade que o GP tenha no projeto, muitas vezes é necessário simplesmente dar uma ordem e exigir que seja seguida.

Para finalizar, tenha em conta que as 3 hipóteses citadas não são sempre contrárias. Os projetos ideais são os que têm bom planejamento, entregam melhores resultados para os clientes e geram lucro para a empresa (e eles não existem somente no mundo da fantasia).

A certificação CAPM (Certified Associate in Project Management) começa a ganhar presença no Brasil.  Apesar de que ainda são poucos profissionais certificados (78 até Março, contra 7.258 certificados PMP), os chapters começam a tomar iniciativas para divulgar a credencial e oferecer cursos e workshops.

Acabei de publicar no Portal O Gerente, uma entrevista sobre a certificação CAPM com Carlos Augusto Vieira de Freitas, um dos primeiros certificados CAPM na América Latina.  Carlos Augusto nos conta sobre sua experiência com a certificação e sua evolução no Brasil.  Ele também é o criador do grupo Yahoo “Certificação CAPM do PMI“.

Alguns destaques da entrevista:

No final do ano passado recebemos algumas vagas em que era solicitado como pré-requisito a Certificação CAPM, o que prova que as empresas também estão identificando e reconhecendo a necessidade e importância que um profissional certificado pode agregar.

Sempre passamos a orientação aos alunos que não decorem todos os processos, entradas, saídas e ferramentas & técnicas e sim, compreenda o conceito de cada processo. A partir daí o conhecimento será assimilado.

O principal é compreender e entender o objetivo das credenciais CAPM e PMP. O que muitos ainda confundem é “achar” que uma certificação é melhor que a outra. Isso não é verdade, as credencias não são concorrentes e não competem entre si, e sim se complementam.

É importante o profissional se encontrar dentro do perfil e objetivo para aí sim, definir qual o caminho a seguir. Iniciar corretamente o caminho dentro do desenvolvimento profissional em gerenciamento de projetos faz a diferença aos profissionais e ao mercado de trabalho.

Os padrões do Project Management Institute (entre eles o PMBOK) seguem a orientação da ANSI (American National Standards Institute), e por isso devem ser atualizados a cada 5 anos.  O PMI tenta manter a prática de atualizá-los a cada 3 anos, e se coloca um ano de “folga”.   Por isso no final do ano passado foi lançada a 4a edição do PMBOK.

O “jornal” mensal do PMI (PMI Today) traz o processo que é usado para o desenvolvimento e atualização dos padrões, informação que pode ser interessante para os membros, profissionais certificados e aqueles que buscam a certificação no PMI:

1.  É feita uma pesquisa para identificar novos padrões que devem ser desenvolvidos ou determinar se há a necessidade de atualizar um padrão.

2. Se uma necessidade é identificada, um project charter e escopo preliminares são desenvolvidos.

3. Um gerente de projeto voluntário é designado e uma equipe preliminar de planejamento é constituída.

4. O charter e escopo são finalizados e aprovados.

5. Voluntários são selecionados para a equipe.

6. O conteúdo é desenvolvido.

7. O conteúdo é aberto para revisão pública para exposição preliminar.

8. Comentários recebidos na exposição preliminar são adjudicados pela equipe de projeto.

9. As decisões finais da equipe de projeto sobre os comentários são enviados ao que originaram os comentários.

10. Os profissionais que originaram os comentários podem questionar as decisões enviando comentários adicionais.

11. Os questionamentos são avaliados por um grupo revisor.

12. A edição final é feita pelo Editor de Produtos do PMI.

13. O documento final é enviado ao grupo de consenso para voto.

14. O CEO aprova o documento para publicação.

15. O documento é publicado.

Gerentes de Projeto nem sempre dão a devida atenção à venda interna do projeto em uma organização.   Quanto maior a empresa, maiores os aspectos políticos e estratégicos que devem ser gerenciados, e o sucesso do projeto pode ser função direta do apoio prévio dos líderes.

Obter a aprovação do chefe direto é uma coisa.  Ter apoio geral da empresa é outra completamente diferente.  Somente a distribuição de recursos (humanos e financeiros) e as variações no balanço de poder na organização já são razões mais do que suficientes para que o gerente de projeto analise cuidadosamente o impacto que seu projeto terá, e quais ações deve tomar para obter a maior aceitação possível de seu projeto.

A análise que o Gerente deve fazer pode se concentrar em 3 grupos:  Recursos, Política & Poder e Apresentação:

Recursos

Todo projeto consome recursos, e todo recurso é limitado.   Se você consegui verbas para seu projeto, algum projeto de sua ou outra área deixará de ser feito.   Ao conhecer quais setores não tiveram investimentos aprovados, você poderá se proteger contra possíveis “inimigos” do projeto.   Não quero dizer que se trate de uma guerra por recursos, mas não subestime a frustração que outros gestores podem ter.

Quando for o caso, mostre que seu projeto também trará benefícios aos demais, e sempre tenha um estrito controle financeiro, buscando formas de redução de custos e otimização do investimento.  Mostrar que você faz valer o investimento e que não há recursos sendo desperdiçados ajudará muito a que todos os líderes vejam seu projeto com bons olhos.

Política & Poder

O efeito é similar ao de recursos:  quando um setor inicia um projeto importante para a organização, naturalmente a balança de poder pode variar.  Novamente, quem sai perdendo terá a tendência a desmerecer o projeto.

Em muitos casos, o impacto pode ser ainda mais grave.  Líderes que perdem poder podem levar a situação para o lado pessoal, e agir por emoção ao invés da razão.

Não existem regras para solucionar este tipo de situação.  Depende muito da estrutura política de cada empresa e do tipo de líderes com os quais o gerente de projeto está lidando.   De forma geral, é sempre bom ter um patrocinador com força política.  O papel do gerente de projeto é não colocar mais lenha na fogueira das vaidades (evitando, por exemplo, qualquer tipo de exposição desnecessária do projeto).   Eventualmente acontecerão disputas, mas quais devem ser lutadas é uma escolha que deve ser feita com muito cuidado.

Apresentação

A forma como você apresenta seu projeto na organização pode dar um ótimo empurrão inicial e uma trégua nas pressões dos líderes.  Não se trata de mostrar detalhes técnicos e eficiência gerencial.  O gerente de projeto deve pensar como os altos gestores da organização e mostrar como o projeto se alinhará com a estratégia e objetivos corporativos.

O que mais importa à liderança é o resultado final do projeto.  Claro que eles devem ter a tranquilidade quando ao desempenho e execução, mas nada subsitui que eles vejam um alto potencial (realista!) no produto do projeto.

Você avalia a sustentabilidade de seu projeto?   Sabe quais são os impactos que ele causa em diversos aspectos do mundo que o rodeia?

Já escrevi artigos sobre sustentabilidade na pequena empresa e na cadeia de suprimento, e achei interessante fazer o mesmo com gerenciamento de projetos.    Não vou falar sobre a sustentabilidade do produto do projeto (sobre o qual o gerente de projeto tem menos controle), mas do projeto em si.

Partindo da definição que dei para a empresa sustentável, podemos definir um projeto sustentável desta forma:

O projeto sustentável é aquele que gera retorno para a empresa e seus clientes (internos ou externos) sem causar impactos negativos (ou causando impactos positivos) aos outros stakeholders envolvidos.

A sustentabilidade de um projeto se sustena em quatro aspectos:  Ambiental, Social, Cultural, Econômico.   A seguir descreverei algumas idéias para avaliar cada aspecto em seu projeto:

Sustentabilidade Ambiental:

• O lixo que o projeto gera é reciclado?
• Imprimem-se grandes volumes de papel de forma desnecessária?
• O projeto aproveita a tecnologia para reduzir viagens e reuniões presenciais?
• O projeto desenvolve iniciativas ecológicas em torno do produto que está sendo criado?

Sustentabilidade Social:

• A equipe do projeto recebem um salário justo e um tratamento digno?
• As condições e segurança no projeto são adequadas?
• A atuação da equipe afeta o dia a dia da sociedade em torno do produto do projeto?
• O projeto incentiva iniciativas sociais em torno do produto que está sendo criado?

Sustentabilidade Cultural:

• O projeto está bem encaixada no perfil do bairro ou da região?
• Se o projeto é multicultural, as diferenças os stakeholders são respeitadas?
• As atividades do projeto são adequadas para a região na qual a elas ocorrem?
• Os valores culturais da equipe são os mesmos que os dos outros stakeholders (especialmente o cliente)?

Sustentabilidade Econômica:

• O projeto trará lucro e resultados positivos de forma legal?
• As negociações com os fornecedores são feitas de forma justa?
• Os clientes internos ou externos recebem o valor pelo qual estão pagando ou são enganados com falsas promessas e expectativas?
• As atividades do projeto são conduzidas de forma ética?

Avalie todos estes aspectos em seu projeto, para garantir que ele deixará uma marca positiva.  Isto é bom para todos - incluindo, claro, o gerente de projetos.

Inúmeras coisas podem ir mal e matar um projeto.   Prevê-las é o objetivo do gerenciamento de risco do projeto.   No entanto, nem sempre conseguimos avaliar adequadamente todos os cenários que podem dificultar o andamento de um projeto.

O problema é que muitas vezes a mente das pessoas não está aberta para discutir cenários macro, e se concentram como apenas em como cada atividade pode dar errado.  Isto é natural pela forma em que o levantamento de riscos é algumas vezes apresentado (levantando riscos atividade por atividade).

Na Harvard Business Review de Setembro/2007, há uma idéia interessante para mudar esta forma de pensar nos riscos.   O conceito é muito simples:  realizar uma reunião para discutir uma situação imaginária - porque o projeto morreu?

O processo seria mais ou menos assim:

• O gerente de projeto (ou líder da reunião) descreve o cenário a todos: o projeto morreu e todos devem imaginar porque isto aconteceu.
• Cada membro da equipe escreve, de forma individual, as causas pelas quais o projeto fracassou (colocando especialmente aquelas causas menos “populares”).
• Um a um, cada membro vai lendo suas causas, as quais são registradas em uma lista única pelo gerente de projeto.
• Esta lista é usada pelo gerente para fortalecer seu plano de projeto, especialmente no que se refere ao gerenciamento de riscos.

Uma das coisas que imaginei é:  porque não discutir as causas da morte do projeto em conjunto?   No entanto, depois percebi que faz sentido.   Se a idéia é obter novos conceitos que não foram discutidos previamente, a imaginação de cada um deve estar livre da influência dos outros.   Em uma discussão prévia, uma idéia interessante pode ser sufocada pelo grupo que a está discutindo.

Também há um conceito psicológico por trás deste método:   “Uma pesquisa realizada em 1989 por Deborah J. Mitchell, da Universidade Wharton; Jay Russo, da Universidade Cornell; e Nancy Pennington, da University
de Colorado, descobriu que imaginar que um evento já ocorreu aumenta em 30% as chances de identificar as razões pelas quais ocorreria.”

Este processo, o qual ainda não tive a oportunidade de testar, não substitui as outras formas de gerenciamento de risco, mas parece ser um jeito muito interessante de melhorar o plano de projeto.   É um processo mais leve e descontraído, que pode levar a insights poderosos.

Todo gerente de projetos já deve ter passado por esta situação:  você entra para coordenar uma reunião de projeto, e durante a discussão das situações a serem resolvidas a situação sai do controle e se torna uma troca de acusações e atitudes defensivas entre os participantes.   De repente, não se trata mais de buscar soluções, e sim de identificar culpados e inocentes.  Se você ainda não viveu esta situação, saiba que é mais comum do que imagina, especialmente em empresas que não possuem uma forte cultura de transparência e responsabilidade.

O gerente que lidera a reunião de projeto deve conhecer este tipo de situação, saber identificar os sintomas de que a reunião caminha para o desastre e tomar ações corretivas para manter os objetivos da discussão. De outra forma, pode ter as seguintes consequências:

• falta de união da equipe
• desconfiança mútua
• perda de tempo
• perda de foco
• perda de produtividade

Existem várias atitudes e ações que o gerente de projetos pode tomar para eliminar ou ao menos mitigar ao máximo este tipo de situação.  A seguir estão algumas dicas:

1. Evitar ansiedade quanto aos erros cometidos.

Se a reunião vai tratar soluções para erros cometidos, o gerente não deve comunicar que o objetivo será, por exemplo “resolver o atraso causado pela equipe de desenvolvimento X”.  Seria muito melhor dizer “buscar soluções para manter o cronograma do deliverable Y dentro do prazo”.

A diferença é sutil, e pode até parecer frescura, mas a primeira opção cria uma ansiedade quanto à discussão que será gerada, estabelece um clima negativo na reunião e faz com que os participantes da reunião cheguem “armados”.

2. Preparar adequadamente a pauta.

Além de colocar o foco nas soluções, o gerente de projeto deve estruturar a pauta para que temas potencialmente explosivos não fiquem no começo da reunião.  Caso ele não consiga controlar os ânimos, não só perderá o tempo dedicado a outros temas importantes, mas também terá que lidar durante o resto da reunião com forte negatividade.

3. Deixar a discussão sobre culpas e erros para conversas individuais.

Expor os erros de membros da equipe durante a reunião é totalmente improdutivo e gera imediatamente as consequências que descrevi anteriormente.   Não que o erro deva ser esquecido, mas ele deve ser tratado de forma privada com a equipe ou o colaborador que o cometeu.

4. Barrar discussões que ameçam virar acusações.

A linha é muito tênue entre uma discussão produtiva e um início de briga.  Uma palavra mal dita por um dos participantes pode desencadear reações defensivas e ofensivas.  Cabe ao gerente de projeto que está coordenando a reunião ficar muito atento aos primeiros sinais de mudança de foco para interferir e redirecionar a conversa.

Também é importante, assim que for definido um plano de ação em um tema difícil, fechar o assunto e partir para próximo sem permitir divagações que podem levar a caminhos indesejados.

5. Documentar lições aprendidas sem dar nomes a culpados.

Se durante a reunião se está aproveitando para documentar lições aprendidas, elas nunca devem ficar associadas a um erro cometido por uma pessoa ou grupo.   Novamente, trata-se de colocar o foco nas soluções para que os problemas não voltem a acontecer, e não em apontar quem é o indivíduo que falhou e que não deve participar em projetos futuros.

6. Se colocar como corresponsável pela falha.

O gerente de projeto deve assumir a responsabilidade pelos sucessos e fracassos de seu projeto.   Se colocar na linha de fogo quando algo não está bem mostra profissionalismo e inspira respeito dos membros da equipe.   Mesmo que a falha tenha sido individual e inevitável por parte do gerente, ele nunca deve se isentar e apontar culpados.

Sugestão de leitura adicional: Dicas para Resolver Problemas, no blog TenStep.

O PMI lançou na virada do ano a 4a Edição do PMBOK - o Project Management Body of Knowledge.  A primeira questão que me veio à mente foi…  e daí?   Como isto afeta meu trabalho como gerente de projetos?

Claro que a resposta a esta questão é completamente diferente para a realidade de cada profissional da área.  Em meu caso, o PMBOK serve como uma base de conhecimento que aplico caso a caso em meus projetos, e não um manual que sigo à risca.  Portanto, algumas mudanças no documento não afetam a forma como realizo meu trabalho.  Certamente tenho interesse em conhecer as mudanças no PMBOK, mas isto não é uma prioridade em minhas leituras e estudos.

Existem, no entanto, algumas circunstâncias nas quais é realmente importante conhecer o que mudou no PMBOK e sua aplicabilidade na prática de gerenciamento de projetos.   A seguir listo algumas situações nais quais considero fundamental conhecer de perto esta nova edição:

1. Se você pretente obter a certificação PMP a partir do próximo semestre.  A prova para a certificação está programada para mudar para a nova edição a partir de Julho de 2009.   Portanto, se você pretende fazer o exame após este prazo, parta imediatamente para o estudo da nova edição.

2. Se é estudioso da área.  Muitos profissionais gostam de conhecer profundamente os diversos padrões, documentos e metodologias de gerenciamento de projetos.  Neste caso, conhecer exatamente o que mudou entre a 3a e 4a edição do PMBOK faz parte de sua pesquisa.

3. Se você dá treinamentos focados no PMBOK ou em certificações do PMI.  Existirá um período de transição no qual você terá alunos que farão a prova do PMP tanto na 3a edição quanto na 4a.   Mesmo que as turmas sejam separadas, o instrutor deve se atualizar e saber bem quais são as mudanças entre as edições.

4 Se sua empresa tem um alto grau de maturidade em gerenciamento de projetos, e segue uma metodologia baseada nos padrões do PMI, há grandes possibilidades de que as mudanças no PMBOK afetem processos de projetos da organização.

Não existe gerenciamento perfeito sem processos perfeitos.

Em meu último post, no qual publiquei duas tiras do Dilbert sobre gerenciamento de projetos, o Sidney, do Infocontrol escreveu uma dúvida interessante:  “Como você costuma lidar quando a gerência é perfeita mas os métodos de trabalho não o são? Comunicação ou Burocratização?“.

Bom, em primeiro lugar, vamos esclarecer que sempre que dizemos perfeito estamos nos referindo a algo que atingiu um alto nível de excelência.  Perfeição pura não existe.

Agora, vamos à questão do Sidney.  Em minha visão, os métodos de trabalho estão diretamente associados à gerência.  Quem define ou ao menos orienta os processos em grande parte das empresas são os gestores.  Portanto, processos falhos devem ser diretamente atribuídos a uma gerência imperfeita.  Fugir deste fato pareceria mais uma desculpa de quem está falhando.  Por exemplo:

• E se a gerência não é quem define os métodos de trabalho?  - Então a gerência está sendo imperfeita em influenciar a mudança na empresa.
• E se são os altos executivas da empresa os que definem os processos? - Então a gerência está sendo imperfeita no gerenciamento de stakeholders.
• E se os funcionários não seguem os processos? - Então a gerência está sendo imperfeita no processo de seleção ou treinamento da equipe.

A lista pode continuar, mas não vejo necessidade.  Um gerente que deseja atingir a excelência deve ter ótimas habilidades em todos os aspectos de seu trabalho.  Falando específicamente do gerente de projetos, isso significa, por exemplo, dominar a teoria e a aplicação de todas as áreas de conhecimento relacionadas à atividade, como gerenciamento de escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos, aquisições e integração (sim, colei do PMBOK).

Na prática, a perfeição no existe.  O que deve exitir é um constante aprimoramento da capacidade e das habilidades do gerente de projetos.

Mais um pouco sobre Gerenciamento de Projetos no Dilbert:

Agora, esta é excelente:

Uma ferramenta muito simples, mas bastante prática ajudar na compreensão macro do projeto e de seus principais objetivos é o mapa de milestones.

Este mapa nada mais é do que uma representação gráfica os principais milestones do projeto, sem nenhum detalhamento das atividades.  Por mais que pareça muito simples, gerentes de projetos experientes sabem que não é raro que conceitos básicos do projeto não estejam claros na mente de diversos stakeholders.

Tomando o exemplo da construção de uma pequeno chalé, este seria um mapa de milestones:

(Clique para ampliar)

Usos Práticos da Ferramenta

• Compreensão dos objetivos do projeto junto a clientes e outros stakeholders antes de iniciar o planejamento detalhado.
• Facilitar sessões de brainstorming, especialmente no inicio do projeto.
• Facilitar a comunicação dos principais objetivos até a conclusão do projeto.
• Ajuda a manter o foco da equipe no projeto.
• Facilitar a comunicação com stakeholders que não querem, não devem ou não precisam conhecer os detalhes do plano de projeto.
• Exercício mental para o gerente de projetos e a equipe validarem o plano de projeto

Cuidados no Uso da Ferramenta

• Não misture atividades no mapa.  Não é esse o objetivo da ferramenta.
• Resista à tentação de incluir muitas informações no mapa ou exceder no detalhamento.  Isto tirará a atenção dos pontos mais importantes.
• Não usar este meio de comunicação com pessoas mais próximas ao dia a dia do projeto.  Estas pessoas querem ver os detalhes do plano de projeto.
• Não permitir que, ao apresentar este mapa, se entre em discussões sobre o plano de projeto.  Haverá um momento certo para isto.

A forma do desenvolvimento do escopo varia muito por tipo de empresa, tipo de projeto, estilo (e autoridade) do gerente de projeto, entre outro fatores. Por isso, não é fácil definir a melhor ou pior forma de desenvolver o escopo de um projeto.

No entanto, há um tipo de projeto no qual o detalhamento gradual do escopo costuma trazer os melhores resultados: desenvolvimento de novos produtos.

Para deixar claro, por desenvolvimento de novos produtos estou me referindo à criação de algo realmente novo, e cujo projeto passará por fases que ainda não são totalmente conhecidas pelos membros da equipe. Não entram neste conceito os projetos que envolvem a adaptação de um produto a um novo cliente, por exemplo, já que nestes casos o processo costuma estar muito mais incorporado na empresa.

Posso citar 4 razões pelas quais não vale a pena detalhar o escopo logo no começo do projeto no desenvolvimento de novos produtos :

1. Evita exageros nos requisitos. Quando você solicita a alguém que escreva todas suas especificações de uma vez porque será a única oportunidade para fazê-lo, a tendência é que ele inclua tudo que ele pode imaginar e que talvez precise. Isto, na prática, pode levar à criação de funcionalidades e características desnecessárias para o produto.

2. O escopo não fica completo. Além de você ter o risco de receber especificações além do realmente necessário, isso não elimina o potencial de escopo incompleto. Especialmente quando estamos falando em desenvolver algo novo, não é muito sensato imaginar que a equipe e o cliente conseguirão cobrir todas as especificações desde o início.

3. Aumenta o retrabalho. Se estamos criando algo realmente novo, certamente existirão pontos desconhecidos ao longo do projeto. Se forçamos a equipe a pensar nos mínimos detalhes antes das primeiras fases do produto estarem prontas, é natural que seja necessário retrabalhar estes detalhes mais adiante.

4. Cria-se uma expectativa pouco realista. Quando teoricamente temos o escopo detalhado desde o começo, automáticamente os stakeholders criarão uma expectativa sobre a consistência daquele escopo e do cronograma consequente. No momento em que os passos desconhecidos no desenvolvimento de produto causarem mudanças em escopo, custo e prazo, nem todos entenderão isto como algo natural do tipo de projeto sendo executado.

Ditas as razões pela qual desenvolver o escopo gradualmente, cabe ao gerente de projeto determinar exatamente o nível de escopo que é desejado em cada fase. Não se trata de pensar somente no curto prazo e esquecer do que virá mais adiante… isto seria um tiro no pé. O importante é que o escopo das fases mais avançadas seja definido de forma mais macro, e que permita pelo menos:

• Orientar adequandamente as atividades e deliverables nas fases iniciais.
• Estimar o custo e prazo totais do projeto.
• Identificar riscos de grande probabilidade ou impacto que devam ser discutidos desde o começo.
• Mostrar a viabilidade do projeto (será que não existe uma especificação desejada pelo cliente e que poderá travar o desenvolvimento)?

O que costumo dizer é que nunca existem regras fixas, mas sempre deve existir o bom senso.   Nenhum projeto é idêntico ao outro, e o gerente do projeto com a equipe devem buscar os melhores caminhos para seu sucesso.

Aproveite para ler os outros artigos relativos a escopo no blog.

O Gerenciamento de Portifólio de Projetos de uma organização envolve o uso de técnicas, processos e ferramentas para que seu conjunto de projetos sejam priorizados adequadamente, aproveitem da melhor forma os recursos disponíveis, e gerem os melhores resultados para os stakeholders.

O Peter Mello, da X.25 Treinamento e Consultoria, montou um fluxograma online que ilustra os processos recomendados pelo Project Management Institute.

Clique aqui ou na imagem a seguir para ver o fluxograma.

“Se alguma coisa pode dar errado, vai dar errado.”
- Lei de Murphy.

“Se alguma coisa é impossivel dar errado, mesmo assim vai dar errado.”
- Corolário de O’Malley à Lei de Murphy.

“Se alguma coisa pode dar errado, vai dar errado da pior maneira possível.”
- Lei de Sod.

“O volume de trabalho a ser feito sempre se expande de forma a ocupar todo o tempo disponível à sua conclusão.”
- Lei de Parkinson.

“Se houver 50% de chance de alguma coisa dar errado, dará errado em 90% dos casos.”
- Lei de Cole.

“Um projeto de dois anos levará três anos. Um projeto de três anos nunca será concluído.”
- Lei de Smith.

Murphy, O’Malley, Sod, Parkinson, Cole e Smith estão vivos e com saúde - trabalhando em seu projeto.

Alerta de Maquiavel aos Gerentes de Projeto
“Lembre-se que não existe nada mais difícil de fazer, mais perigosa de administrar, ou mais incerto em seu sucesso, que tomar a iniciativa na introdução de uma nova ordem de coisas. Porque o inovador tem como inimigos todos os que se deram bem debaixo das velhas condições, e defensores tépidos naqueles que podem se dar bem debaixo das novas.”

Lei de Woehlke
Nada será feito enquanto nada for feito. Os gerentes de projeto não conseguirão o pessoal de que precisam a menos que eles estejam sobrecarregados com horas extras, úlceras e esforços sobrehumanos. Só quando prazos são estourados é que a direção aprova o pessoal que, se estivesse disponível no início, teria permitido cumprir os prazos.

Lei de Cohn
Quanto mais tempo você gasta reportando o que você está fazendo, menos tempo você tem que fazer qualquer coisa. A estabilidade é alcançada quando você gastar todo seu tempo fazendo nada além de reportar o que você está fazendo.

As 7 Fases de um Projeto
1. Entusiasmo
2. Desilusão
3. Confusão
4. Pânico
5. Caçada aos culpados
6. Punição dos inocentes
7. Promoção dos não participantes

A Baseline Magazine publicou o resultado de uma pesquisa feita nos Estados Unidos com o objetivo de levantar as causas pelas quais um projeto “morre”.  Apesar da pesquisa ter sido realizada no exterior, e feita principalmente com profissionais de TI, acredito que é uma boa referência para qualquer projeto em qualquer segmento.  Os resultados foram:

30% por mudanças nas necessidades do negócio

23% porque o projeto não entregou o que era prometido

14% porque o projeto deixou de ser uma prioridade

13% devido a estouro do orçamento

7% porque não suportava a estratégia de negócios

4% por atrasos excessivos

O gerenciamento do risco deve levar em conta os diversos fatores que podem ter impactos positivos ou negativos no projeto, e esta pesquisa pode ajudar o gerente de projetos a ter em mente temas importantes durante a análise.

Um aspecto que achei interessante da pesquisa é que somente 40% das causas eram relativas a áreas de conhecimento “núcleo” de gerenciamento de projetos (2o item:  gerenciamento de escopo,   4o item:  gerenciamento de custos,  6o item:  gerenciamento de tempo).   Os demais 3 itens (1o, 3o e 5o) representam 51% do total e são relativos ao negócio em si.

Isto deve servir de alerta para o gerente de projetos.   Aqueles que ficam excessivamente focados no que acontece DENTRO do projeto podem deixar escapar fatores EXTERNOS que podem vir a influenciar significativamente o projeto.   Ter uma visão destes fatores externos (necessidade do negócio, prioridades da empresa e estratégia institucional) é uma capabilidade essencial para que se possa influenciar os acontecimentos e ajustar os rumos do projeto para que este sobreviva.