Projetizando a Vida

Oi Pessoal,

A Partir  do dia 10/05/2010 estarei ministrando 0 curso de  Gerenciamento de Projetos com as práticas do PMBOK 2008 na Stefanini Training, que fica em São Paulo na Avenida Angélica.

É um curso para Gerentes de Projeto Iniciantes que queiram conhecer(Ou conhecer mais sobre) o PMBOK.

O Curso tem 32 horas e será ministrado as Segundas/Quartas e Sextas. O Investimento para esse custo está com valor bastente  interessante é de apenas  R$  702,00.

Mais Informações e Inscrições através do Site da Stefanini Training

Todas as pessoas que se interessaram por Gerenciamento de Projetos já ouviu que entre 80 e 90% do tempo de um Gerente de Projetos é ” gasto”  como COMUNICAÇÃO.

O PMBOK em sua 4ª Edição(versão 2008) afirma, na página 338(versão em Português) que: ” A comunicação foi identificada como a maior razão de Sucesso ou Fracasso de um projeto.”

Apesar disso dentro da gigantesca bibliografia de gerenciamento de projeto é extremamente difícil encontrar bons livros falando sobre o assunto (confirmei isso recentemente, ao iniciar a orientação de uma aluna em seu TCC de Pós Graduação em Gestão de Projetos), mesmo o PMBOK, depois de afirmar a sua importância através da frase citada acima, dedica apenas 21 de suas 336 páginas ao Gerenciamento da Comunicação,  e vale ressaltar que isso significa um avanço em relação a versão 2003, que dedicava apenas 14 páginas…

O Grande problema que percebi em várias metodologias de desenvolvimento/gerenciamento com que trabalhei é que se confunde  documentação com comunicação.

Documentação é importante sim, para que todos saibam o que está acontecendo, para nivelar informações, para sinalizar o acompanhamento do projeto.

Dentro da área de conhecimento de Gerenciamento da Comunicação o PMBOK em sua  4ª Edição (2008) define 5 Processos:

1.       Identificar Partes Interessadas

2.       Planejar as Comunicações

3.       Reportar o Desempenho

4.       Gerenciar as Expectativas das Partes Interessadas

5.       Distribuir Informações

Em minha experiência de projetos, gerenciando e sendo gerenciado, pude perceber que os processos que recebem maior atenção são Reportar o Desempenho e Distribuir Informações, muito provavelmente porque esses elementos são, basicamente, processos de DOCUMENTAÇÃO.

Ouvi certa vez de um superintendente, em reunião para Gerentes de Projeto, a seguinte frase: ” Se falharmos na documentação do que ocorreu durante o projeto, ficamos sem defesa, nas mãos do cliente…”

Realmente isso é verdade, se não está documentado, não temos defesa, MAS…

Precisamos mesmo nos defender sempre?

Para mim essa metodologia devia se chamar COASS (Cover Our ASS!).

Essa frase parece afirmar que o projeto terá problemas, que o cliente ficará insatisfeito e que precisamos nos resguardar, fiquei com vontade de perguntar (mas não perguntei num de meus raros momentos de lucidez): Não seria melhor evitarmos q insatisfação do cliente? GERENCIARMOS SUAS EXPECTATIVAS, para que no final, pelo menos na maioria dos projetos, não ser necessária uma defesa?

Não estou dizendo que a documentação não é importante, apenas que existem outros processos tão (ou mais) importantes que a documentação.

O Grande problema é que documentar é fácil(chato e trabalhoso, mas fácil), basta ser metódico e organizado, atualizar um cronograma, escrever um report e disponibilizá-lo, fazer atas de reunião,  não existe um segredo para isso, um bom template e algumas explicações e qualquer Gerente Flanelinha (artigo O Gerente de Projetos e o Flanelinha) consegue realizar.

Já o Processo: GERENCIAR AS EXPECTATIVAS DAS PARTES INTERESSADAS é muito mais complicado, afinal é preciso primeiro saber quem  são as PARTES INTERESSADAS? quais são suas expectativas?  Elas são viáveis? Estão dentro do Escopo do Projeto?

Note que o verbo empregado é GERENCIAR e não ATENDER e muito menos SUPERAR.

Gerenciar expectativas exige uma atitude muito difícil, é preciso SE RELACIONAR com a parte interessada, é preciso saber negociar, influenciar e, raras vezes, impor limites.

E SE, e sempre tem um ” e se…”, com tudo isso, o cliente ainda tiver uma expectativa inviável, seja em termos de prazo, em termos de custo ou de escopo?

