Projetizando a Vida

Todo mundo que já gerenciou ou mesmo já participou de alguns projetos deve ter ouvido, ou até mesmo dito essa frase,d e maneira mais ou menos educada…

Existe uma estatística do PMI que diz que 80% dos projetos não terminam no prazo, com o custo estimado ou com as características prometidas, isso quando não acontece as 3 coisas, ou seja, em maior ou menos escala 80% dos projetos dão M….

Quando falo siso não estou falando de projetos públicos, que muitas vezes nascem já se sabendo que vai estourar a verba, nem de projetos gigantescos com inúmeras variáveis, falo de projetos no sentido mais amplo…

O PMBOK, as metodologia de gerenciamento e até este blog se propõe a auxiliar para que esse percentual de falhas.

Muita gente usa a palavra fracasso, eu não gosto de usá-la, pois fracasso é algo definitivo, já falha é algo corriqueiro e contornável, QUASE sempre é possível recolocar o projeto nos trilhos, e isso depende, fundamentalmente, do Gerente de Projetos.

Mas o que um Gerente de Projetos PODE e PRECISA fazer, quando um Projeto dá M…. ?

O Que PODE ser feito Depende de alguns fatores, como Bom Sendo, Domínio da situação, Autonomia e Coragem.

A Autonomia de um GP depende do tipo de organização em que ele trabalha, mesmo num projeto pessoal, como seu Projeto de Vida, existe uma organização envolvida, a Organização Familiar, um GP solteiro que não tem ninguém que dependa dele tem autonomia maior, ou quase total , já quando se tem dependentes, sejam esposa(o), filhos, pais ou agregados, a autonomia não é tão grande.

Domínio da situação também é fundamental, e nem sempre depende do GP, entra ai o Bom Sendo, para definir tudo isso.

E finalmente a Coragem, muitas vezes você precisa dar a cara pra bater, assumir o erro e isso nunca é fácil.

Agora, o que o Gerente de Projetos PRECISA fazer?

A Primeira atitude do Gerente de Projetos é identificar o problema, quanto antes o Problema for detectado, menos o custo para corrigi-lo.

A Primeira coisa é admitir para SI MESMO que alguma coisa está errada, e esse é um dos passos mais difíceis.

Identificado o problema é preciso avaliar o impacto no resultado final do projeto.

Avaliado o Impacto é preciso determinar os caminhos a seguir, normalmente existe mais do que um, se você só vê um caminho CUIDADO, se não existe decisão a ser tomada, provavelmente não é necessário um Gerente de Projetos…

Uma possibilidade que muita gente ignora é a de deixar rolar.

Determinadas as soluções possíveis, é preciso uma análise de Custo X Benefício: Qual é o custo (em termos de esforço, prazo, imagem, credibilidade, etc.) de cada uma delas, inclusive de deixar rolar.

Com essa análise feita entra a CORAGEM, ou seja escolher a melhor opção PARA O PROJETO, e na para o Gerente.

Resta agora replanejar tudo, e aqui é preciso cuidado. Um replanejamento em um projeto é normal, dois é aceitável, três é crítico…

Mas existe projetos com MUITOS replanejamentos, isso demonstra falta de planejamento, falta de Experiência, de bom Sendo ou de Coragem.

Existem projetos que não simplesmente não são possíveis de serem executados, é verdade, mas isso só demonstra falta de Bom Senso, deveria ser quebrado em atividades menores e cada uma ser tratada como um projeto a parte.

Quando falo em Coragem é a coragem de assumir que a nova data final é inatingível, o que via causar novo replanejamento, o que deve ser feito é pensar numa data REALISTA e defendê-la “até a morte”.

Um “detalhe” importante é determinar com muito cuidado as causas do problema, para evitar que os erros se repitam.

Mas vamos a um exemplo prático, uma M…. real!

Como falei no artigo sobre planejamento, 90% dos problemas de projeto se devem a erros de planejamento, e o erro mais comum é desprezarmos “fatores externos”…

Quando comecei meu projeto de escrever uma série de artigos sobre Grupo de Processos no PMBOK me comprometi com um cronograma de 2 artigos por semana, ignorando fatores externos como meu emprego que me consome 10 H/dia, meus outros blogs (Blog Profissional e Boteco Futebol), alguns clientes blogueiros e minha família…

Resultado: Cronograma comprometido. Precisei fazer na semana passada um primeiro Re-Planejamento, e sem avaliar corretamente o problema, me comprometi a “retirar o atraso”…

Na maioria dos projetos quando assumimos essa retirada de atraso, aproveita-se algo que já tem, com pequenas adaptações e deixa-se de fazer atividades “desnecessárias”, como testes e controle de qualidade (Alguem já viu isso acontecer?).

Resultado uma grande M…..!

Nesse caso aproveitei alguns artigos antigos e “cumpri o cronograma”, só que meu “controle de qualidade” deixou passar um detalhe, o artigo era baseado no PMBOK 2000 e não no PMBOK 2004 !!!!!

Resultado, novo replanejamento, dessa vez com maior cuidado, correção do problema (O Grupo planejamento foi re-escrito e o de Execução foi “retirado para revisão”).

Depois disso estabeleci um novo cronograma, agora levando em conta atividades “extra-projeto” e publicarei UM ARTIGO POR SEMANA dessa série, a começar pela revisão do Grupo de Execução que ocorrerá até sexta-feira.

Bom que isso sirva de exemplo a todos, mesmo Gerentes de Projeto com experiência costumam errar, principalmente em projetos onde o “Cliente” não é muito exigente…

Anote isso no seu caderninho de lições aprendidas, pois como falei no artigo sobre planejamento: Shits happen !!!