Projetizando a Vida

Estive muito tempo afastado do Blog, de início foi por pura falta de tempo, que é o que acontece quando um Gerente de Projeto assume muitos projetos,e todos juntos resolvem provar que Murphy era otimista, todos os riscos ocorrem, em todos os projetos, e você precisa correr atrás…

Não reclamo disso, pois esse é o Dia a Dia de um Gerente de projetos…

Contudo isso entrou nos eixos há pouco mais de um mês, e ai me apareceu  um dilema, Como retomar o blog, como torná-lo mais útil aos leitores e, obviamente, como torná-lo útil para mais pessoas (em outras palavras, como aumentar a visitação)?

Resolvi montar um Projeto Blog, e a primeira parte foi Planejamento,  sem esquecer o risco de precisar focar nos outros projetos, visto que preciso sobreviver… *Rs

Meu Objetivo com esse post é fazer um novo KICK-OFF do projeto blog, relançar o blog e, de início, tenho uma novidade: O Blog está devidamente TWITTADO… *RS

Você  poderá  agora me seguir e seguir o Blog pelo Twitter, basta entrar em : http://twitter.com/luizm

A Partir de agora, alem dos textos, o Projetizando a Vida fará mais resenhas, comentarei eventos, cursos e livros relacionados a Gerenciamento de Projetos, convido desde já os leitores a enviarem seus eventos, mas com um aviso: Farei um comentário isento, se não gostar, bom, você que pediu… *Rs

“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?

Aguardei  a  quarta versão com certa ansiedade, ainda não li com a seriedade e atenção que merece (isso quer dizer ler com calma, várias vezes cada capítulo), mas posso afirmar que tive uma primeira decepção…

Eu acho que uma das falhas do PMBOK na sua versão anterior  e que permanece  nessa nova é a falta de um tópico sobre Gerenciamento de  Crises.

Não sei exatamente qual o critério para a criação de uma Área de Conhecimento, mas deixo uma pergunta aos membros do PMI:  Será que não Gerência de Crises não seria uma área de Conhecimento a  ser incorporada numa versão futura do PMBOK?

Sei que muitos vão falar que projetos bem gerenciados não geram crises…

Para esses eu peço que me citem 10, ou melhor, 5, ou ainda 3, ta bom se for grande, me contento com 1 PROJETO que não tenha tido nenhuma crise…

Antes de qualquer coisa: O que é uma crise?

Crise é aquela situação onde as três variáveis (prazo, custo e escopo) são comprometidos e a qualidade nem se fala…

Algo precisa ser feito, mas ninguém chega a um consenso do que deve ser feito, normalmente troca-se o gerente,  muitas vezes troca-se a equipe e algumas vezes cancela-se o projeto, mas será que isso é mesmo necessário?

Infelizmente na maioria das vezes é,  porque o Bom Senso foi deixado de lado, é preciso mostrar que algo está sendo  feito,  e o mais visível é substituir algumas “peças”,  e torcer para as coisas darem certo…

E as vezes dão, mas na maioria das vezes se escuta do cliente: “mas o fulano tinha prometido isso e aquilo…”, e engole-se mais um aumento de escopo!!!

Nessa hora  é que faz falta o Gerenciamento de Crises…

É  hora de pisar no freio,  chamar o bom senso de volta à  mesa e ao invés de procurar encontrar os culpados, o que normalmente se faz, precisa-se procurar os erros e as causas dos erros, e trabalhar em conjunto para encontrar a melhor solução…

Quando se chega nesse momento o prejuízo já está consumado para todos, achar a solução é ais importante e mais inteligente que achar o culpado…

Infelizmente na maioria das vezes,  talvez pela  falta da Área de Conhecimento de Gerência de Crises, a crise só é resolvida pela troca do Gerente do Projeto, e mesmo assim somente se o Novo Gerente tiver o Bom Senso de ouvir todos os lados do problema de forma imparcial de forma a formar a sua própria visão do problema, e buscar uma solução que diminua o prejuízo, visto que nesse momento ele já é um fato consumado.

A inspiração para escrever esse Post veio de uma reunião que tive hoje pela manhã, quando estava assumindo um projeto com “alguns problemas” para terminá-lo da melhor forma possível. Quando fui apresentado a Gerente de Projetos do Cliente ela falou, com uma “leve” desconfiança :  “Você é o Novo Gerente de Projeto?”

Eu respondi:  Não, sou o Gerente de Crises…

Nesse momento senti que o Projeto começou a entrar nos eixos…

Infelizmente não sou Vidente, e como todo  Gerente de Projetos lamento profundamente isso, mas apesar disso, posso garantir que sei duas coisas  sobre o próximo projeto que vou assumir, embora não saiba qual será ele.

 E mais ainda, sei também duas coisas de Seu projeto atual e sobre seu próximo projeto, mesmo sem saber quais são eles, e nem mesmo sem saber quem é você… (e isso depois de dizer que não sou vidente!)

 Essas duas coisas são :

 1. O Escopo vai mudar