Infelizmente essa situação é mais comum do que o desejado, o Gerente de Projetos é alocado pela Organização Executora, que vendeu a um Cliente um projeto inviável, ou o Cliente solicitou um produto e na verdade deseja outro…

Esse é um caso clássico de CONFLITO DE EXPECTATIVAS, e é exatamente nesse contexto que o Gerenciamento das Expectativas é fundamental, as partes precisam saber que as expectativas são incompatíveis, é preciso negociar, tentar influenciar ou até mesmo impor limites, claro que tudo isso precisa ser DOCUMENTADO, mas se as expectativas forem gerenciadas, a Documentação pode sim funcionar como defesa, mas pelo menos nenhuma das partes interessadas poderá dizer que foi uma surpresa.

É mais complicado que simplesmente documentar? Sim, muito mais complicado…

Talvez por isso Gerentes de Projeto ganhem mais que Documentadores…

Pensando em projetos baseado nos relatórios de acompanhamento e no resultado final costumo afirmar que existem dois tipos de projetos:  os que dão certo  até dar errado e os que dão errado até  dar certo…

Quem não me conhece vai me achar pessimista, mas não é isso, essa é uma visão tremendamente otimista… *Rs

Todos que tem que já trabalharam em projetos sabem que o ambiente de projeto é um ambiente complexo, por mais simples que seja o projeto existem dezenas de variáveis para cada elemento, e fazer com que todas essas variáveis estejam sempre de acordo,  não é um trabalho simples…

Mas voltando ao meu primeiro parágrafo, vamos analisar o primeiro caso:

• 1. É aquele projeto onde tudo corre as mil maravilhas, mês a mês o percentual do projeto concluído evolui exatamente como o previsto, sem nenhuma ocorrência, nenhum dos riscos se confirma, não existe mudança de escopo, não existe atrasos em atividades intermediárias… O Mundo perfeito, até que o projeto chega nos seus 99% de conclusão…
  Nesse momento, alguma coisa acontece, talvez um encosto, inveja ou olho gordo de alguém, mas o projeto trava nesse 99%, e nada faz com que ele ande…
  Quando muito vai para 99,01, 99,02%…
  Então se descobre que o projeto não teve apoio do Sponsor, que o usuário mudou 5 vezes o escopo, que o fornecedor atrasou, que um dos profissionais alocados saiu da empresa e não foi possível substituí-lo, que alguém dimensionou errado, enfim, o projeto em que deu tudo certo, dá errado.
• 2. Vamos analisar o segundo tipo de projeto, já no primeiro relatório, o Gerente de Projetos aponta que o usuário quer mudar o escopo, atividades atrasam e ações precisam ser tomadas para recuperar o tempo perdido, o fornecedor atrasa, como demonstra os reports diários de atraso do GP. Os riscos ocorrem, surgem novos, novas ações de resposta aos riscos são definidas, enfim, nada dá certo, até que se aproxima a data de entrega do projeto e, MILAGROSAMENTE, o projeto acontece, e o projeto dá certo…

Sorte? Azar? Ou competência?

Costumo dizer que não sei qual será meu próximo projeto, mas sei de duas coisas: O Escopo vai mudar, e algo vai dar errado.

Isso não é pessimismo, não é fatalismo… Como dizia uma música dos anos 1970; ” Hope for the Best, but expecting dthe Worst…”  ( Esperando pelo melhor, mas se preparando para o Pior, numa tradução livre), esse deve sempre ser o comportamento do Gerente de Projeto, ao apontar desvios, que para muitos é um erro, ele força as ações que dirigem o projeto para o sucesso.

Já se nada é apontado, nada é feito, e no final…

Mas ai aparece aqueles que dizem, mas e se realmente nada acontecer e der certo no final?

Bom um projeto desses não precisaria de um Gerente de Projetos… E como não acredito em projetos sem Gerentes de Projeto, não consigo acreditar em projetos assim…

