Ou seja, não importava que eu não tivesse experiência na construção de uma ponte, no planejamento de um casamento, ou na configuração de um servidor de banco de dados… eu estava no caminho para ser um gerente de projeto profissional, e isso significava que eu poderia controlar qualquer coisa (desde que eu seguisse as 5 fases do PMBOK e fizesse tudo o que as 11 áreas de conhecimento me disseram para fazer)!

Por algum tempo, esse foi o caso. Eu fiz questão que todos os meus projetos tivessem técnicos competentes que eram bons comunicadores de modo a proporcionar boas estimativas, identificar os riscos cedo e frequentemente, e gerenciar os detalhes das entregas. Eu era capaz de me concentrar na gestão no nível executivo, facilitando a resolução de problemas, e fornecer suporte administrativo ao projeto.

Mas então algo aconteceu – fui designado a um projeto no qual eu tinha um pouco de conhecimento técnico, mas não muito, e minha equipe tinha apenas nível intermediário. Eles eram fortes tecnicamente, mas eram relativamente inexperientes em trabalhar em um ambiente de projeto de grande porte. Na época, porém, eu não sabia disso e assumi que eles eram tão hábeis como qualquer outra equipe do projeto que eu tinha trabalhado no passado. Quando nos sentamos para planejar, eu usei o mesmo processo que com as minhas outras equipes de projeto; quando realizamos reuniões de status, eu usei o mesmo processo que com outras equipes de projeto; e quando identificados riscos, eu usei o mesmo processo que com outras equipes de projeto. No entanto, as atividades de desenvolvimento continuaram a estourar prazos, e minha indagação sobre o que deu errado com a equipe rendeu respostas como “não sabemos”.

Como resultado, eu usei meu conhecimento bastante limitado da área em questão para ajudar a tapar os buracos que eu vi. Quando indagado pelo patrocinador e pelos especialistas no tema, eu lhes dava respostas que eu acreditava ser verdade, sem consultar a equipe. Quando a equipe de operações de TI fez perguntas sobre a tecnologia, eu dei respostas que eu tinha ouvido no passado, sem consultar a equipe. E então as coisas começaram a dar muito errado. O cliente ficava perguntando à equipe sobre as coisas que eu havia dito, e eram informados de coisas opostas. A equipe do projeto me manteve afastado das discussões, e meu gerente de programa voltou para mim com o feedback de que eu estava prestes a ser demitido do meu projeto.

Nesse ponto, ter uma equipe que não era tão forte quanto minhas equipes anteriores não era o problema. Minhas suposições, e minha tomada de decisão isolada devido às frustrações e expectativas injustas em relação à equipe introduziram uma miríade de riscos aos entregáveis. Estes riscos tornaram-se quase imediatamente problemas quando eu comuniquei sem consultar a equipe. Eu era o problema. Eu era o maior risco ao escopo, cronograma e orçamento do projeto.

Então, o que eu deveria ter feito?

1. Não assuma que você sabe tudo

Mesmo eu tendo alguma experiência com a área técnica, e sendo um gerente de projeto bem experiente, eu não deveria ter assumido que eu sabia mais do que a equipe. Não há problema em dizer “eu não sei”, contanto que você prometa obter as respostas e acompanhar.

2. Considere os requisitos de sua equipe

Em vez de forçar a equipe por meio de processos que funcionaram bem para outras equipes, eu deveria ter considerado as suas necessidades e seu nível de experiência. Durante as fases de “formação” e “debate” de desenvolvimento da equipe, eu deveria ter feito perguntas ao invés de impor processos. Quando eu vi um processo que não deu certo, eu não deveria ter entrado de forma automatizada no modo de comando e controle; antes, eu deveria ter trabalhado com a equipe para reavaliar.

3. Reconheça que você não pode realizar uma tarefa impossível

Na condição de gerente de projeto, é o seu trabalho facilitar resultados bem sucedidos do projeto. A menos que você esteja executando explicitamente um papel específico em uma equipe de projeto, seus únicos verdadeiros resultados são os relatórios de status, comunicações e sessões facilitadas. Cabe à sua equipe entregar o conteúdo técnico. Se houver problemas de desempenho, converse com os membros da equipe (e, depois, com os gerentes deles se necessário). Se há preocupações com o escopo, fale com o seu patrocinador. Se há preocupações com os recursos, fale com o seu PMO. Não tente pegar o problema para si; tente facilitar a resolução.

No final, eu me concentrei muito no segundo e no terceiro e me esforcei com o primeiro até o encerramento do projeto. Depois de dar respostas por tanto tempo, foi difícil não o fazer. Quanto ao projeto em questão, depois de um reinício da linha de base, ele foi entregue dentro do escopo, cronograma e restrições orçamentárias.

Que tipo de oportunidades de aprendizagem através de projetos você teve? Como mais poderia um gerente de projeto ser o maior risco do projeto?

Autor: Jason H. Zalmanowitz,

Artigo publicado originalmente no site PM Hut