2. Alguma coisa vai dar errado…

 Pois é,  depois que parar de rir, pare e pense em todos os projetos que você já teve conhecimento, você vai ver que o escopo mudou, e alguma coisa deu errado.

 Chamo a isso de Verdades dos projetos, essas são duas verdades incontestáveis dos projetos, o Escopo muda, e algo dá errado …

 Mas se o escopo muda, porque que é que não acerta o escopo logo no início?  E porque não planeja melhor para evitar que as coisas dêem errado?

 A resposta é simples, é porque se você fizer isso vai gastar muito mais tempo no planejamento,  vai gastar muito mais esforço se precavendo contra problemas que não vão ocorrer, seu prazo e seu orçamento ficarão infinitamente maiores, e depois de tudo isso…

 Seu Escopo vai mudar mais uma vez, e alguma outra coisa vai dar errado…

 Afinal, essas são duas Verdades absolutas em Projetos.

 Quando falamos em Projetos estamos falando , por definição,  em algo que nunca foi feito antes,  pelo menos não EXATAMENTE daquela forma, afinal, “projetos são empreendimentos temporários que visam produzir um produto ÚNICO, a um custo pré-determinado”…

 São tantas variáveis envolvidas que é impossível controlar todas, por isso, algo vai dar errado, algum imprevisto vai forçar uma mudança de escopo, sem levar em conta o famoso Jaques… (já que esta fazendo isso…)

 Quando se fala em Projetos de TI então, temos um “complicômetro” a mais, é a nossa “matéria prima”…

 Se na engenharia a matéria prima é o cimento, o tijolo, o concreto, na Informática a “Matéria Prima” são as pessoas…

 Lidar com pessoas é uma das atividades mais difíceis de se aprender, ou você tem empatia ou não tem, ou o “santo bate” ou nada feito…

 Conheci um Gerente de Projetos, um dos Bons, que me dizia que o principal instrumento que ele usava era a Planilha de Riscos, pois com ela, ele conseguia controlar tudo, sem ela ele estava perdido…

 Um dia resolvi testar, e comecei a usar os meus “E SE…”

E SE o cliente mudar o escopo?

 Lá vai o Carlão, planilha de Risco, Item 5, Mudança de Escopo por parte do Cliente, Probabilidade Alta, Impacto Alto, Estratégia de Enfrentamento Triplo(Plano de aceitação ativa, Plano Mitigação e  Plano de Contingência): Plano de aceitação ativa- Incluir 5% de margem de segurança. Plano de Mitigação: Documentar Escopo Inicial e Negociações, Demonstrar alteração de Escopo ao Cliente e Renegociar.  Contingência: Estratégia de Compressão: FastTrack.

 E SE o programador fizer corpo mole?

 La vai o Carlão, Planilha de Risco, Item 9, Baixa Produtividade da Equipe pro Desmotivação…

 E assim por diante, peguei a Planilha de Risco dele e vi que tinha 95 riscos apontados, com as devidas estratégias de enfrentamento.

 Perguntei, quanto tempo ele “perdia” criando aquela planilha para cada projeto, ele respondeu: Perder? Nem um minuto… Investir? 1 dia…

 Antes que eu trucasse, ele falou, essa Planilha me acompanha há 10 anos, a cada projeto eu apenas ajusto as probabilidades e o impacto, eventualmente entra um ou outro, mas nunca sai nenhum, afinal, sempre tem escopo flexível, sempre tem custo apertado, cronograma inviável, profissionais insatisfeitos, etc., etc.

Projetos são empreendimentos únicos é  claro, mas o ser humano é sempre igual, e portanto, as empresas e o relacionamento entre elas são muito parecidos, assim como seus problemas, por isso, os riscos são sempre os mesmos, somente sua probabilidade e seu impacto é que mudam…

 E ele terminou com a frase sobre as verdades: Só sei duas coisas sobre meu próximo projeto: O Escopo vai Mudar e Alguma coisa vai dar errado. A única forma de conviver com isso é ter uma planilha de riscos muito bem montada.

 Logo depois dessa conversa montei a planilha do projeto que eu estava iniciando, apontei 22 riscos. Quando terminei o projeto ela tinha 35, Hoje ainda a carrego comigo, já tem 53.

 E Antes que alguém me peça a planilha, aviso que eu pedi a dele, e darei a mesma  resposta que ele me deu:  Mais importante que ter uma boa planilha de riscos, é construir uma planilha de riscos, construa a sua.

Voltarei a falar sobre Riscos em breve e criarei uma área de templates no Blog para deixar um modelo para quem quiser construir a sua, ok?

Alguns textos sobre riscos:

Por que ignoramos a gestão de riscos em nossos projetos? (GestaodeProjetos.net)

Analisando Riscos na Gerencia de Projetos (O Blog da Gerência de Projetos)

OBS: A Imagem acima é a capa do Livro Gerenciamento de Riscos em Projetos, da FGV, que recomendo a leitura e pdoe ser adquirido no Submarino, clicando aqui