“Qual é a dificuldade de ser gerente de projeto? É só saber perguntar para quem vai executar a tarefa: ‘quando é que você acha que fica pronto?’ e anotar no project. E depois ficar cobrando: ‘Tá pronto? E agora tá pronto? E agora tá pronto?’ E se for o caso, reportar para o superior: ‘Chefe, olha aqui, o fulano falou que tal tarefa vai estar pronta dia tal’.

 Esse foi o comentário que Heinz, um leitor, deixou no comentário no Post “Oba! Quero ser gerente de projetos!“.

 Não consegui identificar o “tom” em que ele falou ISS, se foi Irônico ou se foi sério, se ele realmente pensa isso,  por esse motivo optei por respondê-lo através deste Post.

 Ser Gerente de Projetos é muito mais do que montar e cobrar cronograma, e mesmo essas atividades, não são tão simples como parecem.

 Montar um Cronograma é muito mais do que “colocar atividades no post”, ele começa antes, na identificação dessas atividades, baseado nos produtos a serem entregues, na estimativa de esforço e determinação das precedências entre elas. E durante a “cobrança” é preciso detectar atrasos antes que eles ocorram e pensar em alternativas como : esse atraso impacta a data final do Projeto? Como fazer para retirar esse atraso? Adianta eu colocar mais recursos para a tarefa X? E para a Tarefa Y?  

 Para responder essa e muitas outras perguntas (E por enquanto apenas falando em “cobrar cronograma”)  existem dezenas de técnicas e métodos não vou falar aqui em Caminho Crítico, Corrente Crítica, Fast Track ou Crushing, isso é tema para um post exclusivo, ou melhor são temas para vários Posts exclusivos.

 Gerenciar um projeto é muito mais do que “Tomar conta” da equipe e do Cronograma, é preciso planejar, acompanhar, comunicar, avaliar  riscos, dimensionar esforço, definir estratégias, e, acima de tudo, FAZER ESCOLHAS.

 O Que me deixou em dúvida se o Heinz foi irônico ou se acredita no que disse é que já vi muitos projetos sendo “gerenciados” dessa forma, normalmente esse tipo de “gerenciamento” faz com que o projeto ande bem durante muito tempo, até que o cronograma do project aponte que o projeto está 99% concluído, e não sai mais daí…

 É o que eu chamo de “síndrome dos 99%”,  os 99% são fáceis de atingir, agora, esse 1% final, que é normalmente “Fazer Funcionar”, é que complica, para esse 1% você precisa de um Gerente, os outros 99% pode ser feito por um Tomador de Conta…

 Eu até  imagino a cena, o cara chega, com uma Flanelinha na mão e diz:  “TIO, posso tomar conta do seu Projeto? Deixa ai 10 real pra nóis…”

 PS.JABÁ:   Para aqueles que ainda não são Gerentes de Projeto  e não querem se tornar apenas Flanelinha, estou lançando um curso pela Stefanini Training: “Formação em Gerenciamento de Projetos para Analista de Sistemas”, agora em maio/2009,  interessados deixem comentários ou enviem e-mails que mando o Conteúdo Programático, datas e etc. Ou Liguem para (11)2176.9800.

Para boa parte dos leigos , e infelizmente alguns “Gerentes de Projeto” (entre aspas mesmo), gerenciar os projetos é montar um cronograma no MS Project e acompanhar o percentual de execução do trabalho e, quando for preciso, acertar as datas…

Ah,  e também fazer atas de reunião, não deixando escapar nada, para ter todas as desculpas quando o projeto atrasar, o custo estourar ou quando o produto entregue não for o que o cliente queria…

Esses “Gerentes de Projeto” seguem a metodologia COASS (Cover Our ASS),  coisa extremamente importante de ser feita, diga-se de passagem,  porém gerenciar projetos não é apenas isso…

O Gerenciar Projetos começa no momento do planejamento, na criação de um cronograma possível e provável  de ser cumprido.

Para se criar um cronograma possível é preciso detalhar  o escopo a ser entregue, gerando a famosa EAP - Estrutura Analítica de Projeto, prefiro o nome em português ao invés do original em inglês (WBS - Work Breakdown Structure) porque ele reflete o que devemos fazer ANALISAR  a estrutura de nosso projeto, ou de nosso escopo, antes de definirmos o esforço necessário para implementá-lo.

Um  exemplo fácil, imagine um projeto de engenharia bem simples:  construir um lago de pesca numa chácara…

O Que deve ser feito?  Alugar uma retro-escavadeira, cavar o buraco, reforçar as paredes, encher de água e colocar os peixes…

Simples não é? Você  faz um cronograma, tudo certinho e quando começa a escavar, chega um fiscal e te pede o estudo de impacto ambiental, ou ainda te comunica que aquela área é uma área de manancial, portanto precisa de uma autorização especial, etc, etc …

Ao se fazer uma análise detalhada do escopo, essas limitações seriam detectadas, e as atividades de obter essas licenças seriam refletidas no projeto, evitando surpresas que fatalmente causarão atrasos significativos no cronograma e aumento de custos…

Portanto um cronograma possível deve ser precedido de um EAP (ou WBS), em outras palavras um  Cronograma possível é aquele onde as atividades apontadas  estão previstas e o prazo para cada uma delas é devidamente calculado.

Não adianta, no  exemplo do nosso lago,  prever  fazer o buraco em 1 dia, se a capacidade da minha retro-escavadeira exige 3, nem ao menos prever encher um lago de 5.000 m² de superfície em 2 dias, se a quantidade de água na minha região exige 1 mês…

Feito esse EAP e estimando com Bom Senso o esforço para cada atividade,  teremos um CRONOGRAMA POSSÍVEL,  mas será que é provável que o mesmo seja cumprido?

Com sinceridade, normalmente não.

Porque nesse cronograma não existe uma avaliação extremamente importante mas que a maioria dos “Gerentes de Projeto” não estão preparados para fazer:  A Análise de riscos.

A Análise de risco é a avaliação de tudo o que  pode acontecer para atrapalhar (ou ajudar)  o projeto (falarei sobre Análise de risco em maiores detalhes em outros artigos).

Para o G.P.  que trabalham em consultorias de TI esse problema é muito grande, pois na maioria das vezes o G.P.  só é designado depois do aceite da proposta, quando então já haverá um comprometimento de Escopo, Prazo e Custo.

Se tudo fosse como na matemática, onde 1 + 1 é sempre 2, as coisas até que seriam mais fáceis, mas na verdade você vai descobrir  que 1 + 1 pode ser 2, mas as vezes 2,1 e outras 1,8, se não for 5…

O Primeiro problema é o Escopo,  como em TI nenhum sistema é isolado, sempre existe o problema das interfaces, que precisam ser  construídas ou alteradas e não fazem parte do Escopo previamente definido, ou então uma informação fundamental não é gerada pelo sistema legado, e sem ela não da pra implementar o sistema. E Prepare-se, se você não fizer uma EAP muito bem feita, só vai descobrir isso às vésperas da implantação, e prepare-se para o Stress…

O Segundo Problema CUSTO:  fatalmente houve uma negociação dura, o Comercial cedeu bastante, mas isso é problema do G.P, que terá que reduzir seu custo, mesmo  que surpresas de escopo como uma nova Interface seja descoberta e você precisa desenvolver…

E finalmente o Cronograma…

É aqui que surgem problemas, alguém previu atividades de validação do cliente que demora um dia, e ele leva duas semanas…

Obviamente alguém vai dizer, mas isso é problema e custo do cliente….

TEORICAMENTE sim, mas, e as atividades que dependem daquela? Você segue em frente sem a validação para garantir o cronograma? Se a resposta for sim, e o cliente mudar algo, você terá retrabalho.   Se você espera e  o cliente não muda nada, você atrasou o cronograma (e pessoa parada custa o mesmo que pessoa trabalhando, ou seja, aumentou o custo).

E Ainda existe o problema de “Recursos Compartilhados”,  aquele DBA que precisa entrar apenas duas semanas, portanto você  vai aproveitar um recurso da empresa, mas exatamente naquela semana que você vai precisar dele, ele foi alocado em outro projeto, por 3 semanas,  ou aquele teu funcionário fundamental recebeu uma proposta de emprego com 50% de aumento, ou…

Alguém vai dizer: larga de ser pessimista,  assim você não consegue entregar nada…

É por isso que existe a análise de risco, tudo isso deve ser dimensionado e ter uma resposta para cada possibilidade, e então você cria um CRONOGRAMA PROVÁVEL…

Agora é que vem o problema, se você conseguisse fazer isso e o cliente (e o seu comercial) aceitasse, seria bem mais fácil…

Mas quem disse que ser Gerente de Projetos é fácil? (Além é claro aquele vendedor do curso de G.P.).

Provavelmente você será pressionado a comprimir esse cronograma, a antecipar a entrega, mas não deixe de montar o seu CRONOGRAMA PROVÁVEL, pois mesmo que  você entregue o CRONOGRAMA POSSÍVEL, também será pressionado a comprimi-lo.

A Boa notícia é que quase sempre é possível comprimir um cronograma, e o melhor de tudo é que quando o cliente te pressiona a comprimir o cronograma você consegue alguns compromissos  dele, como validar os “entregáveis” no prazo acordado, o que ajuda e muito…

Voltarei a falar  sobre cronogramas, principalmente sobre Técnicas de Compressão de Cronogramas.

Bons Projetos.

PS.  IMPORTANTÍSSIMO : Jamais chame seu cronograma de Cronograma Provável, ou mesmo Cronograma Possível, chame apenas de Cronograma, o resto fica entre nós… OK?